Bug#721137: ghostscript: ps2pdf produces bad pdf on x86_64 (unreadeable text)
Hi!
Some other matters lead me to learn a bit of the pdf format, so I've tried to
investigate some more this bug.
First, the ps2pdf shipped with Jessie seems to still produce the same pdf
out of my test.tex / test.dvi / test.ps (with only a few minor textual
differences in optional fields such as metadatas).
Secondly, the pdf viewers available in Jessie are doing a better job
at displaying this test.pdf:
- Evince (or actually the underlying poppler library) is now displaying correctly
this problematic pdf. Try for instance 'pdftocairo -png test.pdf test.png'.
- Xpdf is still displaying correctly these pdf, but still with the warning
about "Bad bounding box in Type 3 glyph".
- I tried to use directly gs for rendering to png, and it works fine:
gs -dSAFER -dNOPAUSE -sDEVICE=png16m -dTextAlphaBits=4 -dBATCH -dGraphicsAlphaBits=4 -dQUIET -r100 -sOutputFile=test.png test.pdf
- The only issue left is with the mupdf viewer (or its command-line tool mudraw).
I've attached the png obtained from the original test.pdf via:
mudraw -o test.png test.pdf
It looks exactly as the earlier faulty display (three black dots instead of
the expected text) that was obtained via Wheezy's evince.
Anyway, I still think that ps2pdf is producing an erroneous pdf, and that the various
pdf viewers are doing there best to overcome this issue. Indeed, as hinted by the
xpdf warnings, the /FontBBox [0 0 1 -1] in test.pdf looks quite wrong.
NB: Actually, I inspected an uncompressed version of test.pdf, obtained by
'pdftk test.pdf output testu.pdf uncompress' , but you could do the same thing
with the original test.pdf.
In particular the last number in /FontBBox is the max height of characters (inversed
by a -1 in /FontMatrix). If we enlarge this height, say to a /FontBBox of [0 0 1 -25],
we start seeing in mupdf the lower half of the characters of the text "Bla Bla Bla".
If you continue to a /FontBBox of [0 0 1 -58], the text is displayed correctly
(I've tried 58 since it seem to be the largest height of the four bitmap characters
in the text (see /H in the uncompressed pdf). Strangely, the width doesn't seem to
need any fixing in the /FontBBox, probably because of the /Widths directive.
This faulty FontBBox seems indeed to be introduced by ps2pdf, since there's apparently
a /FBB[0 0 0 0] and a /FootBBox FBB in the initial test.ps. I really don't know much
of PostScript, but that looks like a [0 0 0 0] FontBBox, meaning "autodetect" ?
Btw, trying a [0 0 0 0] FontBBox in test.pdf doesn't please mupdf (back to a few black
dots).
Finally, a few words about the latex code (my previous test.tex) that lead to this issue.
After some more googling, it appears that using \usepackage[T1]{fontenc} is fine, and even
a good idea (see for instance [1]). But this line is normally meant to be used in combination
with some extra font package, e.g. \usepackage{cm-super} or \usepackage{lmodern} or
\usepackage{ae}, the latter being my favorite. With any of these font packages, we obtain
nice Type 1 fonts, while the T1 fontenc alone leads to the use of Type 3 fonts (see [2]), and
these Type 3 fonts seem to be a frequent source of issues. In particular here, my original
test.tex with an extra \usepackage{ae} leads (still via dvips and ps2pdf) to a pdf
which displays ok, even with mupdf. Nonetheless, it would be nice to fix this issue with
Type 3 FontBBox.
Best regards,
Pierre
PS: I also tried ps2pdf on an i386 machine, but the behavior was the same as what I describe
above for amd64. Strange, since for the initial reporter this bug was apparently
architecture-related ?
[1] http://tex.stackexchange.com/questions/664/why-should-i-use-usepackaget1fontenc
[2] http://tex.stackexchange.com/questions/1291/why-are-bitmap-fonts-used-automatically
Reply to: