[okular] [Bug 467328] Okular mismanages fonts embedded in PDF document when printing

[Sergio]

https://bugs.kde.org/show_bug.cgi?id=467328

--- Comment #7 from Sergio <sergio.callegari at gmail.com> ---
(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?

-- 
You are receiving this mail because:
You are the assignee for the bug.