https://bugs.kde.org/show_bug.cgi?id=467328
--- Comment #7 from Sergio <sergio.calleg...@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.
