On Tue, Feb 11, 2020 at 05:47:03PM +1100, ma...@kakoune.org wrote:
> 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.
Thanks, much better!
> > 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.
First of all, I have askexd you multiple times for a conrete example case
so I can look at it, but so far you are good at ignoring all my requests
for more info.
Furthermore, I must admit I get more and more confused - what you write
seems to be contradicting itself: does or does your patch not add scaling
to xft and thus change font metrics independent of FT?
You seem to now claim that it only avoids an X error?
Or in other words, your patch to add scaling is not required to exhibit
the problem in urxvt - if thats the case, again, it would be nice if you
gave a concrete example that reproduces the problem.
> > I see - but while I agree that this computation should be improved,
> > 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.
The test characters serve another purpose, namely detecting whether locale
info matches the font - many monospace font are not actually monospaced,
and xft does a very bad job at exposing this information (in general, xft
is a desaster regarding font metrics, most programs that rely on metrics
have to work around xft in some ways, which is why it would be nice if
this would keep working).
It might not be a good way to do it, but that's another issue.
> > 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.
UNICODE3 only affects terminal character storage, it has nothing to do
with 32 bit codepoints, which are supported even when the terminal uses 16
bits per cell.
> > 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.
And my point was that it is irrelevant for this discussion, as it has its
own API.
> > 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.
Ok, but the way you presented this was ditrectly tied to the bitmap scaling
that Xft didn't do, and the motivation for the patch was explained by this
scaling as well.
If the scaling doesn't change the API, then why is there a need to change
rxvt-unicode?
> > > 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.
So does or does the patch enable scaling? You claim both, which obviously
can't be the case.
--
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
