Summary: | Okular mismanages fonts embedded in PDF document when printing | ||
---|---|---|---|
Product: | [Applications] okular | Reporter: | Sergio <sergio.callegari> |
Component: | PDF backend | Assignee: | Okular developers <okular-devel> |
Status: | ASSIGNED --- | ||
Severity: | normal | CC: | aacid, med.medin.2014, oliver.sander |
Priority: | NOR | ||
Version: | 22.12.2 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
Test document
Screenshot of print preview |
Description
Sergio
2023-03-14 13:11:39 UTC
Created attachment 157270 [details]
Test document
Created attachment 157271 [details]
Screenshot of print preview
From the screenshot it is quite evident that the document displays correctly (bottom window), but is not previewed correctly (window on top, where the text is unreadable). Printing the document produces what is shown in the preview window.
Qpdfview can print the PDF document just fine. Printing in Okular is a bit special. I conjecture that you can print your document if you select the 'force rasterization' option in the print dialog. @Oliver Sanders
> (In reply to Oliver Sander from comment #4)
> Printing in Okular is a bit special.
>
> I conjecture that you can print your document if you select the 'force
> rasterization' option in the print dialog.
Your conjecture is correct.
Even if this workaround is effective, I think that this issue deserves attention:
- first, forcing rasterization does not fix the wrong preview;
- secondly, one typically works with force rasterization off (also because it can slow things down in some cases and I am not sure whether it can affect the printout quality in some cases). It is not nice when you discover that you have printed 200 bad pages that you should have forced rasterization;
- thirdly, in some occasions the issue is subtle. Here, I have managed crafting a PDF where all the characters get substituted by little squares when printing, which make the bug quite detectable. However, in some cases out of a multipage document you end up only missing a word on a single page or a few characters here and there. It is very easy to miss the issue and pass around an unprofessionally looking document or even signing an incomplete document;
- finally, due to the complexity of the PDF standard issues like this one tend to make one doubt the correctness of the original PDF. Is it OK or slightly out of specs, so that some viewer can print it and some other cannot? Unfortunately, this issue has already prompted the opening of inquires on the Libreoffice tracker and the Source Sans 3 font tracker.
Out of curiosity, in what sense printing in Okular is a bit special? In cases where rasterization is not explicitly required, cannot the PDF be passed to the printing subsystem more or less as is?
I fully agree that `force rasterization` is only a workaround. Okular currently converts pdf files to postscript and sends that to the printer (I forgot why exactly). Presumably it is the conversion step that goes wrong in your case. If you want to have a look at the code: That's at `generator_pdf.cpp:1366`. There used to be a patch that made Okular send the pdf file straight to the printer, but I can't seem to find it right now. And then there's the official Qt way of printing: Render everything to a `QPrinter` object. Code for that is at https://invent.kde.org/graphics/okular/-/merge_requests/411 , but that has its own set of problems. (In reply to Oliver Sander from comment #6) > I fully agree that `force rasterization` is only a workaround. > > Okular currently converts pdf files to postscript and sends that to the > printer (I forgot why exactly). Presumably it is the conversion step that > goes wrong in your case. Most likely the issue is indeed in this conversion. Noticed that if you pre-process the PDF via a pdf-to-pdf conversion via Ghostscript (which most likely results in a simpler PDF) then the PDF prints fine. For sure the PDF to PDF conversion via ghostscript changes the way in which the fonts are embedded because the `pdffonts` utility returns different results. I wonder if the conversion is related to the need to select page ranges or to do page scaling, but both things should be manageable at the PDF level. Or if it is needed by non-CUPS platforms (windows) where PDF might not be the "standard" way of describing the page for printing. If you want to have a look at the code: That's at > `generator_pdf.cpp:1366`. > There used to be a patch that made Okular send the pdf file straight to the > printer, but I can't seem to find it right now. Resurrecting this patch might have good potential! > And then there's the official Qt way of printing: Render everything to a > `QPrinter` object. Code for that is at > https://invent.kde.org/graphics/okular/-/merge_requests/411 , but that has > its own set of problems. I had a look at it, but I am not sure I fully understand. If I get it correctly, the QPrinter object is an object you paint onto (sort of QPainter?). So if you have an application that wants to draw something meant to be printed you do that on the QPrinter object and in this way you get something that is printable. However, in case of a PDF document this seems a bit redundant and prone to be lossy: first you paint the PDF on the QPrinter object and then the QPrinter object converts its content back to PDF for printing (at least on CUPS platforms). I understand that the set of problems you mention are indeed a consequence of the first conversion. Maybe if Qtpdfium grows a PDF->Qpainter rendering path that might overcome some of the limitations of the poppler rendering path, but still the QPrinter route appears to me as not the most efficient one. For complex PDFs it could also slow things down a bit. Is my understanding correct? A few more questions: 1) Is the conversion to ps currently done by poppler? I see a Poppler::PSConverter object being used. If so, regardless of the conveniency of practicing the intermediate postscript conversion is there a poppler bug ultimately? Should an issue be opened with them? 2) when you ask for the rasterization, is the rasterization always happening at 300x300 dpi in unix regardless of the printer resolution? I see mention to a discussion at https://git.reviewboard.kde.org/r/130218/, but that site is dead. Thanks again! I have opened a request for feedback or for participation in the discussion on the poppler tracker: https://gitlab.freedesktop.org/poppler/poppler/-/issues/1377 > Okular currently converts pdf files to postscript and sends that to the printer (I forgot why exactly).
Because thousands of years ago printing PDF files directly was not something that worked.
(In reply to Albert Astals Cid from comment #10) > > Okular currently converts pdf files to postscript and sends that to the printer (I forgot why exactly). > > Because thousands of years ago printing PDF files directly was not something > that worked. So, would resurrecting the patch mentioned by Oliver be the best option as of today? As long as there is the intermediate postscript conversion, do you thing that the observed behavior is indeed a poppler bug (i.e., that https://gitlab.freedesktop.org/poppler/poppler/-/issues/1377 is a bug?) A possibly relevant merge request was started @ https://invent.kde.org/graphics/okular/-/merge_requests/704 1) Yes, poppler is used 2) On Windows, rasterization resolution follows the printer. Elsewhere, 300dpi is hardcoded. (In reply to Oliver Sander from comment #13) > 1) Yes, poppler is used > > 2) On Windows, rasterization resolution follows the printer. Elsewhere, > 300dpi is hardcoded. That conversion also messes with embedded fonts when you use virtual PDF to file. See https://discuss.kde.org/t/okular-printing-bug/14546/8 |