Recently, there’s been a spat of editorials regarding custom fonts for the web—with two competing proposals (Microsoft’s EOT and embedding a TrueType font directly with the @font-face directive), as well as the well known Fahrner Image Replacement technique, and the related sIFR (Scalable Inman Flash Replacement) technique.

I’m pleased to announce yet another technique: rendering SVG font definitions using dojox.gfx, coming in the Dojo Toolkit 1.2 release!

Fake newspaper demo

The problem

Custom fonts for the Open Web have been a pain-point since almost the beginning of the Web. Plagued by a number of issues, typography for the Web has been limited to working with a subset of fonts that can be reasonably expected to be installed on everyone’s computer. The reasons for this stagnation include the following:

Font licensing issues

One of the main reasons custom fonts have not found a good home on the Web has to do with licensing issues—simply linking to a True Type font (a la the @font-face directive) enables font piracy in the worst way. Jeffrey Zeldman said it best, in this comment (scroll down to the third comment, unfortunately there are no direct links available):

The problem with @font-face is that it violates the font manufacturing license agreement with the end-user. Put simply, it readily enables font piracy. Any font embedded this way can be downloaded to the web viewer’s machine, and used as if he or she had paid for the font. Hacker skills are not required. The ability to download embedded fonts is readily discoverable to any competent browser user.

Fonts are closely and jealously guarded by most creators; simply put, it takes an incredible amount of effort to create one well. Because of this, most font manufacturers limit licenses to a single computer. To make it worse, most fonts cannot be copyrighted—this is because almost all fonts can be considered derivate works (i.e. most have a beginning from somewhere in the days before digital typesetting).

To try to satisfy both the licensing issues that come with most fonts, and to prevent font piracy, a few proposals have been made.

Embedded Open Type (EOT)

The most promising (in terms of satisfying both font manufacturers and web users) is Microsoft’s Embedded Open Type proposal. The basic concept is for a legitimate font license holder to convert their font to the EOT format (using Microsoft’s tools), binding the font to the web site serving it. Recently, Microsoft has teamed up with the Ascender Corporation (a major font manufacturer) to try to bring the EOT specification to the W3C, as well as providing online tools for converting a font to the EOT format.

The problem with the EOT concept though is that only Internet Explorer supports it; none of the other browser manufacturers have been willing to implement it.

Font Linking

Another approach is direct font linking, recently added, and then removed (as far as I can discern), in Apple’s Safari 3.1 browser. The problem with this approach is that it violates most font license agreements; the aforementioned Font Embedding site has a pretty good explanation of why it violates most agreements.

Image replacement techniques

The most common technique used today for custom typography is to create an image with the desired typography, and use CSS techniques to replace text with them. Both static and dynamic techniques can be used; sIFR is probably the best known, and a number of other sites will implement something like a PHP/GD stack, where the server is called with the text and parameters required, and the server generates the image on-the-fly and sends it back out to the client.

Revisiting font licenses

Two other efforts have been quietly underway to create Open Source-based licensing schemes for fonts. The first is the SIL Open Font License, designed to allow for modification and redistribution; the other is releasing a font under the GNU with font exception license. While the OFL seems like a genuine effort, some restrictions still make it difficult to use for the Web; the GNU with font exception is the license of choice for fonts included with Linux. (Also, an honorable mention goes out to the Creative Commons for their efforts with this thorny issue.)

A solution

In general, the issues surrounding font usage have to do with the ability for someone to visit a web site, grab a specific file, and be able to reuse it without paying for a legitimate copy within any of the most commonly used programs (such as Office). Because of this concern, both the EOT and sIFR techniques work–because the fonts are embedded in a form that is not reusable in a common way.

One approach: the SVG Font Specification

Similarly, the SVG Font specification allows for the same concept—by working with a specific font definition, especially one that can be customized for the specific usage, the spec avoids most of the prickly issues surrounding licensing.

SVG fonts are relatively simple in concept; within the <defs> element, you define the main specifications of a font, and then you include specific glyph definitions. Optionally, you can include character-specific kerning information (the space between letters); some fonts include this type of hinting, and the SVG specification supports it.

Implementing the SVG Font specification with dojox.gfx

By taking the approach of loading an SVG font definition, parsing it and translating it to the dojox.gfx API, we were able to implement the ability to use custom font definitions within the context of native browser support. No plug-ins are needed; just generate your font, and go. Here’s an example using two “free-as-in-beer” fonts to create a page similar to one of the sIFR demonstrations (screenshot below):


Fake newspaper demo

To create the page, we use two fonts (a serif font based on Bookplate, and another based on a Eurostyle font), and dynamically swap out certain elements onload (a la sIFR). In addition, there are two other demonstrations—an example of customized pie charts, and a playful comic, showing how the font replacement works on the fly:

Comic demo

(Yes, that’s my mug shot; I traced it using Adobe Illustrator and converted it to dojox.gfx. You can make me say whatever you’d like =) )

Using dojox.gfx.VectorFont

Using the fonts are simple yet somewhat complex; unfortunately this is the nature of the beast. In future revisions, simpler APIs will be introduced; for now, you draw your text using the font directly.

Step 1: Create your font definition.

The first step is to create your SVG font definition. There are a number of tools out there you can use; we used the Batik ttf2svg conversion tool.

One thing that is great about using SVG Fonts is that you can remove the glyphs that you don’t need, minimizing the size of the generated SVG. This is a good thing—some converted fonts can be very large (on the order of 100+ KB) when including all glyphs, so removing them helps us minimize our font file download size.

(Note that unfortunately we cannot work with compressed SVG (i.e. svgz) files.)

Step 2: Load your font

The next step is the load up your font via the dojox.gfx API:

dojo.require("dojox.gfx");
dojo.require("dojox.gfx.VectorText");

var myfont = dojox.gfx.getVectorFont(someUri);

This will locate your SVG definition, parse it and prepare your font for usage.

Step 3: Write something!

To render something, you follow these basic steps:

  1. Create a dojox.gfx Surface to write on
  2. Create a dojox.gfx Group; you’ll use this to write into
  3. Call the font’s draw method.

Let’s take a basic example; we’ll use the font we “loaded” above, and write “The rain in Spain falls mainly on the plain.”.

var s = dojox.gfx.createSurface(someNode, width, height);
var g = s.createGroup();
var phrase = myfont.draw(
    g,
    { text: "The rain in Spain falls mainly on the plain.", align: "middle" },
    { size: "3em" },
    "blue"
);

The font’s draw method (the main method) takes 4 arguments:

  1. the dojox.gfx.Group to render into
  2. a “Text Arguments” object; this is a keyword/configuration object that specifies a number of parameters about the text
  3. a “Font Arguments” object; like the Text Args, this is a keyword/configuration object that specifies font arguments
  4. A fill color

It returns a dojox.gfx.Group; this group is a direct child of the group you passed to the function.

The structure that is generated by the font is pretty complex; there are a lot of groupings and translation transformations. Because of this, we require the original group so that you can perform your own transformations without affecting any of the internal ones created for the phrase. The pie chart example (from above) demonstrates this; all font renderings are rotated based on the position within the chart. In fact, this is one of the greatest strengths of the VectorFont—the ability to create the entire block as any other basic shape in dojox.gfx.

Other features

In addition to straight font rendering using a specific size (e.g. 12px, 3em, “medium”), you can also draw using two other modes: a flow mode, and a fitting mode.

Drawing in flow mode

To draw something in flow mode, you specify two additional named parameters in the Text Arguments object:

    { 
        text: "The rain in Spain falls mainly on the plain.", 
        align: "middle", 
        width: 200, 
        fitting: dojox.gfx.vectorFontFitting.FLOW 
    }

By specifying the width and the FLOW constant, you are asking the draw() method to break your text up, based on the size specified in the Font Args object, into as many lines needed to render the text. This is similar to the way HTML blocks are rendered; one difference is that there’s no overflow, so you need to be careful to ensure your surface is tall enough to accommodate all of your text.

Drawing in fit mode

The fit mode allows you to specify a bounding box for your text. The font will attempt to “best fit” your phrase within that box by finding the largest font size/scale that will fit within this bounding box, breaking your text up into lines as needed; in the process, the draw method will ignore any size parameters you’ve passed.

To use the fit mode, pass a width, height and the FIT constant to your Text Arguments object:

    { 
        text: "The rain in Spain falls mainly on the plain.", 
        align: "middle", 
        width: 200, 
        height: 150, 
        fitting: dojox.gfx.vectorFontFitting.FIT 
    }

Caveats

As with most things, VectorText comes with a few caveats.

The elephant in the room: Internet Explorer.

Because of the poor performance with VML—including VML’s lack of both a cubic bezier curve and arcs—rendering fonts (especially complex ones) in Internet Explorer can give you less-than-stellar results. Using the Silverlight plug-in as a renderer will help somewhat, but since it is not so ubiquitous you cannot yet rely on it for all users of Internet Explorer.

Rendering too much text.

Since each glyph (i.e. character) is created as a dojox.gfx.Path object, large amounts of text can slow a browser down to a point where it is unusable. Because of this, we recommend that you treat this the same way you’d treat sIFR—use it sparingly, and don’t use it to render all of the text on your pages.

Text on a path

Text on a path is not supported at this time.

a11y /i18ln

Because of the nature of the renderers, in general no text drawn by a GFX font will be considered a11y-friendly. We’re working on changing this but we don’t know when we’ll have a solution.

Internationalization can be supported—but to do so will require that your SVG font definition supports the glyphs needed to render text. Vertical and right-to-left text is not currently supported but is planned for future releases.

In conclusion

With the new VectorText capabilities, dojox.gfx takes vector drawing to a whole new level for the Open Web. Happy drawing!