Maiorana, Jason wrote: > >Furthermore, the IRG has been, and still is, busy adding Han variants > >to encode. I cannot analyse their proposals, so I cannot tell what > >is variant of what. If you really want a particular variant, go look > >in extension B, or in the upcoming extension C... > > These may be difficult to use as font file formats, such as true type, > have a fixed ucs-2 internal encoding in the cmap, so they have > difficulty representing beyond-bmp characters.
As far as I aware (I'm not a Truetype/Opentype/AAT/Graphite specialist)
various encodings can be used as input to the cmap, including UTF-16
and UTF-32 (there is some setting somewhere telling which encoding
a particular cmap is for). There is, however, a fixed limit of at most
2^16 *glyphs* in a single font, but no restriction that those glyphs
have to be for BMP characters.
> Does anybody here have a system where beyond-BMP glyphs work well
> with? (Input Servers, font display, titlebars, etc)
>
>
> >Also lurking in the
> >wings are "variant selectors", anticipating more variants, but
> >that they should not be given separate characters, but use
> >"variant selectors" instead. Finally, the Unicode consortium
> >has started pondering on "normalisation tailoring", since some
> >find the canonical mappings of some Han characters "unhelpful".
>
> There are no Han variations yet, afaik.
True. Which is why I said "lurking in the wings". They are very
likely to be in Unicode 4.0, though (propably still unused for Han
for a while longer).
/kent k
> I think that for unified
> characters which have significantly different orthography, there
> could easily by a pair of non-unified codepoints which were more
> specific. Thats certainly better that "variant selectors" which
> are destined to be poorly supported if ever.
<<attachment: winmail.dat>>
