Another idea is to have "font servers". A glyph, after all, is nothing
more than an image, which can be sent across the net. If a particular
viewer does not have the glyph image corresponding to a character, it
can go off and fetch it. Given caching, and the small working set, I
doubt performance would suffer overly much.
>Right. Multiple families does not solve this. Each string could contain
>only a single language. You'd need separate nodes for Japanes and
>Chinese, but with multiple families specified you could specifiy a
>language of "ja" and then give a string that has Japanese and Russian
>since glyphs for both exist in Unicode.
Hmm. Perhaps you could make language MFString as well, which would
give at least a fairly good idea of the glyphs required, so a
multithreading system could possibly start loading the fonts in
advance. Either that, or have a default value of "*" for language,
indicating "all". I think it's probably better to use a font map.