https://bugs.kde.org/show_bug.cgi?id=398442
--- Comment #9 from Frederick Eaton <frede...@ofb.net> --- Thanks Michael for clarifying that you can reproduce the bug. > In the end, the processing is done by CUPS (or the CUPS filters > involved) according to the "outputorder" CUPS option. Okular does > not reverse the pages itself, only passes the respective option to > CUPS according to whether the checkbox is ticked or not. I figured this out already, and I think this is the wrong way to do it. It makes sense for "Duplex"; not for "Reverse". Please take a minute to look at the Evince print dialog. There is an area for specifying page ranges, number of copies, and page reversal. As you can see from this 2006 commit, Evince implements page reversal by sending pages to the spooler in reverse order: https://gitlab.gnome.org/GNOME/evince/commit/e15ce77fdce11d47bc92a209efb013c008d502d5 In the GTK dialog there is also a separate "Page Setup" tab which has options for stuff like "Output tray" as well as "Two-sided" and ... "Page ordering"! In other words, Evince and other GTK apps let you configure output-order separately from the main "Reverse" option. The "Output tray", "Two-sided", "Page ordering", etc. are CUPS/lp options, and the dialog takes their defaults from ~/.cups/lpoptions, if they exist there, but the dialog (which is probably a bug...) ignores the defaults specified in OpenUI blocks in the PPD: *%=== Duplex ================================ *OpenUI *Duplex: PickOne *OrderDependency: 25 AnySetup *Duplex *DefaultDuplex: DuplexTumble *Duplex DuplexTumble: " " *Duplex DuplexNoTumble: " " *Duplex None: " " *CloseUI: *Duplex When I tested it, Okular ignores both sources of defaults (PPD and lpoptions), although it does correctly recognize that a non-duplex printer should have the duplex radio buttons disabled. (By the way, if I owned a duplex printer, how would I tell Okular to turn on duplexing by default? With GTK I have to specify this with 'lpoptions', how do KDE users do it?) Rather than putting the page ordering under the "Options" tab with "Duplex Printing", like GTK does, Okular/KDE calls it "Reverse" and puts it in a "Copies" tab together with stuff like "Print range" and number of copies. These are all things which can be configured at the client side of the print-stream, as a filtering or pre-processing step, unlike options such as "Duplex", resolution, quality, etc. It would be confusing to give one of them a printer-dependent default. Since 'lp' also allows you to select the page range for a document, number of copies, etc., I thought it would make sense for CUPS to add a "page-order" lp option to supplement the "output-order" lp option. The "output-order" would control the temporal ordering of the pages - which comes out of the printer first - while "page-order" would control the order of the pages within the finished document, via a filtering/preprocessing step just like "page-ranges" - for those rare cases where someone wants a document with the pages actually reversed. This would make your life easier, but I doubt that Apple is willing to add new features to CUPS to make life easier for Linux programmers, particularly as I am not actually able to think of a strong case where someone would want to print a document with pages going backwards. Maybe one solution you could consider is just removing the "Reverse" option from the dialog and the software. This would fix your software for the 70% of people who use inkjets [*], at the expense of the (hypothetical) <0.1% of people who read documents in reverse. But I guess you'd have to implement that change in Qt/KDE since the dialog comes from there. Or you could just ignore the dialog's "Reverse" setting, while leaving the checkbox there to potentially confuse the 0.1%. [*] http://news.printcountry.com/2010/04/inkjet-vs-laser-printer-market-share-and-statistics.html Anyway, your proposal requires querying CUPS to find the default page-order setting in the PPD and in printers.conf/lpadmin. Given that neither Okular nor Evince know how to correctly query the default "duplex" setting from the PPD, and given that Duplex has an OpenUI/CloseUI block in the PPD while there is nothing like this for the output-order setting (at least not in the default PPD I got from cups-filters), I think you will run into technical obstacles. And given that the Okular devs have been seemingly oblivious to the fact that inkjet printers output pages in a different order than laserjets for - what, over a decade? - I'm doubting your logic that end users would magically have this fact at the top of their minds when they open a print dialog and see the "reverse" box checked! I think most people would just be confused by this. They would think that it is a directive to control the client side of the print stream, as it does in GTK apps (Evince, Firefox, et al), and probably Apple and Microsoft products too. And they would uncheck it, and find the pages coming out backwards, wonder why, and manually rearrange them. The next time they try to print, they'd see that "reverse" is checked, remember the act of rearranging the previous printout, growl and uncheck it, and ... eventually switch to using other software. That's how I imagine it, maybe we can do an experiment with some users. Just FYI, I use Okular because at one point it was much faster and more responsive than Evince, when rendering the huge documents I download from Google Books. That's what brings me here. I think it is good to have competition. I guess competition means that people on both sides have the freedom to make dumb decisions. Anyway, let me know if you want further input, but I think you also have the ability to think things out for yourself and take it from here. -- You are receiving this mail because: You are the assignee for the bug.