imm <[EMAIL PROTECTED]> wrote: > On 22 Oct 2007, at 17:51, Johannes Hofmann wrote: > >>> Is there some reason why a non-XFT WM shouldn't handle utf8 encoded >>> strings? >> >> You are right. This has probabely nothing to do with Xft at all. >> But non-utf8 aware window managers seem to have a problem with >> XA_WM_NAME beeing set to an utf8 string. > > 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. > 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. > > >>> This patch just seems to discard the utf8 encoding and convert the >>> string to "plain" ascii instead - but I can't believe that is the >>> proper >>> intent? >> >> Actually it is the intent, but the more I think/google about it I'm >> no longer sure whether this is the right thing to do. > > The patch you proposed would "break" fltk for all WM's, whether they > are utf8 aware or not. That seems to be the wrong thing to do. Better > to fix the WM so that it is utf aware, surely. > >> In what encoding do XA_STRING type things need to be provided >> according >> to the X-standard? > > 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. > > Then to pass it the utf8 encoded name string here (where your patch > acted): > > XChangeProperty(xdisplay, i->xid, XA_WM_NAME, > XA_STRING, 8, 0, (uchar*)name, l); > I thought, but are not 100% sure anymore, that XA_WM_NAME is the "old" way to pass the window name not utf8 encoded, and _NET_WM_NAME was introduced to have a compatible way to pass utf8 window names. > > > I'd imagine (but have not tried) that the correct thing is to check > what the status is after calling: > > XChangeProperty(xdisplay, i->xid, _NET_WM_NAME, > UTF8_STRING, 8, 0, (uchar*)name, l); > > if that has returned a BadAlloc, BadAtom, BadMatch, BadValue or maybe > BadWindow error then I'd guess that means your WM can't do utf8 and > you should transform your name string to plain old ascii (as per your > patch). > Otherwise I guess that means the WM can handle the utf8 name and no > further action is required? > Then your patch would be activated for WM's that couldn't handle the > utf8 names, and more capable WM's would be passed the name directly. > 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. Johannes _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
