On 2020-02-11 04:46, Marc Lehmann wrote:
Ok, another thing not mentioned is that libfxt does not actually have
this
behaviour at the moment. And looking at how this is done, I suspect the
patch doesn't work very well because it is simply wrong - I don't think
libxft is the right place to implement font-scaling hacks - if freetype
can't do the scaling, then the correct place for this would be
freetype,
and then existing code won't get broken by it, either.
I think it is debatable if freetype of libXft should do the scaling, for
example
cairo does its scaling itself. Freetype renders vector fonts to any
scale, but
for bitmap fonts it only provides access to the bitmaps stored inside
the font
not touching them at all. For example you cannot ask freetype to a BGRA
glyph
for a mono bitmap font, Freetype clients are expected to convert those
mono bitmaps
to BGRA themselves, I think it is reasonable to see scaling as similar
to this.
It would be nice to provide all those utilities inside freetype itself,
but
that is a much bigger endeavour.
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. I dont
think
this would beat libXft users in any way, and most libXft clients do not
require any change. rxvt-unicode does because it bypasses libXft for
metric
computation, but other software such as st or emacs seems to be okay.
Cheers
Maxime.
_______________________________________________
rxvt-unicode mailing list
[email protected]
http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
