Open fonts at Libre Graphics Meeting 2009 [LWN.net]

May 13, 2009

This article was contributed by Nathan Willis

École Polytechnique in Montreal played host to the fourth annual Libre Graphics Meeting (LGM) May 6 through 9, gathering around 100 developers and users of free graphics software from across the globe to collaborate, discuss, and learn. One of the biggest topics of the week was free and open fonts: their licensing, design, and integration with the free software desktop. In just a few short months, the release of Firefox 3.5 will push the issue into the forefront courtesy of Web Fonts, and the free software community aims to be ready.

Dave Crossland and Nicholas Spalinger of the Open Font Library (OFLB) project each delivered a talk about OFLB (Crossland on the project's web site relaunch, and Spalinger on the challenges it faces moving forward), but the importance of free-as-in-freedom fonts permeated into several other talks as well. Developer Pierre Marchand demonstrated changes in an upcoming revision of his FontMatrix application, and the World Wide Web Consortium's (W3C) Chris Lilley spoke about Web Fonts and other developments in CSS3.

Additionally, the "users" represented at LGM included graphic artists, but also professionals deeply invested in free font support for open source software — including XeTeX creator and Mozilla's font specialist Jonathan Kew, Brussels-based design agency Open Source Publishing, and Kaveh Bazargan, whose company uses free software to handle typesetting and file conversion for major academic publishing houses like the Institute of Physics and Nature.

A free font and free software primer

As with software, the main front in the battle over free fonts is licensing. Historically, digital type foundries like Adobe and Monotype have sold proprietary fonts to graphic design houses and publishers under very restrictive licensing terms that prohibit all redistribution. Freely redistributable fonts have existed for years, but licensing them in a free software context can be complicated, too.

When the font is used solely to produce printed output, licensing is not a problem, but when the font must be embedded inside a another digital file (such as a PDF) incompatibilities arise because fonts contain executable code (such as hinting, which algorithmically adjusts the width and height of glyph strokes to align with the pixel grid of the display device to optimize sharpness) in addition to glyphs themselves. Including the font inside another document that contains executable code — such as PDF or PostScript — makes the resulting document a derivative work of the font.

A "font exception clause" for the GPL was written to allow font designers to license their creations under GPL-compatible terms without activating the GPL for all documents embedding the font. That solution did not catch on with type designers for a number of reasons, including the naming conventions of the type design world — where derivative fonts customarily do not reuse the upstream font's name to avoid confusion. Nonprofit linguistics organization SIL International created the simpler, font-specific Open Font License (OFL) to address designers' concerns while permitting redistribution, modification, and extension. The Open Font Library project was started to foster the creation and distribution of high-quality free fonts under the OFL.

OFLB has grown steadily since its inception, presently hosting around 100 fonts, but the project anticipates a sea change when Firefox 3.5 is publicly released this spring. Firefox 3.5 will add support for Web Fonts via the @font-face CSS rule, which allows a web page to specify text display using any font accessible using an HTTP URI. Before @font-face, the only fonts available for selection through CSS were the ten "core fonts for the Web" from Microsoft: Andale Mono, Arial, Comic Sans, Courier New, Georgia, Impact, Times New Roman, Trebuchet MS, Verdana, and the always popular Webdings.

Because commercial type foundries by and large still object to redistribution of their products — even for display purposes only — the advent of @font-face marks a tremendous opportunity for OFLB and free fonts in general.

OFLB gets a redesigned site

Crossland previewed OFLB's newly visually- and technologically-revamped web site. Donations paid for a professional redesign to appeal to graphic designers regardless of their interest in free software principles, and the new site runs on the ccHost content management system developed by Creative Commons.

The OFLB site will allow type designers to upload their fonts for public consumption; users will search and download them, and can re-upload "remixes" of the originals. Font "remixes" are expected to center around filling in missing glyphs, allowing the OFLB community to flesh out support for non-Latin alphabets, but remixes that make aesthetic changes to the original are also supported. In keeping with the OFL, remixes and originals will be cross-linked to each other, but remixes will have to choose a distinct name.

The new site will foster WebFont usage by allowing direct linking to its resources in @font-face directives. Each font's page contains the required CSS code snippet for simple copy-and-pasting into a page or template. OFLB has also worked to get its online library directly integrated into the font editing application FontForge. Crossland noted that although proprietary web page design software like Dreamweaver is popular with graphic designers, no such GUI tool is common for free software users, who tend to create sites with content management systems (CMS). The project is interested in integrating OFLB support into open sources CMSes such as Wordpress or Drupal that support theming, but nothing is in the works yet.

Between talks, discussion turned to the possibility of integrating features from Marchand's FontMatrix into the OFLB site. FontMatrix is a tool for maintaining large collections of fonts, selectively activating only those needed so as to conserve memory and make selection easier within design applications, but Marchand has added more and more diagnostic features to the program with each revision. The new version of FontMatrix he demonstrated can explore font metadata in depth, allowing searching through font collections based on such facets as language support, style, weight, license, and creator. The OFLB site could re-use some of that code to empower visitors to search its font collection in ways more powerful than today's tag-based browsing.

Growing the free font tent

Spalinger's OFLB talk focused on the challenges the project faces, including the possibility that users will attempt to upload fonts to the site that they do not own, such as proprietary fonts from commercial foundries. The project is debating how best to manage the site to ensure that only properly attributed, OFL-licensed work is submitted. Lilley observed that it may not be the project's legal responsibility to police the site, but only to respond appropriately when a type designer registers a complaint. Crossland concurred with that sentiment, but added that the project also wants to establish a bright line between its service, which aims to provide a designer-friendly, high-quality collection, and the scores of low-quality "free font" sites that garner little credibility or trust because of their policies.

Crossland added that one possibility would be to approach commercial foundries and offer to perform font fingerprinting on their products using FontMatrix's tools, then alert the foundries if a possible match was uploaded. Kew thought this approach unlikely to succeed, suggesting instead that it was better to do the reverse: make a public feed available of the fingerprints of the OFLB fonts, then respond to questions and concerns of the foundries if they detect a problem.

Other concerns include proposals for font file formats that include DRM — such as Microsoft's Embedded OpenType — and how best to encourage font designers to collaboratively extend OFLB fonts (such as adding new alphabets) without creating a glut of remixes for each source font that are never merged back into the upstream original.

Conclusion

Back in April, Mark Pilgrim famously ranted at the foundries for their stubbornness and refusal to acknowledge the importance of WebFonts. Crossland referenced Pilgrim's comments in his talk, observing that the ability of @font-face to disrupt the legacy foundries' business model was a golden opportunity for OFLB and, by extension, free software. The foundries think that @font-face will cannibalize sales, but the end users who see the type displayed via @font-face were never the foundries' customers to begin with. The graphic designers are the customers, and graphics designers love fonts. If the foundries offer them nothing for use in WebFonts, OFLB may well be their only option.

Other LGM sessions over the four-day event featured updates from major open source graphics and design applications like Scribus, Inkscape, and Gimp, research and technical demonstrations, and debates on critical issues such as usability, the rise of non-free web applications, and combining free software with profitability. All of the conference presentations and Q&A sessions were recorded by Bazargan, and are now available online in multiple video formats.

(Log in to post comments)

Open fonts at Libre Graphics Meeting 2009

Posted May 14, 2009 7:26 UTC (Thu) by socket (guest, #43) [Link]

While I can certainly understand the appeal of having more control over the fine presentational details of one's website, I'm concerned about what this could mean for web accessibility.

To give some context: the screen I normally use is 14" diagonally at roughly the golden ratio (unlike a lot of screens these days), with 1400x1050. I just looked it up, it comes to 124x124 dots per inch. My X.org log, as configured by YaST (running OpenSuSE 11.1), reports:

(**) RADEON(0): Display dimensions: (287, 215) mm
(**) RADEON(0): DPI set to (123, 124)

So, that sounds about right. Since a point is 1/72nd of an inch these days, 12 points should be 4.23 millimeters. I'd consider that comfortably readable.

But in order for text to be actually readable, I have to tell Firefox to use no less than a 26-point font. In reality, this puts my x-height at about... 3 millimeters, as I imprecisely measure with a ruler on my screen. When a website assumes it's acceptable to insist on using a font at 12 points, the x-height is a smidge under a millimeter and a half. I'm sorry, but my copy of the compact Oxford English Dictionary is more readable than that. $DEITY forbid I ever get so nearsighted I can't pick out individual pixels.

Is Firefox not querying X right? Is X not presenting DPI information to applications right? Is it XFCE's fault? I don't know. Not sure where this bug should be filed, but it's beside my main point...

I tell Firefox to ignore whatever fonts the website wants to use, for several reasons. (1) The already mentioned size problem. (2) Sans serif is for headers and large text, Serif is for blocks of text. That's a basic readability rule that's been thrown out the window by web designers. (3) Mucking around with kerning for the sake of being "interesting" never actually is. (4) Does anybody remember how many different dashes or spaces Unicode offers, and what they mean for their use in language and/or the effect on the typography? Neither do I. (5) Most importantly, accessibility.

It's the content that matters most - it's the content that will keep people coming back to some sites, and avoid others. Until the majority of web developers actually learn something about typography and readability, I'll make my own font choices, thanks. I strenuously object to any attempt at letting website developers make the web less accessible than it already is.

Open fonts at Libre Graphics Meeting 2009

Posted May 14, 2009 8:47 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

Firefox does not use points as font size unit. It uses pixels. This is why you need to specify 16 (px) fonts in Firefox to get roughly the 12 (pt) size on a typical ~ 100 dpi screen (and yet another value on your system, that you need to change for every freaking encoding because someone decided having encoding-specific sizes was smart)

Of course this is a usability disaster. I've always felt exposing pixel sizes this way when the physical size of a pixel can vary greatly from one screen to another was a way to break so utterly text size adjustment no one could tell what dev made the biggest mistake anymore.

(People will raise the "angle of view" argument. Since no one can measure "angle of view" automatically this is just a way to refuse fixing the problems. Physical sizes can be autodetected and they're good enough for many cases)

Open fonts at Libre Graphics Meeting 2009

Posted May 14, 2009 16:10 UTC (Thu) by rgmoore (subscriber, #75) [Link]

I assume that the reason people want to specify text size in pixels is that they also use a lot of raster graphics (like JPG and PNG) whose sizes are inherently defined in pixels. If the graphic designer wants a consistent layout behavior, it's easier to define everything in pixels. As long as designers want to do that, the best solution will be to use the scale control built into your web browser, rather than setting a larger default text size.

Open fonts at Libre Graphics Meeting 2009

Posted May 15, 2009 8:12 UTC (Fri) by nim-nim (subscriber, #34454) [Link]

That was not a valid argument when graphic designers wanted to ignore that screens where not equal in resolutions (the infamous "best viewed in 800*600" era), and it's not an argument when they want to ignore pixel sizes are not equal either.

Open fonts at Libre Graphics Meeting 2009

Posted May 14, 2009 19:44 UTC (Thu) by oak (guest, #2786) [Link]

> (People will raise the "angle of view" argument.

Yes, I was just thinking about this. :-)

(Others: viewing angle = relation between DPI and viewing distance.
There's a large difference whether you look at your PDA screen from dozen
cm distance or your projector canvas from 4m distance.)

> Since no one can measure "angle of view" automatically this is just a
way to refuse fixing the problems. Physical sizes can be autodetected and
they're good enough for many cases)

For projectors not so...

What kind of API you were thinking for physical sizes (hmm. does xinerama
complicate this)? And which one is more appropriate; the application
window size or screen size? Former would be easier for apps to get right.
Unless you're using a compositing manager that uses large zooming
factor...

Open fonts at Libre Graphics Meeting 2009

Posted May 15, 2009 8:08 UTC (Fri) by nim-nim (subscriber, #34454) [Link]

>> Since no one can measure "angle of view" automatically this is just a
>> way to refuse fixing the problems. Physical sizes can be autodetected and
>> they're good enough for many cases)

> For projectors not so...

Since the vast majority of screens are not projectors and any browser page sucks when projected anyway that is not a good argument.

Basically you have three kinds of devices :

1. desktop and laptop screens where distance to eyes is pretty much fixed (for laptops, human arms are trivially not extensible). Using raw physical size to adjust text will just work here.

2. embedded stuff where the pixel size and eye distance can vary wildly so the actual behaviour is terminally broken, and you can not get by at all without a device-specific adjustment (since remote sessions and shared homes exist this adjustment must really be tied to the device not the user general preferences). This device-specific adjustment can be sourced from a device db.

3. TV and projectors : viewed at a distance, and this distance is not device specific but installation-specific. Handling those requires asking the user for the viewing distance at first plug-in time.

So here you are, to handle all the kinds of devices on the market you need:

1. To autodetect the physical pixel size. This is sufficient for laptops and desktops and already done by X for years (except the "but projectors" people refused to use this measure and made a mess doing other stuff). In the case of broken devices that do not expose their physical size, allow manual overrides. This could have been automated yesterday.

2. Factor in a device-specific adjustment for embedded stuff (from a device db, as we already do for input devices, printers, etc).

3. Factor in a user-inputed installation-specific adjustment for TVs and projectors (which remain the minority case, and can be trivially detected because they use video not computer resolutions or old low-density computer resolutions)

Also some users like small text, other users like big text, so once you have adjusted everything so your pt size is meaningful and device/installation independant, you need to let the user declare if he likes 8pt or 12pt text (totally useless before making sure 1pt is something meaningful).

Thus a working API would be:

1. raw physical pixel size (today's X DPI) => totally autocomputed, system-wide/system-specific

2. perceptual pixel size (raw physical size * a where a = 1 for laptops and desktops, a is db-sourced for embedded stuff and a is user-sourced for TV/projectors), system-wide, needs manual (deferred via a db or not) settings

3. user text size preferences : user-session specific, in pt, with the pixel value of pt computed using the perceptual pixel size. Can be broadcasted to gtk/qt/choose-yout-toolkit via XSettings

Open fonts at Libre Graphics Meeting 2009

Posted Jun 27, 2009 11:48 UTC (Sat) by jwalden (guest, #41159) [Link]

Odds are you'll never read this response, but for anyone else who does...

Firefox does not use "pixels" that way, and neither does CSS. CSS pixels actually correspond to your angle-of-view suggestion, and the spec defines a precise optical angle for them. Thus far most screens lack sufficiently high resolution to really demonstrate this, but it's my understanding that if you grab a high-res screen and run Firefox (3.5 at least, I believe 3.0 as well) on it, a pixel as selected by CSS does not exactly correspond to what the spec names as a "device pixel".

Frankly, having used for brief times a 30" screen, the bigger problem is that there's so much space that no website or application can fill it, and window maximization is an obsolete concept because seek times across its height and width at a normal distance for a computer screen are so atrocious. That's arguably a window manager problem, but I can imagine individual applications might take various steps to better use that space.

Open fonts at Libre Graphics Meeting 2009

Posted May 14, 2009 11:47 UTC (Thu) by nye (guest, #51576) [Link]

Interestingly, I hate reading blocks of serif text on a screen (I usually force the use of Tahoma, with antialiasing disabled between 8pt and 13pt), though I've never used one with a DPI above 100 so perhaps that's the difference between us.

Open fonts at Libre Graphics Meeting 2009

Posted May 14, 2009 13:07 UTC (Thu) by ajb (guest, #9694) [Link]

Actually I think web fonts may help with accessibility, in many circumstances: it means that at least the actual text is there somewhere, as opposed to in an image with no Alt text.

Open fonts at Libre Graphics Meeting 2009

Posted May 26, 2009 10:40 UTC (Tue) by muwlgr (guest, #35359) [Link]

Yeah, as DPI for modern displays is getting bigger and bigger, we are gradually entering the DPI hell. Pixels are becoming useless and meaningless measures of whatever. Use angular measures, use linear sizes in inches/cm/mm, adjust display of your content for certain viewing distance. But never more use pixels. When I read someone's blog with centered column width specified in pixels, with huge blank fields on the sides, I am losing the last respects for the web designer who did it. And my screen is only 1280x800 14", 107 DPI. And yeah, font sizes are sometmes given in points, sometimes in pixels.

I think that any size specifications in pixels in HTML CSS should be marked deprecated and eventually forbidden to use. You could not assume any certain pixel size and density any more.

Open fonts at Libre Graphics Meeting 2009

Posted May 26, 2009 15:45 UTC (Tue) by foom (subscriber, #14868) [Link]

> should be marked deprecated and eventually forbidden to use

Actually "pixels" have a very useful meaning in HTML -- and it's nothing to do with the resolution of
your screen. The size "1pixel" == the size of a 1x1 image element without size overrides.

As screens get higher res, browsers will *need* to scale up "pixels", not just because of CSS px size
specifications, but because of images.