Albrecht Schlosser wrote: > 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. >>> Ah, meanwhile I checked that I use xft on linux. I'll try again without, >>> just to see what happens. >> >> If you were able to try a parallel build, one with XFT, and one without, >> then I'd very much welcome the feedback (although if you do find a >> problem I'll likely not be in a position to fix it all that soon!) > > Okay, I tested it on Linux with and without XFT, and I tested it on the > Linux pc with local X display and with remote X display on my windows > pc. There's no difference visible :-( > > All the Linux versions (with different fonts) I tested don't display > ISO-8859-1 characters "correctly" (well, they don't convert them to > utf-8 and display this correctly would be more precise, right?). > > The Windows version, however, does. I'll append two small png images: > utf8-linux.png (gray) and utf8-windows.png (XP-default color, is it > beige in english?). > > The two strings should display "abcäöüßÄÖÜëxyz..." - the first is ISO > encoded, the second is utf-8.
Update: I just found out that I didn't really use Xft in my tests, because I didn't have the header files installed :-( (USE_XFT was always defined as 0, although I configured with --enable-xft). After installing the (debian) package libxft-dev, USE_XFT is defined as 1, and there are some xft-related warnings when compiling. Now there is a difference: the ISO string is now truncated at the first non-utf-8 character, i.e. it displays "iso-8859-1: abc" only, but the utf-8 string is still okay. Albrecht _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
