On Wed, Jul 12, 2023 at 06:48:45PM +0200, Страхиња Радић wrote: > Hi, recently André Desgualdo Pereira reported a bug in dwm when window names > consist only of characters in ISO 8859-1. In short, windows with such names > had their names broken at the place of ISO 8859-1-specific characters which > are > not in ASCII, for example áâãéíóôúç. When the window name has other Unicode > characters, for example Cyrillic characters etc., the window name is shown > correctly, because it is encoded in UTF-8 and its WM_NAME's type as reported > by > xprop is COMPOUND_TEXT (encoding field is set to 385). In the other case, it > is > set to STRING and encoding field is set to 31. > > I have determined that the window name is encoded in ISO 8859-1 and passed to > drw_text in drw.c as-is, when that function assumes the argument is encoded > in > UTF-8. Commenting out the first part of the relevant if-test results in such > titles being shown correctly due to conversion by > XmbTextPropertyToTextList. > > However, doing so results in other strings passed to gettextprop, which are > encoded in UTF-8 but with encoding field set to 31 (XA_STRING), to also be > passed to that function and converted according to current locale, resulting > in > garbage being output instead of the intended text. This happens for root > window > name set by slstatus, for example. > > In this patch, I have commented out the existing first if-branch in > gettextprop, and introduced another which tests if the window is a root > window. > This is probably not ideal, but the alternative would be some form of UTF-8 > autodetection, the passed data being mislabeled as it is.
> From c5b399e138f6873e2eb9a292d55c5382e654f074 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?=D0=A1=D1=82=D1=80=D0=B0=D1=85=D0=B8=D1=9A=D0=B0=20=D0=A0?= > =?UTF-8?q?=D0=B0=D0=B4=D0=B8=D1=9B?= <[email protected]> > Date: Mon, 10 Jul 2023 09:25:30 +0200 > Subject: [PATCH] dwm.c: Always convert title to UTF-8, except for root window > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > Window names containing only ISO 8859-1 were broken on the location of > non-ASCII ISO 8859-1 character, for example áâãéíóôúç, because they were > treated as UTF-8. When commenting out the if-branch testing for XA_STRING, > root > window title, usually set by status programs such as slstatus to UTF-8 text, > was not shown correctly, so this patch adds an exception for root window > instead, skipping conversion in that case. > > Reported by Dr. André Desgualdo Pereira. > > Signed-off-by: Страхиња Радић <[email protected]> > --- > dwm.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/dwm.c b/dwm.c > index f1d86b2..c896325 100644 > --- a/dwm.c > +++ b/dwm.c > @@ -917,7 +917,10 @@ gettextprop(Window w, Atom atom, char *text, unsigned > int size) > text[0] = '\0'; > if (!XGetTextProperty(dpy, w, &name, atom) || !name.nitems) > return 0; > - if (name.encoding == XA_STRING) { > + /*if (name.encoding == XA_STRING) { > + strncpy(text, (char *)name.value, size - 1); > + } else */ > + if (w == DefaultRootWindow(dpy)) { > strncpy(text, (char *)name.value, size - 1); > } else if (XmbTextPropertyToTextList(dpy, &name, &list, &n) >= Success > && n > 0 && *list) { > strncpy(text, *list, size - 1); > -- > 2.38.5 > Hi, Unless I'm missing something. It seems like an application or environment issue. For dwm it is assumed the environment is utf-8 and application should use it. I think it makes sense if the application uses utf-8 or the same encoding as the environment. It shouldn't pick some encoding an expect the window manager to autodetect and handle all of them. -- Kind regards, Hiltjo
