> > 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!) -- Ian SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
