nanogui: UniCode
Subject:
Re: Unicode
From:
"Bradley D. LaRonde" ####@####.####
Date:
29 Mar 2000 16:05:14 -0000
Message-Id: <011501bf9997$28e263e0$41ea9626@ltc.com>
----- Original Message -----
From: "Greg Haerr" ####@####.####
To: "Bradley D. LaRonde" ####@####.#### ####@####.####
####@####.####
Sent: Wednesday, March 29, 2000 10:37 AM
Subject: Re: Unicode
> : > So this could speak for a 16-Bit representation. I think, it would
> : > be more easy to convert a given program to 16 bit, because you have
> : > a single 16 bit value for a character, not a floating scheme. So it
> : > could be easier to use existing routines for example to get the
> : > length of a string etc. (This could be different: Is a length the
> : > lenght in bytes or the number of characters -what now could be
> : > different. But in old programs its always the same.)
> :
> : I couldn't disagree with you more. I loathe the idea of not using char
for
> : strings, and so does most of GNU/Linux I think.
>
> Well, the good news is that although Microwindows does support
> 16 and 32-bit unicode out of the box, we also have UTF-8, which,
> as Alan posted, has the dual advantage of working with most all the
> C string manipulations functions, as well as being identical to ascii-7
> in the low half. Also, UTF-8 can express all unicode 16 and 32
characters.
>
> So a program written specifying UTF-8 text display will work well
> with ascii and can be used without modification to display any unicode
> character. Note this only works now with truetype fonts, as the T1LIB
> adobe T1 font library still wants a char-sized index for the glyph.
See, there you go again Greg, offering a dazzling array of features and
ruining my religious war. :-)
Regards,
Brad
