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?=
> 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: Страхиња Радић
> ---
> 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, , 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, , , ) >= 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
