Created attachment 8635 [details] DDGCourse2006-evince-page60.pdf Attached is the evince-mangled page 60 of the document attched to this Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/1006263 The original document is correctly displayed by both Ghostscript and Poppler and the attached page is also correctly displayed by Poppler. If one renders the attached page with Ghostscript (output device does not matter, screen display via "gs DDGCourse2006-evince-page60.pdf" already shows the problem), one sees the missing symbols ("(", ")", "-", ",") in the formulas, especially S(t) in the upper left part, or S(i_0, i_1, i_2, i_3) in the middle-left. This causes problems when printing in Ubuntu and Debian, as PDFs are often displayed and printed with evince and for most printers the PDF output of evince is processed by Ghostscript.
As attachment sizes are restricted on this bug tracker, here are the links to the files on Ubuntu's bug tracker: Original PDF file: https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/1006263/+attachment/3168809/+files/DDGCourse2006.pdf Sample page: https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/1006263/+attachment/3168803/+files/DDGCourse2006-evince-page60.pdf
Sorry, the previous comment was intended for another bug tracker, as usual ...
This is a bug in the font embedding. Take, for example, the font "Computer Modern", which is embedded with the FontName CairoFont-5-0. The font stream for this font contains this: /Encoding 256 array 0 1 255 {1 index exch /.notdef put} for dup 1 /braceleftbigg put readonly def Then a few lines later, it contains this: /Encoding StandardEncoding def So, Ghostscript, Acrobat and other interpreters are (correctly) using the later definition of Encoding, which is StandardEncoding, which does not have "/braceleftbigg" at index 1 in the array. Poppler, xpdf (presumably via Freetype) are incorrectly using the first definition of Encoding. Note that the "readonly" operator refers to the *array* - so the array contents are read only, but Encoding entry in the font dictionary remains writable. Removing the erroneous Encoding entry causes the GS output to be as intended (I didn't use the word "correct" here, as the GS output is actually "correct" either way, since the file's meaning changes with that edit). All the mathematical symbol fonts have the same fault, the other fonts in the file do not have this problem. So Cairo is emitting a broken font, and it should revised so that it only writes the intended encoding, and not the erroneous "StandardEncoding" instance.
Problem fixed in Cairo (https://bugs.freedesktop.org/show_bug.cgi?id=50496) Thank you very much for your help.