GNU bug report logs - #73752
29.4; Ligatures are randomly rendered with extra spaces

Previous Next

Full log

Message #80 received at 73752 <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 73752 <at> debbugs.gnu.org, xuan <at> xlk.me
Subject: Re: bug#73752: 29.4; Ligatures are randomly rendered with extra spaces
Date: Mon, 28 Oct 2024 21:48:26 +0530

[திங்கள் அக்டோபர் 28, 2024] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: luangruo <at> yahoo.com,  73752 <at> debbugs.gnu.org,  xuan <at> xlk.me
>> Date: Mon, 28 Oct 2024 09:56:13 +0530
>> 
>> Real-life Lisp programs certainly do not change face font attributes so
>> often but I believe the script does it so to reproduce the issue
>> quickly.  In a regular Emacs session, it is enough for the same text to
>> be shown in different font sizes (as a consequence of using C-x C-+) and
>> font weights to eventually exhibit this misalignment IME.
>
> You need to catch this situation in some reproducible recipe.  Because
> up front I don't understand how is this possible: we cache each
> composition with its font object, which includes the font size (and
> also slant, weight, etc.), so a different variant of the same font
> ought to match only cache entries that use the exact same font.  Or
> maybe I don't understand well enough what
> composition_gstring_put_cache does to compute the hash of a
> glyph-string header (which is the hash key for a composition)?

Is this hash dependent on the font driver?  IME and from what I see from
other issues in ligature.el's GitHub issue page, the problem seems to be
specific to Cairo builds which would also explain why you are not able
to reproduce this.

Also, do we clear the composition cache when all the GUI frames of an
Emacs daemon are deleted?  The misalignment goes away when I close all
the GUI frames of the daemon, and open a fresh new GUI frame.

>> I do not understand the technical details but the width of the glyph
>> used to draw it is not the one that should be used for the underlying
>> font (weight, size, etc. included) which leads to this misalignment.
>
> Which seems to indicate that we somehow use a different font's metric.

That is my impression, yes.

>> To make it more clear, let's say that =:= is shaped for a font X with a
>> specific weight, size, etc.  At a later point in time, the width of the
>> glyph corresponding to X is used to draw =:= with font Y of same family.
>> This leads to the observed misalignment AFAIU.
>
> But how can this happen?  Without a reproducible recipe, which can be
> reproduced without waiting for too long, it is very hard to
> investigate this.

I have no idea.  This is not easy to reproduce and seems to be heavily
dependent on the configuration.  Although I use a Cairo build (with
Lucid toolkit), the misalignment is not as severe as OP says and it
takes a lot more time to reproduce as well.  I could never come up with
a reproducer that takes less time.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.