We’ve mentioned the Sanitiser for OpenType (OTS) before, but have never really gone into detail about why it exists, what it does, and why it occasionally makes our lives a little harder. Essentially, it is a library for making sure that the font rendering engines used by browsers don’t crash due to unusual OpenType or WOFF font files. Browsers use different font renderers on different platforms, so the rules are quite strict to make sure files will work on all of them.
To use a rather odd but oddly accurate analogy, OTS is like a bouncer at a club who’ll try giving you a makeover instead of turning you away for not following the dress code.
Here’s some examples of the dress code:
‘searchRange’ and ‘rangeShift’ fields must be correct
This is a big one, with as many as 25% of font files containing incorrect values for searchRange, according to a note left in OTS’s source code. Luckily, our friendly bouncer is willing to fix it and let you in.
Deprecated CFF features like ‘ForceBoldThreshold’ must not be used
Admittedly this is a less common issue, but Adobe have removed several parts of the Compact Font Format specification over time, including ForceBoldThreshold, lenIV and dotsection commands. Unfortunately, our bouncer has never heard of any of these and doesn’t know how to deal with it, so you’re turned away.
I have two theories on why this happens. The first is that older versions of the CFF specification were not checked when developing OTS, so OTS just doesn’t recognise the features as valid and rejects the file. The second is that one of the font renderers has problems with these features, and the problems are rare enough that it wasn’t considered worth writing code for fixing.
Values in ‘gasp’ table must be correct
The ‘gasp’ table contains information on which grid fitting and scan procedures to use when rendering the font. If the values are wrong, our bouncer decides that you don’t really need it anyway, and throws the table out entirely. The renderer uses default values and everything is fine, although the clarity and readability of the text might suffer a little.
Of course, this is just a tiny subsection of the list – there are hundreds of ways in which a file can fail.
Adobe Reader, however, has always had a ‘try and make it work’ attitude when it comes to broken files – both for PDF files, and the font files they often contain. This has resulted in a lot of odd, outdated or broken fonts being used. Of course, when you convert fonts from such a permissive environment and use them in a much stricter one, problems will show up! This means that we often actually need to fix or update fonts before we even convert them.
Of course, the result for web users is extremely stable browsers. Browsers definitely need a bouncer, so we’re at least lucky that it’s a friendly one!
Latest posts by Sam Howard (see all)
- PDF to HTML5’s Holy Grail – Vertical positioning for PDF fonts - October 8, 2015
- WOFF 2.0: What is it, why is it coming, and what’s next? - April 2, 2015
- Web fonts: A quick introduction to Wrapper and Glyph formats - February 27, 2015
- 5 tips for using fonts in HTML5 - January 29, 2015
- A Beginners introduction to Unicode - December 4, 2014