DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2376 Version: 1.3-feature > cope with some kind of extended ASCII *and* UTF8 at the same time? We have had several discussions about whether this is desirable, or whether we should aim for strict UTF8, and the answer is unclear. > This looks plain wrong to me: > char c = buffer()->character( pos ); > if (!((c & 0x80) && !(c & 0x40))) ok = 1; > [and the nested for loop code] The original FLTK-1.1 code was completely unaware of UTF-8, and all handling is based on byte indexing and comparison. Most of the code is fairly simple to convert to use UTF-8 because it doesn't do any character processing as such. The Fl_Text_{Buffer,Display,Editor} code was derived from NEdit, and handles lots of complicated things that don't play well with aspects of UTF-8/Unicode that nobody had thought about before, and doesn't handle other things required for certain UTF-8/Unicode character sets, e.g. proportional fonts, and columns per character. The code is in an interim state. We know that some methods such as character() are not strictly correct, but are just steps in the gradual refactoring of the code. The Fl_Text_* widgets are code monsters, so progress to refactor them completely has been slow. Link: http://www.fltk.org/str.php?L2376 Version: 1.3-feature _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
