Fonts have been a source of annoyance as I’ve worked on Slide Drive’s LibreOffice-SVG importing. SVG doesn’t have any way to flow text like it does in a web page; it must be positioned on a per-line or per-character basis. This makes it particularly important to get fonts right. If text is positioned per-line, using the wrong font will cause lines to be too short or too long, possibly ruining the slide layout. If text is positioned per-character, using the wrong font will cause the inter-character spacing to be really off, making it ugly and much more difficult to read.

Things initially looked good: Marco Cecchetti programmed LibreOffice’s SVG exporting feature to embed copies of all necessary font/characters combinations in the exported document. It seemed like users would be able to use any fonts they wanted without needing to worry. Unfortunately, I soon realized that Firefox does not support embedded fonts in SVGs. This isn’t going to change, either: they chose not to implement them because of concern that it could harm adoption of the Web Open Font Format.

Tools exist to convert between these formats, but none of them are in JavaScript, which is the only thing we’re using on the client and the server (Node.js). We’re left with nothing but the fonts that happen to be installed on the users’ systems.

There are a handful of “safe” fonts that we can expect to find on 90%+ of clients. There are no fonts with 100% reach. Most fonts, including the widely-used ones like Arial, are proprietary and aren’t always available on *nixes. However, a couple of alternatives each for Arial, Times New Roman and Courier New have been designed with the goal of perfectly matching the kerning/spacing of the original fonts. These won’t appear identically, but they shouldn’t maintain the readability and layout of the originals.

The “Liberation” font set is one of these alternatives, and is becoming incredibly popular on Linuxes. Where it isn’t supported, Google has their own set that are available through Google Web Fonts, providing a cross-platform option (at least when Internet is available).

So, here’s the approach I’m going with: include a list of alternatives for many common fonts. The top priority are fonts with identical metrics, as mentioned above, but at a lower priority we’ll include approximately-similar fonts, and finally fall back to a generic font category (serif, sans-serif or monospace). For each font in the document, try the following options in order:

  • Check if the font is installed on the system.
  • Check if the font is embedded in the SVG, if supported.
  • Check if any of the fallback fonts are installed.
  • Check if any of the fallback fonts are available through Google web fonts.
  • Give up.

When the user is creating a presentation, they’ll be warned if they use a font that we don’t expect to be “safe”, and warned more strongly if they use a font we don’t recognize at all (i.e. have no fallbacks for, of any quality).

This isn’t perfect, but it should provide the best experience possible in most cases.