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

[Michael Weghorn]

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

--- Comment #8 from Michael Weghorn <m.weghorn at posteo.de> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.