Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
imacarthur wrote: 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. 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. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
Bill said: The fltk2 OSX version has had major rewrites to use Carbon correctly and to stop using QuickDraw. You probably want to copy most/all of it if possible. Well, I just had a closer look to fltk2 quartz impl., the first thing I had a look to was the region handling used for clipping drawing areas. But still in fltk2, we use Rgn related API which is pure deprecated QD. I guess it should use CGPaths and achieve the clipping directly in the graphic context as in Quartz there is no region concept anymore, we should use APIs like CGPathCreateMutable() instead of NewRgn, Replace RgnHandle probably by a CGPathMutableRef and so on. I'll look to other fltk2 quartz impl. to see if I can copy some of it which I hope. Fabien ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
Bill Spitzak wrote: ... 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. Depends on what you want. I'd rather see consistent behavior (don't display invalid UTF-8) than try to support both ISO-8859-1 (or your favorite 8-bit encoding) and UTF-8 inconsistently. Moreover, if FLTK allows a mix of UTF-8 and 8-bit characters, it will be very likely that text fields and other widgets will end up with a mix, leading to really interesting problems when those values are written to a file... So, I'm -1 on supporting both ISO-8859-1 and UTF-8 at the same time through any kind of auto-detect code. -- __ Michael Sweet, Easy Software Products mike at easysw dot com ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
imacarthur wrote: Hmm, I don't think I expect any warnings... We probably want to start gathering up the reports of warnings and fixing them, actually... Here they are, all of 'em #warning ... Compiling Fl_x.cxx... Fl_x.cxx:341:2: warning: #warning XFT support here Fl_x.cxx:453:2: warning: #warning XFT support here Compiling fl_font.cxx... In file included from fl_font.cxx:43: fl_font_xft.cxx:539:2: warning: #warning Need to improve this XFT right to left draw function Compiling gl_draw.cxx... gl_draw.cxx:101:2: warning: #warning We really need a glXUseXftFont implementation here... Compiling glut_font.cxx... glut_font.cxx:118:2: warning: #warning FIXME This needs to be UTF aware now Ah - OK, I thought you meant there were things the compiler itself was complaining about, which surprised me because I thought we'd sorted most of them. These are only the deliberate warnings, to remind us about all the things I never did properly... That said, I wonder if the warnings in Fl_x.cxx might have a bearing on the problem you reported... I can't even remember what I dodged around there... The warning from fl_font needs to be sorted out when we get better support for RTL and bi-dir text rendering, but that needs bigger changes through all of fltk, I suspect (if we do it at all). The gl/glut related ones are to remind us that the current implementation we have pretty much assumes all text strings are ASCII. -- 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
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
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 fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
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!) 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. Fonts, and the set of glyphs they actually contain, is a bit of a pain. Some things appear *not* to work on Linux because the fonts tend to contain sets of glyphs targeted for specific languages, or language groups. This happens on Windows and OSX too, of course, but it is less obvious there because: - M$ provide a few pan-Unicode fonts that contain a much larger set of glyphs, making it less likely you'll hit a gap. - OSX ATSU incorporates a mechanism (off by default, but enabled in my fltk-utf8 port, despite being quite slow!) that tries to automatically substitute glyphs from a set of fallback fonts, if the current font does not provide the glyph you requested. Now, that last trick (auto font substitution) we sort of can do with XFT, or at least we could write some code that emulated that behaviour by creating a font set (at runtime) that covered the glyphs in the text to be rendered. I did a few experiments on this at the time, but left it out because I wasn't happy with what I'd done. I plan on going back to this. Eventually... 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. RTL - right-to-left, used for languages (Hebrew, Arabic, etc) that are rendered in the other direction. Other TLA's you'll often see looking at fonts are: LGC - Latin Greek Cyrillic, used to denote a font that contains glyphs intended to cover the majority of languages that use L, G or C characters. CJK - Chinese Japanese Korean, ditto, for C, J or K languages. -- 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
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
Yesterday I tested with test/utf8, and I could display utf-8 chars in=20 different fonts, even this RTL (?) text on the left side, #5 and #6. RTL - right-to-left, used for languages (Hebrew, Arabic, etc) that are rendered in the other direction. Talking about that one and utf8 impl. for OS X, I was starting to correct some Quartz FIXME ... when I noticed that the QD impl. is _broken_ on OS X. I guess it has to do with the new fl_font_mac.cxx API's and behavior like this fl_rtl_draw() API. So I started to code back what was missing in our current 1.3 getting inspired from the original 1.1.9 code, but the result is that the label texts are all systematically, incorrectly shifted right making the label getting outside his related widget box when it should be inside like for standard buttons. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
Talking about that one and utf8 impl. for OS X, I was starting to correct some Quartz FIXME ... when I noticed that the QD impl. is _broken_ on OS X. I guess it has to do with the new fl_font_mac.cxx API's and behavior like this fl_rtl_draw() API. Yes, probably my fault - I gave up on QD when I did my utf8 port and switched to Quartz only. It was too hard to make it handle the Unicode properly, while Quartz was much easier, and I needed it working quickly... QD is officially deprecated now anyway, so I'd like to direct energies into really fixing the Quartz implementation rather than trying to patch the QD version. The Quartz implementation still has some vestigial QD hooks that probably we should work out how to remove. 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
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
Ian wrote: Talking about that one and utf8 impl. for OS X, I was starting to correct some Quartz FIXME ... when I=20 noticed that the QD impl. is _broken_ on OS X. I guess it has to do with the new fl_font_mac.cxx API's and=20 behavior like this fl_rtl_draw() API. Yes, probably my fault - I gave up on QD when I did my utf8 port and switched to Quartz only. It was too hard to make it handle the Unicode properly, while Quartz was much easier, and I needed it working quickly... QD is officially deprecated now anyway, so I'd like to direct energies into really fixing the Quartz implementation rather than trying to patch the QD version.=20 The Quartz implementation still has some vestigial QD hooks that probably we should work out how to remove. It's a good thing, but as we still support it in 1.3, it should work as before, even if not supporting utf8. I'll see what I can do to fix it. BTW I would really like to start helping in the utf8 add-on, the only thing is that I'd also like to see someone that is involved in the current modifications to please update the READ.fltk118-utf file to explain in it: - What is really done in the utf8 modification today (i.e: we don't fully support it, like the glyphs variable width placement in the text and so on, what is the Oksid ...) - What are the new inputs/output strings types expected in the process (we have to deal in fl_font_mac.cxx with UTF8,UTF16, char, UniChar,...) The UTF8 format is, from what I see, not complicated at all (at least it's encoding method), but I currently have difficulties to understand what is still to be fixed/enhanced in 1.3 For now I understand there must be 2 different functionalities: output an utf8 coded string in a text-related widget (like in the utf8 demo), input special characters to be encoded internally as utf8 (keyboard input modifications ?). It would greatly help to document the current 1.3 modifications and what is expected, so that any developer in the team could give a hand. Thanks, Fabien ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
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. Albrecht inline: utf8-linux.pnginline: utf8-windows.png___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
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
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
Fabien Costantini wrote: ... QD is officially deprecated now anyway, so I'd like to direct energies into really fixing the Quartz implementation rather than trying to patch the QD version.=20 The Quartz implementation still has some vestigial QD hooks that probably we should work out how to remove. It's a good thing, but as we still support it in 1.3, it should work as before, even if not supporting utf8. I'll see what I can do to fix it. Actually, I vote to drop QuickDraw support entirely. That interface (QuickDraw) is slower and buggier than Quartz, and is deprecated in 10.5. -- __ Michael Sweet, Easy Software Products mike at easysw dot com ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
On 24.09.2008, at 17:08, Albrecht Schlosser wrote: All fonts have the same problems, e.g. word - looks like: --- schließen - schlie?n Auflösung - Aufl?g größe: 98 - gr? 98 Well, unicode encodes characters in 32bit (currently only the lower 24 bits are used). utf8 is kind of a compression system that converts 24bit numbers into multiple 8bit numbers. To simplify life, characters 127 and below stay the same, wheter encoded in utf8 or not. Characters above 127 however describe different ways of compressing the original 24 bit character. 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. The correct way though would be to convert all source files from ISO to UTF8. http://robowerk.com/ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
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. 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. 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. 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. -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
OK, this is interesting... Does it fail to render the ISO-8859-1 characters on all platforms, or is it only on linux? There's something I saw in the linux parts of my utf8 code that might be implicated here... But if it isn't working on OSX or win32 either it may be a more general problem. Either way, I expected that this should work so if it does not... It's okay on Windows, but fails on Linux with local X display and remote (Windows) X display as well. Hmmm, this maybe ties in with something I'd seen... Some code I have works on win32 and OSX, but not on linux, and it seems it might be the same effect you are seeing. However... It could be argued that linux is doing the Right Thing and the other platforms are wrong! Do you know what numeric value the offending glyphs have, BTW? I don't have my ISO-8859-1 stuff here... Umlaut / special char.: AE OE UE ae oe ue ss Umlaut / special char.: ÄÖÜäöüß -- ISO 8859-1 (ISO Latin 1) 196 214 220 228 246 252 223 -- Right... That's a pity... I had a theory that it was related to the values of the glyphs lying in the range 0x80 to 0x9F (which are CTRL chars in Unicode, but not necessarily in other encodings.) But your problem glyphs aren't in that range. Hmmm. What font are you using, BTW? If it's something I have, I might try and have a look (work/time permitting or course!) For non-Germans: the german Umlauts can alternatively be written as the base character with an appended 'e' or 'E', resp., the sharp as a double s, but pronounced 'sz'. Matthias mentioned something about that before - it's maybe a pity that ß isn't transliterated as 'sz' rather than 'ss' actually as that might disambiguate the conversion of 'SS' to lower-case... Or maybe that would mean something totally different too? I remember that it worked with your utf-8 patch, too, but I tested only windows. I suspect that's just luck, or you only tested on windows. I don't think there's any reason to believe it worked any better than 1.3. The other point (input characters): Although FLTK renders the ISO characters correctly, it returns utf-8 characters, if the non-ASCII characters are entered in an Fl_Input, e.g. (IIRC). I would have to convert this back to ISO-8859-1 anyway, because my server speaks ISO-8859-1 only (with an additional Euro sign). The utf-8 patch includes some helper functions that should help with this, or there's always iconv... But yes, it is a nuisance. Maybe fl_utf8toa() or fl_utf8to_mb() or similar might help you? Worth a look, anyway. Cheers, -- 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
Re: [fltk.development] fltk-1.3 and ISO-8859-1 transliteration
MacArthur, Ian (SELEX GALILEO, UK) wrote: OK, this is interesting... Does it fail to render the ISO-8859-1 characters on all platforms, or is it only on linux? There's something I saw in the linux parts of my utf8 code that might be implicated here... But if it isn't working on OSX or win32 either it may be a more general problem. Either way, I expected that this should work so if it does not... It's okay on Windows, but fails on Linux with local X display and remote (Windows) X display as well. Hmmm, this maybe ties in with something I'd seen... Some code I have works on win32 and OSX, but not on linux, and it seems it might be the same effect you are seeing. However... It could be argued that linux is doing the Right Thing and the other platforms are wrong! Do you know what numeric value the offending glyphs have, BTW? I don't have my ISO-8859-1 stuff here... Umlaut / special char.: AE OE UE ae oe ue ss Umlaut / special char.: ÄÖÜäöüß -- ISO 8859-1 (ISO Latin 1) 196 214 220 228 246 252 223 -- Right... That's a pity... I had a theory that it was related to the values of the glyphs lying in the range 0x80 to 0x9F (which are CTRL chars in Unicode, but not necessarily in other encodings.) But your problem glyphs aren't in that range. Hmmm. What font are you using, BTW? If it's something I have, I might try and have a look (work/time permitting or course!) The default font: Text-Font (15): -*-courier-medium-r-normal--* Label-Font (14): -*-helvetica-medium-r-normal--* or Text-Font (14): -*-bitstream vera sans mono-medium-r-normal-* Label-Font (13): -*-helvetica-medium-r-normal-* All fonts have the same problems, e.g. word - looks like: --- schließen - schlie?n Auflösung - Aufl?g größe: 98 - gr? 98 But I did _not_ change anything related to utf-8, I'm using windows with my default setup (maybe CP 1252?), and Linux with the same setup as before: $ locale [EMAIL PROTECTED] LANGUAGE=de LC_CTYPE=[EMAIL PROTECTED] LC_NUMERIC=[EMAIL PROTECTED] LC_TIME=[EMAIL PROTECTED] LC_COLLATE=[EMAIL PROTECTED] LC_MONETARY=[EMAIL PROTECTED] LC_MESSAGES=[EMAIL PROTECTED] LC_PAPER=[EMAIL PROTECTED] LC_NAME=[EMAIL PROTECTED] LC_ADDRESS=[EMAIL PROTECTED] LC_TELEPHONE=[EMAIL PROTECTED] LC_MEASUREMENT=[EMAIL PROTECTED] LC_IDENTIFICATION=[EMAIL PROTECTED] LC_ALL= maybe that's the point, but I don't know what to set for utf-8. Matthias mentioned something about that before - it's maybe a pity that ß isn't transliterated as 'sz' rather than 'ss' actually as that might disambiguate the conversion of 'SS' to lower-case... Or maybe that would mean something totally different too? That wouldn't help - you can't retransform the other Umlauts, too. It's all the same, there can be words that have an ae that can't be converted to ä. I remember that it worked with your utf-8 patch, too, but I tested only windows. I suspect that's just luck, or you only tested on windows. Yes, I wrote that. The utf-8 patch includes some helper functions that should help with this, or there's always iconv... But yes, it is a nuisance. Maybe fl_utf8toa() or fl_utf8to_mb() or similar might help you? Worth a look, anyway. Yes, I saw these, and I thought that they could help, but I did neither have the time nor the need yet. But time will come, I'm sure... Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
