Roozbeh Pournader wrote on 2001-12-27 22:58 UTC:
I remember the discussion here about the font naming and structure issues
for non-BMP characters. But I cannot remember the outcome (and if there
were oppositions). Since we are thinking about doing some work on Pango to
support non-BMP characters, I wanted to ask for a briefing...
I am more and more convinced that if we are going to do anything of this
sort on the old XLFD front, then it should be the definition of a new
ISO10646-C encoding, which is a glyph encoding and which has in its
properties character/glyph mappings. This encoding would come together with
little and highly efficient C functions
makeiso10646cglyphmap(XFontStruct *font, iso10646cglyphmap *map);
reads the character-to-glyph mapping table from the font
properties into a compact and efficient in-memory representation
freeiso10646cglyphmap(iso10646cglyphmap *map);
frees that in-memory representation
mbtoiso10646c(char *string, iso10646cglyphmap *map, XChar2b *output);
wctoiso10646c(wchar_t *string, iso10646cglyphmap *map, XChar2b *output);
take a Unicode character string and convert it to a XChar2b glyph
string suitable for output by XDrawString16 with the ISO10646-C
from which the iso10646cglyphmap was extracted.
ISO10646-C fonts would still be limited to have not more than 64
kibiglyphs, but these can come from anywhere in UCS, not just from the
BMP. This solution also easily provides for glyph substitution, such
that we can finally handle the Indic fonts. It solves the
huge-XFontStruct problem of ISO10646-1, as XFontStruct grows now
proportionally with the number of glyphs, not with the highest
characters. It could also provide for simple overstriking combining
characters, but then the glyphs for combining characters would have to
be stored with negative width inside an ISO10646-C font. It can even
provide support for variable combining accent positions, by having
several alternative combining glyphs with accents at different heights
for the same combining character, and the ligature substitution tables
would encode, which combining glyph to use with which base character.
Looks all very easily doable to me. Someone would just have to sit down
and write a proper spec for ISO10646-C fonts plus the above mentioned
client-side Unicode - ISO10646-C character-glyph-conversion routine,
and then we can start producing fonts and tools.
Unfortunately, I don't have the time to start this in the foreseeable
future. Any volunteers interested in writing a first draft (preferably
in the same troff format in which the other X spects are already
written)?
Markus
P.S.: The C in ISO10646-C stands for combining, complex, compact, or
character-glyph mapped, as you prefer. (And please don't start again
with the fuzz about that C is not a part number of an ISO standard.)
For those who think that all this is obsolete, remember that it is the
only solution proposed so far that makes efficient complex script
rendering available to legacy X terminals with immutable ROM servers and
no RENDER or ST extension.
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: http://www.cl.cam.ac.uk/~mgk25/
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
