Created attachment 124703 [details] example pdf When I download my credit card statements for a particular (large) bank. Most of the text is not visible. However, if I select 'print preview' or print, the text is there. (All text is visible using xpdf.) It's almost like there are 2 layers - generic background text (bank name, some legalese) which is visible, and then all the normal information (address, transaction information) which is not. This is just with one company. My other statements work fine. poppler-0.34.0-2 poppler-glib-0.34.0-2 poppler-utils-0.34.0-2 poppler-qt-0.34.0-2 poppler-qt5-0.34.0-2 poppler-data-0.4.7-4 poppler-sharp-0.0.3-8 I filed a bug against okular, and they passed the buck upstream to you guys. https://bugs.kde.org/show_bug.cgi?id=364246
Created attachment 124704 [details] okular view
Created attachment 124705 [details] okular print preview
*** Bug 96856 has been marked as a duplicate of this bug. ***
I believe I'm experiencing this same bug from PDFs generated by the same bank. I can add some more details. The poppler qt4/demos/poppler_qt4viewer fails in exactly the same way that okular v0.21.3 does. I compiled poppler from today's git master branch. The file displays properly in both older evince (2014) and xpdf (2014). xpdf reports this message thousands of times to stderr: "Syntax Warning: Save (q) operator before d0/d1 in Type 3 glyph" The document says it was produced by the "OpenText output transformation engine 5.2"
These commands produce correct output on my system: pdftops infile.pdf out.ps gs out.ps Whatever is wrong seems very specific to Qt4 and Qt5.
mjs have you tried pdftoppm? I'd prefer that you check your facts before saying the problem is in one specific part of the code when it really isn't.
I did not say "the problem is in one specific part of the code". At this point, I am treating poppler as a black box, since I am not familiar with its internals. pdftoppm does not render the document correctly. Nearly all the text and graphics is missing. So pdfcairo and pdftops work fine, but okular (and poppler_qt4view) and pdftoppm do not. Is there some commonality or difference between these that gives a hint where to look?
Well, let me quote you "Whatever is wrong seems very specific to Qt4 and Qt5.". anyhow, yes, splash backend, are you going to work on a patch?
Created attachment 127695 [details] [review] merged changed type3 glyph handling from xpdf 3.04 xpdf 3.04 changed its handling for wrong used type3 glyphs a little bit, therefore it works with xpdf 3.04. I merged these changes now into poppler code, here the resulting patch.
Pushed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.