bug#54646: 29.0.50; set-fontset-font and font clipping issues

[Visuwesh]

[சனி அக்டோபர் 08, 2022] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: rpluim@gmail.com,  54646@debbugs.gnu.org
>> Date: Sat, 08 Oct 2022 17:18:12 +0530
>> 
>> [சனி ஜூன் 11, 2022] Visuwesh wrote:
>> 
>> > [...]
>> > However, I have been using the xft+harfbuzz combo for a ~week now and I
>> > can say with confidence that I don't experience this strange issue.  I
>> > would highly appreciate it if the decision to remove the xft backend
>> > could be delayed until a solution comes up [1].  Although the font
>> > rendering is worse, the text stays readable at all font sizes.
>> 
>> I made some "progress" on this bug report.  The misplacement goes away
>> when I close _all_ frames open on the Xorg display and open a fresh new
>> frame.  If I only close the frame visiting the problematic buffer and
>> open a new frame to visit the buffer again, the misplacement does not go
>> away.
>> AFAIK, this workaround is not possible in "emacs -Q" since there is no
>> way to close all frames without also exiting Emacs.  I tried to leave
>> the "original" frame around and opening a new frame but that did not
>> help.
>
> Could you please state what issue are you trying to discuss here?

The fact that glyphs for Tamil text gets misplaced.  To see what I mean,
please refer to the images I attached in the OP.

> This bug report had its last communication 4 months ago, and its
> discussion thread is very long and includes several separate issues.
> It's hard to understand to which parts are you alluding here.

Sorry about that.  All the separate issues eventually boiled down to
"Emacs has glyph misplacement issues for Tamil text."  The rest of the
issue was me figuring out if my config was introducing the misplacement
or whether it was a font issue, both of which aren't the case.  I can
reproduce it in emacs -Q and with any Tamil font I throw at Emacs.

> If this is the original issue with incorrect advance width of the
> glyphs, then why is it interesting whether it goes away when you close
> all the frames?

Because, AFAIR, the workaround of closing all the frames did not work
before but it does now.

> It will sooner or later appear again, and to solve the problem we
> need to understand what causes that, no?

Yes, the issue shows itself again later but I wondered whether the
'close all the frame' thingy gave some hints.  Also, I should note that
the patch for bug#50951 made this issue rarer (but still noticeable).