[okular] [Bug 398442] okular doesn't respect page reverse setting of PPD or lpadmin

[Frederick Eaton]

https://bugs.kde.org/show_bug.cgi?id=398442

--- Comment #9 from Frederick Eaton <frederik at 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.