If you have a printer that supports duplex, it is not possible to print one-page-per-sheet (=duplex off), even if "duplex printing:none" is set and is the default setting for system-config-printer-kde and your local CUPS. Reproducible: Always Steps to Reproduce: 1. Make sure CUPS is configured for bo duplex per default ("sides=one-sided"). 2. Make sure in system-config-printer-kde your printer's duplex feature is set correctly. 3. Make sure in system-config-printer-kde "duplex printing:none" is set per default. 4. Print anything, again making sure that "duplex printing:none" is set in the printing dialog. Actual Results: The print job is duplexed despite anything. You can get a one-sided printout only by emulation (inserting empty pages in your document!). Expected Results: The print job is printed one-sided as defined by default setting and/or by individual request. * Other non KDE applications (like evince or libreoffice) are capable of printing with and without duplex as requested. * Other KDE applications (like calligra foo) behave like okular, hence the bug seems to concern the KDE printing envirenment in general. * Changing CUPS version does not help. * Changing CUPS printer driver type does not help. * Restarting CUPS does not help.
Can you please do these two command sequences and see if it is also printed in duplex? A) pdftops myfile.pdf lpr myfile.ps B) lpr myfile.pdf
If you can provide the information requested in comment #1, please add it.
Am 10.08.2013 19:34, schrieb Christoph Feck: > https://bugs.kde.org/show_bug.cgi?id=322993 > > --- Comment #2 from Christoph Feck <christoph@maxiom.de> --- > If you can provide the information requested in comment #1, please add it. > Dear Cristhoph, unfortunately I'm put out of action at the momenty due to an injury. Hence I have no access to the printer and system where the putative bug showed and have to hand in the requested tests later, in some weeks.
Dear Christoph, finally the results: A) pdftops myfile.pdf ; lpr myfile.ps B) lpr myfile.pdf both result in a duplexed printout. Furthermore, I created a new user (i.e. a ~/.kde with defaults), opened myfile.pdf with okular, set "duplex printing:none" - and got my sheet duplexed. Hence that seems like a "default: duplex" option is somewhere hidden in the system thet overrides all. However, CUPS states "Defaults: job-sheets=none, none media=iso_a4_210x297mm sides=one-sided" and I haven't knowingly configured anything else for that printer (or printing in general). # grep -i duplex /etc/cups/ppd/goethe.ppd *cupsEvenDuplex: True *OpenUI *Duplex/Double-Sided Printing: PickOne *OrderDependency: 10 AnySetup *Duplex *DefaultDuplex: None *Duplex DuplexNoTumble/Long Edge (Standard): "<</Duplex true/Tumble false>>setpagedevice" *Duplex DuplexTumble/Short Edge (Flip): "<</Duplex true/Tumble true>>setpagedevice" *Duplex None/Off: "<</Duplex false/Tumble false>>setpagedevice" *CloseUI: *Duplex *OpenUI *OptionDuplex/Duplexer Installed: Boolean *OrderDependency: 10 AnySetup *OptionDuplex *DefaultOptionDuplex: False *OptionDuplex False/Not Installed: "" *OptionDuplex True/Installed: "" *CloseUI: *OptionDuplex So seems consistent with "sides=one-sided". Any suggestions where else to search?
No idea here, but given that both A) pdftops myfile.pdf ; lpr myfile.ps B) lpr myfile.pdf give you a duplexed printout I'm not sure okular is to blame here to be honest (i.e. i'm not sure this bug is really a bug)
Yes, this was my first idea, too. However, as initially reported, when you print the SAME PDF document from a non-KDE-Application, e.g. "evince 3.4.0 (using poppler/cairo 0.18.4)", it's correctly printed one-sided! Additional example and information: a) If I start "Calligra Words" (version 4.10.5, meanwhile) with a blank document, write two paragraphs containig "Page 1" and "Page 2" respectively, insert a page break between them, finally invoke Calligra Word's printing dialog, choose the printer (HP4250), select "duplex: none", I directly get a duplexed sheet, too. b) To make things even more interesting, choosing another printer (HP4700), the same procedure ends up correctly with two one-sided pages. Hence, I conclude 1) there must be some kind of bug, not only in okular, but somwhere in KDE's printing environment, 2) it's not locateable in user specific settings, as a new profile behaves the same way (always duplexing) 3) it only appears with certain (maybe few?) printer models (or lets say PPD files)
Additional approach to eliminate any doubts concerning the PPD file: I just downloaded "hplip-3.13.8.run", extracted "hp-laserjet_4250-pcl3.ppd" which is said to work "excellent" by openprinting.org (http://www.openprinting.org/printer/HP/HP-LaserJet_4250) from it and choose that PPD file for the relevant printer using CUPS webinterface. diff hp4250.ppd hp4250.ppd.duplexproblem < *%%%% Created by the CUPS PPD Compiler CUPS v1.5.0. > *%%%% Created by the CUPS PPD Compiler CUPS v1.6.3. < *FileVersion: "3.13.8" > *FileVersion: "3.13.4" < *NickName: "HP LaserJet 4250 pcl3, hpcups 3.13.8" > *NickName: "HP LaserJet 4250 pcl3, hpcups 3.13.4" After restarting CUPS, I printed "myfile.pdf" again with all three "Duplex Printing" variants from okular: * None * Long side * Short side Actual Result: All three variants end up in identical printouts, duplexed "Long side".
Why you conclude 1) there must be some kind of bug, not only in okular, but somwhere in KDE's printing environment, if lpr has nothing to do with KDE and is just CUPS upstream printing utility from command line?
1) Not only okular: Because other KDE applications like applications from Calligra Suite behave identical. 2) Somewhere in KDE's printing environment: I haven't encountered any application yet not belonging to KDE SC and showing this "always duplexing long sinde" issue. Of course, that's no proof, just some clue. 3) lpr: AFAIK just an (obsolete?) frontend for CUPS, it certainly could be the toolchain's point of failure, where my printjobs go wrong, too. This would be more probable, if KDE's printing dialogues are (and other applications are not) a frontend to lpr - I'm sorry, I just really don't know. But my first thout was (and is): if every printjob is finally executed by CUPS, and as CUPS is configured correctly and working fine to for other programs (firefox, thunderbird, LibreOffice, GIMP, ...), and workling for all applications with other printer models, it seems very unlikely that a simple frontend (lpr) is defective. Summing up all that: One simple explanation then could be that something goes wrong in thunking the duplex options. In "man lpr" there is something about " -o option[=value]" directives, and no general duplexing/ortientation options. This makes the whole thing printer model specific, and this is just what I noticed this phenomenon is, which further supports such a "erroneous thunking hypothesis". The bug could then either be located in KDE's forming a lpr commandline, as well as in the specific driver or printer in interpreting it. Again, the latter seems unlikely to me, as no program should be able to manually override CUPS's default duplexing setting for that printer then. What do you think about that? Do you agree, if okular uses lpr as backend, and if I print the document of interest in three variants (no/long-side-flipped/short-side-flipped duplexing), then three different commandlines should be passed to lpr beneath underhood? And to test this, is there a way to get hold of them for logging/debugging the issue? (By the way: It's not my intention to blame okular or KDE, I just want to be able to use duplex options on demand. :o) )
Somewhat irreverent, I now just did cd ~/bin # This is in front of my $PATH echo 'kdialog --msgbox "Capturing lpr input to /tmp/test.dat"' > lpr echo 'echo $* > /tmp/test.dat' >> "' > lpr chmod a+x lpr Then I printed myfile.pdf with okular in the three duplexing variants and renamed the resulting /tmp/test.dat. This captured three lpr commandlines indeed! 1) The baseline: no duplexing -P myprinter -#1 -J myfile.pdf -o media=A4 -o portrait -o sides=one-sided -o outputorder=normal -o Collate=False -o Duplex=DuplexNoTumble -o OptionDuplex=True -r /tmp/kde-myself/okularSomeFilename.ps 2+3) Only one different Option for the two duplexing variants: ... -o sides=two-sided-long-edge ... ... -o sides=two-sided-short-edge ... And if I print myfile.pdf using evince, no messagebox is triggered and no fake-lpr output is captured, instead the printer works. Now we can test lpr directly: /usr/bin/lpr -P myprinter -o sides=one-sided -o OptionDuplex=True myfile.ps and it's duplexed again. So the guesswork in chapter 9 above was not too bad. (However, still no way to use that printer directly from KDE applications, except changing CUPS default before!)
You could check if this also shows with pure Qt applications, for example qpdfview.
No answer in more than 6 months