Top 4 problems in PDF CFF Fonts (and we fixed them for our HTML5 conversion)

One of the most common of the many font formats PDFs support is the Compact Font Format (CFF, also known as Type 2) – a condensed version of Adobe’s Type 1. CFF is not supported directly by browsers, but can be wrapped in OpenType (and derivatives like WOFF and EOT) along with a number of other tables.

Unfortunately, though, a considerable proportion of CFF fonts contain errors which – while not a problem for most PDF viewers – cause the fonts to be rejected by browsers. Here’s a few we fix during conversion!

1. Unknown keys in dictionaries

CFF fonts contain a few dictionaries which contain a list of optional keys and values. These are used for a range of purposes like associating Strings within the font with fields (such as setting the name/copyright information of the font), providing values for hinting systems, and in many cases recording the offset within the file to another section.

Unfortunately, three and a half years after the first specification of the format was published, a revision was put out removing two of these keys – ForceBoldThreshold and lenIV. These are still found in a few files, so we have added some code to remove them (and update all the offsets in the file).

2. Dictionary keys with the wrong number of values

Along similar lines, some fonts contain keys like BlueValues, which is used for defining alignment zones used in hinting. Each zone is defined using one integer to represent the bottom of the zone, and another to represent the top of the zone.

We have a file which has 9 integers set as the value of BlueValues. We also have a file which has no value for the key at all (but the key is still present). We have written code to check that the keys all have a suitable number of values associated with them, and code to fix these values or ditch the key entirely if they are found.

3. Deprecated commands in glyph descriptions

Similarly to the problem of deprecated keys appearing in dictionaries, a number of commands used in glyph descriptions have since been deprecated. There used to be a command to denote that a dot (like the one in ‘i’) is about to be described, as well as commands for storing and loading numbers.

4. Missing ‘endchar’ command

The set of draw commands for each glyph is always supposed to finish with an ‘endchar’ command. Predictably, some fonts have ignored this rule and relied on the renderer using the offsets to know when a glyph description ends. Browsers, due to their obsession with stability and security, rely on font renderers as little as possible and ignore these fonts, so we always make sure to add them if they are missing.

We’ve seen some other odd issues in our time – I recently saw a font with a large amount of blank data between the Private DICT and local Subrs, for instance – but these are the most common issues our code has to fix in CFF fonts so far.