all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Visuwesh <visuweshm@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me
Subject: bug#73752: 29.4; Ligatures are randomly rendered with extra spaces
Date: Mon, 28 Oct 2024 21:48:26 +0530	[thread overview]
Message-ID: <87wmhs19rh.fsf@gmail.com> (raw)
In-Reply-To: <86iktc6zp5.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 28 Oct 2024 16:59:18 +0200")

[திங்கள் அக்டோபர் 28, 2024] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: luangruo@yahoo.com,  73752@debbugs.gnu.org,  xuan@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)?

Is this hash dependent on the font driver?  IME and from what I see from
other issues in ligature.el's GitHub issue page, the problem seems to be
specific to Cairo builds which would also explain why you are not able
to reproduce this.

Also, do we clear the composition cache when all the GUI frames of an
Emacs daemon are deleted?  The misalignment goes away when I close all
the GUI frames of the daemon, and open a fresh new GUI frame.

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

That is my impression, yes.

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

I have no idea.  This is not easy to reproduce and seems to be heavily
dependent on the configuration.  Although I use a Cairo build (with
Lucid toolkit), the misalignment is not as severe as OP says and it
takes a lot more time to reproduce as well.  I could never come up with
a reproducer that takes less time.





  parent reply	other threads:[~2024-10-28 16:18 UTC|newest]

Thread overview: 50+ 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 [this message]
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

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wmhs19rh.fsf@gmail.com \
    --to=visuweshm@gmail.com \
    --cc=73752@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=luangruo@yahoo.com \
    --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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.