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

Previous Next

Full log

View this message in rfc822 format

From: Visuwesh <visuweshm <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Tim Ruffing <dev <at> real-or-random.org>, xuan <at> xlk.me, 73752 <at> debbugs.gnu.org
Subject: bug#73752: 29.4; Ligatures are randomly rendered with extra spaces
Date: Thu, 31 Oct 2024 13:42:06 +0530

[Message part 1 (text/plain, inline)]

[புதன் அக்டோபர் 30, 2024] Eli Zaretskii wrote:

>> From: Tim Ruffing <dev <at> real-or-random.org>
>> Cc: dev <at> real-or-random.org, eggert <at> cs.ucla.edu, 73752 <at> debbugs.gnu.org
>> Date: Wed, 30 Oct 2024 18:34:14 +0100
>> 
>> 
>> > > pp is calling Emacs to print to its stderr.  If that is redirected
>> > > somewhere else you won't see the output.
>> > 
>> 
>> Ah, this was the right hint. I'm using emacs in daemon mode, started
>> from systemd, so I can inspect stderr via journalctl.
>> 
>> ------
>> 
>> Broken rendering for ligature "===" starting at pos 1290 (emacs happens
>> to be in daemon mode)
>> 
>> [...]
>>  39  480: COMP[19 (0..0)] pos=1290 w=20 a+d=20+6 face=39 MB
>>  40  500: COMP[19 (1..1)] pos=1291 w=20 a+d=20+6 face=39 MB
>>  41  520: COMP[19 (2..2)] pos=1292 w=20 a+d=20+6 face=39 MB
>> [...]
>> 
>> $ pp composition_gstring_from_id(19)
>>  
>>  [[#<font-object "-UKWN-Iosevka Term SS04-regular-normal-normal-*-20-*-*-*-d-0-iso10646-1"> 61 61 61] 19 [0 0 61 5852 10 1 11 11 -4 [0 0 20]] [1 1 61 5896 10 -1 11 11 -4 [0 0 20]] [2 2 61 5891 10 -1 9 11 -4 [0 0 20]]]
>> 
>> -------
>> 
>> Proper rendering (emacs happens to be not in daemon mode):
>> 
>>  39  390: COMP[13 (0..0)] pos=1290 w=10 a+d=20+6 face=39 MB
>>  40  400: COMP[13 (1..1)] pos=1291 w=10 a+d=20+6 face=39 MB
>>  41  410: COMP[13 (2..2)] pos=1292 w=10 a+d=20+6 face=39 MB
>> 
>> $ pp composition_gstring_from_id(13) 
>> 
>>  [[#<font-object "-UKWN-Iosevka Term SS04-regular-normal-normal-*-20-*-*-*-d-0-iso10646-1"> 61 61 61] 13 [0 0 61 5852 10 1 11 11 -4 nil] [1 1 61 5896 10 -1 11 11 -4 nil] [2 2 61 5891 10 -1 9 11 -4 nil]] 
>> 
>> 
>> Both sessions are still running. I Hope this helps. Let me know if need
>> more remote hands.

I observe very similar results:

Properly rendered (in a fresh Emacs session):

    [[#<font-object "-SAJA-Cascadia Code-bold-normal-normal-*-15-*-*-*-m-0-iso10646-1"> 45 45 62] 2 [0 0 45 1970 9 0 9 7 -4 nil] [1 1 45 1969 9 -1 10 7 -4 nil] [2 2 62 2728 9 -1 9 11 0 nil]]

Misaligned:

    [[#<font-object "-SAJA-Cascadia Code-bold-normal-normal-*-15-*-*-*-m-0-iso10646-1"> 45 45 62] 2231 [0 0 45 1970 9 0 9 7 -4 [0 0 10]] [1 1 45 1969 9 -1 10 7 -4 [0 0 10]] [2 2 62 2728 9 -1 9 11 0 [0 0 10]]]

In the misaligned session, cached entry for the same text ("-->") that
is rendered properly at a different font size:

    [[#<font-object "-SAJA-Cascadia Code-bold-normal-normal-*-17-*-*-*-m-0-iso10646-1"> 45 45 62] 2179 [0 0 45 1970 10 0 11 7 -4 nil] [1 1 45 1969 10 -1 11 7 -4 nil] [2 2 62 2728 10 -1 10 12 0 nil]]

[Message part 2 (text/plain, inline)]

> Did the "bad" display start from "good" at the beginning of a session?
> Or did it start from "bad" to begin with?  If the former, the next
> idea is to put a watchpoint on the cached composition in a session
> with "good" display, and then do whatever it takes to make it "bad",
> hoping that the watchpoint will break at some point and show us the
> code which replaces nil with these [X-OFF Y-OFF WADJUST] vectors.

I think it starts from "bad" to begin with.  But the former theory could
still apply, if you do not mind this vague answer, can you provide
instructions to set a watchpoint?  If the watchpoint never triggers, we
might be able to at least rule out the former theory.

Previous Next

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