> On a related note, it is suggested (by people who know good stuff, e.g. > Bill, Manolo) that the win32 conversions be converted to all be > "string-by-string", dropping the old "char-by-char" mechanism. If we do, > then ERRORS_TO_ISO8859_1 may also fail on win32 in future? > > Hmm, yup, just tested that by using the ::draw(int angle, const char* > str...) version of the win32 draw text method, and indeed it fails, > though does not cause a crash, just doesn't work...
Ugh! My bad. The current version of 1.3, r8574, does nto actually use fl_utf8toUtf16() in its ::draw(int angle, const char* str...) method, it uses the MS API call MultiByteToWideChar(CP_UTF8, MB_ERR_INVALID_CHARS,...) etc instead. This is part of my trying to work around XP's aberrant handling of surrogate pairs. It transpires that fl_utf8toUtf16() does indeed do ERRORS_TO_ISO8859_1, despite what I said, though it does not depend on the macro to select that behaviour - it just does it anyway. So I was wrong. MultiByteToWideChar(CP_UTF8, MB_ERR_INVALID_CHARS,...) simply drops the entire string, if ANY code point in the string is invalid. Changing it to MultiByteToWideChar(CP_UTF8, 0,...) makes it only drop the invalid code point (on XP it is dropped, on Vista it is replaced by the Unicode substitution char U+FFFD or whatever it is...) So that is "better" in that most of the string is still rendered, but is not the same as the ERRORS_TO_ISO8859_1 behaviour... Or maybe I can figure out why fl_utf8toUtf16() sometimes does odd things on XP and just use that for consistency. Note that I still can't persuade XP to handle surrogate pairs nicely anyway... _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
