Summary: | Symbols in formulas of attached PDF not shown | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Till Kamppeter <till.kamppeter> |
Component: | PDF Interpreter | Assignee: | Alex Cherepanov <alex> |
Status: | RESOLVED INVALID | ||
Severity: | critical | CC: | chris.liddell |
Priority: | P4 | ||
Version: | 9.05 | ||
Hardware: | PC | ||
OS: | Linux | ||
Customer: | Word Size: | --- | |
Attachments: | DDGCourse2006-evince-page60.pdf |
Description
Till Kamppeter
2012-05-30 08:55:49 UTC
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. |