DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current Yes, I think that's right. The OP wrote: "... by doing a UTF-8 to UCS-2/UCS-4 conversion, which has the side effect of filtering the string." That's true, and I tested it with an application that uses ISO-8859-1 for all data (text) internally. The appearance is much more like it is with the Windows version. But there's a difference: on Windows we _must_ convert all strings from UTF-8 to the hosts wchar_t format to do Unicode rendering, on Linux we don't need to do it (basically). So what happens is that we lose speed for something we don't need to do if all text is correct (UTF-8). :-( OTOH, as mentioned above, we _do_ convert all strings on Windows, and this has the same speed loss, so it might be negligible. Maybe? My tests showed some problems with rendering of non-UTF-8 text (similar to misc/iso-8859-1.txt), so I'll need more time to test... Technical remarks to the provided patch: - As seen recently, we must not allocate dynamic arrays like "wchar_t wstr[n + 1];" - we must malloc() or new (and free/delete) dynamically sized data for compatibility reasons with old compilers. - As Ian said, the runtime sizeof() comparisons are probably not needed, and we don't need to convert the string if we use it later in the else case as-is. That should be improved, if we agree to apply it. Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
