Created attachment 56632 [details] One example of a document where text is not displayed Version: 0.12.4-1.2 (Debian squeeze) On some documents, text is not displayed at all. I've attached one of them, and a screenshot of how it is displayed to me. It is however possible to select and copy the text correctly. It happens on any PDF viewer I've tried (evince, epdfview, okular, xpdf). You can also download the PDF file from here: http://www.sprachenzentrum.fu-berlin.de/downloads/Ablauf_20111221.pdf
Created attachment 56633 [details] Screenshot of the display of the above document
Works for me. Do you have poppler-data installed?
I just installed it, however still the same result. (I've also reinstalled all poppler packages, in case there's some caching stuff or so.) These are all packages available in my system named something with poppler (i means it is installed), do I have to install some of them? p gir1.0-poppler-0.8 p libpoppler-cil p libpoppler-cil-dev p libpoppler-cpp-dev p libpoppler-cpp0 i libpoppler-dev i libpoppler-glib-dev p libpoppler-glib-ruby p libpoppler-glib-ruby1.8 p libpoppler-glib-ruby1.8-dbg i A libpoppler-glib4 p libpoppler-glib6 p libpoppler-qt-dev p libpoppler-qt2 i A libpoppler-qt4-3 p libpoppler-qt4-dev p libpoppler13 i A libpoppler5 p libpopplerkit-dev p libpopplerkit0 p monodoc-poppler-manual i poppler-data p poppler-dbg i A poppler-utils p python-poppler p python-poppler-dbg p python-poppler-qt4 v python2.5-poppler v python2.5-poppler-dbg v python2.6-poppler v python2.6-poppler-dbg v python2.7-poppler v python2.7-poppler-dbg p ruby-poppler p ruby-poppler-dbg
Works for me on Debian Squeeze using the same version of poppler. According to pdffonts some fonts are not embedded. You could run fc-match <fontname> to see what font will be substituted and reconfigure fontconfig to use a different font. Does the problem occur when using pdftoppm?
The problem does occur with pdftoppm. Here is the output of fc-match: > ~$ fc-match Arial > arial.ttf: "Arial" "Normal" > ~$ fc-match Arial,Bold > arial.ttf: "Arial" "Normal" > ~$ fc-match 'Times New Roman' > times.ttf: "Times New Roman" "Normal" I've tried with another account on this system, there it does work. So I tested a little and found out that when I move away my .fonts directory, it works. I'll try to find out which particular font it is. Thanks for your help so far!
Created attachment 56940 [details] the file that breaks it With this file inside my .fonts directory, display is broken, without it, it's fine.
I can reproduce the problem by putting that font in ~/.fonts. It turns out that fc-match is not the best way finding the substitution font. For example: > fc-match Arial LiberationSans-Regular.ttf: "Liberation Sans" "Regular" But pdfonts in git master has a new option to show the substitution font. Using this feature shows a different font: > pdffonts -subst bug45659.pdf name object ID substitute font substitute font file ------------------------------------ --------- ------------------------------------ ------------------------------------ Arial 5 0 Helvetica Fractions /home/ajohnson/.fonts/hvfr____.PFB Arial,Bold 7 0 Helvetica Fractions /home/ajohnson/.fonts/hvfr____.PFB Times New Roman 24 0 Nimbus Roman No9 L /usr/share/fonts/type1/gsfonts/n021003l.pfb Looking at the hvfr font in fontforge shows that the only glyphs it contains are fractions. This explains why the text is not displayed. I also tested with the xpdf303merge branch and the was text correctly displayed. According to pdffonts the Liberation Sans font was substituted: > pdffonts -subst Ablauf_20111221.pdf name object ID substitute font substitute font file ------------------------------------ --------- ------------------------------------ ------------------------------------ Arial 5 0 Liberation Sans /usr/share/fonts/truetype/ttf-liberation/LiberationSans-Regular.ttf Arial,Bold 7 0 Liberation Sans Bold /usr/share/fonts/truetype/ttf-liberation/LiberationSans-Bold.ttf Times New Roman 24 0 Liberation Serif /usr/share/fonts/truetype/ttf-liberation/LiberationSerif-Regular.ttf I'm not sure what changed in xpdf303merge to change the font substitution but it looks like this bug will be fixed when xpdf303merge is merged to master.
> I'm not sure what changed in xpdf303merge to change the font substitution but it looks like this bug will be fixed when xpdf303merge is merged to master. Okay, that sounds good, then that bug seems solved both for me and in the libraries. Thank you!
xpdf303 has been merged to master.
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.