SVG Fonts

Is the SVG working group about to choose shame and get war?

Raph Levien <raph@acm.org>
23 Jun 1999

The font specification of the SVG draft is not yet done. It is clearly a very difficult task. The SVG working group has assembled a group with very impressive credentials. Yet, I fear there is a good chance they will avoid tackling the really tough problems, and the result will be a "standard" with poor interoperability, inconsistent rendering on different platforms, and problems with internationalization.

This essay contains an outline of what I perceive these problems to be, and ends with a plea to get it right this time.

The semantics/presentation spectrum

Web content exists on a spectrum ranging from purely semantic (XML markup without any style information) to purely presentation (GIF images). Many of the more interesting forms of content lie somewhere in between. HTML is the classic example; it has some semantic structure, but not enough to, say, reliably extract the abstract of a document, and some control of presentation, but not anywhere nearly enough to satisfy graphic designers.

I describe this as a spectrum, but it's not strictly one-dimensional. HTML with Cascading Style Sheets is better suited for representing document structure and has better control over presentation than vintage HTML. Nonetheless, there exists tension between the two poles. Formats with excellent presentation control (such as PostScript) tend not to be very good at semantic structure, and vice versa.

SVG occupies a fairly clear-cut niche in this spectrum. The very first of the detailed requirements is:

1. Consistent visual results and behaviors across implementations

This requirement clearly places SVG on the "presentation" end of the spectrum.

Incidentally, the commentary following the laudable subgoal "a. The specification needs to be complete and unambiguous" states that "The above goals are independent of the specification." I find it rather amusing that completeness and unambiguousness can be somehow independent of the specification. If this is the true intent, it would explain a lot :)

SVG also attempts to preserve at least some semantics of text. Text is represented as XML character data. It should at least be possible for search engines to extract the text from SVG files and perform keyword searches.

If SVG is successful in meeting its requirements, I believe it will satisfy an important and useful niche. However, present spec falls short in many ways.

Presentation

The SVG requirement has it pretty close to correct. Control over presentation implies that a conforming SVG file should display near-identically every time it's rendered. The gap in the SVG document is defining what's "conforming." The spec as it currently stands delegates exact choice of fonts to the CSS WebFont mechanism. This mechanism has lots of cool techniques for substituting "close" fonts; something quite desirable for most HTML rendering, but at odds with the goal of consistent presentation in SVG.

Semantics

I want to identify two aspects of "semantics preserving:"

The first of these can be accomplished to some extent with the "ALT tag" trick, i.e. supplying the text along with rendered content. However, this trick in no way helps with editability.

Another key issue with editability is whether editing the text preserves the overall quality of the document, including lower-level things like kerning, ligatures, hyphenation, and justification, as well as higher-level issues like correct references to page numbers.

Balancing semantics and presentation is considered a very difficult problem. There are certainly no easy answers; the systems that have acheived both well have done so only because of considerable effort.

CSS WebFonts: good for HTML, bad for SVG

SVG delegates selection of the actual font to the CSS2 WebFont mechanism. On the whole WebFonts do a good job for HTML, but are inadequate for SVG.

The primary feature of WebFonts is their ability to specify fonts by familiar names, or by features, so that if a font "close" to what the designer intended is available on the viewer's system, it can automatically substitute that font. Because the font may have slightly different metrics, it is likely to render slightly differently on different platforms. For HTML documents, you don't care, because HTML is not dependent on the exact appearance of the font. Other issues, such as line-breaking algorithms can also vary from browser to browser.

Perhaps the best thing about WebFonts for HTML is that it does not have a dependence on a single specific font format. If the document asks for "Times," then viewers which substitute Adobe Times in Type1 format, Monotype Times New Roman in TrueType, or even Nimbus Roman No9 L are all doing the right thing.

WebFonts also includes a mechanism to download fonts from the Web. Because there is no single font format specified, there is correspondingly no guarantee that the viewer is capable of rendering the font once downloaded. Fortunately, CSS in HTML doesn't require such a guarantee; the font substitution will usually provide a font close to what was intended.

The SVG working group currently proposes adapting CSS WebFonts wholesale for SVG. I submit that this is a bad idea.

First and foremost, SVG graphics, unlike HTML pages, do depend on exact font metrics. Because SVG files are likely to place individual words with explicit x,y coordinates, and are capable of doing so for individual glyphs (for example, to achieve finer control over kerning), substitution of an even slightly different font can destroy the visual quality of the graphic.

Second, the font download mechanism is inadequate because it does not specify a set of font formats for interoperability. SVG viewers must implement all the formats in that set, and conforming SVG documents must restrict themselves to fonts from that set. Otherwise, interoperability is lost.

What's perhaps of greatest concern to me is that the present SVG proposal makes it easy to do the wrong thing. Even if there is a common format, SVG makes it easy enough to specify fonts imprecisely, or to include a downloadable font in a format understood by most SVG viewers, or at least the one used by the designer. We've seen enough of this on the Web already. Why perpetrate more?

SVG text: ALT tags, poor editability

The SVG text model is quite good at allowing the XML text to be extracted, but is poor at editability.

The major problem is redoing the text formatting when the text changes. It is very likely that editing text will force changes in hyphenation, justification, and other layout parameters. The SVG standard has no provision for preserving the layout in this way while editing text.

I want to point out that combining editability with presentation is possible. The TeX system, in particular, manages to guarantee that different implementations will preserve formatting down to the pixel level. TeX also supports full editability at a rather high semantic level. The quality of its line-breaking and formatting algorithms is excellent, and its math capabilities are unsurpassed. Perhaps the SVG working group may want to take another look at whether SVG should be editable.

The text rendering pipeline

Rendering text into pixels can be considered a pipeline, with the following abstract stages:

In SVG, the primary responsibility for each of these stages, aside from the last, resides with the creator of the SVG file. However, a number of font formats include partial specification of some of the earlier stages. TrueType, in particular (and its OpenType variant) contains tables for converting sequences of characters to sequences of glyphs (using a finite state machine), and for specifying kerning. TrueType does not specify hyphenation or justification, so that is still up to the creator of the SVG file. Even more glyph-based font formats, such as Adobe Type1, specify the escapement of each glyph.

For all this to work correctly, the creator of the SVG file must second-guess the transformations specified in the font, and perform its layout responsibilities accordingly. For good results, this obviously requires a match between the fonts used in creation and display.

SVG documents can also override the character-to-glyph conversion provided by the font, using the altglyph property. In the extreme case, this can be used for every glyph in the document. Better get your gzip compressor ready!

Font formats

The most obvious way out of the dilemma is to specify a single font format required of all conforming SVG implementations, and used by conforming SVG files. This section examines a number of existing font formats, their advantages, and disadvantages.

Adobe Type1

I like Adobe Type1. It's a fairly simple format, and is very well suited to high-quality output. The hinting mechanism is relatively weak for non-antialiased low resolution screen displays, but presumably this is of little importance for SVG.

The major problem with Adobe Type1 is that it's almost entirely glyph-based. Further, Type1 itself is relatively weak at representing the large number of characters needed for CJK alphabets. A partial solution is to use CID-keying, but this begs the question of how to map Unicode character names to CID's. One reasonable approach would be to suggest the use of CID's identical to Unicodes when a match is appropriate; this would reduce the usage of the altglyph property considerably.

Adobe Type1 is also freely implementable, without patent or trade secret problems, as far as I know.

TrueType

TrueType is another widely popular font format.

The greatest strength of TrueType is that it is based solidly on Unicode. It uses cmap and mort tables to convert sequences of characters reliably to sequences of glyphs, even for "difficult" scripts such as Arabic or Devanagari.

Perhaps the greatest potential problem with TrueType is an intellectual property cloud. According to a FAQ written by the inventor of TrueType, it is covered by patents that would be infringed by any free implementation. For reference, I believe those patents to be 5,325,479, 5,159,668, and 5,155,805.

OpenType

OpenType is the vulcan mind-meld of the TrueType and Type1 formats. The file format is essentially the same as TrueType, while both TrueType and Adobe Type1 glyph shape encodings are allowed.

The major drawback to OpenType is its daunting complexity. The specification itself is rather large, and there is a large set of what appear to be optional features. It is not at all clear to me how these optional features should be handled in a spec which is intended to be interoperable.

Because of OpenType's advanced layout features, it is likely that text in an OpenType font would need very little glyph substitution. Keep in mind, however, that SVG currently requires a separate <text> element for each word in a justified line, or for each glyph in manually kerned text.

OpenType also inherits TrueType's intellectual property issues.

TrueDoc PFR

TrueDoc PFR seems to be the most widely implemented font format for Web font downloading.

An advantage of TrueDoc PFR is its relatively compact size.

According to the FAQ, a PFR font is not responsible for kerning, etc. Rather, this is up to the application. This suggests to me that the use of TrueDoc PFR fonts in high quality documents would lead to excessive use of absolute character positioning. Get our your gzip!

Bitstream claims two patents on TrueDoc. Thus, it seems highly unlikely that it is freely implementable.

Others...

There are tons of font formats. Metafont has amazing technical features, but has a reputation of being difficult to work with. Embedding font shapes (possibly as <path> elements) is not out of the question. There are plenty of other choices.

Recommendations

I recommend that the SVG working group consider conformance seriously, taking special care not to skirt the hard problems by simply delegating conformance to other specifications by reference. In the cases where the referenced specifications have optional features, the SVG spec should nail these down.

In particular, I recommend that the working group adopt a single font format as the standard. This font format should be suitable for internationalization, be freely implementable, and have good quality. Ideally, it should be simple, as well.

It should be possible to create a conformant SVG document in any script supported by Unicode. If necessary, this can be done by specifying an altglyph property for each glyph in the document. However, creators of SVG documents should not be encouraged to create non-conformant files for "convenience."

The subtitle of this essay was inspired by:

levien.com SVG
levien.com home