[செவ்வாய் அக்டோபர் 29, 2024] Eli Zaretskii wrote: >> From: Visuwesh >> 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.