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

Previous Next

Package: emacs;

Reported by: xuan <at> xlk.me

Date: Fri, 11 Oct 2024 21:40:02 UTC

Severity: normal

Merged with 54646

Found in versions 29.0.50, 29.4

Fixed in version 30.1

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Visuwesh <visuweshm <at> gmail.com>
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 16:59:18 +0200
> 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)?

> 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.

> 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.




This bug report was last modified 253 days ago.

Previous Next


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