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