Bug: printing only "odd pages" does print "even pages"

> So does this mean, bugs will no more be fixed? Or does this mean there were no bugs during the latest 6 years?

It means that you looked at some random GitHub repository which contains an old version of the source code instead of the actual upstream repository at [1].

> Note: If you choose in point 4. "pages" 4-8, then it will print the pages as expected.

The best way to figure this out would be to enable CUPS debug or job logging - e.g. [2] - to understand the job parameters that resulted from both variants.

[1] https://code.launchpad.net/~adamreichold/qpdfview/trunk

[2] https://fedoraproject.org/wiki/How_to_debug_printing_problems#CUPS_logging

Hello,

Thank you for taking up the issue.

I think, it's Job 201:
https://filehorst.de/d/dFvjDHaI

Are you able to reproduce this?

The options passed to CUPS for job 201 look correct to be correct:

Collate finishings=3 fit-to-page Ink=COLOR job-billing= nolandscape number-up=1 number-up-layout=lrtb outputorder=normal page-ranges=4-8 page-set=even pdftops-renderer=pdftocairo sides=one-sided job-uuid=urn:uuid:75fb02cc-6a9e-3b8a-6ae8-39ae5160387f job-originating-host-name=localhost date-time-at-creation= date-time-at-processing= time-at-creation=1605890386 time-at-processing=1605890386 document-name-supplied=qpdfview.fbsjjc.pdf

I'd suggest trying to print the file directly via the command line using similar options to determine if the problem is some other option or within the CUPS filter stack, e.g.

lp -o page-ranges=4-8 -o page-set=even qpdfview.fbsjjc.pdf

The job logs for the difference between choosing pages from 4 to 8 and pages 4-8 would interesting as these should yield exactly the same CUPS options when number-up printing is disabled.

Thank you.

1)
Quote: " I'd suggest trying to print the file directly via the command line using similar options to determine if the problem is some other option or within the CUPS filter stack, e.g.

lp -o page-ranges=4-8 -o page-set=even qpdfview.fbsjjc.pdf"

->
I have tried this in a terminal:
lp -o page-ranges=4-8 -o page-set=odd qpdfview.fbsjjc.pdf (-------> odd)
-> Result: Works as expected.

2)
Quote: "The options passed to CUPS for job 201 look correct to be correct:

Collate finishings=3 fit-to-page Ink=COLOR job-billing= nolandscape number-up=1 number-up-layout=lrtb outputorder=normal page-ranges=4-8 page-set=even"

->
OK. I assume that you have caught the phrase "...b outputorder=normal page-ranges=4-8 page-set=even"
..." from my log file?
So there is really "page-set=even" in my log-file? But I selected "odd" in the GUI! See Point 5) in my post 1.

3)
Have you followed my steps from Post 1 in your system with your qpdfview installation. If yes: What was your result?

I was assuming that this job was referring to your "edit" which makes it easy to mix things up. But as I said, I think the most helpful thing would be to have CUPS logs for both ways to use the print dialog to be able to compare the options sent in both scenarios.

And no, I did not try to reproduce this because frankly, this interaction has not been of the kind that spurs me into action. For example, trying to reproduce it will only make sense if I know which version of the application you are using and in which environment. (One likely explanation is an old version of qpdfview combined with a new version of Qt which significantly changed its print dialog which then required changes in qpdfview to adapt.)

I think this is actually Qt's print dialog working in a somewhat surprising way: It seems to adjust the selected page set to the given page range, i.e. from 4 to 8 with odd pages will make the print dialog itself set page-set=even, I guess because the odd pages of that subrange are even. Selecting 5 to 9 with odd pages makes the print dialog set page-set=odd as the odd pages of a subrange starting at an odd page are the odd pages overall.

The page set is one of CUPS options that qpdfview does not touch when used with recent Qt versions and hence this admittedly puzzling behavior is out of scope for qpdfview.

>Quote: "For example, trying to reproduce it will only make sense if I know which version of the application you are using and in which environment."

Sorry. Of course.
MX Linux 19.3 (Debian 10 based)
Xfce 4.14.2
qpdfview 0.4.18
Here you will find all QT packages with "versions" I have installed:
https://www.bilder-upload.eu/bild-7955c1-1605960457.png.html

Thank you.

Concerning QT version:

Maybe you mean this:
libqt5core5a: My version: 5.11.3+dfsg1-1+deb10u4

Concerning QT version:

Or maybe you need this list?:
https://www.bilder-upload.eu/bild-f711ef-1605964215.png.html

As written above, I did debug it and it is a deliberate change to how Qt's print dialog works: If page from/to fields are used to select a range that starts at an even page, Qt's print dialog will change the page set from even/odd to odd/even, presumably as the even/odd pages "of that range" are then odd/even pages of the whole document. If the selected range starts at an odd page, nothing is modified.

Since this is a deliberate change to how Qt's print dialog works, there is nothing I can do about it in qpdfview. An easy workaround seems to be to specify the page range using the textual input instead of the numeric fields.

P.S.: This also implies that this will affect any application which relies on Qt's built-in print dialog, not just qpdfview.

OK. But then I do not understand why Qt's print dialog will not change the page set from even/odd to odd/even, when we use the textual input instead of the numeric fields. (?)

I can only speculate, but presumably because they do not parse that specification and more importantly because it is impossible to do so in the general case, e.g. what to do for "2-4,7-9" which contains ranges starting at an even and an odd page? I would argue that it would have more consistent to just never do this, but the designers of the print dialog seem to have decided otherwise.

Thank you.

Featherpad is a QT text editor.

I have now tried out the same in Featherpad.

Result: Featherpad does not change the page set from even/odd to odd/even when selecting 4 to 8 with odd pages.

I did not debug Featherpad nor do I know how it works. What I do know as that before qpdfview even starts looking at the print options, the above logic of Qt's print dialog is applied.

The reason for this is that FeatherPad implements by calling into Qt's QPlainTextEdit::print(QPrinter*) which will output only the requested page range and send that to CUPS, so the change makes sense there. (In the case of page ranges being specified, I guess this will render all pages and just pass on the page range.) qpdfview sends the whole file to CUPS along with restricted page range in all cases because we would have to extract parts of the PDF otherwise.

Tested with: Featherpad version 0.16.0
https://github.com/tsujan/FeatherPad

Note: Post #16 was my answer to your quote "P.S.: This also implies that this will affect any application which relies on Qt's built-in print dialog, not just qpdfview." from Post #11.

Sorry cross-posting.

I have pushed code to qpdfview's trunk which will now second guess the print dialog and tries to undo that transform when figuring out the CUPS options. Please do not try this with number-up printing as it will almost surely be wrong. This should be available via the dailydebs [1] soon or you can build from source [2].

[1] https://code.launchpad.net/~adamreichold/+archive/ubuntu/qpdfview-dailydeb

[2] https://code.launchpad.net/~adamreichold/qpdfview/trunk

Thank you. I appreciate your effort. :-)

What do you mean with "Please do not try this with number-up printing as it will almost surely be wrong. "
What is "number-up" printing? Can you make an example?

> What is "number-up" printing? Can you make an example?

It means printing more than one logical page onto a single physical page, e.g. pages 1 and 2 of your document will be printed together on one side of the first sheet of paper. (In contrast to duplex printing which uses both sides of each sheet.)

This requires us to transform the given page range backwards as well and I have not tried to work out if combining both works hence I am pretty sure it does not.

Maybe you are interested in some background information:

How did I run into this problem? Here is the answer: I have an HP ink printer that I use with HPLIP. I would just like to print on both sides. The back side and the front side of the paper. This safes money, place and is more environment friendly. My printer supports automatic page rotation. HPLIP also supports this basically. However, HPLIP unfortunately does not pause before pulling back and turning the page. This causes the ink to smear. Since nobody in the HPLIP forum was able to help me, I looked for a workaround.

This workaround would theoretically work in the following way:
I use the one-sided print mode.
In the first run the even (or odd) pages should be printed. Then I remove the sheets manually and put them back into the printer again. Then I do the second print run. This time I want to print the odd (or even) pages.
Concretely it should always work according to these rules:
1st print run "reverse"
2nd print run "normal
To find out, whether the even pages or the odd ones need to be printed in the first print run, simply add one to the first page that should be printed.
Example: You want to print pages 4-8:
You add one to 4. This is 5. As 5 is odd, you have to print the odd pages in the first print run.

When I wanted to test it in reality, I came across the problem described in Post #1. So it's a pity: Also the workaround seems to be full of problems and surprises. :-(

Hello,

>Quote: "I have pushed code to qpdfview's trunk which will now second guess the print dialog and tries to undo that transform when figuring out the CUPS options. Please do not try this with number-up printing as it will almost surely be wrong. This should be available via the dailydebs [1] soon or you can build from source [2].

[1] https://code.launchpad.net/~adamreichold/+archive/ubuntu/qpdfview-dailydeb
[2] https://code.launchpad.net/~adamreichold/qpdfview/trunk"

Will this also solve the empty page issue?

When does it print an empty unexpected page?
Answer:
A) pages 4 to 8 odd normal
B) pages 4 to 8 odd reversed
C) pages 4 - 8 even normal
D) pages 4 - 8 even reversed

Thank you.

I do not know, but using the dailydebs you should be able to just try it yourself using the current code from trunk. I would also suggest trying whether using the "lp" command directly produces different results for these ranges.

>Quote: "I do not know, but using the dailydebs you should be able to just try it yourself using the current code from trunk."

I have tried to do this with your instructions on
https://code.launchpad.net/~adamreichold/+archive/ubuntu/qpdfview-dailydeb

First try with terminal:
$ sudo add-apt-repository ppa:adamreichold/qpdfview-dailydeb
[sudo] Password for user:
sudo: add-apt-repository: Command not found

Second try with Synaptics:
Message:
The driver for method /usr/lib/apt/methods/ppa could not be found Is the package apt-transport-ppa installed? failure to get ppa://adamreichold/qpdfview-dailydeb/dists/stable/InRelease Some index files could not be downloaded. They were ignored or old ones were used in their place.

My system is not Ubuntu, it's MX Linux (Debain)

So it seems, that I have to wait until it is available in my package manager.

(I also do not have qpdfview in "MX Test repository" and not in "Debian Backports".
In "stable repository" I have version 0.4.18-1)

(I am just a simple Linux user. Not very skilled.)