O’Reilly’s Fonts & Encodings Book Offers Much For Web Designers Too

fonts-encodings

If you haven’t read Samuel John Klein’s review of Fonts & Encodings, click here and take a look at the full range of this book. This article here is not another review, but a more detailed look at one particular chapter that will be interesting to web designers: Chapter 10, “Fonts and Web Pages.” I consider myself a typophile but I am also a web designer, and rarely do the two disciplines ever meet due to the limitations of the Internet, with its user-controlled presentation and weak typographic controls (it has gotten better with CSS, but it is still far away from the controls one has in print apps like InDesign).

The dilemma of type and web design

We web designers are in this predicament because a typeface is the only element of a webpage that does not actually belong to the author of that page: the font of that typeface is licensed, and while you can use it as needed you cannot distribute it freely, in the same way purchasing a license of Photoshop does not allow you to distribute it to whoever you wish. The webpage visitors needs his own legal copy of the font in order to display it in his/her browser. Technology has tried to get around this in three ways:

  • Tags: HTML, XHTML and CSS offer tags for font selection and formatting. While this gives the designer some control over typography, it still requires the end user to have the font handy either on his/her computer or downloaded from the Internet (more on this later).
  • Plug-ins: Microsoft, Bitstream and em2 Solutions have all produced plug-ins that enable browsers to pull the fonts they need to display webpages. This is maybe the best solution for displaying fonts perfectly but each plug-in has its limitations and requirements.
  • SVG: Adobe’s Scalable Vector Graphics format is emerging as a new W3C-supported standard for defining type geometry. It’s a promising alternative to plug-ins but not all browsers support it.

Each technological solution has its pros and cons. Let’s look at each one.

Tags mean nothing to fussy browsers

I’m sure many of you already know of or already use CSS so I won’t waste time here with typographic rules from CSS1 and CSS2 (if you don’t know anything about CSS, click here for a primer). Fonts & Encodings focuses on CSS3, the latest iteration of CSS that really comes into its own in terms of typographic rules. Here are some up-and-coming CSS rules:

  • font-size-adjust: When a preferred typeface is not available, this rule will change the type size on the fly so the font substitution still produces close to the same x-height on the page. For instance, the book shows that if your preferred typeface for a page is Centaur (which has an x-height of 0.366) and the substitution font will be the system’s serif typeface (usually Times) then specify the font-family as "Centaur", serif and font-size-adjust as .366, then when performing the substitution the browser will calculate what size Times should be displayed in so it has the same x-height as Centaur.
  • font-stretch: This controls the characters’ horizontal scale. You can use keywords from ultra-condensed to ultra-expanded and everything in between.
  • font-effect: Emboss, engrave, or outline type.
  • font-smooth: Smooth characters’ edges, similar to anti-aliasing. This one can actually make type look worse at small sizes, so a font can be set to smooth only when larger than certain sizes.
  • font-emphasize-style and font-emphasize-position: These two rules apply to ideographic languages (Japanese, Chinese and Korean) and allow use of the ideographic emphasis mark, a small circle placed next to a glyph to show emphasis. These marks are similar to the Western bold and italic for showing emphasis. These two rules control the style and placement of these marks.

All these CSS3 rules are wonderful, but I regret to inform you that none of these are supported by any web browser as of yet. It is yet another case of real-world technology not quite up to speed with the specifications being created by the W3C and other groups. I’m sure we will see these rules in a few years, but not now.

Now on to the fonts themselves: did you know CSS3 allows for controlled font substitutions, font downloading and even on-demand font synthesis? It’s true, and Fonts & Encodings shows how:

  • Substitutions (in CSS3) can do much more than just swap one font for another. You can actually place a typeface’s stem heights, slope, cap-height, x-height and other measurements along with its Panone-1 classification, and browsers that understand the code can select a local font that matches the data or comes close. If you don’t know what a Panose-1 classification is, pick up the book at your local bookstore and check Chapter 11 (hint: Panose-1 classifications look something like “2 0 5 3 0 0 0 2 0 4″).
  • Download a font with a simple src URL. This is easy enough to execute and takes the least code.
  • Synthesizing a font takes place within the browser, where data on units per em, bounding box coordinates and specific Unicode character widths are processed and used to create a typeface that fits the webpage. The best analogy for this process is PDF: a PDF that doesn’t have its fonts embedded will substitute Adobe Sans or Adobe Serif, modifying the characters’ widths and geometry so it fits the page correctly.

This is wonderful technology, but browsers do not yet support it as far as I can tell. In conclusion, tags are slowly developing as a robust method to control type in webpages but it has not been successfully implemented yet.

Plug-ins for downloading fonts

The idea of downloading fonts is not new: plug-ins have been available for awhile that do basically the same concept you see in the CSS3 method above. The idea is to download an encrypted font for use in displaying a webpage (the encryption is required so users can’t extract the font for unlicensed uses), and there are three products for this:

  • Bitstream’s TrueDoc. TrueDoc technology has been supported by only two products, one now defunct and the other out of distribution though still supported by Bitstream. The idea is to save a font in PFR (“Portable Font Resource”) format and then access it with an XHTML tag that supplies the URL of the PFR file. Note that this tag is not supported by CSS. Not surprisingly, browser support seems to have died off: the last browser that looks to have supported it fully was Netscape 4.
  • Microsoft’s Font Embedding. Font Embedding techology is not much better than TrueDoc. It works only with Windows (naturally) and the EOT (Embeddable OpenType) format that makes it work is not documented and is therefore unavailable to anyone other than Microsoft (of course) and is operational only with Internet Explorer (figures). It appears EOT files are created by the designer by scanning webpages and then selecting glyphs to go into the file. Other than the monopolizing actions of Microsoft, Font Embedding is a decent solution that is efficient and free to users.
  • em2 Solutions’ GlyphGate. em2 actually produced the technology behind Font Embedding, and they improved on it with a server-side plug-in that generates fonts in real-time for users and browsers on demand. The real beauty of this solution is that it works for every browser out there: if it can’t generate a font for a webpage, it will generate a graphic instead and substitute that for the text. GlyphGate can also apply advanced type features (ligatures, old-style figures, etc.) and even kerning, which browsers can’t even do yet. There’s no real downsides to this solution other than the fact that it needs to be set up on the web server: if you publish website through third-party hosts, GlyphGate will not be an option.

Using SVG to create type

Did you know SVG is a W3C standard based on XML? That web-friendly pedigree makes SVG very desirable:

  • SVG is readable and editable by human beings. There’s no proprietary formats or hidden technology involved with SVG, and SVG files can also be indexed like regular HTML pages.
  • XML tools are all you need to create and edit SVG graphics, and there’s plenty of options for such work.
  • SVG images can be indexed with metadata, making it easy to search and find graphic elements.

SVG graphics are described fairly simply with code in XML syntax. It looks like a bunch of numbers to regular folks (see page 350 in Fonts & Encodings) but at least it’s clean and organized. SVG type is even more clean because there are already several XML elements that can describe text: font-family, font-style, font-weight, font-size and more. These are all based on CSS and SVG defers to CSS specs when it comes to these properties. SVG also has a kerning element that can kern type, something that CSS can’t do. Entire fonts can be coded as SVG, plain-text files that dispense with the whole copyright issue altogether because it alone can’t be made into commercial font files (the W3C is encouraging developers not to write tools that do just that). A complete description of SVG fonts and their elements can be found in Fonts & Encodings.

Conclusion

Typography, fonts and the Web almost contradict one another. Fonts are a licensed product, purchased by one person and for use by only one person. Browsers and webpages are free and available anywhere. The conundrum is in how to allow users to have a font handy for browsing a website without actually purchasing the license. So far the solutions have come from various companies, each with their own agendas, and no one solution is perfect. However, I think a solution is not far away.