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 [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
