About

Cufón aims to become a worthy alternative to sIFR, which despite its merits still remains painfully tricky to set up and use. To achieve this ambitious goal the following requirements were set:

1. No plug-ins required – it can only use features natively supported by the client
2. Compatibility – it has to work on every major browser on the market
3. Ease of use – no or near-zero configuration needed for standard use cases
4. Speed – it has to be fast, even for sufficiently large amounts of text

And now, after nearly a year of planning and research we believe that these requirements have been met.

So, how does it work?

Cufón consists of two individual parts – a font generator, which converts fonts to a proprietary format and a rendering engine written in JavaScript.

The generator

In reality the generator is little more than a web-based interface to FontForge. First, the generator builds a custom FontForge script based on user input and then runs it, saving the result as an SVG font. The SVG font is then parsed and SVG paths are converted to VML paths. This is a crucial step in achieving stellar performance in Internet Explorer, as it supports VML natively. The resulting document is then converted into JSON with a mix of functional JavaScript. This has numerous advantages:

1. To include a font, you only need to load it with the standard <script> tag as any other JavaScript file and it will be registered automatically
2. There is no need to manually parse the file on client-side again
3. External JavaScript files block execution until they have loaded, which helps us to achieve a flicker-free, clean replacement
4. It compresses extremely well. While often somewhat large in terms of file size without any compression, a compressed font usually weighs in 60-80% less than the original.

The process is then repeated for the rest of the fonts given to the generator (if any) and the resulting JavaScript file is sent back to the client with a distinctive filename.

The renderer

The renderer is a bit more complicated. It consists of 3 parts – a Core, which provides the API and common functionality, and two rendering engines. One of them renders VML shapes and is used for Internet Explorer (it supports VML from version 5.5), while the other one uses the widely supported HTML5 <canvas> element. Due to the path data already being VML, little work is needed in the VML engine. The canvas engine, however, must convert all paths to the corresponding sets of drawing commands provided by the canvas API. This turned out to be somewhat tricky at first, but a solution was found after two complete rewrites in the form of code generation and caching, resulting in a very fast renderer.

Inline SVG was also considered but quickly turned down due to it being surprisingly slow in the few browsers that actually support it properly.