DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current I've just attached svn-diff-against-r7855.txt which I think solves this problem, but it's still very much a work in progress that needs to have someone else's expert eye casting over it. There are some functions that need renaming and relocating into the correct files. This patch addresses two different issues: 1. the use of fl_utf8len(char c) and other byte-by-byte walking through the Fl_Text_Buffer ring buffer which fails if the text contains CP1252 C1 control characters. I've introduced an almost equivalent fl_drg8len(char* s) function (to be renamed) that uses fl_utf8decode() to calculate the length of the byte sequence starting at s. I've updated next_char() and prev_char() to copy some bytes from the ring buffer into an array so that I can call fl_utf8fwd() and fl_utf8back() to determine how many bytes to move the pos value. Various other places where fl_utf8len(c) is called or byte values are examined have also been changed. There are a couple of uses left over that I'm not sure about. These changes allow the arrow keys to work on the lines for octal 200 and above without hanging the application or exiting with an assert message, but there is no obvious cursor movement until you reach the next line. Note the replacement of the body of the IS_UTF8_ALIGN macros with functions to enable better debug reporting, etc. 2. I've introduced a drgExpand() function in Fl_Text_Display.cxx that converts a CP1252 string into its full UTF-8 equivalent. This can then be passed to fl_width() and fl_draw() otherwise they don't work correctly because they only handle exclusively UTF-8 strings. The conversion is done to a temporary char array so that the current positions and location pointers into the text and style buffers don't need to be changed. Unfortunately this means that there is a lot of string rewriting every time that text is measured or drawn. Obviously this drgExpand() function should be renamed and relocated if we decide to continue with this solution. I think that just leaves one routine where fl_utf8len(c) is called with a UCS value rather than a byte, which is just plain wrong. I shall raise an RFC in fltk.development to discuss this further. Link: http://www.fltk.org/str.php?L2348 Version: 1.3-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
