Idea: MM webfonts resurrection?

Dear list members,

As a separate issue from my OFF/X proposal, I'd like to throw another 
idea here:

Both Adobe and Apple dabbled with the idea of variable glyph rendering 
models ("TrueType variations" and "Multiple Master"). Apple once defined 
extensions to the TrueType rendering model (and layout model, actually) 
which used the glyf table in addition to several other tables: fvar, 
gvar. In the OpenType specs 1.0-1.2, Adobe defined an extended version 
of the CFF table along with the tables fvar, MMSD, MMFX -- this was 
removed in the OpenType spec 1.25.

I certainly understand why the gvar model never got traction, and why 
the MM model was removed from the OT spec at the time. The ultimate 
target medium at that time was print, which was "static", and supporting 
it on the desktop system level, in application UIs, has always been a 
hassle.

But today, in the web context, I think at least one of these variable 
font models deserves resurrection -- because it offers tremendous 
compression potentials, lends itself well into the "responsive web" 
paradigm, offers new possibilities for text layout on the web and, above 
all, can be implemented much more easily on the web than it ever could 
be on desktop platforms. Plus, the specs are already there.

Imagine the following situation:
1. The website sends to the browser a WOFF with gvar/MM capabilities. 
This is done once.
2. Whenever the same CSS font-family is used with a different 
font-weight or font-stretch parameter, the browser dynamically selects 
the appropriate instance of the gvar/MM font.

Currently, if I want to use a "hairline", a "regular" and a "bold" 
version of a font on my website, the browser has to download three fonts 
down from the server. Even if those fonts were originally created 
parametrically (e.g. using Multiple Master), they have been generated 
into static instances, converted to WOFF, and are then served as 
separate resources. This is a huge waste of bandwidth, and of course 
highly limits the usefulness.

If a variable font model was supported, @media queries could influence a 
dynamic client-side font stretching when the viewport is scaled. And the 
numerical font-weight parameter could be used to its full potential 
(from 0 to 1000 or from 100 to 900, in single-number increments).

This is just a loose idea for now. But my main point is: web fonts are 
now "decoupled" from the desktop fonts. Web browsers have the ability to 
support font formats which are not supported on desktop systems -- this 
is currently the case, where the "old-style" SVG Font "mini" 1.0 format 
is supported in many browsers, but in no desktop OS. Similarly, if one 
official version of the SVG table gets adopted as part of the SFNT 
container, web browsers can start supporting it regardless of whether 
and how this gets supported in desktop systems. Even now Firefox 
supports Mozilla's SVG table proposal, and a custom build of Chrome 
supports the CBDT/CBLC bitmap tables.

Specifically, if "we" wanted to resurrect Adobe's model for MM fonts 
within the SFNT container, my proposal would be to dig out the old MMFX, 
MMSD and fvar table specs along with the pre-OpenType 1.25 CFF table 
spec (I have them -- retrieved them from archive.org! :) ), rename that 
CFF table to "MMCF" so it doesn't conflict with the official CFF table, 
and shape up a proposal. I'm not sure whether technically, the Apple 
gvar proposal is simpler to implement than Adobe's MM model or vice versa.

But what I know is:
1. The web browser's window is an inherently dynamic canvas where 
content can be moved, scaled, reflowed dynamically. Most web assets 
these days can be made responsive -- only web fonts cannot.
2. Either of these variable font models has existing stable specs which 
can be implemented relatively straight away in the major browsers. So we 
don't have to sit down at a drafting board and invent anything from 
scratch.
3. Variable font models offer tremendous font compression potentials: 
you only serve one font file per entire family. No WOFF 2.0 can beat 
that! :)
4. The web browsers could easily convert the variable font into a 
regular "static" font in memory and use the OS's rendering subsystems. 
Since those variable font models are monochrome and outline-based, there 
is much less potential for a huge debate than there is with SVG inside 
of the SFNT container.
5. Many type designers are already familiar with the design paradigm, at 
least with the MM paradigm. Most type design applications offer this way 
of working, and they could be extended relatively easily to output such 
fonts.
6. None of this invalidates or conflicts with anything that is out there 
already, or is being done.

Surely, work would need to be done in the CSS spec to perhaps extend the 
parameters such as font-weight or font-stretch, or perhaps invent some 
new ones, to control this. But I think it's very much worthwhile. There 
may be caveats on the way. But I think it's a relatively low-hanging 
fruit. :)

Best,
Adam

-- 

May success attend your efforts,
-- Adam Twardoch
(Remove "list." from e-mail address to contact me directly.)

Received on Thursday, 20 June 2013 04:03:42 UTC