BTW, your mails were very badly formatted, making it needlessly hard to
read due to the weird word-wrap. Can you make proper paragraphs?
On Tue, Feb 11, 2020 at 09:46:05AM +1100, ma...@kakoune.org wrote:
> > simply wrong for normal fonts, and normal font rendering cetrainly has
> > priority over emoji bitmap fonts.
>
> Looking at the code, if there is no transforms applied, it looks like the
> only
> difference between rxvt-unicode and libXft computation is the rounding,
> which I
> agree can be an issue.
Xft inability to give proper metrics is the reason why we have to go to
the actual underlying font.
> 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.
> 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.
> > 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?
>
> AFAIK the only increase in code size is in static storage for
> extent_test_chars,
So it does increase the codesize needlessly. I believe you when you say
you don't care, but I care about needless bloat.
> 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 believe it is more "correct" because it removes a potential source of
> error
> by making extent_test_chars match the codepoint type that rxvt-unicode uses,
While also introducing another non-potential error. I'd rather stay with
the correct code :)
> Also, the addition of the `#if UNICODE_3` line makes it pretty clear for
> modifications that where to put eventual additional 32bit codepoints.
unicode3 is not the right option for this - either 32 bit code points are
used, or not.
On Tue, Feb 11, 2020 at 09:56:15AM +1100, ma...@kakoune.org wrote:
> I think it is debatable if freetype of libXft should do the scaling, for
> example
It is, and I was debating it. If freetype would do the scaling, which is
arguably the corerct place to do it, then there would be no API breakage.
This alone is a strong argument for doing it in the same place as other
scaling is applied.
> cairo does its scaling itself.
Cairo is poretty irrelevant as it has its own API.
> Freetype renders vector fonts to any scale,
So freetype would be the natural place for this - it makes no sense to
implement scaling in different places.
> 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.
> > 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 :)
> 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.
So you are now claiming rxvt-unicode needs a patch so that libxft doesn't
trigger X errors? That makes no sense to me - could you elaborate what the
mechanism behind this is, and how to reproduce it?
rxvt-unicode is by far not the only program accessing ft font metrics,
btw. All of these work fine with libxft without your patch.
Greetings,
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
rxvt-unicode mailing list
rxvt-unicode@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
