As in Summary: Activating duplex longside printing has no effect. All pages are printed on single pages. It worked in okular 16.08.3 and thus seems to be a regression for the KF5-transition.
I am running into this as well. Okular also lost the ability to set CUPS printer options, as the print properties "Advanced" tab is now missing. I wonder if all of these regressions are due to Okular now using the Qt5 print dialog. Unfortunately, these regressions totally mess up my printing, so I have had to switch to Evince for the time being. ** My System ** OS: KDE Neon 5.8.5 64-bit (Plasma Desktop 5.8.5, KDE Frameworks 5.29.0, Qt 5.7.0) Linux Kernel: 4.4.0.57-generic Printer: Brother HL-2280DW using the 2.1.0-1 drivers from the Brother website.
Related to https://bugs.kde.org/show_bug.cgi?id=373863 - I'm seeing exactly the opposite problem... ;) Maybe Okular does not specify any duplex-printing-information to the driver which falls back to its default setting? Anyway, a very annoying nuisance. :-(
Confirmed on Archlinux Also, grayscale printing won't work from the okular print wizard. Okular 16.12.1-1 Linux 4.8.13-1 Plasma 5.8.5.1 Frameworks 5.30.0-1 kdelibs 4.30.0-1 Printer: Brother MFC-J5620DW Driver: 3.0.1-2
Confirmed en KDE Neon I can't change print quality Okular 1.0.1 KDE Frameworks 5.30.0 Qt 5.7.1 (compilado con 5.7.0) El sistema de ventanas xcb
I have the same problem. My system: openSUSE Tumbleweed 20170626 KDE Plasma version: 5.10.2 KDE Frameworks version: 5.34.0 Qt version: 5.9.0 Kernel version: 4.11.6-1 OS type: 64 bits
(In reply to dickvandrake from comment #5) > I have the same problem. > > My system: > > openSUSE Tumbleweed 20170626 > KDE Plasma version: 5.10.2 > KDE Frameworks version: 5.34.0 > Qt version: 5.9.0 > Kernel version: 4.11.6-1 > OS type: 64 bits Duplex printing do not works (Okular Versión 1.1.2) My printer is an HP Deskjet F2480
As for bug 373863: In order to analyse the problem further, it would be very helpful to have the PPD file of the printer in use. It is usually stored under '/etc/cups/ppd/<PRINTERNAME>.ppd'. In case it could be attached to this bug report, that might be very helpful.
Created attachment 106723 [details] ppd file
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.
The very file existed here, but was empty. I removed it anyway and still, printing is done with duplex no matter whether "None" or "Long Side" is set in okular printing dialog
Created attachment 106724 [details] modified PPD file that uses the standardized "Duplex" keyword
(In reply to Robby Engelmann from comment #10) > The very file existed here, but was empty. I removed it anyway and still, > printing is done with duplex no matter whether "None" or "Long Side" is set > in okular printing dialog Thank you very much for testing. Is the behaviour for you right now exactly the opposite as it was when you initially opened the bug report? As far as I understand your first comment, all pages were printed on single pages back then and are now always printed duplex, no matter what value is set in Okular's print dialog for that option. Did I understand that correctly? The following two things might help in further narrowing down the issue: 1) Provide information from CUPS's log file: * increase log level by setting Directive 'LogLevel debug' in CUPS's config file '/etc/cups/cupsd.conf' * restart CUPS, e.g. by running 'sudo systemctl restart cups' * try printing from Okular again, setting the respective options in the print dialog * It would be particularly helpful if you could do this once for every available option for duplex printing ("None", "Long Side", "Short Side") * attach the log file '/var/log/cups/error.log' (or relevant parts of it) to this bug report, in particular the line containing "[Job <JOB_NUMBER>] argv[5]" is relevant, as it contains the options passed to CUPS. 2) Try with modified PPD file that uses the default keyword "Duplex" for the duplex option Is the result still the same when you use the modified PPD file "hl4150cdn_MODIFIED.ppd" that I have attached to this bug? (The only modification is that I have replaced the vendor-specific keyword "BRDuplex" with the standard keyword "Duplex", which might change how this is handled in Qt and/or Okular). In order to use the modified PPD, you can run the following command in the directory where the modified PPD is located: lpadmin -p <YOURPRINTERNAME> -P hl4150cdn_MODIFIED.ppd The same command with the previous PPD file given will reassign that PPD again.
Yes, when I read my first comment the behavior changed from always single pages to always duplex. Didn't realize it up to now. Your modified ppd-file makes no difference here. Still only duplex.
tried again, now again, I have one sided printing only, see the logs attached
Created attachment 106729 [details] cups logs
Thank you for providing more information. I think that the problem (or at least a part of it) is that the PPD uses the vendor-specific "BRDuplex" keyword instead of the standardized "Duplex" one and the printer possibly ignores the "Duplex" options in the modified PPD. The log file shows that the option "sides=one-sided" is even present for the case where you chose "long sided" in the Okular print dialog (which in my expectation should have resulted in "sides=two-sided-long-edge"). From a quick glance, this might be because Qt only handles the "Duplex" keyword to decide whether a printer supports duplex. When I try with the modified PPD file, I can see that the option "sides=two-sided-long-edge" is set as expected in the CUPS log (with no real printer available, I don't get any output however). Since you said that this does not work either, the proprietary Brother printer driver ignores it as it only handles its own vendor-specific option... Are there other applications where setting the duplex option in the print dialog does work as expected? (I just came across https://askubuntu.com/questions/766471/non-standard-keywords-in-postscript-printer-driver-ppd-break-integration-with) where somebody else describes problems with the Brother-specific keywords.) Is it possible that you had previously changed the system-wide setting for the duplex option and this is now back to the default since you used the original PPD file again (since duplex is deactivated again)? Is duplex enabled again for the printouts when you run 'lpoptions -p <YOUR_PRINTER_NAME> -o BRDuplex=DuplexNoTumble' (and disabled after running 'lpoptions -p <NAME_OF_YOUR_PRINTER> -o BRDuplex=None')? (This writes the respective value to '$HOME/.cups/lpoptions' and is basically what my assumption in comment 9 was, but there seems to be more to it in conjunction with the vendor-specific keyword.)
I have a brother printer and the duplex-settings work for basically all applications that I tried except Okular since being ported to Qt 5. So it worked with Okular from KDE 5 when it still was a KDE/Qt-4-based application (please excuse this explanation if it's imprecise) and still works fine with LibreOffice, Adobe Acrobat Reader, Chromium, etc...
I can confirm all the things stated by Gunter Ohrner in the previous comment.
In my opinion it "used to work" in Qt4-based Okular because it used Qt4's print dialog, and Qt4's print dialog still listed all the properties present in the PPD. This functionality was removed from Qt, though; see [1]. Only a small subset of options have been reimplemented. The "other software that works" most likely uses the options from the PPD directly, or it contains some heuristics for determining the actual option name the PPD wants for a certain feature. [1] https://bugreports.qt.io/browse/QTBUG-54464
I suppose that you are right that this is because the Qt 5 print dialog does no more display all options from the PPD, but only selected ones at the moment (like "Duplex"). In Firefox print dialog: Is the duplex option available in the "Page Settings" tab under "Two-sided" or only in an "Advanced" tab under "Two-Sided Printing" (or similar). The latter would confirm that it is handled as a "custom" PPD option (rather than the default "Duplex" option which would be shown in the "Page Settings" tab). In case the vendor-specific keyword is actually the cause and this is therefore the general problem with Qt 5's current printing dialog, I currently see no "reasonable" way of adding support in Okular, rather than working on Qt itself. For reference: Some discussion about printer-specific options in the Qt 5 print dialog has also taken place on the Qt development mailing list in January and February, s. thread "Printer-specific options in Qt5's print dialog (Linux, CUPS)" at [1] and [2]. [1] http://lists.qt-project.org/pipermail/development/2017-January/thread.html [2] http://lists.qt-project.org/pipermail/development/2017-February/thread.html
(In reply to Michael Weghorn from comment #16) > Are there other applications where setting the duplex option in the print > dialog does work as expected? > (I just came across > https://askubuntu.com/questions/766471/non-standard-keywords-in-postscript- > printer-driver-ppd-break-integration-with) where somebody else describes > problems with the Brother-specific keywords.) Konqueror works (using just the same print dialog as Okular). LibreOffice works and shows the option as "Duplex" in its print settings dialog. lpr on the command line works, using the "-o Duplex" setting: * lpr -PDCP-7065DN -o media=A4 -o Duplex=None -o page-ranges=1-2 "$PSFILE" This line prints one-sided, as expected. * lpr -PDCP-7065DN -o media=A4 -o Duplex=DuplexNoTumble -o page-ranges=1-2 "$PSFILE" This line prints duplex / double-sided, as expected. Chromium works and labels the option als "beidseitig" in its print page (no separate dialog). It also directly updates the print summary line (where it states how many pages will be printed in which mode) to reflect the setting. Firefox works, here the setting is in the tab "Seite einrichten" in the print dialog. The setting is called "Beidseitig", and available options are called "Langer Rand (Vorgabe)", "Kurzer Rand (Umdrehen)" and "Einseitig", so it's fully translated. Basically, I do not know about any other software than Okular which does NOT work.
(In reply to Gunter Ohrner from comment #21) > [...] > Konqueror works (using just the same print dialog as Okular). > > LibreOffice works and shows the option as "Duplex" in its print settings > dialog. > > lpr on the command line works, using the "-o Duplex" setting: > > * lpr -PDCP-7065DN -o media=A4 -o Duplex=None -o page-ranges=1-2 "$PSFILE" > This line prints one-sided, as expected. > > * lpr -PDCP-7065DN -o media=A4 -o Duplex=DuplexNoTumble -o page-ranges=1-2 > "$PSFILE" > This line prints duplex / double-sided, as expected. > > Chromium works and labels the option als "beidseitig" in its print page (no > separate dialog). It also directly updates the print summary line (where it > states how many pages will be printed in which mode) to reflect the setting. > > Firefox works, here the setting is in the tab "Seite einrichten" in the > print dialog. The setting is called "Beidseitig", and available options are > called "Langer Rand (Vorgabe)", "Kurzer Rand (Umdrehen)" and "Einseitig", so > it's fully translated. > > > > Basically, I do not know about any other software than Okular which does NOT > work. Thank you for that additional information. The way the duplex option is handled in your case differs from what I get when I use the attached PPD file. Could you possibly attach your printer's PPD file as well? It should be located under '/etc/cups/ppd/<PRINTER_NAME>.ppd'.
Created attachment 106857 [details] PPD Brother DCP7065DN for CUPS It's also a Brother printer (DCP 7065DN) but actually seems to use the standard Duplex keyword. Driver: dcp7065dnlpr:i386 2.1.0-1
(In reply to Gunter Ohrner from comment #23) > It's also a Brother printer (DCP 7065DN) but actually seems to use the > standard Duplex keyword. The fact that it uses the "Duplex" option seems to explain why it works so well in other applications. I just set up a dummy printer with that PPD and checked what options are passed to CUPS when printing from Konqueror and Okular. In my case, both options "Duplex" and "sides" were passed as expected for both Okular and Konqueror (using current KDE neon gitstable), so I wonder a bit why the two applications behave differently when printing to a real printer. Does a user-specific default value as described in comment 9 possibly play a role? (I did not have such a file '~/.cups/lpoptions'.) In addition, CUPS's 'error_log' file with Debug level enabled might help, as described in comment 12, point 1). [As far as I understand this issue right now, different aspects might come into play when using either the standardized "Duplex" keyword or a vendor-specific one, so I think it might possibly make sense to split this up into two separate bug reports in case this assumption is confirmed by your reply to the above answers (to make it possible to better focus on the single aspects).]
Note that the "Advanced" options tab has been reintroduced for the current development version of Qt 5 [1]. Also, the problem with duplex options being set at different places has been fixed [2], so I'd expect that the problem should be solved with those Qt upstream changes (will be part of the upcoming Qt 5.11). [1] https://codereview.qt-project.org/#/c/213391/ [2] https://codereview.qt-project.org/#/c/215131/
Should we close this as RESOLVED UPSTREAM, then?
(In reply to Nate Graham from comment #26) > Should we close this as RESOLVED UPSTREAM, then? I'd say yes.
Great. For people experiencing this issue, it should be resolved once Qt 5.11 is released and your distro provides it.