MacArthur, Ian (SELEX GALILEO, UK) wrote: > >>> I suspect this doesn't work all that well, particularly on >> linux/XFT, >>> where I suspect that this workaround is partly inhibited by >> my decision >>> to render the text strings using XftDrawStringUtf8() directly. >> I believe this is what is happening. In fltk2 id does not use the Xft >> UTF8 functions, it works similar to the other platforms. This >> allows it >> to display most ISO-8859-1 correctly. More importantly, it will draw >> something for a piece of text with invalid UTF_8 in it. The Xft >> functions quit if they see invalid UTF-8 which is not very desirable >> behavior. > > Yup - this is what I thought was happening. > However, the waters are muddied somewhat by the revelation that the > system where Albrecht observed the failure was running a "non-XFT" fltk > build (seems there were issues with header dependencies so that XFT was > off.) > > So the failing strings were being drawn by the "regular" X mechanisms - > which I had expected would Just Work. > > It seems that once XFT was enabled on that system.... it still didn't > work... (but that was expected!)
There are three cases now: (1) Windows: renders ISO-8859-1 correctly (2) Linux w/o Xft: replaces some characters with '?', supposedly until it can find a correct utf-8 character again. (3) Linux with Xft: cuts off at the first non-utf8 char, as Bill wrote. Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
