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 The following applies specifically to a German Windows system, but everybody with non ASCII texts should have the problems. FLTK revision: 1.3.x-r7613 |=---=[ Navigation In Fl_Text_Display::move_right/left/up/down(): char c = buffer()->character( pos ); This returns a utf8 decoded character code (an int), not the binary char at that position. This is what was more likely meant: char c = *(buffer()->address( pos )); To see the problem start test/editor.exe (which loads the default text "Rügenwälder RuÃ.") and navigate to the umlaut "Ã". The cursor will hang to the right of "Ã" for one additional arrow key stroke. |=---=[ Rendering Open test/editor.exe and navigate around to see gaps appearing. Fl_Text_Display::draw_vline() erases more characters when encountering umlauts than it repaints. The problem is that charLen = Fl_Text_Buffer::expand_character was meant to expand tabs, but it also returns the underlying code length for umlauts. In the two for loops, charLen is therefore used to count both visible chars and utf8 char codes. Specifically X += charWidth; adds the char width twice for umlauts because of this and causes the visual gaps. Probable solution (written in prose rather than code): Make a distinction between the visible character length (for tabs and special sequences) and the underlying char code length to advance in the loop. 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
