Noto Emoji Color confuses libXft

Hi,

attempting to add color emoji support to an existing application using Xft, I got this error after an XftDrawString:

X Error of failed request:  BadLength (poly request too large or internal Xlib length error)
  Major opcode of failed request:  139 (RENDER)
  Minor opcode of failed request:  20 (RenderAddGlyphs)
  Serial number of failed request:  18
  Current serial number in output stream:  19

I’ve tracked it down (using Xephyr -listen tcp :1, DISPLAY=localhost:1 and wireshark) to libXft calling XRenderCreateGlyphSet with format 0x22, which resolves to

  pict format:
        format id:    0x22
        type:         Direct
        depth:        1
        alpha:         0 mask 0x1
        red:           0 mask 0x0
        green:         0 mask 0x0
        blue:          0 mask 0x0

in my case.

AddGlyph is then called on this GylphSet for U+263A and a 136x128 bitmap, although with 17626 bytes of bitmap data, which would be a depth 8 bitmap. In XftFontLoadGlyphs, a render mode of FT_RENDER_MODE_MONO is assumed, unless font->info.antialias is true, but the bitmap doesn’t actually get downsampled to 1bpp.

I’m not sure whether this is a problem in Xft or Noto Emoji Color setting some flag wrong.

Here is the sample program I’ve been using for this test case: https://gist.github.com/yath/a0d0b4839b030ef4e76b36abb556bacc

[tinmarino]

Hi, sorry to contaminate noto-emoji but other issues redirect here.

The merge request is pending on libXft https://gitlab.freedesktop.org/xorg/lib/libxft/-/merge_requests/1

[behdad]

@behdad, doesn’t the Xft library use the Render extension when available, so it could in theory (if somebody did the work) support color fonts? See Xft on freedesktop.org. I’m totally not volunteering myself, just curious why Xft couldn’t be fixed if somebody wants to do it.

Even then this is not a noto-emoji bug.