Tk Source Code

Ticket transfered from TCL tracker: [https://core.tcl.tk/tcl/info/b200333437946d14]

When font metrics is returning fixed fonts, it fails with the X Error in the
summary.  It is reproducible with this test script on Fedora 25:

<verbatim>
foreach family [font families] {
    if {[font metrics \"$family\" -fixed]} {puts $family}
}
</verbatim>

The test code returns fixed fonts then this error:

<verbatim>
X Error of failed request:  BadLength (poly request too large or internal Xlib length error)
  Major opcode of failed request:  138 (RENDER)
  Minor opcode of failed request:  20 (RenderAddGlyphs)
  Serial number of failed request:  454
  Current serial number in output stream:  519
</verbatim>

The problem is indicated by using strace on the test script:

<verbatim>
open("/usr/share/X11/XErrorDB", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=42077, ...}) = 0
read(4, "!\n! Copyright 1993, 1995, 1998  "..., 42077) = 42077
close(4)                                = 0
write(2, "X Error of failed request:  BadL"..., 95X Error of failed request:  BadLength (poly request too large or internal Xlib length error)
  ) = 95
write(2, "Major opcode of failed request: "..., 36Major opcode of failed request:  138) = 36
write(2, " (RENDER)\n", 10 (RENDER)
)             = 10
write(2, "  ", 2  )                       = 2
write(2, "Minor opcode of failed request: "..., 35Minor opcode of failed request:  20) = 35
write(2, " (RenderAddGlyphs)", 18 (RenderAddGlyphs))      = 18
write(2, "\n", 1
)                       = 1
write(2, "  ", 2  )                       = 2
write(2, "Serial number of failed request:"..., 37Serial number of failed request:  454) = 37
</verbatim>

The problem seems to be the size of /usr/share/X11/XErrorDB.  It is 42077 characters on Fedora 25.

I have tcl-8.6.6-1.fc25.x86_64 and tk-8.6.6-1.fc25.x86_64 installed on Fedora 25.

Just check my Ubuntu (22-10), it has libxft 2.3.4, while the version with Werner's changes are in libxft 2.3.5. So, one more libxft patch-version left to go ....

This is only a little follow-up to libxft color font rendering.

Some activity in the libxft repository indicates that support
for color fonts (noto-emoji) is hopefully on the way into the
next release (they have added my patch, huzzah!).

For reference, see the commits around 2022-07-09 in
[https://gitlab.freedesktop.org/xorg/lib/libxft/-/commits/master]

Merged to 8.6 and trunk.

Still not 100% ideal, but - for sure - far better than the crash ....

Closing for now (but ... if there are further ideas, or other remarks, feel free to add them here).  Let's hope Xft will be fixed finally, not much we can do here any more.

My test results so far (all done on x86_64):

Ubuntu 19.10       works but "Noto Color Emoji" isn't proper displayed

Ubuntu 20.04beta   see Ubuntu 19.10

Fedora 30          "Noto Color Emoji" already sorted out in [font families],
                   specified as -font option wasn't tested
      
Fedora 31          see Ubuntu 19.10

Fedora 32beta      see Ubuntu 19.10

    NB: Fedora 30 uses libXft-2.3.2, all others use libXft-2.3.3

Yes, it works now on Ubuntu. (the font used doesn't display as much Emoji as the "Noto" font, but that's not this patch fault .....) Great!

I would appreciate testing by other people, but since this patch only adds Error-handlers, I agree with Christian that this should be merged to 8.6, I see no possible harm doing that. Will do that in a few days, after somewhat more testing.

Great work, good idea!

Comment 12 on Apr 12, 2020 on my bugzilla bug report
    https://bugzilla.redhat.com/show_bug.cgi?id=1498269
gives information about fixing Xft for color emoji support:

    Note that for the past few months, someone has been working
    on Xft emoji support upstream:
    https://gitlab.freedesktop.org/xorg/lib/libxft/-/merge_requests/1

Confirmed Jan's test on Ubuntu 19.10 and 20.04beta, it bails out
in Tk_MeasureChars(). Refined patch against core-8-6-branch is in
unixrfont-3.diff and works now on Ubuntu 19.10, Fedora not tested
but most likely will work there, too.

Since the Xft color font support is still worked on and there might
be more olden Xft installations around for the next months/years
I think we definitely should fix this issue by some workaround.

Note that for the past few months, someone has been working on Xft emoji support: [https://gitlab.freedesktop.org/xorg/lib/libxft/-/merge_requests/1]

Well, committed this patch to the bug-fix branch.  But ... it doesn't help anything on Ubuntu :-(

Jan, please try again with the first Tk_CreateErrorHandler() in
InitFont() called before GetFont() like so:

---snip---
--- tk/unix/tkUnixRFont.c
+++ tk/unix/tkUnixRFont.c
@@ -324,15 +324,21 @@
 
     /*
      * Fill in platform-specific fields of TkFont.
      */
 
-    ftFont = GetFont(fontPtr, 0, 0.0);
-    fontPtr->font.fid = XLoadFont(Tk_Display(tkwin), "fixed");
+    errorFlag = 0;
     handler = Tk_CreateErrorHandler(Tk_Display(tkwin),
 		    -1, -1, -1, InitFontErrorProc, (ClientData) &errorFlag);
-    errorFlag = 0;
+    ftFont = GetFont(fontPtr, 0, 0.0);
+    if (ftFont == NULL || errorFlag) {
+	Tk_DeleteErrorHandler(handler);
+	FinishedWithFont(fontPtr);
+	ckfree(fontPtr);
+	return NULL;
+    }
+    fontPtr->font.fid = XLoadFont(Tk_Display(tkwin), "fixed");
     GetTkFontAttributes(ftFont, &fontPtr->font.fa);
     GetTkFontMetrics(ftFont, &fontPtr->font.fm);
     Tk_DeleteErrorHandler(handler);
     if (errorFlag) {
 	FinishedWithFont(fontPtr);

---snip---

Tested the patch on latest Ubuntu. Unfortulately, it still gives the same X Error.

chw's patch was committed in a [https://core.tcl-lang.org/tk/timeline?r=bug-1dcca5f2aad5a763|bugfix branch].

Thanks for the quick patch.  It would be nice if the Noto Color Emoji could be supported.

The attached unixrfont-2.diff patch adds the forgotten calls
of Tk_DeleteErrorHandler().

See the unixrfont.diff proof-of-concept patch against core-8-6-branch
which tries to solve the issue using X error handler at appropriate
places. This excludes the "Noto Color Emoji Font" from the example
script and at least on Fedora 30 remedied the premature exit caused
by an obscure X error. As usual, review and more tests needed.

Big Easter eggs for everyone and take care!

Fedora 32 also has the problem.  All color bitmaps cause this problem in TK.

Refer to https://bugzilla.redhat.com/show_bug.cgi?id=1498269 for more information, specifically comment 6.

X-link to [b4d47f5419], which is a duplicate ticket but has more info, namely a link to the corresponding Fedora ticket where the opinion of the Fedora guys seems to be stated about Xft.

Confirmed on a Fedora 25 x86_64 installation. The culprit is the
"Noto Color Emoji" font from the google-moto-emoji-fonts package.
The problem went away after uninstalling that package. Most likely
this is an Xft deficiency (and maybe should be reported to the
Fedora bug tracking system).

> The problem seems to be the size of /usr/share/X11/XErrorDB.  It is 42077 characters on Fedora 25.

Very unlikely.  Need to know what font it is failing on, so need the strace output before it opens the XErrorDB to get the error text.

On a fairly pristine Fedora 25 (hasn't been updated in years, had to install Tk), I get:
DejaVu Sans Mono
Liberation Sans
Nimbus Mono L
FreeMono

This is most likely a font problem and not a Tk problem.