Print/Properties/Landscape sends nolandscape to CUPS

[brian_p]

The datails are in Debian bug #829579:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829579

Cheers,

Brian

[Adam Reichold (adamreichold)]

Hello Brian,

thank you for taking the time to report this. I could not immediately reproduce this problem running Arch Linux with Qt 5.7 and CUPS 2.1.4, i.e. when I select "Portrait", then "nolandscape" is part of the CUPS options and when I select "Landscape" then "landscape" is part of the CUPS options. Can you please provide the complete "argv[5]" for jobs submitted with "Portrait" and "Landscape" selected? Also the exact versions of Qt and CUPS used would probably be helpful. Thanks.

Best regards, Adam.

[brian_p (claremont102)]

CUPS is is the same as yours and Qt is probably 5.6. However, I followed in your footsteps on Arch and it is exactly as you say. I also found Debian stable and testing were the same. I'll look more closely at my Debian unstable installation and persue it through the Debian report. Meanwhile, you can discard this bug report if you wish. Look upon it as user error. :)

BTW, my interst in qpdfview (thank you for developing it) was aroused because it uses CUPS directly without modifying the file it sends. That is why I was a little surprised by what I observed.

Cheers,

Brian.

[Adam Reichold (adamreichold)]

Marked as invalid as suggested by the original reporter.

[brian_p (claremont102)]

Hello Adam,

I can now reproduce the issue I observed on Debian unstable on my Arch Linux install. The two were not identical set ups because the Arch one was not running cups-browsed. Starting it gives similar results to the following, which was performed on Debian unstable.

1. Set up a single print queue on a client:

   lpadmin -p qpdfview-test -v file:/dev/null -E -m drv:///sample.drv/generic.ppd.

2. Shared printers on the server. On the client 'lpstat -a' gives

   Colour accepting requests since Fri Jul 09 13:12:53 2016
   ggg accepting accepting requests since Fri Jul 09 13:12:53 2016
   LaserJet-300 accepting requests since Fri Jul 09 13:12:53 2016
   qpdfview-test accepting requests since Fri Jul 09 13:12:53 2016
   test1 accepting requests since Fri Jul 09 13:12:53 2016

3. Printed a PDF from qpdfview using the qpdfview-test queue after changing the selection from "Portrait" to "Landscape". The error_log shows:

   D [09/Jul/2016:13:13:11 +0100] [Job 118] argv[5]="noCollate ColorModel=Gray
   finishings=3 nofit-to-page job-billing= nolandscape number-up=1
   number-up-layout=lrtb outputorder=normal page-ranges=1-19
   sides=one-sided job-uuid=urn:uuid:b3ddf304-d5e8-3cf1-4276-9dbaa0d149bd
   job-originating-host-name=localhost date-time-at-creation=
   date-time-at-processing= time-at-creation=1468066391
   time-at-processing=1468066391 document-name-supplied=qpdfview.Hf2034 Duplex=None"

   Observed that going back to print again shows "Portrait" selected. I thought the previously selected option was supposed to stick.

If the orientation comes up as "Landscape" and "Portrait" is selected argv[5] shows "landscape" as being sent to CUPS.

4. Deleted qpdfview-test and set up aqpdfview-test to put it top of the print dialog. Printed to aqpdfview-test with the "Landscape" option. argv[5] show "landscape" and the setting sticks in the print dialog.

5. Unshared printers on the server. Things are fine now and the chosen setting sticks in the print dialog.

6. Set up a new CUPS server with five queues on another machine and repeated, obtaining the same outcome as above.

I have no further ideas on testing and cannot even begin to advance a reason for this behaviour. Apart from my Debian setup being defective, of course.

Cheers,

Brian.

[brian_p (claremont102)]

Where are we going with this report? Considering I could not originally replicate on Arch it seemed sensible to close it. Now I can reproduce it. Doesn't that merit some sort of reassessment, even if it is to tell me it is my setup or the fault of another package?

At the moment I do not even know where to look. I'm not after help with a problem but if there is no way technically that qpdfview in itself could behave like this I could put it out of my mind.

Cheers,

Brian.

[Adam Reichold (adamreichold)]

Hello Brian,

please be patient, I did not have time to look into this. My suspicion is that the problem is between CUPS and Qt's print dialog, but suspicions do not make a useful bug report for either of these projects. From what you describe, I find it unlikely that this behavior is rooted in qpdfview specifically since it does not realize that part of the printing dialog but just passes on the options to CUPS. Of course, since we do touch those options, it is still possible that we somehow manage to mess them up.

As a next step, I would try to reproduce your setup to some extent and then begin debugging to try to understand what CUPS options pass through the application and to the print server. But a simpler option to just try to find out whether this is rooted in qpdfview or a more general problem with Qt or CUPS, would be to use a different Qt5-based application and see if it shows similar behavior.

In any case, we can make the bug report as new again.

Best regards, Adam.

[brian_p (claremont102)]

Hello Adam,

I have just taken a look at the Debian bug I reported and, as far as I can see, it is fixed. A CUPS error_log shows landscape being sent when chosen in the dialog. If you close the bug here I think it closes the Debian one; please feel free to do it.

Thank you for your considerations.

Cheers,

Brian.

[brian_p (claremont102)]

Forgot to mention: I tested with 0.4.17~beta1+git20180709-1.

--
Brian.