Subject: bug#73752: 29.4; Ligatures are randomly rendered with extra spaces

From: Visuwesh <[email-masked]>
Date: Sun, 27 Oct 2024 21:49:32 +0530

[ஞாயிறு அக்டோபர் 27, 2024] Eli Zaretskii wrote:

> Ping!  Unless someone can debug this, I'm going to close this bug as
> unreproducible.

I can reproduce this with Cascadia Code but it took a lot more than "5
seconds."  I see no extra spaces but I see misalignment, it is not as
bad as it was reported in

    https://github.com/mickeynp/ligature.el/issues/56

by others.  I tried it with JetBrains Mono but failed to reproduce.  I
have a suspicion that it might be related to bug#54646 where I face(d) a
similar issue with Tamil text.  FWIW, I experienced a similar
misalignment (exactly) once with Julia Mono for the sequence

    LATIN SMALL LETTER A (a) + COMBINING CIRCUMFLEX ACCENT

where the accent was a little off to the side.  Since I run Emacs as a
daemon, closing all GUI frames and opening a fresh new one made the
misalignment go away.

I am attaching two images "good.png" and "misaligned.png" to illustrate
the issue.  [ I hope the images aren't too big.  ]

In the "misaligned" Emacs instance, some combination of font
weight+size+slant do not exhibit the misalignment.

M-x report-emacs-bug RET reports:

In GNU Emacs 31.0.50 (build 15, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.18.0, Xaw scroll bars) of 2024-10-17 built on astatine
Repository revision: fada04cfc788a486265c9da6636611986b48ae49
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101011
System Description: Debian GNU/Linux trixie/sid

Configured using:
 'configure --with-sound=alsa --with-x-toolkit=lucid --without-xaw3d
 --without-gconf --without-libsystemd --with-cairo CFLAGS=-g3'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM
XINPUT2 XPM LUCID ZLIB

Important settings:
  value of $LC_MONETARY: ta_IN.UTF-8
  value of $LC_NUMERIC: ta_IN.UTF-8
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

>> Date: Sat, 12 Oct 2024 12:09:02 -0400
>> Cc: [email-masked]
>> From: Yixuan Chen <[email-masked]>
>> 
>> On 10/12/24 04:02, Eli Zaretskii wrote:
>> > I cannot reproduce the problem on my system.  I've let Emacs randomize
>> > the fonts for quite some time, and everything keeps rendering
>> > correctly without the extra spaces.  When you say "eventually", how
>> > long do you typically wait until the problem appears?
>> 
>> It took me 5 seconds at most, and usually happened immediately.
>> 
>> > (As two deviations from your init.el, I used a different font
>> > (Cascadia Code), since I don't have JetBrains Mono installed; and I
>> > replaces use-package with the equivalent Lisp, since I don't want to
>> > install ligatures.el on this system.  I don't think these two
>> > deviations should matter, but I mention them FTR.)
>> 
>> I can replicate the same problem (and even worse in some cases) using 
>> Cascadia Code.
>> 
>> The `use-package` should be replaceable, except you want to keep the 
>> list of ligature strings formatted in the same way. I'm not fluent in 
>> Elisp or emacs API, so my dumb way of randomization is achieved through 
>> regexp matching over the ligature strings. If they are re-organized in 
>> some way (say merged into one huge line), it might break the randomization.
>> 
>> > I think this might be system-dependent.  Can someone try this in a
>> > Cairo build on GNU/Linux and see if the problem reproduces?
>> 
>> Potentially, I'm using emacs-pgtk on wayland.
>>