Version: (using KDE 4.2.2) OS: MS Windows Installed from: MS Windows The Windows-Version of Okular (installed with kdewin-Installer) does not provide any printing-functionality. I can print with KWrite and ohter applications, but not with Okular.
Sorry, but I have to use Windows on my working place. Replacing Adobe Reader with Okular would be wonderful, but I need to print PDFs.
Due to the interaction with 3rd party libraries we use, printing a PDF means actually being able to print an existing PostScript file. Windows guys, do you have a way to do that?
*** Bug 195911 has been marked as a duplicate of this bug. ***
Because noone else seems to have an answer: I guess this will be possible with pdfcreator, a free pdf printer program http://www.pdfforge.org/products/pdfcreator. In the docs of the installed program there is a hint to start pdfcreator from okular (see topic command line)
Hi, Can kdeprint print a PDF/PS? and if not could kdeprint be combined with ghostscript and/or some existing windows api? Other KDE can print, it would make sense to take something like kdeprint and build a central framework, as opposed to each app having its own print solution. Being able to fire PS files at such a framework would also mean kde apps can use most of the printing code they use in Linux, no? If this bug is linked to 'KDE-Windows' instead of Okular, how to the okular people get to see it when they are triaging bugs? I would also like to stress that with printing support Okular would be one of the best open source document viewers available for windows. Other viewers are either bloated, adware, negware, or some combination thereof. -Thorben
Created attachment 63015 [details] Enable print menu items on windows This patch enables the print menu items for okular on windows. If there are no objections I would commit this patch
Using the arthur renderer is not a good idea as it misrenders most of the pages.
Let me give some background. A conscious decision was made by Okular that they wanted the highest possible quality print-outs of PDF's, so painting the PDF onto a QPrinter is not an option as the quality is massively degraded. Printing degraded quality documents is considered worse for Okular's reputation than not printing at all. Instead Okular passes the PDF file directly to the print system to use via the CUPS/lpr command line call. Unfortunately this is a model that doesn't work on Windows as the Windows Print System doesn't provide a tool to print files directly. Basically all we need is a windows command line tool that can take a ps/pdf and translate it to GDI without degrading the quality and print it without showing a print dialog. The one option I know of is Ghostscript which provides this. PDFCreator mentioned above doesn't seem to provide this? So the obvious question is if the Windows team think it would be acceptable to make gs a hard dependency for Okular on Windows. GS looks to be a 12Mb binary download on Windows. If so it shouldn't take much work to add the gs command line call to FilePrinter, but I would need to do more research on how gs and printer drivers interact as you seem to need to tell it what driver to use.
OK, gs documentation is at http://svn.ghostscript.com/ghostscript/trunk/gs/doc/Devices.htm#Win
Well, to say the truth: I haven't looked into it completely, but we already do have a ghostscript package for libspectre postscript viewing support in okular. This package also provides the commandline tools. I am currently working on the 4.7.0 release for Windows, so I am very much interested if any of you who has more insight into printing in okular could come up with a working patch which uses ghostscript instead...
Well, if you have gs already, it shouldn't take me too long :-) I assume the following will work under windows to detect if the gs exe is installed? KStandardDirs::findExe("gswin32c") And that the following will execute it OK: ret = KProcess::execute( "gswin32c", argList ); If so I just need to code up what parms to pass to it and execute that instead of the lpr command we use under Linux. I need to rebuild my windows emerge install, but I could have a patch for review in the next day or two.
While analysing okular printing stuff I used the following script named lpr.bat and a little hack in okular to search for lpr.bat instead of lpr (because KStandardDirs::findExe did not find the batch file) to print from okular echo %* >> c:\kde\vc100d\tmp\lpr.log set FILE=%7 set OUTPUT=%2 set OPTIONS=-sDEVICE=mswinpr2 -dNoCancel -dBATCH -dNOPAUSE -dBitsPerPixel=4 echo gswin32 %OPTIONS% -sOutputFile="\\spool\%2" %FILE% >> c:\kde\vc100d\tmp\lpr.log gswin32 %OPTIONS% -sOutputFile="\\spool\%2" %FILE% >> c:\kde\vc100d\tmp\lpr.log if ERRORLEVEL 1 then goto error exit 0 :error exit 1 Unfortunally I found are some issues with this script. 1. -dBitsPerPixel=4 degrades massive the resolution 2. Using -dBitsPerPixel=24 results into more than 2 GB big spool file and an unusable workstation for at least 10 minutes when printing a pdf file containing 24 page with several images.
Just an additional remark: okulars fileprinter uses KTemporaryFile instances (two instances named tk). There are calls to tk.close() which should close the temporary file, so that it can be renamed later. Unfortunally QTemporaryFile 4.7 implementation do not close the file in real, instead it only seeks to the beginning of the file. I had to add a tk.setFileName("") after the call to close() to really close the file.
Thanks Ralf. > 1. -dBitsPerPixel=4 degrades massive the resolution > 2. Using -dBitsPerPixel=24 results into more than 2 GB big spool file and an > unusable workstation for at least 10 minutes when printing a pdf file > containing 24 page with several images. I seem to recall having performance issues like that with kpdf back in the KDE3 days when kdeprint used gs under Linux for file conversions from pdf into ps. I would have hoped they had fixed it by now :-( Seems we're between a rock and a hard place. I'll have a play myself, but it looks like we can't use that option. > Unfortunally QTemporaryFile 4.7 implementation do not close the file in real, > instead it only seeks to the beginning of the file. A bug I presume, or intentional? Windows only, or Linux too?
That Q/KTemporaryFile bug is windows only. the real close() is only called in the dtor.
okular converts the pdf file to ps before printing, so I tried to print a 28 page pdf file on a hplj4005 network printer with gswin32 -dPrinted -sDEVICE=mswinpr2 -dNoCancel -dBATCH -dNOPAUSE -dBitsPerPixel=4 -sPAPERSIZE=a4 <file> The printer panel shows a 1,62 GB big print file and each page needs about 48 seconds on the printer (normally the printer prints 2-3 pages a second) Using -dBitsPerPixel=24 shows a 4 GB big print file in the printer panel. The question now is: What is easier to fix - popplers qpainter support or gs windows printing ?
In the opposite: the same document printed using qpainter results into a 51 MB big print file.
Created attachment 63034 [details] Acrobat Reader example 1
Created attachment 63035 [details] Acrobat Reader example 2
Created attachment 63036 [details] okular example 1
Created attachment 63037 [details] okular example 2
I checked some documents against acrobat reader 10. The rendered documents shows at a zoom level of 400 % very similar (see the appended screenshots). Do okular not use poppler for rendering into an image ? Where are the problems in qpainter, so that it cannot be used for printing too ?
Created attachment 63046 [details] okular pdf testcase
Created attachment 63047 [details] okular test case thumbnail
Created attachment 63048 [details] okular test case main window Fit page
Created attachment 63049 [details] okular test case print output
The uploaded testcase files shows at least one problem with printing (compared "okular test case main window Fit page" with "okular test case print output"). The main window display with a resolution of 79.2605 dpi looks much better then the print output with a resolution of 135 dpi and a bigger image size - both outputs are drawn by Poppler::Page->renderToImage() Does anyone have an idea where this comes from ?
> Do okular not use poppler for rendering into an image ? Yes it does, but not using the Arthur backend as it sucks > Where are the problems in qpainter, so that it cannot be used for printing too ? Problems in QPainter? We do not use QPainter at all in poppler when rendering with PDF files, If you mean why we can not use the QImages we draw on screen to dump them on the QPrinter it is because your screen as a 75dpi resolution and your printer a 600dpi one, so you end up either printing something that makes your eyes cry or something that is *huge*
Created attachment 63052 [details] fixed rendering
Git commit 195c51e8f1b9475a4051af5b2325c629796495ff by Ralf Habacker. Committed on 20/08/2011 at 21:06. Pushed by habacker into branch 'master'. Enable print menu items in windows BUGS: 190497 M +33 -1 generators/poppler/generator_pdf.cpp http://commits.kde.org/okular/195c51e8f1b9475a4051af5b2325c629796495ff
Which part of "using the arthur backend is not a good idea" did you not understand?
(In reply to comment #28) > > Do okular not use poppler for rendering into an image ? > Yes it does, but not using the Arthur backend as it sucks fixed > > Where are the problems in qpainter, so that it cannot be used for printing too ? > Problems in QPainter? We do not use QPainter at all in poppler when rendering > with PDF files, sorry for beeing a little unspecific I meant Page::renderToPainter method, which is only implemented for Arthur backend, which is not usable. >If you mean why we can not use the QImages we draw on screen to dump them on >the QPrinter it is because your screen as a 75dpi resolution and > your printer a 600dpi one, so you end up either printing something that makes > your eyes cry or something that is *huge* agreed. Additional there are major differences between print and print preview. The preview should not be rendered with the same resolution as the real print because of the preview should not need more than a few seconds. Because Printing in okular is different from sceen drawing the solution on windows is to tell QPrinter contructor which type of resolution it should use. QPrinter constructor by default uses QPrinter::ScreenResolution (=96 dpi) which is used for generating previews. Calling QPrinter printer(QPrinter::PrintResolution) let it choose the resolution from the printer driver first, overrideable by the print config dialog, which is exactly what is required.
Oh, you are rendering to an image in a second patch, didn't see that. Anyway you seem to be ignoring the margins and a bazillion things ;-)
(In reply to comment #33) > Oh, you are rendering to an image in a second patch, yes > didn't see that. Anyway you seem to be ignoring the margins and a bazillion things ;-) hmmh, did not get qprinter all this stuff from the print config dialog ? I verified this with the print resolution, which is initial set by the printer driver and is overridable by the config dialog.
(In reply to comment #34) > (In reply to comment #33) > > Oh, you are rendering to an image in a second patch, > yes > > didn't see that. Anyway you seem to be ignoring the margins and a bazillion things ;-) > hmmh, did not get qprinter all this stuff from the print config dialog ? > I verified this with the print resolution, which is initial set by the printer > driver and is overridable by the config dialog. http://doc.qt.nokia.com/latest/qprintdialog.html#details
To be honest i have no idea, maybe, my expiences with QPrinter have been mostly bad so i tend to think that they do not do anything at all, but maybe in this case it works.
(In reply to comment #36) > To be honest i have no idea, maybe, my expiences with QPrinter have been mostly > bad so i tend to think that they do not do anything at all, but maybe in this > case it works. see qt_win_read_back_PRINTDLGEX at line 151 of http://qt.gitorious.org/qt/qt/blobs/4.7/src/gui/dialogs/qprintdialog_win.cpp
Git commit 74ba13d6c5e67cfe6c15da0a2318613e4c7dc383 by Ralf Habacker. Committed on 20/08/2011 at 21:06. Pushed by habacker into branch '4.7'. Enable print menu items in windows BUGS: 190497 M +33 -1 generators/poppler/generator_pdf.cpp http://commits.kde.org/okular/74ba13d6c5e67cfe6c15da0a2318613e4c7dc383