GNU bug report logs - #54646
29.0.50; set-fontset-font and font clipping issues

Previous Next

Package: emacs;

Reported by: Visuwesh <visuweshm <at> gmail.com>

Date: Thu, 31 Mar 2022 03:38:01 UTC

Severity: normal

Merged with 73752

Found in versions 29.0.50, 29.4

Fixed in version 30.1

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
Subject: bug#54646: 29.0.50; set-fontset-font and font clipping issues
Date: Sat, 08 Oct 2022 15:42:42 +0300
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: rpluim <at> gmail.com,  54646 <at> 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?
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.

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?  It will sooner or later appear again, and to solve
the problem we need to understand what causes that, no?




This bug report was last modified 253 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.