Thanks for the report, but I don't think I really understood the issue so far after quickly getting over the other bug reports you mentioned. Therefore a few questions here:

1) Can you give a quick description of

* the steps you took
* the result you expect
* what actually happens

(As far as I understand, you want the order reversed by default, but I'm not yet sure where you have configured this.)

2) Can you please attach the PPD you're using here? The CUPS issue suggests that https://github.com/apple/cups/files/2010726/HP_Photosmart_Plus_B210a.ppd.txt is the file being used, but at first glance, the only thing related to reversing page order is commented out, so doesn't have any effect:

    *% *DefaultOutputOrder: "reverse"

3) What Qt version are you using?

$ pacman -Q qt5-base
qt5-base 5.11.1-2

Steps:

1. Configure a printer to reverse pages (using PPD or lpadmin)
2. Print something in Okular
3. The pages come out non-reversed. I would have expected them to be reversed

According to my bug report, I was able to get pages to reverse / not reverse using the Virtual_PDF_Printer which is part of the cups-pdf package. This provided an easy way to confirm the bug. However, I was not able to do that in the recent version, perhaps when Till Kamppeter updated cups-filters it changed something related to this behavior. Now all "reverse" settings, even in the print dialog, are ignored by Virtual_PDF_Printer, in all clients. In fact, after I just upgraded, normal printing seems to be broken on the server I used to print. But before upgrading I was able to confirm that Okular ignores the lpadmin and PPD settings when printing on paper.

I would suggest trying to debug using Virtual_PDF_Printer, if you can reproduce the bug there, then you can save paper. You can use lpadmin to control the outputorder settings:

    lpadmin -p Virtual_PDF_Printer -o outputorder-default=reverse
    lpadmin -p Virtual_PDF_Printer -R outputorder-default

Apparently this causes a line to be added to /etc/cups/printers.conf, although I can't find any documentation of this fact:

    $ lpadmin -p HP_Photosmart_Plus_B210_series -o outputorder-default=reverse
    $ sudo systemctl restart org.cups.cupsd.service                           
    $ sudo grep outputorder /etc/cups/printers.conf 
    Option outputorder reverse
    $ lpadmin -p HP_Photosmart_Plus_B210_series -R outputorder-default         
    $ sudo systemctl restart org.cups.cupsd.service              
    $ sudo grep outputorder /etc/cups/printers.conf                   
    [1]$

Otherwise, as I said in the report, adding a line to the ppd should work as well:

    $ sudo grep -i defaultoutput /etc/cups/ppd/HP_Photosmart_Plus_B210_series.ppd 
    *DefaultOutputOrder: "reverse"

In both cases the setting was respected by evince and other utilities, but not okular.

Till Kamppeter suggests it should be:

    *DefaultOutputOrder: Reverse

I'm not sure if that fixes things for Okular, but I would doubt it, as controlling the setting via lpadmin also didn't work.

Obviously you don't want to comment out the PPD line after you add it. If it was commented out in the PPD I uploaded, that was probably a reflection of the state of the file at the time I was trying various settings.

A lot of my original bug was about lack of documentation, so good luck.

After a full system upgrade (to fix printing), I confirmed that the bug still exists. This is for printing on paper, and configuring reversal using 'lpadmin' (i.e. printers.conf). Evince reverses, Okular doesn't. I'll be happy to hear what results other users get when they try this.

Also I can again reproduce this with cups-pdf, so you don't need a printer.

1. Install cups-pdf
2. Add a printer via the CUPS interface, and select CUPS-PDF
3. Select the cups-pdf PPD /usr/share/cups/model/CUPS-PDF_opt.ppd
4. Use lpadmin to configure page reversal:

lpadmin -p Virtual_PDF_Printer -o outputorder-default=reverse

5. Print a multi-page document using Okular to Virtual_PDF_Printer
6. Check the cups-pdf spool, something like:

/var/spool/cups-pdf/frederik/t.pdf_pool_cups-pdf_frederik-job_61.pdf

The pages are not reversed.

7. Try printing the same document with lp and evince

$ lp -dVirtual_PDF_Printer t.pdf
request id is Virtual_PDF_Printer-62 (1 file(s))
# check the pages are reversed in /var/spool/cups-pdf/frederik/*job_62.pdf
$ evince t.pdf # print to Virtual_PDF_Printer with evince
# check pages reversed in /var/spool/cups-pdf/frederik/*job_63.pdf 

Hope this helps.

Thanks for the update. This helps in understanding the scenario.

At a quick glance, the setting is overriden in 'fileprinter.cpp':

> QStringList FilePrinter::optionPageOrder( QPrinter &printer )
> {
>    if ( printer.pageOrder() == QPrinter::LastPageFirst ) {
>        return QStringList(QStringLiteral("-o")) << QStringLiteral("outputorder=reverse");
>     }
>     return QStringList(QStringLiteral("-o")) << > QStringLiteral("outputorder=normal");
> }

Without further examining, this is probably the value set in the checkbox.
Maybe one way to address this would be to have the Qt print dialog evaluate whether the option you mention is set for the selected printer and set the checkbox state accordingly (though that will need further investigation).

Can you confirm it's also working as you'd expect when you use the "Force rasterization" option in the print dialog? (which probably doesn't really help you since you'd like not to have to check any option every time your print, if I understand correctly...)

> Can you confirm it's also working as you'd expect when you use the "Force rasterization" option in the print dialog?

Yes.

Some observations:

- What does "force rasterization" mean? It's not really self-explanatory. Does anyone use it?

- If I check an "Options >>" option in the print dialog, the next time I open the dialog it is unchecked. Which is fine because usually I'm selecting a page range or number of copies or something that I want to only do for one document. As a user I would expect the "Reverse" setting in this place to apply to just one document as well, not to the printer in general. In other words it should produce a document whose pages are backwards when I take it out of the printer and try to staple them. To accomplish this, you wouldn't override the "output-order" setting of CUPS. Rather you would modulate it, as in exclusive-OR: "print dialog options = reverse" + "default output order = reverse" -> "setting for this job = normal".

But I think that CUPS should be doing that automatically, even when the output order setting is specified on the command line, it should modulate and not override. I don't see the utility of allowing client applications to override printer-specific details like this, it breaks the abstraction layer that CUPS is supposed to provide. Why should Okular need to know whether my printer prints face-up or face-down? Why should it *get* to know?

Unfortunately I was not able to communicate this to the CUPS maintainer before he closed my bug as "too heated". YMMV.

You may want to look at how other KDE applications do printing, I seem to recall finding one which did not have this problem, but I can't remember for sure and I didn't find it when looking over the various bug reports I made. Or you could look at Evince and other GTK applications.

It would probably be useful if you were able to reproduce this yourself. I have provided instructions for how to do that without a printer, did you run into problems following them?

(In reply to Frederick Eaton from comment #7)
>
> - What does "force rasterization" mean? It's not really self-explanatory.
> Does anyone use it?

"Force rasterization" means that the document is rendered into a bitmap ("pixel image") before being sent to the printer, i.e. all objects in the document are "rasterized".
I don't know how many are regularly using it.
Other than the default printing handling done by Okular, "force rasterization" leaves most of the handling to the Qt print dialog, which is used by most KDE applications. Rasterization has other drawbacks, though.


> 
> - If I check an "Options >>" option in the print dialog, the next time I
> open the dialog it is unchecked. Which is fine because usually I'm selecting
> a page range or number of copies or something that I want to only do for one
> document.

This matches the way all other options in the Qt print dialog are currently handled as well.

> As a user I would expect the "Reverse" setting in this place to
> apply to just one document as well, not to the printer in general. In other
> words it should produce a document whose pages are backwards when I take it
> out of the printer and try to staple them. To accomplish this, you wouldn't
> override the "output-order" setting of CUPS. Rather you would modulate it,
> as in exclusive-OR: "print dialog options = reverse" + "default output order
> = reverse" -> "setting for this job = normal".

I don't really agree in this point. 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. In my personal opinion, it would probably be best to tick the checkbox by default if the printer default is to reverse page order. This would be in accordance to how PPD-specific options in the "Advanced" tab or the "Duplex" option is handled (at least from Qt 5.11/5.12 on). For those options, the default value that has been set for the corresponding printer is preselected in the dialog.

> 
> But I think that CUPS should be doing that automatically, even when the
> output order setting is specified on the command line, it should modulate
> and not override. I don't see the utility of allowing client applications to
> override printer-specific details like this, it breaks the abstraction layer
> that CUPS is supposed to provide. Why should Okular need to know whether my
> printer prints face-up or face-down? Why should it *get* to know?

As far as I understand, CUPS does behave as it should in this respect and evaluates the option. As mentioned above, Okular itself should not have to care about the printer details, e.g. how to make it use a specific functionality. All this is already handled by CUPS, Okular just passes the corresponding options to CUPS via its API. Okular itself uses the Qt print dialog, which in turn uses the CUPS API to retrieve the available options.

And here it's not CUPS overriding any setting, but it's Okular that passes an explicit value for the "outputorder" value. When the "Reverse" checkbox is not checked, Okular tells CUPS not to reverse pages, and that's what CUPS does...
When you use CUPS directly on the command line without passing any explicit value, the default value should be used.

> You may want to look at how other KDE applications do printing, I seem to
> recall finding one which did not have this problem, but I can't remember for
> sure and I didn't find it when looking over the various bug reports I made.
> Or you could look at Evince and other GTK applications.

Other KDE applications should mostly behave similar to Okular with the "force rasterization" option enabled, since they use the Qt print dialog. As mentioned above, Okular does some custom handling when the "force rasterization" option is not checked, since the Qt print dialog does not provide a way to pass an existing PDF file by itself, s.a. https://phabricator.kde.org/D7949 .


> 
> It would probably be useful if you were able to reproduce this yourself. I
> have provided instructions for how to do that without a printer, did you run
> into problems following them?

Sorry for not mentioning more explicitly in comment 6; I am able to reproduce the described behaviour now.

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.

Here is where I got the data about ~/.cups/lpoptions:

https://askubuntu.com/questions/339607/why-dont-applications-respect-a-printers-default-options