From: Visuwesh <visuweshm@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Tim Ruffing <dev@real-or-random.org>, xuan@xlk.me, 73752@debbugs.gnu.org
Subject: bug#73752: 29.4; Ligatures are randomly rendered with extra spaces
Date: Sat, 02 Nov 2024 16:09:15 +0530 [thread overview]
Message-ID: <87bjyxyl64.fsf@gmail.com> (raw)
In-Reply-To: <86msiiync2.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 02 Nov 2024 11:52:29 +0200")
[சனி நவம்பர் 02, 2024] Eli Zaretskii wrote:
>> From: Tim Ruffing <dev@real-or-random.org>
>> Cc: 73752@debbugs.gnu.org, xuan@xlk.me
>> Date: Sat, 02 Nov 2024 04:34:17 +0100
>>
>> Neither the critical line in composition_gstring_adjust_zero_width nor
>> the calls to lglyph-set-adjustment in composite.el are triggered. But
>> this hack in hbfont_shape means I can't reproduce the bug anymore using
>> Yixuan's init file:
>>
>> diff --git a/src/hbfont.c b/src/hbfont.c
>> index 37ed4132492..6fae513069a 100644
>> --- a/src/hbfont.c
>> +++ b/src/hbfont.c
>> @@ -592,11 +592,12 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object
>> direction)
>> LGLYPH_SET_ASCENT (lglyph, metrics.ascent);
>> LGLYPH_SET_DESCENT (lglyph, metrics.descent);
>>
>> xoff = lround (pos[i].x_offset * position_unit);
>> yoff = - lround (pos[i].y_offset * position_unit);
>> - wadjust = lround (pos[i].x_advance * position_unit);
>> + /* wadjust = lround (pos[i].x_advance * position_unit); */
>> + wadjust = metrics.width;
>> if (xoff || yoff || wadjust != metrics.width)
>> LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector,
>> make_fixnum (xoff),
>> make_fixnum (yoff),
>> make_fixnum (wadjust)));
>
> Which leads me to the original suggestion in bug#50951, to do this:
>
> diff --git a/src/hbfont.c b/src/hbfont.c
> index 37ed413..040658a 100644
> --- a/src/hbfont.c
> +++ b/src/hbfont.c
> @@ -600,6 +600,8 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction)
> make_fixnum (xoff),
> make_fixnum (yoff),
> make_fixnum (wadjust)));
> + else
> + LGLYPH_SET_ADJUSTMENT (lglyph, Qnil);
> }
>
> return make_fixnum (glyph_len);
>
> In bug#50951, an alternative change in fill_gstring_body was proposed
> (see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50951#97), which
> was eventually installed, but I guess that might not be enough? Can
> you and Visuwesh please confirm that we sometimes get an lgstring
> argument to hbfont_shape whose glyphs already have a non-nil
> LGLYPH_ADJUSTMENT component, and we leave it unmodified because the
> condition to use LGLYPH_SET_ADJUSTMENT isn't satisfied? Like this:
>
> (gdb) break hbfont.c:598 if xoff == 0 && yoff == 0 && wadjust == metrics.width && LGLYPH_ADJUSTMENT(lglyph) != Qnil
>
> In my testing, a breakpoint with this condition never breaks. But
> that could be because I use a different font (Cascadia Code, instead
> of JetBrains Mono, which I don't have), or because my version of
> HarfBuzz is much older than yours, or for some other reason.
I am not sure if you wanted me to apply the above patch or not. But
just loading a file that contains
(set-face-attribute 'default nil
:family "Cascadia Code"
:height 110
:weight 'bold)
(load "/tmp/ligature.el")
(ligature-set-ligatures 'prog-mode '("--" "---" "==" "===" "!=" "!==" "=!="
"=:=" "=/=" "<=" ">=" "&&" "&&&" "&=" "++" "+++" "***" ";;" "!!"
"??" "???" "?:" "?." "?=" "<:" ":<" ":>" ">:" "<:<" "<>" "<<<" ">>>"
"<<" ">>" "||" "-|" "_|_" "|-" "||-" "|=" "||=" "##" "###" "####"
"#{" "#[" "]#" "#(" "#?" "#_" "#_(" "#:" "#!" "#=" "^=" "<$>" "<$"
"$>" "<+>" "<+" "+>" "<*>" "<*" "*>" "</" "</>" "/>" "<!--" "<#--"
"-->" "->" "->>" "<<-" "<-" "<=<" "=<<" "<<=" "<==" "<=>" "<==>"
"==>" "=>" "=>>" ">=>" ">>=" ">>-" ">-" "-<" "-<<" ">->" "<-<" "<-|"
"<=|" "|=>" "|->" "<->" "<~~" "<~" "<~>" "~~" "~~>" "~>" "~-" "-~"
"~@" "[||]" "|]" "[|" "|}" "{|" "[<" ">]" "|>" "<|" "||>" "<||"
"|||>" "<|||" "<|>" "..." ".." ".=" "..<" ".?" "::" ":::" ":=" "::="
":?" ":?>" "//" "///" "/*" "*/" "/=" "//=" "/==" "@_" "__" "???"
"<:<" ";;;"))
(global-ligature-mode t)
was enough to trigger the breakpoint for me. This is, of course, before
I got a chance to even reproduce the misalignment.
Here's what the gdb buffer looks like:
(gdb) source .gdbinit
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = :0.0
TERM = dumb
Breakpoint 1 at 0x20b4b7: file emacs.c, line 432.
Breakpoint 2 at 0x1cfa8a: file xterm.c, line 27102.
(gdb) break hbfont.c:598 if xoff == 0 && yoff == 0 && wadjust == metrics.width && LGLYPH_ADJUSTMENT(lglyph) != Qnil
Breakpoint 3 at 0x3c3ad7: file hbfont.c, line 598.
(gdb) run -Q
Starting program: /home/viz/lib/ports/emacs/src/emacs -Q
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff1b8f6c0 (LWP 198125)]
[New Thread 0x7ffff118f6c0 (LWP 198126)]
[New Thread 0x7fffebf8f6c0 (LWP 198127)]
[New Thread 0x7fffeb58f6c0 (LWP 198128)]
Error in testing condition for breakpoint 3:
Attempt to take address of value not located in memory.
Thread 1 "emacs" hit Breakpoint 3, hbfont_shape (lgstring=XIL(0x7ffff2a9c745), direction=XIL(0x33c0)) at hbfont.c:598
598 if (xoff || yoff || wadjust != metrics.width)
next prev parent reply other threads:[~2024-11-02 10:39 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-11 16:18 bug#73752: 29.4; Ligatures are randomly rendered with extra spaces xuan
2024-10-12 8:02 ` Eli Zaretskii
2024-10-12 16:09 ` Yixuan Chen
2024-10-27 10:21 ` Eli Zaretskii
2024-10-27 16:19 ` Visuwesh
2024-10-27 17:19 ` Eli Zaretskii
2024-10-27 17:27 ` Eli Zaretskii
2024-10-27 17:39 ` Yixuan Chen
2024-10-27 17:43 ` Eli Zaretskii
2024-10-27 17:46 ` Yixuan Chen
2024-10-27 19:14 ` Eli Zaretskii
2024-10-27 19:36 ` Yixuan Chen
2024-10-27 19:44 ` Eli Zaretskii
2024-10-27 19:47 ` Yixuan Chen
2024-10-27 20:11 ` Eli Zaretskii
2024-10-27 19:41 ` Yixuan Chen
2024-10-27 20:07 ` Eli Zaretskii
2024-10-27 20:32 ` Yixuan Chen
2024-10-28 14:25 ` Eli Zaretskii
2024-10-28 14:44 ` Yixuan Chen
2024-10-28 14:47 ` Yixuan Chen
2024-10-28 15:05 ` Eli Zaretskii
2024-10-28 15:20 ` Yixuan Chen
2024-10-28 17:19 ` Eli Zaretskii
2024-10-28 17:26 ` Eli Zaretskii
2024-10-28 17:28 ` Yixuan Chen
2024-10-28 18:41 ` Eli Zaretskii
2024-10-28 4:26 ` Visuwesh
2024-10-28 14:59 ` Eli Zaretskii
2024-10-28 15:24 ` Yixuan Chen
2024-10-28 16:18 ` Visuwesh
2024-10-28 17:13 ` Eli Zaretskii
2024-10-29 10:59 ` Visuwesh
2024-10-29 13:04 ` Eli Zaretskii
2024-10-29 13:54 ` Visuwesh
2024-10-29 14:00 ` Visuwesh
2024-10-29 15:38 ` Eli Zaretskii
2024-10-29 16:46 ` Visuwesh
2024-10-29 17:45 ` Eli Zaretskii
2024-10-30 5:43 ` Visuwesh
2024-10-29 16:51 ` Eli Zaretskii
2024-10-27 17:29 ` Yixuan Chen
2024-10-29 23:14 ` Tim Ruffing
2024-10-30 15:12 ` Eli Zaretskii
2024-10-30 15:45 ` Eli Zaretskii
[not found] ` <mvmikt9zkcq.fsf@suse.de>
2024-10-30 15:47 ` Eli Zaretskii
2024-10-30 17:34 ` Tim Ruffing
2024-10-30 17:46 ` Eli Zaretskii
2024-10-30 18:00 ` Tim Ruffing
2024-10-30 18:57 ` Eli Zaretskii
2024-10-31 1:39 ` Tim Ruffing
2024-10-31 2:36 ` Yixuan Chen
2024-10-31 2:46 ` Yixuan Chen
2024-10-31 7:44 ` Eli Zaretskii
2024-10-31 9:42 ` Eli Zaretskii
2024-11-01 17:05 ` Eli Zaretskii
2024-11-02 3:34 ` Tim Ruffing
2024-11-02 9:52 ` Eli Zaretskii
2024-11-02 10:39 ` Visuwesh [this message]
2024-11-02 12:07 ` Eli Zaretskii
2024-11-02 13:29 ` Visuwesh
2024-11-02 16:47 ` Eli Zaretskii
2024-11-02 17:04 ` Visuwesh
2024-11-02 17:18 ` Eli Zaretskii
2024-11-02 17:31 ` Visuwesh
2024-11-02 17:34 ` Eli Zaretskii
2024-11-02 17:39 ` Visuwesh
2024-11-02 17:44 ` Eli Zaretskii
2024-11-02 17:54 ` Visuwesh
2024-11-02 18:02 ` Visuwesh
2024-11-02 18:27 ` Eli Zaretskii
2024-11-04 0:11 ` Tim Ruffing
2024-11-04 17:45 ` Eli Zaretskii
2024-11-04 18:02 ` Visuwesh
2024-11-04 23:33 ` Tim Ruffing
2024-11-04 23:47 ` Tim Ruffing
2024-11-06 12:02 ` Tim Ruffing
2024-11-06 13:11 ` Eli Zaretskii
2024-11-07 2:12 ` Tim Ruffing
2024-11-07 7:05 ` Eli Zaretskii
2024-11-07 13:45 ` Visuwesh
2024-11-07 14:40 ` Eli Zaretskii
2024-11-07 15:13 ` Visuwesh
2024-11-07 15:49 ` Eli Zaretskii
2024-11-07 16:00 ` Visuwesh
2024-11-08 8:08 ` Eli Zaretskii
2024-11-06 14:50 ` Visuwesh
2024-11-02 10:32 ` Visuwesh
2024-10-31 8:12 ` Visuwesh
2024-10-31 9:43 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bjyxyl64.fsf@gmail.com \
--to=visuweshm@gmail.com \
--cc=73752@debbugs.gnu.org \
--cc=dev@real-or-random.org \
--cc=eliz@gnu.org \
--cc=xuan@xlk.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).