Version: 0.11.1 (using KDE 4.5.1) OS: Linux I've tried to print a document (pdf) using okular, but I realized that printing options do not work, any of them. I've tried only to print even pages, odd pages, and 4 pages in one (4up), and do not work :( Also I noted that it is TOO slow to process this data (arround a minute in a core2 2.66 4gigs ram), to proccess a 3.2MB pdf :( P.S. I marked this bug as major, since these options are *really* a must have! Reproducible: Didn't try
I clarify it a bit. I know they does not work because I tried to use that options, and save to another pdf as output. The result was a pdf same to original without changes.
Still present in KDE SC 4.6.0!
Can confirm that using Okular 0.14.3 / KDE 4.8.3, printing options such as: - Page set: odd/even - Output: Reverse - Color mode: greyscale - multiple pages per sheet don't work when printing to a PDF or PS file. However 'Print range' does work (both: from-to and current page) Please mark this one CONFIRMED. A more informative bug title might be helpful, too.
*** Bug 256368 has been marked as a duplicate of this bug. ***
We don't have a CONFIRMED status, only NEW, which kind of means the same. To be honest i never set bugs to the NEW status, you can consider anything in UNCONFIRMED as the same as NEW, since otherwise i'd have closed it as FIXED, INVALID or something similar. For those expecting a fix, i have to say that at least from my side don't hold your breath on getting this fixed soon. Printing is something i'm not very interested since the last hate mails i got about printing in Okular some months/years back.
I was able to confirm this bug in other kdelibs applications (kate, rekonq, calligra) and everything but the greyscale mode doesn't work there either. This means only the greyscale mode aspect is specific to Okular, however this is already covered in Bug #189014, meaning this one here can be marked DUPLICATE. All the other aspects of the bug (2on1, odd/even/reverse), should be covered in the kdelibs/print-dialog queue (e.g. Bug #193337).
*** Bug 189014 has been marked as a duplicate of this bug. ***
*** Bug 281199 has been marked as a duplicate of this bug. ***
*** Bug 305698 has been marked as a duplicate of this bug. ***
*** Bug 315611 has been marked as a duplicate of this bug. ***
I'm using a similar version of Okular under Gentoo, and am seeing the same results. The complaint came from a users who was using Linux Mint 17.1 (with up-to-date patches), so both sources rely on the Debian packaging system. $ okular --version Qt: 4.8.5 KDE Development Platform: 4.14.3 Okular: 0.20.3 $ The problem manifested itself as Okular silently refusing to produce more than one physical sheet of a 5-physical-sheet document... in a job where 4-pages-per-page was requested (on an A4 sheet, for what it's worth). I was eventually able to generate the desired printout using various pdftools, provided by ghostscript-gpl-9.10-r2: $ pdf2ps document.pdf $ psnup -d -4 document.ps 4-up.ps $ ps2pdf 4-up.ps 4-up.pdf $ pdfseparate 4-up.pdf "4-up-%d.pdf" $ lpr 4-up-1.pdf 4-up-2.pdf 4-up-3.pdf # (etc) The key is that the pdf2ps step complains mightily about an ill-formatted PDF document, but then does a best effort to keep going. My impression is that Okular sees this error, and silently bails out, leaving the user with a mysterious failure. The error/warning message on the pdf2ps step is: $ pdf2ps document.pdf **** Warning: An error occurred while reading an XREF table. **** The file has been damaged. This may have been caused **** by a problem while converting or transfering the file. **** Ghostscript will attempt to recover the data. **** This file had errors that were repaired or ignored. **** The file was produced by: **** >>>> Microsoft® Word 2010 <<<< **** Please notify the author of the software that produced this **** file that it does not conform to Adobe's published PDF **** specification. $ Incidentally, another PDF document, produced on a Mac with an Adobe toolchain, did not suffer any problems when a 4-up print request from Okular was given. Although the feedback loop might be hard to manage (probably due to asynchronous daemon issues), I would recommend that KDE and/or Okular look out for this error case, and try to inform the user. Alternately, this bug might be fixed in a more recent version of Okular. At present, Gentoo only provides a 4.14.3 ebuild, and I haven't hunted around for non-mainstream Portage respositories that might hold Okular 0.21. -- sur-behoffski
*** Bug 345766 has been marked as a duplicate of this bug. ***
In my case the problem was solved installing foomatic-db foomatic-db-engine
*** Bug 349977 has been marked as a duplicate of this bug. ***
(In reply to speedytux from comment #13) > In my case the problem was solved installing foomatic-db foomatic-db-engine Sadly, this did not work for me in Kubuntu 14.04.
*** Bug 358584 has been marked as a duplicate of this bug. ***
*** Bug 375059 has been marked as a duplicate of this bug. ***
*** Bug 231113 has been marked as a duplicate of this bug. ***
This problem still exists even in latest KDE neon LTS 5.8: KDE Plasma: 5.8.6 KDE Frameworks: 5.32.0 Qt Version: 5.32.0 Okular Version: 1.0.3 How is this possible that such an basic tool is broken since 7 years?
*** Bug 381209 has been marked as a duplicate of this bug. ***
Sadly this is still a problem with Qt 5.11.x, even with all of its printing fixes.
Created attachment 119822 [details] Screenshot
Print 'site' option gets ignored. Tried to extract a single pdf site but it printed the complete document. Okular 1.7.0 OS: openSUSE Tumbleweed 20190428 KDE-Plasma-Version: 5.15.4 KDE-Frameworks-Version: 5.57.0 Qt-Version: 5.12.3 Kernel-Version: 5.0.9-1-default Art des Betriebssystems: 64-bit Prozessoren: 4 × Intel® Core™ i5-6500T CPU @ 2.50GHz Speicher: 15,5 GiB Arbeitsspeicher
*** Bug 408271 has been marked as a duplicate of this bug. ***
*** Bug 425076 has been marked as a duplicate of this bug. ***
*** Bug 436388 has been marked as a duplicate of this bug. ***
This is a limitation in Qt: // Disable complex page ranges widget when printing to pdf // It doesn't work since it relies on cups to do the heavy lifting and cups // is not used when printing to PDF Printing odd and even pages isn't being disabled, but it also doesn't work. Please refer to bug #436388 for further information.
I relayed some information in the upstream bug: https://bugreports.qt.io/browse/QTBUG-77351?focusedCommentId=564096#comment-564096