Around 15 o'clock on May 5, Seer wrote:
> does anyone (keith?) know what plans/changes would be needed to use the > full 31 bit unicode space? Xft uses client-side fonts to provide full Unicode support, using UTF-8, UTF-16 or UCS-4 representations. There's no good way to make the old core fonts handle these cases; various kludges have been proposed around subsetting fonts. None are likely to go very far as large fonts are really quite unusable with the core protocol. > It seems that we are working ourselves into the same corner MS did with > their decision to use UCS-2 (they ended up with the nasty utf-16 with > all the surrogate pairs and what-not) Mozilla is moving towards UTF-16 for many of the same reasons that Microsoft did -- the legacy code base was built around UCS-2 and it seems easier to move from UCS-2 to UTF-16 for some reason. I try to promote UTF-8 as a more reasonable representation; it's certainly smaller for the bulk of *my* text :-) Xft is representation agnostic -- it has APIs for UCS-1, UCS-2, UCS-4 and UTF-8; I'll probably add UTF-16 as well as provide LE/BE versions of the appropriate ones. > Also: having all fonts advertise only support for 10646 wont negatively > affect font-substitution by apps such as mozilla will it? Mozilla doesn't care what the encoding is, except in so far as it provides a clue as to the target language. TrueType fonts provide language tags in the OS/2 table which are used by Mozilla when linked to Xft. The other piece of information Mozilla uses encodings for is to try and guess which characters might be present in the font. Xft provides a complete Unicode mapping for each font before they're opened; this allows Mozilla to find a font supporting a particular glyph without having to try a bunch of fonts which might have the glyph. Keith Packard XFree86 Core Team Compaq Cambridge Research Lab _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
