> However, the actual Unicode ranges as currently defined, (and see
> RFC 3629) specify that the valid range is (currently) only up to
> 0x0010FFFF, so in practice an int32 is fine...
>
> I don't know what Linux or OSX use internally for their 32-bit
> wide char types, I guess we should try and achieve some sort of
> consistency of possible. I guess uint32 would be my guess?
> Win32 will always be an "outlier" since they use a 16-bit wchar...
Now that I see it written down like that, I remember adding the
following to the Unicode and UTF-8 Support doxygen page:
"The current implementation of Unicode / UTF-8 in FLTK will impose
the following limitations:
* An implementation note in the code says that all functions are
LIMITED to 24 bit Unicode values, but also says that only 16 bits
are really used under linux and win32.
[...]
Todo:
Verify 16/24 bit Unicode limit for different character sets?
OksiD's code appears limited to 16-bit whereas the FLTK2 code
appears to handle a wider set. What about illegal characters?
See comments in fl_utf8fromwc() and fl_utf8toUtf16().
"
Would it make sense to update the utf-8 code so that we only ever
pass in int32 or uint32 parameters, and not "wchar_t"? We could add
a test on input that converts anything above 24-bits into a specific
undefined character value, which we would need to document of course.
D.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
