[PATCH] Fix emoji font support

[mawww at kakoune.org]

On 2020-02-11 23:25, Marc Lehmann wrote:
> First of all, I have askexd you multiple times for a conrete example 
> case
> so I can look at it, but so far you are good at ignoring all my 
> requests
> for more info.

Sorry I missed those, here is a description of the issue.

Using urxvt built with --enable-unicode3 and this font configuration,

U
Try to cat a file containing:

😄😊😉😍😘😚😜😝😳😁😣😢😂😭😪😥😰😩😰🦄

(Hopefully those emojis pass through the email properly)

With an unpatched Xft and unpatched rxvt-unicode ou will get a mono 
emoji displayed, and in stderr you will see

urxvt: An X Error occurred, trying to continue after report.
urxvt: + Serial number of failed request:  527
urxvt: + X Error of failed request: BadLength (poly request too large or 
internal Xlib length error)
urxvt: + Major opcode of failed request:  138
urxvt: + (which is an unknown extension)
urxvt: + Minor opcode of failed request:  20

This error is triggered by Xft which does not know how to deal with 
those emoji glyphs.

If you use a patched Xft with an unpatched rxvt-unicode, the error goes 
away but the emoji are still mono ones.

Now if you swap the fonts:

URxvt.font: xft:Noto Color Emoji:pixelsize=11,xft:Terminus:pixelsize=12

Still with patched Xft and unpatched rxvt-unicode, emojis are displayed 
in color, but line spacing is huge (I believe it matches the pixel size 
of the images stored inside the font, which IIRC is 124x124 for Noto 
Color Emoji), and cell width is around double the one we get from the 
Terminus font (because the emoji font glyphs are square, and contains 
glyphs for digits)

If you try this font configuration with unpatched Xft and rxvt-unicode, 
you will get the X error, huge line spacing and huge horizontal spacing 
(not double horizontal spacing, much more looks like cells are 124x124, 
so it seems it takes the unscaled size of the emoji glyph that will fail 
to render anyway).

If you try those configuration with both patches applied, you will get 
correct rendering and spacing with the Emoji font as fallback, and 
correct rendering, line spacing, but "doubled" width with the Emoji font 
as primary (because digits characters from the emoji font are still 
square shaped).

I hope this explains the use case and issue clearly enough.

> Furthermore, I must admit I get more and more confused - what you write
> seems to be contradicting itself: does or does your patch not add 
> scaling
> to xft and thus change font metrics independent of FT?
> 
> You seem to now claim that it only avoids an X error?
> 
> Or in other words, your patch to add scaling is not required to exhibit
> the problem in urxvt - if thats the case, again, it would be nice if 
> you
> gave a concrete example that reproduces the problem.

My patch for Xft adds support for color bitmap fonts and for scaling 
their glyphs, those seems to be exclusively used for emoji support. 
Scaling is only applied on those fonts, which were not supported 
earlier, other kind of fonts do not change behaviour.

This means the only difference between patched and unpatched Xft is that 
a set of fonts that were not usable at all are now usable, everything 
that was working before still works the same, something that was not 
working at all now works.

Under any reasonable definition this is NOT an API break.

> UNICODE3 only affects terminal character storage, it has nothing to do
> with 32 bit codepoints, which are supported even when the terminal uses 
> 16
> bits per cell.

Now I am getting confused as well, do you mean rxvt-unicode can store 
codepoints > 0xFFFF when it uses 16bits per cell ? Here if I compile 
rxvt-unicode without --enable-unicode3 emojis are always rendered as 
squares.

>> > Cairo is poretty irrelevant as it has its own API.
>> 
>> My point was that cairo sits at the same layer as Xft for font 
>> rendering.
> 
> And my point was that it is irrelevant for this discussion, as it has 
> its
> own API.

My decision to add scaling support at the Xft level was informed by the 
fact that cairo, a library that provides the same services as Xft (and 
more) and hence sits at the same layer in the display stack did it 
itself. I believe people working on cairo and freetype interact quite a 
lot, and if the decision was taken to do scaling in cairo rather than in 
freetype, I assumed that makes it unlikely for me to get scaling added 
to freetype.

> If the scaling doesn't change the API, then why is there a need to 
> change
> rxvt-unicode?

Scaling does not change the API, but it makes the workaround 
rxvt-unicode uses to compute font ascent, descent and height (and only 
this, width computation is left untouched except for the addition of an 
emoji character in the set of character used) invalid for the fonts 
scaling applies to, which again is a set of fonts that were not 
supported at all before.

This patch tries to fix that by getting ascent, descent and height from 
Xft as they will have scaling applied, but we could also just apply 
scaling directy inside rxvt-unicode to fix this. It would be
>> Scaling is only enabled for fonts that use color bitmaps, those were 
>> plainly
>> not
>> supported before.
> 
> So does or does the patch enable scaling? You claim both, which 
> obviously
> can't be the case.

I think my sentence was pretty clear, but I'll try to put it another 
way, my patch enable scaling for a set of fonts (color bitmap fonts) 
that were not supported by Xft previously, it enables scaling only for 
this set of fonts, leaving all the previously supported font type (mono 
bitmap font, vector font) working exactly as they used to.

The scaling support COULD be used to do things such as auto-slanting of 
mono bitmap fonts, but that is NOT enabled in the current patch.

Cheers,

Maxime.