[PATCH] Fix emoji font support

[mawww at kakoune.org]

On 2020-02-11 15:15, Marc Lehmann wrote:
> BTW, your mails were very badly formatted, making it needlessly hard to
> read due to the weird word-wrap. Can you make proper paragraphs?

Sorry about that, not sure what is rewrapping my mails, I'll just stop 
manually wrapping my paragraphs.

>> If we use the emoji font first in the font list, then urxvt computes 
>> the
>> metrics
>> pre-scaling, so ends up with a 124x124 font metric when the rendered 
>> glyphs
> 
> Yes, but this is an artifact of the (IMHO) broken way your patched xft
> does the scaling. It doesn't happen with the real xft library, as far 
> as I
> can see.

It is unclear to me why you seem to think that patch changes something 
in xft that break clients. It should not, unpatched rxvt-unicode works 
the same with and without the xft patch. What changes is that a broken 
use case (using color emoji fonts) goes from generating X errors to 
displaying the color emoji glyphs, some software such as rxvt-unicode 
need to be patched to fully support that use case because as a 
consequence of applying the scaling in Xft (putting aside the question 
of if its the right place to do that) which makes the metrics returned 
by freetype for those fonts out of sync with the xft rendered glyphs.

> 
>> Without the emoji inside the extent_test_chars, the emoji font is 
>> ignored
>> we cannot compute its width (as none of the characters we try exists 
>> in the
> 
> I see - but while I agree that this computation should be improved, 
> adding
> characters for single fonts is not a good solution.

Most (if not all) of color emoji fonts only contains emoji characters, 
which is why I added one emoji character in extent_test_chars to support 
that. I imagine this is the same reasoning that led to having a chinese 
and an arabic character in there.
>> I would worry about (especially as this only takes place *if* 
>> rxvt-unicode
>> compiled with UNICODE_3 support).
> 
> That would need to be fixed - the size computation should not be 
> different
> when unicode3 is in effect.

I dont see any way around that, if rxvt-unicode does not support 32bit 
codepoint, how could it compute the size of a 32bit codepoint glyph ? If 
UNICODE_3 is not the correct setting to check I am happy to change that.


> 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.

>> It would be nice to provide all those utilities inside freetype 
>> itself, but
>> that is a much bigger endeavour.
> 
> It would also be much more correct, useful, and wouldn't require 
> patching
> third-party software because it wouldn't break the Xft API.

Again the Xft API does not get broken in any way, something that did not 
work now works, and whatever already worked did not change behaviour. I 
trust there are good reasons for bypassing the Xft API for font metrics, 
but that does not make this workaround part of that API.

>> > I think fixing the original patch to work better is altogether the
>> > better
>> > approach - certainly beats every libxft user because the api has changed
>> > in incompatible ways.
>> 
>> The change of behaviour on libXft side is that instead of triggering 
>> X11
>> errors when trying to display emoji, it actually displays them.
> 
> This doesn'T seem to be true - the patzch clearly implements the 
> sdcalking
> behaviour as well, or did I miss something? That would be the thing 
> that
> needs improving, not triggering X11 errors, which is something you have
> just brought up and is not contested by me :)

Scaling is only enabled for fonts that use color bitmaps, those were 
plainly not
supported before.

Cheers,

Maxime.