(This was written for a specific argument, but I put it here because I often want make the same point again.)

I’m suggesting that character sets should be richer, and that the things which use character sets extend their usefulness beyond the idea of a 1:1 map of character-integer:glyph-curves.

I’m saying that characters sets nowadays are and should be more compositional. Getting a glyph is more like a function call than a symbol lookup. For instance, in Chinese, you should (be able to) make a coupled call to ask for a certain radical with a certain – uh – whatever the other part is.

In Latin alphabets, you can ask for, e.g., a and an acute accent, rather than a single acute a character. Either way you get á, and the number of bits you use will vary only marginally (you are addressing the same space, which might or might not be sparsely allocated). This saves space and initial work, but it is larger (I wouldn’t say wasteful, because I do not think anything is being wasted), and it does mangle the idea that a string is a sequence of bytes which each resolve to a character which resolves to a glyph. I’m saying I think the downsides are thoroughly outweighed.

If that conflicts with your idea of what a font is, (1) I respect that view, (2) I think that on consideration you’ll find it’s lacking some desirable features, and (3) with Unicode + OpenType + ATSUI, for instance, it’s not true. I mean something beyond file with the suffix ttf when I say font.

So I think it’s at least valid, if not necessarily ideal, to ask a font (admittedly – proudly – a more live idea of font than we had twenty years ago) for a subscript 3. Font data beyond splines can and should be factored in rendering. This already happens with hinting and kerning, and American Womanhood is still undefiled by the communist schemings of oily foreign typographers who want their fonts to be more than b-trees of points and vectors.

Put another way, I think your talk of keys is not applicable to the needs of many orthographies and their designers, including ours and me. Attribution has a place in fonts, because font designers know how attributes should be applied to their curves. The storage overhead is low. I’m willing to spend many megabytes on a good font that can display many languages. I would pay for the privilege. If you just need 100 printable characters stored as bitmaps, I commend you on your asceticism but gently ask you to stay out of the way of people who want luxuries like printing, titles, and French.

Worrying about whether you should put the attributes inline or in your font is relevant to many real-world concerns, and I’m happy to discuss it, but in the end I think it’s like asking whether you should say 2^3 or pow(2, 3). You’re doing the same thing; it just depends on what rendering layer you want to ask to construct your bezier curves. My argument here is not that putting the intelligence in the font is always better, just that it’s valid. You can’t end a discussion by saying fonts can’t do that!.

I think your talk of versions of glyphs is rather misguided. There are no versions of glyphs; a glyph is a version. One character conditionally resolves to one of any number of glyphs. The glyphs do not have to be stored all and entire. If you’ve played with multiple master fonts, you’ve seen how you can construct things like weights on the fly.

(Knuth did a lot of interesting work on constructive fonts; while he has some rather goofily platonic ideas, he did some fascinating things with them. Douglas Hofstadter rebuts him a little in Metamagical Themas.)

The optical size (which is what you’d worry about for subscripts, assuming of course you were making them small) is quite similar to weight. It could be extremely algorithmic. Illustrator, Freehand, and Sodipodi don’t store every possible image; they store tools and behaviors and filters for constructing them. MIDI tunes can be played at any speed or volume from a single file. You must understand this, but you don’t seem to be applying the ideas to typography. There is such a thing as a filter for proto-glyphs – it’s been done, and it works. It’s basically just a bunch of linear interpolations: nothing to get all het up about for a modern text renderer.

My model here is something like:

• font = character-to-glyph tree + base glyphs
• character = (a semantically atomic unit of writing, such as a numeral or a letter of the alphabet; analogous to a morpheme)
• character-to-glyph tree = (a pseudo-function to call with a character and its weight, position in a textblock, etc.; returns a glyph)
• glyph = (a vector construct ready to be turned into an image; analogous to a phoneme)
• base glyphs = (The underlying forms of the font, between and from which are interpolated and extrapolated arbitrary glyphs. Base glyphs might or might not ever be returned as glyphs.)
• image = (a two-dimensional array of pixels, loosely speaking)

For an extremely basic example, consider an ASCII bitmap text font with 100 printable characters. The character-to-glyph tree has 100 top-level branches, each of which has one leaf. The glyphs are made entirely out of square curves (i.e., bitmaps are a subset of splines). There is only one set of base glyphs, which happen to convert easily to images. (Sophistication in the character-to-glyph tree is emulated by using a separate font for each plane of base glyphs (bold, italic, etc.). Perhaps the single file of modern fonts confuses you.)

For a more sophisticated example, imagine the process by which a pseudo-manuscript might be digitally calligraphed. When the renderer asks for the first character, it specifies the Unicode point of the character (say it’s A), the desired size, that it is the first character, that it has x pixels of free space above it and y to its left, and that the leading of the text is l pixels. The character-to-glyph tree takes these as parameters, and in turn calls the base glyphs to construct an appropriately ornate glyph, which is returned to the renderer. The renderer in turn is responsible for things like (subpixel) antialiasing, requesting alternates when it senses a collision or repetitiveness, and keeping track of things like the relative fit of lines.

If this process strikes you as wasteful, I invite you to set good text without it. If you only need good-enough text, I suggest you get a non-multiple-master font to save space, or a non-OpenType-aware typesetting application to save processor time. There are exceptionally efficient tools out there which can turn out thousands of pages of text in the blink of an eye if you’re not into niceties like optical sizes and page-level hyphenation. But I’m into those things, and I intend to discuss them in public.