[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