imacarthur wrote: > > On 29 Sep 2008, at 19:14, matthiasm wrote: >> I won't go into detail, but it is enough to know that there are >> illegal sequences, for example, "ös" in ISO genrates a byte sequence >> that would be illegal in utf8. Maybe MSWindwos and OS X recognize >> illegal sequences and assume ISO encoding. > > There is an attempt, of sorts, in the fltk code to catch some of these > illegal sequences and assume they are from ISO-8859-1 or CP1252 (see the > relevant macros in fl_utf.c) which is enabled by default.
Without looking at the code again, that's what I remembered from testing your utf-8 patch, and that's why I thought it should work somehow, at least if the input string is ISO/CP 1252. > 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. > However, I have not looked at this in any real detail, and I don't have > the time just now... If, for example, the text renders OK in > fltk/linux/non-XFT, then my theory may have some merit. > But, if it is equally broken in builds either with or without XFT > enabled, then Something Else is going on, and I really have no idea > right now what! > > >> The correct way though >> would be to convert all source files from ISO to UTF8. > Oh yes. Yes, I'll have to do that when I decide to go productive with FLTK 1.3. > Albrecht's concern, I think, was that his server's wouldn't understand > utf-8 (presumably for paths or filenames) so there can be issues there > also. I think this works OK for me since all may filenames and paths are > ASCII, and ASCII==utf8 for the range of characters my language uses, but > I can see that if your paths or filenames include character values > outside the base 127 ASCII values, then the utf8 mapping might be, erm, > "less convenient". My problem is not a file server. My main app is a client that communicates with a server, and the user does all data entry with this client app. Thus, all text data (from widgets derived from Fl_Input, Fl_Text_Editor, and some more) would have to be converted. But I was aware of that anyway, I only wanted to make some tests without string conversion, and it worked on Windows, but failed on Linux. That seemed strange, but since there are different fonts, I'll have to test more. Yesterday I tested with test/utf8, and I could display utf-8 chars in different fonts, even this RTL (?) text on the left side, #5 and #6. Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
