[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: |
Thu, 21 Apr 2022 20:20:45 +0530 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
[ஞாயிறு ஏப்ரல் 03, 2022] Visuwesh wrote:
> [Sunday April 03, 2022] Eli Zaretskii wrote:
>
>>> From: Visuwesh <visuweshm@gmail.com>
>>> Cc: rpluim@gmail.com, 54646@debbugs.gnu.org
>>> Date: Sun, 03 Apr 2022 15:56:35 +0530
>>>
>>> > The %c format is only good for single-byte characters, which these
>>> > ones aren't. Please use %x to print them (in hex).
>>> >
>>>
>>> Will do, thanks.
>>>
>>> > Also, I think printing everything is too much, and doesn't allow to
>>> > focus. Please print only when the character's code is one of those
>>> > involved in the problematic display.
>>>
>>> Unfortunately, the characters that are problematic tend to differ from
>>> each run. Nevertheless, I will hand-pick the problematic characters and
>>> send it.
>>
>> That'd be good. We need a reproducible case to work with.
>>
>>> > if (chars[char_idx] == CHAR1
>>> > || chars[char_idx] == CHAR2
>>> > || chars[char_idx] == CHAR3)
>>> > printf (...
>>> >
>>> > where CHAR1, CHAR2, and CHAR3 are the characters involved in the
>>> > problematic display, according to "C-u C-x =".
>>> >
>>> > May I suggest that you show me the code you add to hbfont.c before you
>>> > run it? This would avoid unnecessary iterations for you.
>>> >
>>>
>>> Sure,
>>
>> This is okay, but please don't forget to add that 'if' condition. I
>> think the characters involved in the composition, and in addition one
>> character on each side of those, should be enough.
>
> It seems like I did not get my point across: the characters that tend
> to be rendered problematic differ from each run so I will hand-pick the
> data for the problematic characters in _that_ run and send it.
>
>>
>> Please show the final code, so that I could then interpret the
>> print-outs correctly.
>>
>> Thanks.
>
> Considering the above, it would be
>
> [....]
It took me eons to do this again, I apologise for that. There's one
thing that I noticed about this issue: when I use this webpage
https://www.dinamalar.com/news_detail.asp?id=3012739 as a test page and
I let _all_ the scaled characters in that page be displayed, I cannot
reproduce the issue but if I let only some of the scaled characters in
that page be displayed and go to a part that was never displayed before,
the characters there have the "bad" shaping. I'm writing this here
in the hopes that it might help in debugging.
I was not successful in getting the data for all offending sequences.
The offending sequences were,
bb9 bbf -- ஹி
ba9 bc1 -- னு
bb5 bbf -- வி
b86 -- ஆ
and the GOOD case for bb9 bbf is
lbearing 1 rbearing 28 width 28 ascent 9 descent 5
1 bb9 bbf xadvance 1809 yadvance 0 xoffset 0 yoffset 0
xpos 0 yoff 0 wadjust 28
and the BAD case is
lbearing 1 rbearing 28 width 28 ascent 9 descent 5
1 bb9 bbf xadvance 3193 yadvance 0 xoffset 0 yoffset 0
xpos 0 yoff 0 wadjust 50
If you want more data, then I can try repeating this (I did not retry
since it is really tedious).
The data is for -Goss-Kurinto
Seri-regular-normal-normal-*-17-*-*-*-*-0-iso10646-1
and HarfBuzz version is still at 4.2.0.
The patch I used is
diff --git a/src/hbfont.c b/src/hbfont.c
index 2721a66120..9432f75bbf 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)
@@ -589,10 +590,17 @@ hbfont_shape (Lisp_Object lgstring, Lisp_Object direction)
LGLYPH_SET_RBEARING (lglyph, metrics.rbearing);
LGLYPH_SET_ASCENT (lglyph, metrics.ascent);
LGLYPH_SET_DESCENT (lglyph, metrics.descent);
+ printf("lbearing %d rbearing %d width %d ascent %d descent %d\n",
+ metrics.lbearing, metrics.rbearing, metrics.width, metrics.ascent,
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);
+ printf("%x %x %x xadvance %d yadvance %d xoffset %d yoffset %d\n",
+ (char_idx == 0 ? 1 : chars[char_idx-1]), chars[char_idx],
+ (char_idx == glyph_len-1 ? 1 : chars[char_idx+1]),
+ pos[i].x_advance, pos[i].y_advance, pos[i].x_offset,
pos[i].y_offset);
+ printf("xpos %d yoff %d wadjust %d\n", xoff, yoff, wadjust);
if (xoff || yoff || wadjust != metrics.width)
LGLYPH_SET_ADJUSTMENT (lglyph, CALLN (Fvector,
make_fixnum (xoff),
- bug#54646: 29.0.50; set-fontset-font and font clipping issues, (continued)
- 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, 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, 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 <=
- 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