PATCH: xlib support for 16-bit characters when rendering text

[Scott Gilbertson]

> Scott> +  return XTextWidth16(fontStruct, xwchars, length);

tom> Is the argument to XTextWidth16 really UCS-2?
tom> I'm wondering if it is locale dependent or something like that.
tom> Do you have a reference to what is correct?
tom> I'm concerned that this may work in some situations but not others.
tom> In that case we'd need to use some other method to get the encoding
tom> correct.

As far as I can tell (this is all very new to me), the X...16 functions take
16-bit characters, rather than 2-byte sequences.  In the XChar2b structure,
byte 1 is defined as the "row" and byte 2 is the "column".  I'm pretty sure,
therefore that it is independent of the processor's endian-ness.  The only
concern I have is that it will map directly to the character set of the font
you're using, which might not be unicode.  I think solving that (i.e.,
re-mapping the characters from unicode to other encodings) would be a big
job, but we could include a FIXME comment to that effect.

In one of my other patches, I try to load a unicode font first, and only try
other encodings if that fails.  That should reduce the number of cases in
which you get a different character than you're expecting.