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: Tue, 29 Oct 2024 19:24:26 +0530 [thread overview]
Message-ID: <871pzz10bx.fsf@gmail.com> (raw)
In-Reply-To: <86wmhr5acv.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 29 Oct 2024 15:04:16 +0200")
[-- Attachment #1: Type: text/plain, Size: 2787 bytes --]
[செவ்வாய் அக்டோபர் 29, 2024] Eli Zaretskii wrote:
>> 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).
I seem to have run into the issue. The attached images
"cascadia-code-bold-15-good" and "-bad.png" are the desired and
misaligned composite text of "-->" rendered in Cascadia Code bold 15
font. The same text is composed fine with Cascadia Code bold 17.
[-- Attachment #2: cascadia-bold-15-good.png --]
[-- Type: image/png, Size: 636 bytes --]
[-- Attachment #3: cascadia-bold-15-bad.png --]
[-- Type: image/png, Size: 632 bytes --]
next prev parent reply other threads:[~2024-10-29 13:54 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
2024-10-29 13:54 ` Visuwesh [this message]
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=871pzz10bx.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.