In glibc wchar_t is 32 bits. Windows wide characters are UCS-2 or were last
time I ran into them. UTF8 is probably the right thing for storing the text in
a file IMHO but there are other choices.
<begin quote from glubc manual>
But for GNU systems `wchar_t' is always 32 bits wide and,
therefore, capable of representing all UCS-4 values and,
therefore, covering all of ISO 10646. Some Unix systems define
`wchar_t' as a 16-bit type and thereby follow Unicode very
strictly. This definition is perfectly fine with the standard,
but it also means that to represent all characters from Unicode
and ISO 10646 one has to use UTF-16 surrogate characters, which is
in fact a multi-wide-character encoding. But resorting to
multi-wide-character encoding contradicts the purpose of the
`wchar_t' type.
<end quote from glibc manual>
The fun is increased because X11 seems only to handle UCS-2 with functions like
XDrawText16, which expects an XChar2b * argumnnt, and 8 bits if you stick to
plain XDrawText. This probably "infects" xforms, Qt, etc. What XwcDrawString
expects and how hard it would be to crate a font_set (see XCreateFontSet) which
does the right thing is not obvious.
My Xfree86 4.2.1 tree does not contain any fonts that do more than one alphabet
anyway... so it theory you could get latin-1 and latin-2 glyphs using UCS-2
(aka XChar2b, wide characters in M$ windows, etc) you actualy need to use two
different fonts or a font_set. Methinks that UCS-4 internal format will require
the the painter to have a UCS-4 to font and glyph mapping function.
If math symbols are on the agenda it might make sense to follow TeX's method
and understand mathcodes instead of heading for wide characters, if only to
save effort by being able to hijack TeX's work (and support other, more
specialised, math formats that come with special fonts).
--
Duncan (-:
"software industry, the: unique industry where selling substandard goods is
legal and you can charge extra for fixing the problems."
