RE: Fw: Re: [AD] messy allegro 5.0 stuff |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Sven Sandberg writes:
> I think Unicode characters have range [0,65535], and in that
> case it would suffice for the return value to be less than
> 0x10000 for unicode and greater for non-unicode. Or, we
> could make it be positive for unicode and negative for
> non-unicode.
Unicode actually defines a full 32 bit character space. Or should I say,
currently doesn't, but might some day :-) They've totally filled up the
0-65535 range, and there are already a few overflows for very
obscure/obsolete/specialised character sets, and likely to be more in
the future.
The full 32 bit character set (called UCS4) can be encoded in many
different ways. UTF16 is basically just 16 bits per character, and
a lot of programs using this can only encode the low 65536 chars of
the complete UCS4, but Unicode actually define escape sequences that
let UTF16 represent values outside that range. UTF8 can directly
represent any value 0 to 2^32-1.
As far as Allegro goes, assuming Unicode only ever ranges 0-65535
is probably reasonable (lots of programs do the same), but not
exactly correct. It would be nice to get this totally right if
possible, allowing the entire 32 bit range for Unicode characters,
and putting the flags and scancode somewhere else...
> Also, maybe it could be useful to have two separate functions to clear
> the scancode buffer and the unicode buffer?
Absolutely: doing both at the same time has caused no end of trouble in
the current API.
--
Shawn