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: Visuwesh <visuweshm <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Robert Pluim <rpluim <at> gmail.com>, 54646 <at> debbugs.gnu.org
Subject: bug#54646: 29.0.50; set-fontset-font and font clipping issues
Date: Fri, 01 Apr 2022 20:28:06 +0530
[Friday April 01, 2022] Eli Zaretskii wrote:

>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: 54646 <at> debbugs.gnu.org,Eli Zaretskii <eliz <at> gnu.org>
>> Date: Fri, 01 Apr 2022 10:49:21 +0200
>> 
>>     Visuwesh> I can reproduce it in HarfBuzz 4.2.0.  Maybe this could be related to
>>     Visuwesh> the toolkit being used?  I have only tested so far with Lucid.  I will
>>     Visuwesh> try GTK some time later.
>> 
>> Iʼve managed to reproduce this, but only once, with HarfBuzz 4.2.0
>> using lucid and Kurinto Seri. I guess that points more at HarfBuzz
>> than at Emacs, but maybe the lucid build is doing things slightly
>> differently to gtk.
>
> I think at this point we need to establish whether we pass the same
> information to HarfBuzz in the "good" and the "bad" cases.  In
> particular, we tell it how to scale the glyph metrics:
>
>   hb_font_t *hb_font
>     = font->driver->begin_hb_font
>     ? font->driver->begin_hb_font (font, &position_unit)
>     : NULL;
>
> The value of position_unit then affects the values returned in the
> Lisp glyph object used to display the grapheme cluster:
>
>       xoff = lround (pos[i].x_offset * position_unit);
>       yoff = - lround (pos[i].y_offset * position_unit);
>       wadjust = lround (pos[i].x_advance * position_unit);
>       if (xoff || yoff || wadjust != metrics.width)
> 	LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector,
> 					      make_fixnum (xoff),
> 					      make_fixnum (yoff),
> 					      make_fixnum (wadjust)));
>
> I'd be interested in what happens there in the "good" vs the "bad"
> cases.
>
> If we pass the same information to HarfBuzz, and it returns different
> results, then it's probably a problem in HarfBuzz.

I get the same value for position_unit just after begin_hb_font call and
just after setting the value of wadjust, in the bad and the good case:
0.015625.  In case I was not clear, here's a patch that shows where I
added the printf calls

diff --git a/src/hbfont.c b/src/hbfont.c
index 2721a66120..887e0c0e86 100644
--- a/src/hbfont.c
+++ b/src/hbfont.c
@@ -490,6 +490,7 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction)
     : NULL;
   if (!hb_font)
     return make_fixnum (0);
+  printf("position_unit begin_hb_font: %f\n", position_unit);
 
   hb_bool_t success = hb_shape_full (hb_font, hb_buffer, NULL, 0, NULL);
   if (font->driver->end_hb_font)
@@ -593,6 +594,7 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction)
       xoff = lround (pos[i].x_offset * position_unit);
       yoff = - lround (pos[i].y_offset * position_unit);
       wadjust = lround (pos[i].x_advance * position_unit);
+      printf("position_unit after lround: %f\n", position_unit);
       if (xoff || yoff || wadjust != metrics.width)
 	LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector,
 					      make_fixnum (xoff),

So I see "position_unit begin_hb_font: 0.0015625" and "position_unit
after lround: 0.0015625" in the good and the bad case.




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.