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.
_______________________________________________
rxvt-unicode mailing list
rxvt-unicode@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
