Truetype fonts (which are used in many places including PDF files) consist of a set of tables. These tables include the Glyf table defines the actual shapes of the characters, and the CMAP table which define which glyf maps onto each character. Because Truetype fonts are designed to work on multiple platforms and with different languages, it is possible to to have several CMAP tables in different formats. So far so good. We can see the tables disassembled in lots of tools – here is a view of a Truetype font in Acrobat 9.0
There are 2 CMAP tables present. As I had a problem with character 224, I checked the tables and found that they gave different results. In theory they should return the same answer.
In this case the CMAP tables give inconsistent results. In PDF files, there is an order of preference for using CMAP tables and in general format 0 should be used in preference to format 4.
So I did some tests on my PDF file collection (after many years working with PDF files I have a ‘small selection’ which I use for regression tests) and found that some contained broken format 0 and some contained broken format 4. The PDF user has to work out which table is correct.
So do not always assume that you can use all the CMAP tables in a font reliably (and make sure you have some decent tools available if you need to investigate). Do you trust your CMAP tables?
Are you a Developer working with PDF files?
Our developers guide contains a large number of technical posts to help you understand the PDF file Format.
Do you need to solve any of these problems?
|Display PDF documents in a Web app|
|Use PDF Forms in a web browser|
|Convert PDF Documents to an image|
|Work with PDF Documents in Java|
2 Replies to “Are your Truetype CMAP tables lying to you?”
It is incorrect to assume you can go through just any “cmap” in a TrueType font (not be mixed up with “CMap”, and not to be written as “CMAP”) with a character code from your PDF in your hands.
Before you go to a “cmap” to need to check the encoding information in your font dictionary. Then you have to find the Unicode code point for that character, then you look inside the font into any of the “cmap” tables to see whether one (or sevral) of them can map your Unicode codepoint to a glyph.
This is slgihtly different for symbolic TrueType fonts, as here there should only either be a single “cmap” or a pair of MacRomandEncoding and Microsoft symbolic encoding (which have to agree on the mapping), and only in this case do you go from character code to the index value in either the “cmap” tables.
Now, I won’t claim there never could be a TrueType font that still gives different results even base on the lookup I described – but then that indeed would be a bug in the font (and I’d like to see sample files for that….).
PS: The text inside the PDF standard is pretty clear about all this, though admittedly it is not an easy read… (check out http://www.adobe.com/devnet/pdf/pdf_reference.html )
PS: On the PDF Association’s website http://www.pdfa.org there is now a brand new discussion forum for topics like this one, and a wide range of excelllent experts are watching the space (and tend to come up with their take often within hours…) – check out http://www.pdfa.org/ .
Thanks for clarifying.