On 22 Oct 2007, at 20:43, Johannes Hofmann wrote: >> What error do you see? >> Is it just that the font you are using doesn't have the necessary >> glyphs to represent your strings, or is it something more >> fundamental? > > It's the utf8 string getting displayed as ascii, i.e. there are more > characters displayed than there are glyphs in the string. > I'm using windowlab, but the problem was also reported from > icewm user.
Hmm - I don't think I've seen this ever, but then the WM's I've been using are utf8 aware anyway so I guess it is not a fair test! >> What WM are you seeing problems with? I have a fair bit of fltk/utf8 >> code now, both with and without XFT, and so far it's mainly been >> OK... This is with my patched fltk-118, so may differ markedly from >> the fltk-2 case, of course. >> >> I imagine the intent of the original code is to tell the WM to expect >> utf8 encoded names here: >> >> XChangeProperty(xdisplay, i->xid, _NET_WM_NAME, >> UTF8_STRING, 8, 0, (uchar*)name, l); > > But here the utf8 string is passed already. If it would just announce > utf8 format for the next operation name would not need to be passed > here. > Also from looking at other code, I think that the _NET_WM_NAME is > used to pass the utf8 encoded window name to the wm. Yes - my understanding is that the WM is meant to use _NET_WM_NAME in preference to WM_NAME, if both are set. But my thinking was that if the setting of _NET_WM_NAME failed, that would be a sign that the WM was not utf8 aware, so "special intervention" might be appropriate... > > I will check this, but I think utf8 aware WM's are already fine even > with my patch, as they will look at _NET_WM_NAME. Yes - probably you are right! _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
