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 I propose to close this STR with the attached patch fl_font_xft.diff that's a simplification of Ossman's one: the UTF-8 decoding is done by fl_utf8towc() that always returns a 32-bit Unicode value under X11, so I don't think XftTextExtents16() and XftTextExtentsUtf8() are useful. In essence, it consists in decoding the UTF-8 string into Unicode (32-bit) characters for each fl_draw() and fl_width() call and drawing or computing the width of the text with an Xft function that accepts 32-bit Unicode values instead of a UTF-8 string. The decoding is done, ultimately, with function fl_utf8decode() that transforms any byte sequence into valid Unicode values, interpreting bad UTF-8 data as CP1252. Thus, any byte sequence will produce some output text. I suspect that UTF-8-accepting Xft functions decode the UTF-8 internally. Thus, doing this decode operation before hand may not slow down the process. I have found it runs well under Linux with test non-UTF-8 data. Link: http://www.fltk.org/str.php?L2505 Version: 1.3-current _______________________________________________ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
