problems with specifying output order

[archenemies]

I submitted this issue to CUPS last week. At the time it seemed obvious to me that it was a CUPS issue, but Michael Sweet argues that it is a cups-filters issue and I wanted to make your project aware of it. I want to pass this off to someone else if I can.

apple/cups#5315

The gist of it is that I have an inkjet printer and I found it confusing that the pages come out in the wrong order. Not only does the default PPD not correctly reverse the pages, but the various ways of setting the output order (via the PPD, via lpadmin and via lpoptions) all seem to have different effects on documents printed by different applications. If you want to, you can play with this just using cups-pdf. If I modify the cups-pdf PPD with a 'DefaultOutputOrder: "reverse"' line, then according to my experiments this directive is honored by lp and Evince but not Okular. The lpoptions settings are honored by lp but not Evince or xpdf.

I am aware of one mistake in my original bug report, in a follow-up post I commented that 'lp' doesn't respect the 'lpadmin' setting but it does. This misunderstanding was due to my not figuring out the need to delete the 'lpoptions' setting with 'lpoptions -r', before repeating my experiments with lpadmin.

In case it helps, here are some issues I've identified while reading the documentation and trying to understand the behavior of CUPS.

• Relationship between lpadmin and lpoptions is not explained in respective manual pages

• User has no way to know that a GUI application like Evince or xpdf will ignore lpoptions but honor lpadmin settings. Should be fixed or documented.

• Okular fails to respect the "reverse" setting in the PPD. You have to manually check the "reverse" button each time. But xpdf, which has the same print dialog and also seems based on qt5, lacks this problem. I couldn't find any documentation of the correct behavior.

• User has no way to know the proper place to set a 'reverse' output order for a face-up printer. The fact that this belongs in the PPD should be documented somewhere other than message boards and mailing lists.

• Output order should be configurable at printer setup time, via the GUI on localhost:631

• Output order should be specified correctly in PPDs for inkjets and other face-ups

• lpoptions and lpadmin man pages should note the importance of removing settings (-r or -R respectively) to avoid overriding PPD settings. For example setting outputorder=normal is not the same as deleting the outputorder key; the former will still override the PPD setting.

• The 'lp' man page should make it clear that '-o outputorder=reverse' will only "print pages in reverse order" on face-down printers. It should also document the possibility of setting '-o outputorder=normal' (which will print pages in reverse order on face-up printers).

• In 'lp' man page, distinction should be made between options like "page-ranges" which work by filtering the document, and options like "outputorder" which work by overriding printer defaults. It's not obvious to users which kind of option outputorder is. Setting "outputorder=reverse" is not the same as checking the "reverse" box when printing from most GUI applications; the former will only print pages in reverse on face-down printers, while the latter will print them in reverse on any (correctly configured) printer.

• There should be a "filter"-type 'lp' option (see above) which correctly reverses pages on all printers. It could be named something like "page-order=reverse". This would function just like checking the "reverse" box in a GUI application like Evince or xpdf. It would be used by people who want to, say, print the even pages of a document in reverse order. Currently this cannot be done via the command-line in a printer-independent way.

• I can't figure out how to remove an outputorder setting using lpoptions "-r". The manual page should tell me what's happening here. Are we looking at the setting from lpadmin?

    $ lpoptions -dHP_Photosmart_Plus_B210a -r outputorder              
    $ lpoptions -dHP_Photosmart_Plus_B210a | tr ' ' '\n'| grep order
    outputorder=reverse
  

• How do I do the above experiment with 'lpadmin'? It seems to lack the feature to print all the settings. Are they in a file somewhere, can I view the file to look at which options are set? Let's add this feature, or update the lpadmin man page to point users to the file where all the key-value pairs can be viewed.

• lpadmin should give a warning when user tries to delete a non-existent key, e.g. if the user executes "lpadmin ... -R outputorder" instead of "lpadmin ... -R outputorder-default".

I'm not sure how many of these issues are within your purview. I've tried to do my part as a bug reporter but it seems to be requiring much more work than I had originally budgeted, partly owing to the fact that no one (including the leaders of my distribution, Arch) wants to formally admit the existence of a usability problem.

[tillkamppeter]

• Relationship between lpadmin and lpoptions is not explained in respective manual pages
  --> Report to CUPS upstream.

• User has no way to know that a GUI application like Evince or xpdf will ignore lpoptions but honor lpadmin settings. Should be fixed or documented.
  --> Bug of GUI applications and print dialogs. All of them should behave the same. An approach to fix this are the Common Print Dialog Backends from OpenPrinting (projects cpdb-libs, and cpdb-backend-cups) on this OpenPrinting GitHub. These will make all print dialogs use the same code to access CUPS, so represent CUPS queues and settings in the same way.

• Okular fails to respect the "reverse" setting in the PPD. You have to manually check the "reverse" button each time. But xpdf, which has the same print dialog and also seems based on qt5, lacks this problem. I couldn't find any documentation of the correct behavior.
  --> See previous point.

• User has no way to know the proper place to set a 'reverse' output order for a face-up printer. The fact that this belongs in the PPD should be documented somewhere other than message boards and mailing lists.
  --> Needs to be mentioned in CUPS documentation, report to CUPS
  --> We need to check (and CUPS too) whether PPD auto-generator handles Face-up and reverse order correctly in generated PPD files.

• Output order should be configurable at printer setup time, via the GUI on localhost:631
  --> Report to CUPS.

• Output order should be specified correctly in PPDs for inkjets and other face-ups
  --> See above, PPD auto-generators need to be checked.

• lpoptions and lpadmin man pages should note the importance of removing settings (-r or -R respectively) to avoid overriding PPD settings. For example setting outputorder=normal is not the same as deleting the outputorder key; the former will still override the PPD setting.
  --> CUPS documentation issue, report to CUPS.

The 'lp' man page should make it clear that '-o outputorder=reverse' will only "print pages in reverse order" on face-down printers. It should also document the possibility of setting '-o outputorder=normal' (which will print pages in reverse order on face-up printers).
--> CUPS documentation issue, report to CUPS.

• In 'lp' man page, distinction should be made between options like "page-ranges" which work by filtering the document, and options like "outputorder" which work by overriding printer defaults. It's not obvious to users which kind of option outputorder is. Setting "outputorder=reverse" is not the same as checking the "reverse" box when printing from most GUI applications; the former will only print pages in reverse on face-down printers, while the latter will print them in reverse on any (correctly configured) printer.
  --> CUPS documentation issue, report to CUPS.

• There should be a "filter"-type 'lp' option (see above) which correctly reverses pages on all printers. It could be named something like "page-order=reverse". This would function just like checking the "reverse" box in a GUI application like Evince or xpdf. It would be used by people who want to, say, print the even pages of a document in reverse order. Currently this cannot be done via the command-line in a printer-independent way.
  --> Needs to be checked what pdftopdf is actually doing, for GUIs see above, for possible bugs in man pages report to CUPS.

• I can't figure out how to remove an outputorder setting using lpoptions "-r". The manual page should tell me what's happening here. Are we looking at the setting from lpadmin?

  $ lpoptions -dHP_Photosmart_Plus_B210a -r outputorder              
  $ lpoptions -dHP_Photosmart_Plus_B210a | tr ' ' '\n'| grep order
  outputorder=reverse

--> Looks like a bug in lpoptions. According to the man page you did it correctly. Report this to CUPS.

• How do I do the above experiment with 'lpadmin'? It seems to lack the feature to print all the settings. Are they in a file somewhere, can I view the file to look at which options are set? Let's add this feature, or update the lpadmin man page to point users to the file where all the key-value pairs can be viewed.
  --> lpadmin puts settings into /etc/cups/printers.conf. Note that CUPS does not update this file in real time. Do killall -HUP cupsd to get the file updated. Do not edit the file while the CUPS daemon is running.

• lpadmin should give a warning when user tries to delete a non-existent key, e.g. if the user executes "lpadmin ... -R outputorder" instead of "lpadmin ... -R outputorder-default".
  --> Post a feature request in CUPS.

[tillkamppeter]

I have checked the situation in cups-filters.
With all PPDs available in Linux distributions (like Ubuntu) pdftopdf is correctly determining the correct output order from the PPD file, checking *DefaultOutputOrder: ..., in case of an OutputOrder option being present, its setting, and in case of an OutputBin option accompanied by *PageStackOrder keywords being present in the PPD, the order given by the *PageStackOrder line for the chosen output bin.
A problem here is that none of the manufacturer supplied PPDs for high-end printers with several output bins have *PageStackOrder entries. Also *DefaultOutputOrder: ... are often missing.
pdftopdf obeys user changes of the output order if they get supplied via OutputOrder or page-delivery option, not via output-order.
--> output-order needs to get added.
If pdftopdf finds an OutputOrder option in a PPD file it assumes that the reversing of the output order can be done by the printer when it receives a certain PostScript command. pdftopdf then sets a bit that reversing the page order should be done by the printer device and does not reverse by itself, but it does not do anything to actually make the printer device reversing the order.
--> Like it is already implemented for hardware copies and collate, pdftopdf also needs to communicate to pdftops if hardware reversing is needed.
I have now committed a patch to the PPD generator (of cups-filters) to generate *DefaultOutputOrder: ... entries for the PPDs for driverless printers. With this driverless printers with a single output bin or with the default bin selected should output in the correct order when using current pdftopdf. This covers most inkjet printers and also laser printers with a single output tray.
Not covered yet (but I will fix it soon):

• Driverless printers with multiple output trays, non-default tray selected: For this I will let the PPD generator add *PageStackOrder lines.
• PostScript printers with OutputOrder option: This is extremely rare (no such PPD in Ubuntu). I am thinking about letting pdftopdf simply always do the reversing, also with these printers.
• User requests reversing the page order via output-order=reverse: I will add the output-order option to be understood by pdftopdf.

All changes on the PPD generator I will also report to CUPS, so that they apply them to their PPD generator, too.
I cannot do anything about manufacturer-supplied PPDs with insufficient information (Missing *DefaultOutputOrder: ... or *PageStackOrder lines), but most high-end printers always stack correctly so that no external reversing is needed.
I also cannot do anything about GUIs as long as the CPDB project is not yet adopted by them.

[tillkamppeter]

I have added *PageStackOrder lines to the OutputBin option of the generated PPDs for driverless printers now, so that for each output bin it is marked whether it needs reverse output or not.

[tillkamppeter]

Now I have also committed my suggested modifications on pdftopdf: also support reversing via output-order option (settings: normal, reverse) and always do the reversing by software, ignoring support for hardware-reversing on PostScript printers.
Now all my ideas of improving reverse output order for face-up output bins are implemented in cups-filters. Please report the issues I have suggested to report to CUPS and please tell also if you think cups-filters needs any other change.

[tillkamppeter]

I have now posted a pull request for CUPS:
apple/cups#5345
It contains all the changes which I did on the PPD generator of cups-filters, to be apllied to the PPD generator of CUPS.

[tillkamppeter]

I had a look into your original report to CUPS now. You posted a sample PPD and also mentioned the line you inserted:

*DefaultOutputOrder: "reverse"

According to the PPD specs it has to be without quotes:

*DefaultOutputOrder: Reverse

This most probably made pdftopdf not recognizing it.

[archenemies]

@tillkamppeter Thanks for your hard work.

The PPD spec is here? I think I see what you are talking about on p. 124. It seemed like the version with quotes was able to change the behavior of my printer under CUPS so I'm not sure where the difference lies, I don't have time to check it again. Maybe we should post something to the linuxquestions.org thread, if it actually matters, because that's what I found upon Googling and others are likely to stumble upon it as well.

Would you expect your changes to have affected the Okular issues or should I retest and submit something to them?

Did anyone fix the documentation problems with the lpadmin and lpoptions man pages not explaining their mutual roles and effects viz overriding? That lack of documentation was a major problem for me when I was investigating this issue.

I'm also curious because I didn't understand what you meant by giving output-order a software-only effect. In the past the command-line output-order option overrided the output order specified by PPD and lpoptions defaults. Is that still the case?

I'm sorry I don't have time to re-report the CUPS issues I already reported, or to submit patches, particularly as Michael Sweet isn't willing to acknowledge that anything needs to be fixed. I'm glad that you were able to acknowledge these issues. I hope that my notifying maintainers of problems is helpful in and of itself, and doesn't necessarily commit me to additional work.

[tillkamppeter]

Is your problem now solved? Can I close this issue?

[archenemies]

The pages now come out of my inkjet in the correct order, thank you for your work.

There were a lot of other items in my list, but I think it is reasonable to close this issue, since someone can submit new issues for them if they run across the same problems.

[tillkamppeter]

OK, the other issues seem partially to be CUPS issues and not cups-filters and with the title of this issue we can assume that we wanted to solve the problem with page-order here and this got actually solved. Thank you very much for your report and cooperation.