Sam Howard Sam is a developer at IDRsolutions who mostly specialises in font support and conversion. He's also enjoyed working with Java 3D, Java FX and Swing. His other interests include music and game design.

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

2 min read

Fonts
PDF CFF Fonts Problems and how 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.

If you’re a first-time reader, or simply want to be notified when we post new articles and updates, you can keep up to date by social media (TwitterFacebook and Google+) or the Blog RSS.

Sam Howard Sam is a developer at IDRsolutions who mostly specialises in font support and conversion. He's also enjoyed working with Java 3D, Java FX and Swing. His other interests include music and game design.

Converting your PDF files to HTML5 with BuildVu 

Recently we announced our updated product range for 2018 and are rebranding some existing products, like JPDF2HTML5 which has been renamed to BuildVu. It...
Georgia Ingham
3 min read

Leave a Reply

Your email address will not be published. Required fields are marked *