[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#54646: 29.0.50; set-fontset-font and font clipping issues
From: |
Visuwesh |
Subject: |
bug#54646: 29.0.50; set-fontset-font and font clipping issues |
Date: |
Fri, 01 Apr 2022 22:10:54 +0530 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
[Friday April 01, 2022] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: Robert Pluim <rpluim@gmail.com>, 54646@debbugs.gnu.org
>> Date: Fri, 01 Apr 2022 20:28:06 +0530
>>
>> > 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.
>
> So we pass the same data to HarfBuzz and get back different results in
> xoff, yoff, and wadjust?
>
> IOW, the results of shaping are different in the two cases, although
> the inputs are identical? Can you print the other values involved in
> the data that gets put into lglyph, and see whether any of it is
> different between the two cases?
>
> the lglyph data is shown in this excerpt from the code:
>
> LGLYPH_SET_CHAR (lglyph, chars[char_idx]);
> LGLYPH_SET_CODE (lglyph, info[i].codepoint);
>
> unsigned code = info[i].codepoint;
> font->driver->text_extents (font, &code, 1, &metrics);
> LGLYPH_SET_WIDTH (lglyph, metrics.width);
> LGLYPH_SET_LBEARING (lglyph, metrics.lbearing);
> LGLYPH_SET_RBEARING (lglyph, metrics.rbearing);
> LGLYPH_SET_ASCENT (lglyph, metrics.ascent);
> LGLYPH_SET_DESCENT (lglyph, metrics.descent);
>
> 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)));
>
> 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?
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...).
bad-case
Description: Bad case
good-case
Description: Good case
- bug#54646: 29.0.50; set-fontset-font and font clipping issues, Robert Pluim, 2022/04/01
- bug#54646: 29.0.50; set-fontset-font and font clipping issues, Visuwesh, 2022/04/01
- bug#54646: 29.0.50; set-fontset-font and font clipping issues, Eli Zaretskii, 2022/04/01
- bug#54646: 29.0.50; set-fontset-font and font clipping issues,
Visuwesh <=
- bug#54646: 29.0.50; set-fontset-font and font clipping issues, Eli Zaretskii, 2022/04/01
- bug#54646: 29.0.50; set-fontset-font and font clipping issues, Visuwesh, 2022/04/03
- bug#54646: 29.0.50; set-fontset-font and font clipping issues, Eli Zaretskii, 2022/04/03
- bug#54646: 29.0.50; set-fontset-font and font clipping issues, Visuwesh, 2022/04/03
- bug#54646: 29.0.50; set-fontset-font and font clipping issues, Eli Zaretskii, 2022/04/03
- bug#54646: 29.0.50; set-fontset-font and font clipping issues, Visuwesh, 2022/04/03
- bug#54646: 29.0.50; set-fontset-font and font clipping issues, Visuwesh, 2022/04/21
- bug#54646: 29.0.50; set-fontset-font and font clipping issues, Eli Zaretskii, 2022/04/22
- bug#54646: 29.0.50; set-fontset-font and font clipping issues, Visuwesh, 2022/04/22
- bug#54646: 29.0.50; set-fontset-font and font clipping issues, Eli Zaretskii, 2022/04/22