On 09/22/2011 02:44 AM, Duncan Gibson wrote: >> I have changed (r.9055) the Doxygen doc of fl_draw() functions >> to state explicitly that all involved strings are UTF-8 encoded >> and all lengths are in bytes. >> >> I would suggest to use the fl_utf8decode() function in your case. >> It will successively compute the byte length of each Unicode character >> in your UTF-8 string. When you have reached the maximum allowed >> number of characters or the string end, you'll know how many bytes >> to send to fl_draw(). This would work for LGC scripts provided >> accented characters are encoded with a single Unicode value. > > The "Unicode in FLTK" section in http://www.fltk.org/doc-1.3/unicode.html > already explicitly states: > > "FLTK will only handle single characters, so composed characters > consisting of a base character and floating accent characters will > be treated as multiple characters" > > as this was the consensus when this was all being discussed in 2009. > D.
Not sure exactly what is meant by that. The low-level utf8fwd/back/decode api will return the Unicode code points without any changes or normalization, so this is correct about that. However printout is *supposed* to render UTF-8 as accurately as possible. In the ideal world the accents will print above the character before them in exactly the right place. I think this is working pretty well on the newest OS/X versions. Windows is somewhat inbetween (I think it recognizes anything that can be replaced with a precomposed character), and Linux is the worst right now (it just draws the glyphs next to each other) (Linux could be the best if FLTK called Pango to do the layout, but there may be resistance to that). In any case FLTK's behavior when printing is not an indication of the intended design. Correctly handling Unicode strings requires enormous resources, and it is hoped that FLTK can avoid writing all that. Supposedly a program just calls these resources directly, and FLTK calls them to render strings, but otherwise it does not need to provide an API. _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
