One part of writing a PDF converter is making sure that the fonts embedded within the PDF are accessible to the target platform. For PDF to HTML, this means converting a range of fonts in different formats into a format accepted by browsers. This is a significant challenge due to the wide range of font renderers used by browsers. We’ve found that using the Web Open Font Format (WOFF) provides the best support across browsers, and have set this as our default format for generated fonts.
Despite this, when debugging fonts we generally generate OpenType fonts. The reasons for this are simple – the formats are almost identical, using the same tables with a slightly different index structure, and there are far more tools available for working with OpenType fonts than WOFF.
So without further ado, here are 6 tools we use to make sure the fonts we generate will work in browsers.
The first step is to open Firefox and load a page which uses the font you want to test.
Both Firefox and Chrome use a piece of open source code called the OpenType Sanitiser (OTS) which checks that fonts are properly formed (and a little more besides!) before passing them on to the font renderer.
Unlike Chrome, Firefox actually includes small reports on rejected fonts in its console. It only tells you which table was the reason for the rejection, but this is a good start!
MS’s Font Validator
It’s worth noting that it lacks proper support for CFF based OpenType fonts, and that browsers and Font Validator consider different aspects of the font important. For example, many things that OTS rejects are not picked up by Font Validator and vice versa. It’s still a good place to get a general idea of what could be causing problems, though.
If you need a general look at the data inside an OpenType font, I can recommend nothing better than Dutch Type Library’s DTL OTMaster.
The first thing it offers is an overview of the glyphs in the font. You can double-click on any glyph to launch a more detailed view which shows associated data from elsewhere in the font.
It also offers a tree representing the data structure of the entire font, allowing you to see the values in every table. The only thing it doesn’t include is the details of the glyph descriptions for CFF based OpenType fonts.
In addition to the free version, there is a paid version which can also change and save the values in the font.
When it comes to graphically examining or modifying glyph outlines the only real open source choice is FontForge. It’s only occasionally of use with broken fonts, though, as it reports relatively few errors and tends to save out your font in a completely different way to how you first read it in. However, it is often useful to look at glyph coordinates, mapping data and glyph metrics, and FontForge does a fine job of that, too.
When it comes to actually editing fonts, often the fastest way – especially if you’re as familiar with the specifications as we are – is to edit the binary by hand. While a lot of tools exist for working with data in Hexidecimal, we couldn’t find anything that could edit and annotate data the way we wanted. Because of this, we put together a tool called (rather unimaginatively) BinaryTool.
BinaryTool can open files from the disk or be called directly from code with a byte array. It then allows you to annotate the file to keep track of what each byte does and save it out either with or without the annotations. In fact, when launching from code with a byte array, you can specify an existing file with annotations for it to update, letting you keep all of your existing annotations and see what’s changed using a Diff algorithm.
It also has a few features for automatically annotating files, jumping to specified offsets, and evaluating mathematical expressions.
In this example, I could erase the incorrect bit and replace it with a 0. The middle column with update automatically with the new, correct, value of 3.
For some things like dealing with Type 1/CFF glyph outlines, there aren’t really any tools available. In those cases, BinaryTool is the only option.
Of course, eventually all of this goes to one place – our code for writing out fonts. Once you have an idea of what’s wrong, often the fastest way to test it will be to change our code for writing out the font and give it a go.
Does anyone else find these tools particularly useful? Do you know of any font tools I neglected to mention?
This post is part of our “Fonts Articles Index” in these articles we explore Fonts.
Do you need to write or read JPEG in Java?
We have an easy guide on how to write JPEG in Java using ImageIO and JDeli.
You can learn how to read/write most of the image files in ImageIO. However, it gives little control over the process.
JDeli is easy to use and offers complete support, so why not give JDeli a try?