[GRASS5] Re: Freetype failure
Roger Miller
roger at spinn.net
Tue Mar 28 12:07:33 EST 2006
On Wed, 2006-03-29 at 00:45 +0100, Glynn Clements wrote:
> > This is true for multibyte characters, but not single byte characters.
>
> I don't understand what you're saying here. Or maybe you're
> misunderstanding something. UCS-2BE is just 16-bit unicode codepoints
> stored in big-endian byte order.
UTF-8 can be 1, 2, 3, 4, 5 or 6 bytes. The first byte corresponds to
the old ascii standard. Transactions with ascii are just one-byte
transfers, most transactions with latin-1 and ISO-8859-1 characters are
also just 1-byte transfers.
> > Sorry if I mislead you. My suggestion was that the code would retain
> > convert_str and convert_str would use iconv to convert all user-supplied
> > encodings to UTF-8 instead of to UCS-2BE as it does now. Draw_text would
> > decode UTF-8 to FT_ULong.
>
> Using UTF-8 as the intermediate encoding doesn't make sense.
>
It makes sense if you start with UTF-8 and there is no intermediate step
at all. Lots of us are using UTF-8 now (possibly without realizing it)
and more of us will be using it in the future.
> Also, AFAIK, FT_ULong is in the host's byte order, so you either need
> to convert char[4] to FT_ULong using shift+or (which is what happens
> at present), or use either UCS-4BE or UCS-4LE depending upon the
> host's byte order (Vax users are out of luck).
Does the existing code account for differences in byte order? I don't
see how it does.
Roger Miller
More information about the grass-dev
mailing list