libX11 issueshttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues2023-03-15T22:54:48Zhttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/6Error in XGetWindowProperty() when it's called very often2023-03-15T22:54:48ZBugzilla Migration UserError in XGetWindowProperty() when it's called very often## Submitted by Vasily
Assigned to **Xorg Project Team**
**[Link to original bug (#22815)](https://bugs.freedesktop.org/show_bug.cgi?id=22815)**
## Description
I've got a problem with xlib when I call XGetWindowProperty after new ...## Submitted by Vasily
Assigned to **Xorg Project Team**
**[Link to original bug (#22815)](https://bugs.freedesktop.org/show_bug.cgi?id=22815)**
## Description
I've got a problem with xlib when I call XGetWindowProperty after new event has been received (with XNextEvent(m_display, &evt);). It seems to be an accidental bug and I can reproduce it only on my PC with Debian squeeze(testing state). (May be you need some info, so ask me please. I'm a newbie in it)
So, some application calls XConvertSelection and my app receives event with SelectionNotify type. And then I call XGetWindowProperty. XConvertSelection is called very fast and eventually I've got the following stack:
```
#0 0xb78ec806 in exit () from /lib/i686/cmov/libc.so.6
#1 0x08ce6ab1 in qt_xio_errhandler () at kernel/qapplication_x11.cpp:707
#2 0xb7bd88b6 in _XIOError () from /usr/lib/libX11.so.6
#3 0xb7be08f7 in _XReply () from /usr/lib/libX11.so.6
#4 0xb7bbddb3 in XGetWindowProperty () from /usr/lib/libX11.so.6
......
```
The first routine from GetProp.c:
XGetWindowProperty(...........
{
xGetPropertyReply reply;
register xGetPropertyReq *req;
xError error;
LockDisplay(dpy);
GetReq (GetProperty, req);
req->window = w;
req->property = property;
req->type = req_type;
req->delete = delete;
req->longOffset = offset;
req->longLength = length;
error.sequenceNumber = dpy->request;
if (!_XReply (dpy, (xReply *) &reply, 0, xFalse)) {
The second routine _XReplay from XlibInt.c:
We can get _XIOError only in one place if the following comparison is false:
if (extra <= rep->generic.length)
but extra is the third argument of _XReplay (number of 32-bit words expected after the reply) which is zero! We compare int extra with rep->generic.length which is unsigned (right?) and don't go to "if" block.
I don't understand the reason why can rep->generic.length be wrong(very large)? And why does xlib compare signed length with unsigned one?
PS
X -version gives
version number: 11.0
X.Org version: 1.4.2https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/43XCreateIC() leaks name and class strings2022-12-26T13:28:35ZBugzilla Migration UserXCreateIC() leaks name and class strings## Submitted by Andrew Church
Assigned to **Xorg Project Team**
**[Link to original bug (#89481)](https://bugs.freedesktop.org/show_bug.cgi?id=89481)**
## Description
In libX11-1.6.2, when creating an input context, the name and c...## Submitted by Andrew Church
Assigned to **Xorg Project Team**
**[Link to original bug (#89481)](https://bugs.freedesktop.org/show_bug.cgi?id=89481)**
## Description
In libX11-1.6.2, when creating an input context, the name and class strings passed with XNResourceName and XNResourceClass are copied, but the copies are not freed when XDestroyIC() is called on the resulting input context:
```
main() {
/* ... */
XIC ic = XCreateIC(x11_im,
XNClientWindow, window,
XNFocusWindow, window,
XNInputStyle, XIMPreeditNothing | XIMStatusNothing,
XNResourceName, "foobar", // Leaked.
XNResourceClass, "foobar", // Leaked.
NULL);
XDestroyIC(ic);
/* ... */
}
```
```
$ valgrind --leak-check=full ./test
[...]
==8402== 14 bytes in 2 blocks are definitely lost in loss record 13 of 94
==8402== at 0x4C2B960: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8402== by 0x79392D1: strdup (in /lib64/libc-2.20.so)
==8402== by 0x69F22E6: ??? (in /usr/lib64/libX11.so.6.3.0)
==8402== by 0x69F3114: _XimSetICValueData (in /usr/lib64/libX11.so.6.3.0)
==8402== by 0x69EE628: _XimLocalCreateIC (in /usr/lib64/libX11.so.6.3.0)
==8402== by 0x69D3AB4: XCreateIC (in /usr/lib64/libX11.so.6.3.0)
```
Set to severity "minor" since the leak size is small and most programs will probably not call XCreateIC() and XDestroyIC() over and over.https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/39XLookupString() returns UTF-8 instead of Latin-12021-06-03T23:33:04ZBugzilla Migration UserXLookupString() returns UTF-8 instead of Latin-1## Submitted by Christian Bauer
Assigned to **Xorg Project Team**
**[Link to original bug (#86148)](https://bugs.freedesktop.org/show_bug.cgi?id=86148)**
## Description
In a UTF-8 locale, the string stored by XLookupString() in th...## Submitted by Christian Bauer
Assigned to **Xorg Project Team**
**[Link to original bug (#86148)](https://bugs.freedesktop.org/show_bug.cgi?id=86148)**
## Description
In a UTF-8 locale, the string stored by XLookupString() in the buffer_return argument uses UTF-8 encoding (for this test I switched to a German keyboard layout using the Gnome keyboard layout selector and hit the 'Ä' key):
```
$ locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=
$ xev
[...]
KeyPress event, serial 42, synthetic NO, window 0x1e00001,
root 0xa2, subw 0x1e00002, time 95582723, (32,24), root:(1952,532),
state 0x0, keycode 48 (keysym 0xe4, adiaeresis), same_screen YES,
XLookupString gives 2 bytes: (c3 a4) "ä"
XmbLookupString gives 2 bytes: (c3 a4) "ä"
XFilterEvent returns: False
[...]
```
According to the manpage, however, XLookupString() is supposed to always use ISO Latin-1 encoding so it should return 1 byte (e4).
The present behavior of XLookupString() breaks legacy applications which expect this function to return a Latin-1 encoded string.
Additional version information:
```
$ cat /etc/fedora-release
Fedora release 20 (Heisenbug)
$ rpm -q libX11
libX11-1.6.1-1.fc20.x86_64
$ X -version
X.Org X Server 1.14.4
Release Date: 2013-10-31
X Protocol Version 11, Revision 0
Build Operating System: 3.14.3-200.fc20.x86_64
Current Operating System: Linux pengolod.intern 3.16.7-200.fc20.x86_64 #1 SMP Thu Oct 30 18:12:41 UTC 2014 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-3.16.7-200.fc20.x86_64 root=UUID=e10befbd-0183-439f-a502-4b689761f29d ro vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=en_US.utf8
Build Date: 27 June 2014 01:35:28AM
Build ID: xorg-x11-server 1.14.4-11.fc20
Current version of pixman: 0.30.0
Version: 7.7 (2012.06)
```https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/71[PATCH] Add compose sequence for U+01492020-11-02T16:06:09ZBugzilla Migration User[PATCH] Add compose sequence for U+0149## Submitted by Marko Myllynen
Assigned to **Xorg Project Team**
**[Link to original bug (#107034)](https://bugs.freedesktop.org/show_bug.cgi?id=107034)**
## Description
Created attachment 140334
Add compose sequence for U+0149
T...## Submitted by Marko Myllynen
Assigned to **Xorg Project Team**
**[Link to original bug (#107034)](https://bugs.freedesktop.org/show_bug.cgi?id=107034)**
## Description
Created attachment 140334
Add compose sequence for U+0149
There is currently no compose sequence available for ʼn (U+0149), this
looks to be the only letter with no compose sequence from the Latin
Extended-A block.
The below Wikipedia page indicates that while deprecated it is still
in quite general use in Afrikaans. This patch is for consideration to
add a new compose sequence for the letter ʼn.
https://en.wikipedia.org/wiki/%C5%89
**Patch 140334**, "Add compose sequence for U+0149":
[0001-Add-compose-sequence-for-U-0149.patch](/uploads/3de498b9f5435fa03e80e3bbc23c10e8/0001-Add-compose-sequence-for-U-0149.patch)https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/62Add lacking compose sequences for some important characters2020-01-25T01:25:08ZBugzilla Migration UserAdd lacking compose sequences for some important characters## Submitted by Michał Górny
Assigned to **Xorg Project Team**
**[Link to original bug (#85623)](https://bugs.freedesktop.org/show_bug.cgi?id=85623)**
## Description
Created attachment 108661
adds lacking compose sequences for som...## Submitted by Michał Górny
Assigned to **Xorg Project Team**
**[Link to original bug (#85623)](https://bugs.freedesktop.org/show_bug.cgi?id=85623)**
## Description
Created attachment 108661
adds lacking compose sequences for some important characters
I created a patch adding several compose sequences that are lacking from current default compose file. Some of them are required in specific orthographies, the other are quite commonly used so I think they should be accessible through Compose key. None of the proposals conflicts with the existing sequences.
Lacking letters:
• EE : "Ə" (U+018F LATIN CAPITAL LETTER SCHWA) – very important, used in Azerbaijani language; analogous to already existing sequence ee : "ə"
• /B : "Ƀ" (U+0243 LATIN CAPITAL LETTER B WITH STROKE) – now only small b with stroke has compose sequence
• /P : "Ᵽ" (U+2C63 LATIN CAPITAL LETTER P WITH STROKE)
• /p : "ᵽ" (U+1D7D LATIN SMALL LETTER P WITH STROKE)
• /R : "Ɍ" (U+024C LATIN CAPITAL LETTER R WITH STROKE) – used in Kanuri language
• /r : "ɍ" (U+024D LATIN SMALL LETTER R WITH STROKE) – used in Kanuri language
Lacking punctuation marks:
• ^' : "′" (U+2032 PRIME) – correct way of denoting minutes, feets etc.
• ^" : "″" (U+2033 DOUBLE PRIME) – correct way of denoting seconds, inches etc.
Lacking modifier letters:
• ^^' : "ʹ" (U+02B9 MODIFIER LETTER PRIME) – used to sign palatalization in transliteration of Cyrillic
• ^^" : "ʺ" (U+02BA MODIFIER LETTER DOUBLE PRIME) – used to sign no palatalization in transliteration of Cyrillic
• ^_, : "ʻ" (U+02BB MODIFIER LETTER TURNED COMMA) – used in Uzbek and Polynesian (including Hawaiʻian) languages
• ^_' : "ʼ" (U+02BC MODIFIER LETTER APOSTROPHE) – used in ortographies of many languages
• ^_" : "ˮ" (U+02EE MODIFIER LETTER DOUBLE APOSTROPHE)
Some common mathematical symbols and arrows:
• ~~ : "≈" (U+2248 ALMOST EQUAL TO)
• Al : "∀" (U+2200 FOR ALL)
• Ex : "∃" (U+2203 THERE EXISTS)
• /\ : "∧" (U+2227 LOGICAL AND)
• \/ : "∨" (U+2228 LOGICAL OR)
• |v : "↓" (U+2193 DOWNWARDS ARROW)
• |^ : "↑" (U+2191 UPWARDS ARROW)
• >-< : "↔" (U+2194 LEFT RIGHT ARROW) – beacuse `<->` and `<>` are both conflicting
Other important lacking symbols:
• |- : "†" (U+2020 DAGGER)
• |= : "‡" (U+2021 DOUBLE DAGGER)
• o|- : "♀" (U+2640 FEMALE SIGN)
• o|^ : "♂" (U+2642 MALE SIGN)
• VV : "✓" (U+2713 CHECK MARK)
• XX : "✗" (U+2717 BALLOT X)
**Attachment 108661**, "adds lacking compose sequences for some important characters":
[Compose.pre.diff](/uploads/b846e2e81bcd33d7e318124e31006efc/Compose.pre.diff)
Version: githttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/90Memory leak in XrmGetStringDatabase2019-03-10T04:54:20ZBugzilla Migration UserMemory leak in XrmGetStringDatabase## Submitted by Ingo Bürk
Assigned to **Xorg Project Team**
**[Link to original bug (#94604)](https://bugs.freedesktop.org/show_bug.cgi?id=94604)**
## Description
Using XrmGetStringDatabase results in memory leaks, despite calling...## Submitted by Ingo Bürk
Assigned to **Xorg Project Team**
**[Link to original bug (#94604)](https://bugs.freedesktop.org/show_bug.cgi?id=94604)**
## Description
Using XrmGetStringDatabase results in memory leaks, despite calling XrmDestroyDatabase. The following is an excerpt from running valgrind:
```
==21703== 192 (16 direct, 176 indirect) bytes in 1 blocks are definitely lost in loss record 1,051 of 1,063
==21703== at 0x4C2CB1D: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21703== by 0x508CE40: ??? (in /usr/lib/libX11.so.6.3.0)
==21703== by 0x508D3B3: ??? (in /usr/lib/libX11.so.6.3.0)
==21703== by 0x508EC9E: ??? (in /usr/lib/libX11.so.6.3.0)
==21703== by 0x508F4AB: _XlcCreateLC (in /usr/lib/libX11.so.6.3.0)
==21703== by 0x50AC8AF: _XlcDefaultLoader (in /usr/lib/libX11.so.6.3.0)
==21703== by 0x5096D3D: _XOpenLC (in /usr/lib/libX11.so.6.3.0)
==21703== by 0x5096F4A: _XrmInitParseInfo (in /usr/lib/libX11.so.6.3.0)
==21703== by 0x507E96F: ??? (in /usr/lib/libX11.so.6.3.0)
==21703== by 0x5081F4D: XrmGetStringDatabase (in /usr/lib/libX11.so.6.3.0)
==21703== by 0x4020A2: check_get_resource_xlib (test.c:413)
==21703== by 0x402222: check_get_resource (test.c:457)
==21703== by 0x401AF2: test_get_resource (test.c:267)
==21703== by 0x401AF2: main (test.c:77)
```
Please let me know about further information you need.https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/89XrmGetStringDatabase does not resolve include statements2019-03-10T04:53:24ZBugzilla Migration UserXrmGetStringDatabase does not resolve include statements## Submitted by Ingo Bürk
Assigned to **Xorg Project Team**
**[Link to original bug (#94642)](https://bugs.freedesktop.org/show_bug.cgi?id=94642)**
## Description
The documentation for XrmGetStringDatabase states that it handles l...## Submitted by Ingo Bürk
Assigned to **Xorg Project Team**
**[Link to original bug (#94642)](https://bugs.freedesktop.org/show_bug.cgi?id=94642)**
## Description
The documentation for XrmGetStringDatabase states that it handles lines in valid ResourceLine format. However, the ResourceLine format includes "#include" statements, which don't seem to be resolved (but ignored instead).https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/87XSetWMName attempts to modify the property2019-02-23T19:51:48ZBugzilla Migration UserXSetWMName attempts to modify the property## Submitted by Christopher Yeleighton
Assigned to **Jim Gettys**
**[Link to original bug (#36328)](https://bugs.freedesktop.org/show_bug.cgi?id=36328)**
## Description
XSetWMName requires a pointer to a modifiable XTextProperty. ...## Submitted by Christopher Yeleighton
Assigned to **Jim Gettys**
**[Link to original bug (#36328)](https://bugs.freedesktop.org/show_bug.cgi?id=36328)**
## Description
XSetWMName requires a pointer to a modifiable XTextProperty. Data like XTextProperty are amenable to storing in ROM; the library specification requires the property to be copied first, for no reason.
At: section "Setting and Reading the WM_NAME Property"
Is:
```
void XSetWMName( *display,
w,
*text_prop);
Display *display;
Window w;
XTextProperty *text_prop;
```
Let:
```
void XSetWMName( *display,
w,
*text_prop);
Display *display;
Window w;
XTextProperty const *text_prop;
```
Version: X11R6.6https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/83There is incompleteness in the documentation, XkbGetNamedGeometry()2019-02-21T16:18:23ZBugzilla Migration UserThere is incompleteness in the documentation, XkbGetNamedGeometry()## Submitted by Eduard Bagrov
Assigned to **Paul Anderson `@pma`**
**[Link to original bug (#23547)](https://bugs.freedesktop.org/show_bug.cgi?id=23547)**
## Description
Standard says, the function XkbGetNamedGeometry can return B...## Submitted by Eduard Bagrov
Assigned to **Paul Anderson `@pma`**
**[Link to original bug (#23547)](https://bugs.freedesktop.org/show_bug.cgi?id=23547)**
## Description
Standard says, the function XkbGetNamedGeometry can return BadName, but besides
it the function can also return BadImplementation and BadAccess.
Version: X11R6.6https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/88Reformatted version of XKB Extension Lib Spec2019-02-21T10:29:38ZBugzilla Migration UserReformatted version of XKB Extension Lib Spec## Submitted by Graham Wideman
Assigned to **Matt Dew `@marcoz`**
**[Link to original bug (#65749)](https://bugs.freedesktop.org/show_bug.cgi?id=65749)**
## Description
X Keyboard Extension: Library Specification
(http://www.x.or...## Submitted by Graham Wideman
Assigned to **Matt Dew `@marcoz`**
**[Link to original bug (#65749)](https://bugs.freedesktop.org/show_bug.cgi?id=65749)**
## Description
X Keyboard Extension: Library Specification
(http://www.x.org/releases/X11R7.7/doc/libX11/XKB/xkblib.html)
is an essential doc for XKB, yet its formatting makes both the html and PDF versions almost impossible to use. Problems include:
-- Crucial diagrams either too small (html), or so large that only a portion is shown (pdf).
-- "See also section xxx" appears frequently, yet doc has no section numbers. (And the html version TOC has no page numbers, of course.)
-- The many source code samples are very poorly formatted for readability
No doubt these are problems with the translation process from the source format to PDF and HTML, and that process should be fixed.
In lieu of that, I have created a replacement version in which I've fixed all of these problems, (and edited nothing else). Attached.
I suggest this be considered for addition to the doc page mentioned above.
If interested, my original is in Word format.
Version: X11R6.6https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/81XFree86 UTF8 additions to Xlib spec2019-02-21T10:29:13ZBugzilla Migration UserXFree86 UTF8 additions to Xlib spec## Submitted by Alan Coopersmith `@alanc`
Assigned to **Jim Gettys**
**[Link to original bug (#274)](https://bugs.freedesktop.org/show_bug.cgi?id=274)**
## Description
XFree86 has made several additions to the Xlib spec to handle ...## Submitted by Alan Coopersmith `@alanc`
Assigned to **Jim Gettys**
**[Link to original bug (#274)](https://bugs.freedesktop.org/show_bug.cgi?id=274)**
## Description
XFree86 has made several additions to the Xlib spec to handle UTF-8 text strings.
Version: X11R6.6https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/75man pages for XSelectInput and XMapWindow should document ordering issue2018-08-10T21:37:25ZBugzilla Migration Userman pages for XSelectInput and XMapWindow should document ordering issue## Submitted by Alan Coopersmith `@alanc`
Assigned to **Xorg Project Team**
**[Link to original bug (#378)](https://bugs.freedesktop.org/show_bug.cgi?id=378)**
## Description
The man pages for XSelectInput and XMapWindow should in...## Submitted by Alan Coopersmith `@alanc`
Assigned to **Xorg Project Team**
**[Link to original bug (#378)](https://bugs.freedesktop.org/show_bug.cgi?id=378)**
## Description
The man pages for XSelectInput and XMapWindow should indicate that XSelectInput
should be called before XMapWindow, to avoid losing Expose events. See O'Reilly,
for example, in volume 2 man page for XMapWindow:
"The client should call XSelectInput() for exposure events, then map,
then process input events. The client's normal response to an Expose
event should be to repaint the window. If you fail to wait for the
Expose event before drawing, the drawing may not appear in the window."
[Originally reported to Sun as Sun bug id #4333109.]https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/74Man pages should mention header files2018-08-10T21:37:14ZBugzilla Migration UserMan pages should mention header files## Submitted by dgatwood
Assigned to **Xorg Project Team**
**[Link to original bug (#29402)](https://bugs.freedesktop.org/show_bug.cgi?id=29402)**
## Description
I recently received a complaint from some folks downstream from me t...## Submitted by dgatwood
Assigned to **Xorg Project Team**
**[Link to original bug (#29402)](https://bugs.freedesktop.org/show_bug.cgi?id=29402)**
## Description
I recently received a complaint from some folks downstream from me that the Xlib man pages don't mention which headers various functions appear in. Although it is certainly possible for folks to grep for it (assuming they are reasonably command-line savvy), that's really not the best way to get things done, particularly in this day and age when there are GUI IDE users who wouldn't know a CLI from a CFL. :-)
So please consider adding the header information to the pages wherever possible. (The specific page this particular developer was complaining about was the XLoadQueryFont man page.)https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/73Discrepancy between man/code and Xlib spec for XRegisterIMInstantiateCallback2018-08-10T21:37:08ZBugzilla Migration UserDiscrepancy between man/code and Xlib spec for XRegisterIMInstantiateCallback## Submitted by Denis Silakov
Assigned to **Xorg Project Team**
**[Link to original bug (#32802)](https://bugs.freedesktop.org/show_bug.cgi?id=32802)**
## Description
In libX11 code, XRegisterIMInstantiateCallback and XUnregisterI...## Submitted by Denis Silakov
Assigned to **Xorg Project Team**
**[Link to original bug (#32802)](https://bugs.freedesktop.org/show_bug.cgi?id=32802)**
## Description
In libX11 code, XRegisterIMInstantiateCallback and XUnregisterIMInstantiateCallback functions have XIDProc as fifth parameter and XPointer as the sixth one. However, Xlib specification (http://www.x.org/releases/X11R7.6/doc/libX11/specs/libX11/libX11.html) declares these parameters to be XIMProc and 'XPointer *' correspondingly.
This seems to be a long standing issue; man pages were fixed several years ago to correspond the existing implementation (bug #9695), but the specification is still broken.https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/72XDrawArc man page maths come out bad on tty2018-08-10T21:36:57ZBugzilla Migration UserXDrawArc man page maths come out bad on tty## Submitted by Brice Goglin `@bgoglin`
Assigned to **Xorg Project Team**
**[Link to original bug (#9946)](https://bugs.freedesktop.org/show_bug.cgi?id=9946)**
## Description
The following bug has been reported to the Debian BTS 2...## Submitted by Brice Goglin `@bgoglin`
Assigned to **Xorg Project Team**
**[Link to original bug (#9946)](https://bugs.freedesktop.org/show_bug.cgi?id=9946)**
## Description
The following bug has been reported to the Debian BTS 2 months ago by Kevin Ryde.
Brice
On a tty, the eqn math bits in "man XDrawArc" come out looking like
[x+wi2th,y+hei2ht]
or
2n for normal-angle in the range [32,2n]
which makes it pretty hard to understand.
Apparently gnu eqn and/or nroff aren't interested in trying to render
maths on a tty. It'd be nice if XDrawArc could have alternative bits
(".ie n" conditions) that come out better, "[x+width/2,y+height/2]"
and "[3*pi/2,2*pi]" etc.
Version: 7.1 (2006.05)https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/60Mismatch between glibc and X11 locale.alias2018-08-10T20:12:17ZBugzilla Migration UserMismatch between glibc and X11 locale.alias## Submitted by Serhiy Storchaka
Assigned to **Xorg Project Team**
**[Link to original bug (#73098)](https://bugs.freedesktop.org/show_bug.cgi?id=73098)**
## Description
The locale.alias file includes mappings which maps locale na...## Submitted by Serhiy Storchaka
Assigned to **Xorg Project Team**
**[Link to original bug (#73098)](https://bugs.freedesktop.org/show_bug.cgi?id=73098)**
## Description
The locale.alias file includes mappings which maps locale name without encoding to locale name with encoding, but this encoding is different than default GLibc encoding for these locale. E.g. en_IN is mapped to en_IN.ISO8859-1, but the encoding of the en_IN locale in glibc is UTF-8 and en_IN.ISO8859-1 locale is not existing.
Here is full table:
GLibc X11 locale.alias
encoding
az_AZ UTF-8 az_AZ.ISO8859-9E
ca_AD ISO8859-15 ca_AD.ISO8859-1
ca_FR ISO8859-15 ca_FR.ISO8859-1
ca_IT ISO8859-15 ca_IT.ISO8859-1
cy_GB ISO8859-14 cy_GB.ISO8859-1
en_IN UTF-8 en_IN.ISO8859-1
et_EE ISO8859-1 et_EE.ISO8859-15
fi_FI ISO8859-1 fi_FI.ISO8859-15
gd_GB ISO8859-15 gd_GB.ISO8859-1
hi_IN UTF-8 hi_IN.ISCII-DEV
iu_CA UTF-8 iu_CA.NUNACOM-8
iw_IL ISO8859-8 he_IL.ISO8859-8
ka_GE GEORGIAN_PS ka_GE.GEORGIAN-ACADEMY
lo_LA UTF-8 lo_LA.MULELAO-1
mi_NZ ISO8859-13 mi_NZ.ISO8859-1
nr_ZA UTF-8 nr_ZA.ISO8859-1
nso_ZA UTF-8 nso_ZA.ISO8859-15
ru_RU ISO8859-5 ru_RU.UTF-8
rw_RW UTF-8 rw_RW.ISO8859-1
sq_AL ISO8859-1 sq_AL.ISO8859-2
ss_ZA UTF-8 ss_ZA.ISO8859-1
ta_IN UTF-8 ta_IN.TSCII-0
tg_TJ KOI8_T tg_TJ.KOI8-C
th_TH TIS_620 th_TH.ISO8859-11
tn_ZA UTF-8 tn_ZA.ISO8859-15
ts_ZA UTF-8 ts_ZA.ISO8859-1
tt_RU UTF-8 tt_RU.TATAR-CYR
ur_PK UTF-8 ur_PK.CP1256
uz_UZ ISO8859-1 uz_UZ.UTF-8
vi_VN UTF-8 vi_VN.TCVN
X11 locale.alias is used to generate mappings in Python, so this causes issues in Python (http://bugs.python.org/issue20087).https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/56Provide compose sequences for common secondary group of ISO 9995-3 (German T3)2018-08-10T20:12:02ZBugzilla Migration UserProvide compose sequences for common secondary group of ISO 9995-3 (German T3)## Submitted by Andreas Wettstein
Assigned to **Xorg Project Team**
**[Link to original bug (#62189)](https://bugs.freedesktop.org/show_bug.cgi?id=62189)**
## Description
xkeyboard-config contains a German T3 layout, see bug #6099...## Submitted by Andreas Wettstein
Assigned to **Xorg Project Team**
**[Link to original bug (#62189)](https://bugs.freedesktop.org/show_bug.cgi?id=62189)**
## Description
xkeyboard-config contains a German T3 layout, see bug #60991. This layout implements the common secondary group of ISO 9995-3:2010. To be fully functional, T3 and each other layout that supports the common secondary group require the support of compose sequences, not all of which are available in libX11 yet. A table of characters that must be supported and a few compose sequences are given in http://www.open-std.org/Jtc1/sc35/WG1/docs/info1-9995-3.pdf
Version: githttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/53Add compose sequences from gtk+ to X.Org2018-08-10T20:11:46ZBugzilla Migration UserAdd compose sequences from gtk+ to X.Org## Submitted by Simos Xenitellis
Assigned to **Xorg Project Team**
**[Link to original bug (#18751)](https://bugs.freedesktop.org/show_bug.cgi?id=18751)**
## Description
Created attachment 20644
Compose sequences (originating from...## Submitted by Simos Xenitellis
Assigned to **Xorg Project Team**
**[Link to original bug (#18751)](https://bugs.freedesktop.org/show_bug.cgi?id=18751)**
## Description
Created attachment 20644
Compose sequences (originating from gtk+)
The compose sequences in the attachment used to exist in gtk+
but are not found in the current X.Org Compose (en_US.UTF-8) file.
A large group of these compose sequences are of the form
`<Multi_key>` `<A>` `<acute>` : "Á" U00C1
`<Multi_key>` `<a>` `<acute>` : "á" U00E1
which is 'letter' first, then 'punctuation'.
X.Org's Compose file does not have this type of sequence (has 'punctuation', then 'letter').
What I would like is a comment on which sequences are OK to add to X.Org's Compose.
I can file then individual reports, etc.
references: http://bugzilla.gnome.org/show_bug.cgi?id=557420
~~**Attachment 20644**~~, "Compose sequences (originating from gtk+)":
[gtk-compose-lookaside.txt](/uploads/337bbe5ce005214c3beb32dab4d4c6fb/gtk-compose-lookaside.txt)https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/52Update locale support for what glibc 2.3.2 supports2018-08-10T20:11:44ZBugzilla Migration UserUpdate locale support for what glibc 2.3.2 supports## Submitted by David Nusinow
Assigned to **Julien Cristau `@jcristau`**
**[Link to original bug (#7415)](https://bugs.freedesktop.org/show_bug.cgi?id=7415)**
## Description
Attached is a patch we've been shipping with Debian for ...## Submitted by David Nusinow
Assigned to **Julien Cristau `@jcristau`**
**[Link to original bug (#7415)](https://bugs.freedesktop.org/show_bug.cgi?id=7415)**
## Description
Attached is a patch we've been shipping with Debian for a while now that
includes support for all the locales supported by glibc 2.3.2. The documentation
for the patch is included in its header. This applies cleanly to what's
currently in git master HEAD.
Version: gitJulien CristauJulien Cristauhttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/51Drawing strings with fontset in missing charsets2018-08-10T20:11:15ZBugzilla Migration UserDrawing strings with fontset in missing charsets## Submitted by wil..@..at.com
Assigned to **Xorg Project Team**
**[Link to original bug (#97251)](https://bugs.freedesktop.org/show_bug.cgi?id=97251)**
## Description
I have a program using Xlib where I draw text using XmbDrawStr...## Submitted by wil..@..at.com
Assigned to **Xorg Project Team**
**[Link to original bug (#97251)](https://bugs.freedesktop.org/show_bug.cgi?id=97251)**
## Description
I have a program using Xlib where I draw text using XmbDrawString(). I've found that certain characters I try to draw do not show as I expect.
Some information about my environment and setup:
* Locale: en_CA.UTF-8 and setlocale(LC_ALL, "") set in the program.
* I load a fontset with XCreateFontSet() with a base font name of only "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60"
* XCreateFontSet() reports 4 missing charsets: JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0
* My X locale database XLC_FONTSET lists ISO8859-1:GL first and ISO10646-1 last, with KSC5601.1987-0 in between.
* I pass in UTF-8 text to XmbDrawString().
What I see is the majority of ASCII/non-ASCII characters render correctly. There are some that do not. One that does not work is U+2122, the trademark symbol, ™. It shows as '"b'.
I've traced through what is happening and this is my best understanding: The conversion code translates it to KSC5601.1987-0 encoding, which my fontset lacks, and then tries to display it with the ISO8859-1 font.
Here is some information at the code level:
In modules/om/generic/omText.c we convert the input (UTF-8 text) to a charset listed in the X locale database. There are several we try to convert to, in order. In src/xlibi18n/lcUTF8.c we load an ordered list of
preferred encodings, matching that from the X locale database. The U+2122 characters gets converted to the KSC5601.1987-0 charset since it is apparently valid there and this charset comes before ISO10646-1 where it is also valid. KSC5601.1987-0 is a charset my fontset does not have. We end up trying to draw it using ISO8859-1 which appears to be the default due to being in position 0. This leads to the '"b'.
I've confirmed if I drop KSC5601.1987-0 from my X locale database, or skip over it during the conversion, that we convert the trademark symbol to ISO10646-1. Converting to ISO10646-1 is what I expected.
The problem is more extreme if we try to load a fontset with a font with a charset specified, such as with a base font name "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1". If I do so then ASCII characters translate to ISO8859-1, but since there is no font in the fontset with that charset, they can't be drawn. But they could if we translated them to ISO10646-1.
For a solution I am thinking that during the conversions (in lcUTF8.c, such as in charset_wctocs()) we could favour trying those charsets that are available in the font set. That is, skip those that are missing, and at worst try them last. This would mean in both of the problem cases I describe, the characters would translate to ISO10646-1 and display.
From looking at the code I'm not sure the best way to make this happen though. It may be acceptable design wise as some of the lcUTF8.c code is already fontset aware.
I've already converted my program to use Xft for drawing text. I realize that is probably the recommended way to go these days. I wanted to try to figure out why the Xlib core font system was behaving like this though.
Please let me know if I can provide any more information or if you have any ideas about this.
Version: 7.7 (2012.06)