Bug#699746: #699746 x11-utils: xprop assumes that WM_ICON_NAME and WM_NAME are encoded in ISO-8859-1

2022-02-14 Thread Vincent Lefevre 
On 2022-02-13 18:44:28 -0500, Thomas Dickey wrote:
> I was recently reminded of this one, and can see that it's no longer relevant:
> 
> + The bug-report made incorrect assumptions about what xprop ought to be 
> doing.
>   So it's not relevant to xprop.

Well, I initially thought that this was xprop's fault, while according
to a few tests below, it now seems that this was entirely xterm's.

FYI, in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699746#38
I said:

| Is xprop doing anything wrong or should this problem be regarded
| as coming from xterm specifically, in which case the bug should be
| reassigned to xterm?

But no-one replied to this.

> + Regarding xterm, my changes in patch #349 make it do by default what Vincent
>   assumed.
> 
>  Patch #349 - 2019/09/22
>  * improve title-string feature:
>   + if any of allowC1Printable, utf8Title or titleModes hint that
> an  application  might  send a title-string encoded in UTF-8,
> check  if  that  is  the  case,  and  if it is recodable into
> ISO-8859-1, use that for the ICCCM-style title.
>   + check  if the title given by a control sequence happens to be
> already  encoded  in UTF-8, to avoid double-encoding (FreeBSD
> #240393).
>   + Make sameName resource work for the EWMH titles.
>   + Modify menu-state of utf8Title to be consistent with the utf8
> source,  i.e., setting the EWMH properties automatically when
> UTF-8 is active.

Thanks. It seems to solve all the problems, while the results with
xterm 344 on Debian/oldstable were still incorrect.

To summarize:

$ /usr/bin/xterm -e 'printf "\e]1;my_icon€\x07\e]2;my_title€\x07"; sleep 999'

with xterm 344 gives "my_title???" and "my_icon???" in FVWM, and the
current xprop (from x11-utils 7.7+5) gives

WM_ICON_NAME(STRING) = "my_iconâ?¬"
WM_NAME(STRING) = "my_titleâ?¬"

which is obviously incorrect.

With xterm 351, I get "my_title€" and "my_icon€" in FVWM as expected,
and the current xprop gives

WM_ICON_NAME(COMPOUND_TEXT) = "my_icon€"
WM_NAME(COMPOUND_TEXT) = "my_title€"

which is correct.

$ /usr/bin/xterm -e 'printf "\e]1;my_iconé\x07\e]2;my_titleé\x07"; sleep 999'

with xterm 344 gives "my_titleé" and "my_iconé" in FVWM, which is
correct, but the current xprop gives

WM_ICON_NAME(STRING) = "my_iconé"
WM_NAME(STRING) = "my_titleé"

which still corresponds to the issue reported here.

With xterm 351, I still get  "my_titleé" and "my_iconé" in FVWM as
expected, and the current xprop gives

WM_ICON_NAME(STRING) = "my_iconé"
WM_NAME(STRING) = "my_titleé"

which is correct.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#699746: #699746 x11-utils: xprop assumes that WM_ICON_NAME and WM_NAME are encoded in ISO-8859-1

2022-02-13 Thread Thomas Dickey 
I was recently reminded of this one, and can see that it's no longer relevant:

+ The bug-report made incorrect assumptions about what xprop ought to be doing.
  So it's not relevant to xprop.

+ Cloos' comment about xterm was interesting but not useful for xterm, because
  the encoding as STRING rather than COMPOUND_STRING is done by the X Toolkit
  library.
  
  Reading the Shell.c file in libXt, arguably an application _could_ set the
  resources titleEncoding and iconNameEncoding while setting the title and
  icon-name, but even setting those to COMPOUND_STRING (which does _not_
  hold UTF-8) wouldn'd make the server transmute those into EWMH names (which
  _does_ hold UTF-8).

+ Regarding xterm, my changes in patch #349 make it do by default what Vincent
  assumed.

 Patch #349 - 2019/09/22
 * improve title-string feature:
  + if any of allowC1Printable, utf8Title or titleModes hint that
an  application  might  send a title-string encoded in UTF-8,
check  if  that  is  the  case,  and  if it is recodable into
ISO-8859-1, use that for the ICCCM-style title.
  + check  if the title given by a control sequence happens to be
already  encoded  in UTF-8, to avoid double-encoding (FreeBSD
#240393).
  + Make sameName resource work for the EWMH titles.
  + Modify menu-state of utf8Title to be consistent with the utf8
source,  i.e., setting the EWMH properties automatically when
UTF-8 is active.

just for grins, I'll close this (expecting the usual response from Vincent).

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#699746: #699746 x11-utils: xprop assumes that WM_ICON_NAME and WM_NAME are encoded in ISO-8859-1

2013-02-06 Thread Thomas Dickey 
The documentation for XGetIconName comments:

   The XGetIconName function returns the name to be displayed in the spec‐
   ified window's icon.  If it succeeds, it returns a nonzero status; oth‐
   erwise, if no icon name has been set for the window, it returns zero.
   If you never assigned a name to the window, XGetIconName sets
   icon_name_return to NULL.  If the data returned by the server is in the
   Latin Portable Character Encoding, then the returned string is in the
   Host Portable Character Encoding.  Otherwise, the result is implementa‐
   tion-dependent.  When finished with it, a client must free the icon
   name string using XFree.

...without specifying a way for the implementation to know that the value
is/is not in ISO-8859-1 ... 

while _NET_WM_ICON_NAME is the one which is documented to support UTF-8.

-- 
Thomas E. Dickey dic...@invisible-island.net
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature