Hi,
> > For the second question, cs* are used for CTEXT encoding, fs* are used
> > for font rendering, these definitions can be different.
> >
> This doesn't convince me.
Nothing wrong there. The cs* sets are used for conversion from CTEXT as well
as to CTEXT. When a convertion module converts some multibyte (or wide char)
string into CTEXT or codes that can be used for rendering it tries charsets
in the order they are numbered.
You can see that in the zh_TW.big5 locale the charset 'cs1' completely
overlaps two next ones. The codes that fall into cs1 range are multibytes
with the first byte 0xa1-0xf9 (the second byte value doesn't matter here),
whereas cs2 covers multibutes with the first byte in the range 0xa1-0xc7 and
the cs3 charset deals with multibytes where the first byte is one from
0xc9-0xf9. Thus the cs2 and cs3 charsets in the multibyte point of view are
subsets of cs1. And when the converter module prepares multibytes for
rendering (converts them into glyph indexes) it never comes to cs2 and cs3
and the corresponded fs*'s are unneeded.
Those two additional charsets are useful for opposite conversion (from CTEXT)
only.
> Considering a process running under zh_TW.big5 locale, when get a CTEXT
> element(with ESC sequence indicates BIG5-E0/E1 charset) through certain
> ICC method, it will convert to CharSet before use it.
Not exactly. When an application gets a CTEXT segment the segment already
match one of CharSet record. "Before use it" the application converts it
into multibyte string.
> But the element will convert to cs2 or cs3(no way to cs1), which has no
> corresponding fs* definition. How it supposed to be correctly rendered?
Xlib doesn't render CTEXT string directly. You should call one of
X{mb|wc|utf8}Draw* function and feed it with multibyte, wide char or utf8
string. But as I said above such string will always be converted into cs1 and
never into cs2/cs3 charsets. (Frankly speaking the wc_encoding values are
actually wrong in that locale description. And if one tries to convert CTEXT
into WC directly and then draw that WC string it will fail, really. But it's
a bug. With MB or UTF8 strings it should not happen.)
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
