> On 08/04/11 06:25, Bill Spitzak wrote: > > On 04/06/2011 01:58 PM, Ian MacArthur wrote: > >> Actually, the "easy" fix for that method might be to *not* use > >> fl_utf8decode() at all but only to use fl_utf8toUtf16() and process > >> the whole string into UTF16 in one go. > > > > This is what fltk2.0 does and it appears to work. > > Yes, and it just seems to be the Right Thing to do anyway. But to make > it "right" we'd need to change the draw() functions and the width() > functions together to make sure that they construct the string in the > same way.
FYI what happened recently around 1.3 fl_draw() and fl_width() on the Mac OS platform: - both functions were initially programmed using whole strings. - but text wrapping was exceedingly slow because of heavy calls to fl_width(). - the fl_width() function was therefore rewritten using the same approach as for WIN32, that is, fl_width() precomputes the widths of blocks of Unicode characters the first time it encounters a block. - text wrapping turned fast. - the fl_draw() function keeps working with whole strings, which is an absolute necessity for scripts such as Arabic where ligation is a key feature. - but fl_draw() has been slightly modified by turning on a flag (kCTKernAttributeName) which deactivates kerning. This ensures that the displayed string width does match the fl_width()-given width that is computed by adding single character widths. - for Unicode points > 0xFFFF, fl_width() does not precompute the width, but recomputes it each time such a character is encountered. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
