[okular] [Bug 373133] 16.12.0 Okular duplex printing on but no duplex printing done

Michael Weghorn bugzilla_noreply at kde.org
Wed Jul 19 11:49:26 UTC 2017


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

--- Comment #9 from Michael Weghorn <m.weghorn at posteo.de> ---
I had a look at this and have an idea what MIGHT be the reason:

Okular uses the options "sides=one-sided", "sides=two-sided-short-edge", and
"sides=two-sided-long-edge" to specify whether or not to do duplex printing.
Those options are passed to the "lpr" command.

On the other hand, PPD files have a standardized keyword "Duplex" that uses
values of "None", "DuplexTumble", and "DuplexNoTumble" to specify the same
option (s. PPD specification).

I made some tests and it seems to me like the PPD option "Duplex" takes
precedence over the "sides" option in case both are given.

Since Okular does not explicitly pass any value for the "Duplex" option, CUPS
uses the user's default value specified for the printer in
'$HOME/.cups/lpoptions' in case that exists.

Example content of a '$HOME/.cups/lpoptions' file that specifies that no
duplexing should be done:

~~~
$ cat .cups/lpoptions 
Default HL2280DW Duplex=None
~~~

So if that option is set, the duplex option set in Okular simply has no effect,
since it is overriden by the other value.


Could somebody of those who are affected verify whether the above assumption
matches their situation - in particular, whether the file
'$HOME/.cups/lpoptions' exists and has a respective value and whether the
problem goes away after renaming/deleting the file?

Additional note:  The attached PPD file uses the vendor-specific keyword
"BRDuplex" instead of "Duplex", but the situation might still be the same.

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


More information about the Okular-devel mailing list