[PATCH] Fix emoji font support
Marc Lehmann
schmorp at schmorp.de
Mon Feb 10 18:37:16 CET 2020
On Sun, Feb 09, 2020 at 08:33:54AM +1100, Maxime Coste <mawww at kakoune.org> wrote:
> The transformation applied is an arbitrary matrix provided by fontconfig
> (most of the time identity, scaling in the case of BGRA glyphs, can also be
> an auto slanting one).
I see...
> not experienced differences in my testing, but from looking at the code there
> would be one difference in the non-transformed case: libXft does not add 63
> before shifting, so it would round down when rxvt-unicode currently rounds up.
The reason why we go directly for freetype metrics as because xft often gives
wrong metrics, which is disastrous for rxvt-unicode, which absolutely needs
to know if characters overlap and how tall they really are, for example.
That means that simply using xft metrics is not an option, as these are often
simply wrong for normal fonts, and normal font rendering cetrainly has
priority over emoji bitmap fonts.
> > So it only affects bitmap fonts? Any specific font that exhibits these
> > issues?
>
> The intention is to enable Noto Color Emoji.
Well, why doesn't it already work, for example? I still have no idea whatt
he problem is that the patch tries to fix. Does urxvt cut off characters,
or what happens?
> In any case, the rest of the patch (everything but the hunk at line 1239)
> is IMHO improving the correctness of rxvt-unicode by making it use text_t
> for width computation, respecting the UNICODE_3 setting. I think this could
> be applied independently.
It does increase code size and I don't see what would be incorrect with
the old code - could you elaborate what you perceive as incorrect in the
existing code?
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp at schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
More information about the rxvt-unicode
mailing list