The problem here is that Unicode has lots (50,000???) of symbols, which
would never be in a single font. With a single family specified you'd
have to display nothing or a "missing character" glyph if the requested
character does not exist in that family. Specifying multiples just gives
more fonts from which to find glyphs.
>
> >The i18n group suggested we make the family an MFString, allowing a
list
> >of fonts to be specified. When searching for a glyph, each font is
> >searched in order until one is found satisfying the slot in the coded
> >character set.
>
> This will not work when Chinese and Japanese are interspersed using
> Unicode (or rather, high-quality glyph disambiguation will not be
> possible). Please take note of the language field on the text node,
> which, when combined together with my outlined font specification,
> would solve the CJK issues in Unicode (or rather provide a foundaton).
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.
--
chris marrin Silicon http://www.sgi.com/Products/WebFORCE/WebSpace
(415) 390-5367 Graphics http://reality.sgi.com/employees/cmarrin/
[email protected] Inc.
"As a general rule, don't solve puzzles that open portals to Hell."