From: Eli Zaretskii <eliz@gnu.org>
To: Visuwesh <visuweshm@gmail.com>
Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me
Subject: bug#73752: 29.4; Ligatures are randomly rendered with extra spaces
Date: Tue, 29 Oct 2024 15:04:16 +0200 [thread overview]
Message-ID: <86wmhr5acv.fsf@gnu.org> (raw)
In-Reply-To: <87o73318ql.fsf@gmail.com> (message from Visuwesh on Tue, 29 Oct 2024 16:29:48 +0530)
> From: Visuwesh <visuweshm@gmail.com>
> Cc: luangruo@yahoo.com, 73752@debbugs.gnu.org, xuan@xlk.me
> Date: Tue, 29 Oct 2024 16:29:48 +0530
>
> >> Is this hash dependent on the font driver?
> >
> > No. Only the font used for the composed characters is recorded, not
> > the font backend which opened it. But fonts are managed by the font
> > backend, so maybe there's some leakage by that way.
>
> OK, thanks. I wonder if we could compare the value returned by
> font-info if something has gone wrong with the font object used to
> compute the hash for the glyph?
That would not be the first thing I'd look at. According to the
screenshots, it is more likely that a wrong cache entry is used for a
composition, which uses the "wrong" font variant. IOW, the font used
itself is fine, it just is not the font that's supposed to be used
with the composed characters in that place.
So I would first look at the font object stored in the header of the
cached composition.
> > Btw, how frequently do you use different frames,
>
> Quite often, I would say. I usually have two frames but it can go
> upwards of 5 to 6 if I have a mouse attached to my laptop.
>
> > and how likely are you to have different definitions for the same
> > faces on different frames in the same Emacs session at the same time?
>
> I don't quite understand this question. Are you asking if I have any
> "frame-specific" face attributes i.e., non-nil FRAME argument in
> set-face-attribute?
Yes.
> If so, no.
OK, so one more theory eats dust (we don't record the frame in the
composition cache).
> > The only way I see to investigate this is to wait for this to happen,
> > then attach GDB to Emacs and look at the problematic compositions in
> > the cache, comparing them to the corresponding compositions in a fresh
> > Emacs session. I can tell what to look for with GDB, if that helps.
>
> That would help. But given how hard it is to reproduce this issue on my
> end, I don't know when I can get back...
It would not be useful for me to give instructions before you actually
hit the problem (because the code will change until then), so if you
want to try this, get back to me when you do reproduce the problem
(and then attach GDB and leave the Emacs session under GDB for any
investigations I'd ask you to do).
Thanks.
next prev parent reply other threads:[~2024-10-29 13:04 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
2024-10-28 17:13 ` Eli Zaretskii
2024-10-29 10:59 ` Visuwesh
2024-10-29 13:04 ` Eli Zaretskii [this message]
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
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=86wmhr5acv.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=73752@debbugs.gnu.org \
--cc=luangruo@yahoo.com \
--cc=visuweshm@gmail.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 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).