unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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)





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