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


Message #98 received at 54646 <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rpluim <at> gmail.com, 54646 <at> debbugs.gnu.org
Subject: Re: bug#54646: 29.0.50; set-fontset-font and font clipping issues
Date: Sun, 03 Apr 2022 14:45:35 +0530
[Message part 1 (text/plain, inline)]
[Friday April 01, 2022] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: rpluim <at> gmail.com,  54646 <at> debbugs.gnu.org
>> Date: Fri, 01 Apr 2022 22:10:54 +0530
>> 
>> > WHat is different between the two cases in this data?  Does the call
>> > to font->driver->text_extents produce different data in 'metrics',
>> > perhaps?  Do the values in pos[i] structure differ?  Something else?
>> 
>> TBH, I'm not even sure if I am comparing the data for the same set of
>> characters but AFAICT the values don't seem to differ.  Is there a way
>> to print the concerned character so I can make better comparisons?
>
> The character codepoints are in the chars[] array, AFAIR.
>
> If the input to HarfBuzz is identical, but the output isn't, it points
> to a HarfBuzz bug.
>
>> I don't think it is of any help but I attached two text files: bad-case
>> and good-case.  bad-case has all the data for the clipped text, and
>> good-case for the non-clipped text (for the same font size, at least I
>> hope so...).
>
> It's hard to understand what you printed out, or where is the
> difference.  It is best to print only the data for the characters for
> which you see display problems, because all the rest is just clutter.
> And in any case, please print the character with the data, otherwise
> it is impossible to know what to compare.

I used the %c printf format control to print the character in
question---chars[char_idx].  comment-section-good is the "good" case and
comment-section-bad is the "bad" case.  The URL I browsed in eww is
https://www.dinamalar.com/news_detail.asp?id=2998931 (isearch for
"Suppon" to get to the comment section).  Unfortunately, all the
characters are in raw bytes so if there's a better to print the
characters, please let me know.

[ "# .*" in the last line are just markers I used.  ]

[comment-section-bad (text/plain, attachment)]
[comment-section-good (text/plain, attachment)]

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.