GNOME Bugzilla – Bug 791746
pdf 1.7 decode removes chars from text made by (PDFium)
Last modified: 2017-12-19 14:15:04 UTC
Version: evince-3.24.2-1.fc26.src.rpm I have a PDF made with <</CreationDate(D:20171214091108)/Creator(PDFium)/Producer(PDFium)>> which i can give you for testing, as it contains personal data, in which evince removes all big i's dashes and dots ( I - . ) from the text blocks. As this is a major defect, because i need to print this to get a contract, is there any way to give you more test data without posting confidente data ? The creatortool in use is not mine, so i can't get a test pdf for you. Other PDF's with i.e. v1.4 made with i.E. PDFCreator 2.2.2.0 working normally.
It may be an issue in Poppler (the library used by Evince to render PDFs). To narrow the issue: $ pdftocairo doc.pdf -png output ... Check output-* (png files) with an image viewer. If you can reproduce the issue, then it is in Poppler, in the cairo frontend. But you can continue narrowing the issue: $ pdftoppm doc.pdf output Check output* (ppm files) with an image viewer. If you can still reproduce the issue, it is in Poppler (general). Otherwise, it is a bug in Evince. If the bug is in the Poppler, please file a bug report in Poppler's bug tracker: https://bugs.freedesktop.org/enter_bug.cgi?product=poppler If you can create another PDF, without sensitive information and still reproduce the issue, you can attach that.
It's not in poppler .. I just checked it, got rendered perfectly. NOW it gets STRANGE! I reopened the document in question and now it's rendered perfectly. I have 2 printouts laying around here, that proove the opposite. So i printed it again, and voila.. big I and . gone.. It got lost while printing, but i also did not see it in the viewed version, 2 hours ago. Which component renders it for printing ? I printed another pdf (pdfv1.4) and that got printed out correctly, nothing missing. I will add some pics to illustrate it.
Created attachment 365719 [details] page 4 outputed by pdftocairo
Created attachment 365720 [details] same region, just printed out and photographed.
Poppler and cairo sometimes draw differently depending on what surface they're drawing to. Try it with "pdftocairo doc.pdf -pdf output.pdf" and see how output.pdf looks. Also see how the PostScript output looks ("-ps" instead of "-pdf") because some printers are set to use one or the other. If it's bad on one of those, it's likely a problem with cairo. If it looks good there, then I don't know. It could be a problem specific to your printer or driver.
Result of : pdftocairo KFZ\ 2018.pdf -pdf output.pdf Missing "I" and "." all around the document. Result of : pdftocairo KFZ\ 2018.pdf -ps output.ps Missing "I" and "." all around the document.
PS export checked and verified with GIMP: still "I" and "." missing. PDF result verified with Xpdf: still "I" and "." missing.
Original PDF with XPDF => nothing missing. Original PDF with Evince => nothing missing.
XPDF printed out : nothing missing Conclusion: Cairo defective Who is responsible for Cairo ? .. FreeDesktop.org ... not sure if i have a bugzillla account there.
Poppler using Cairo frontend. Poppler's bug tracker: https://bugs.freedesktop.org/enter_bug.cgi?product=poppler