[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#50951: 28.0.50; Urdu text is not displayed correctly
From: |
Eli Zaretskii |
Subject: |
bug#50951: 28.0.50; Urdu text is not displayed correctly |
Date: |
Tue, 20 Sep 2022 14:07:12 +0300 |
> Date: Tue, 20 Sep 2022 12:41:40 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: Visuwesh <visuweshm@gmail.com>,
> Eli Zaretskii <eliz@gnu.org>,
> larsi@gnus.org,
> 50951@debbugs.gnu.org
>
> The width of grapheme cluster corresponding to U+06AF (ARABIC LETTER
> GAF) is rounded to zero, and Emacs does not display such clusters:
>
> xdisp.c:
> 32424 gstring = composition_gstring_from_id (it->cmp_it.id);
> 32425 it->pixel_width
> 32426 = composition_gstring_width (gstring, it->cmp_it.from,
> it->cmp_it.to,
> 32427 &metrics);
> 32428 if (it->pixel_width == 0)
> 32429 {
> 32430 it->glyph_not_available_p = true;
> 32431 it->phys_ascent = it->ascent;
> 32432 it->phys_descent = it->descent;
> 32433 it->pixel_width = face->font->space_width;
> 32434 }
> 32435 else
>
> The attached patch avoids zero-width grapheme clusters by adding 1 to
> the width of the last glyph in such clusters.
If the problem is rounding, I think we should do this adjustment only
when the last glyph has a non-zero width that was rounded to zero, no?
Otherwise, we are inventing adjustments out of thin air, which could
adversely affect the displayed result, I think?
Or maybe we should have a variable that controls this heuristic?
Bottom line: I'm uneasy with messing with the grapheme cluster data
without some sound basis. We delegate this job to a text-shaping
engine for a reason. But if there is a sound basis for this
adjustment, could you please elaborate on it?
Thanks.
- bug#50951: 28.0.50; Urdu text is not displayed correctly, (continued)
- bug#50951: 28.0.50; Urdu text is not displayed correctly, YAMAMOTO Mitsuharu, 2022/09/07
- bug#50951: 28.0.50; Urdu text is not displayed correctly, Eli Zaretskii, 2022/09/07
- bug#50951: 28.0.50; Urdu text is not displayed correctly, Visuwesh, 2022/09/08
- bug#50951: 28.0.50; Urdu text is not displayed correctly, Rah Guzar, 2022/09/09
- bug#50951: 28.0.50; Urdu text is not displayed correctly, Rah Guzar, 2022/09/17
- bug#50951: 28.0.50; Urdu text is not displayed correctly, Eli Zaretskii, 2022/09/17
- bug#50951: 28.0.50; Urdu text is not displayed correctly, YAMAMOTO Mitsuharu, 2022/09/19
- bug#50951: 28.0.50; Urdu text is not displayed correctly,
Eli Zaretskii <=
- bug#50951: 28.0.50; Urdu text is not displayed correctly, YAMAMOTO Mitsuharu, 2022/09/20
- bug#50951: 28.0.50; Urdu text is not displayed correctly, YAMAMOTO Mitsuharu, 2022/09/20
- bug#50951: 28.0.50; Urdu text is not displayed correctly, Eli Zaretskii, 2022/09/22
- bug#50951: 28.0.50; Urdu text is not displayed correctly, YAMAMOTO Mitsuharu, 2022/09/25
- bug#50951: 28.0.50; Urdu text is not displayed correctly, Eli Zaretskii, 2022/09/26
- bug#50951: 28.0.50; Urdu text is not displayed correctly, YAMAMOTO Mitsuharu, 2022/09/26
- bug#50951: 28.0.50; Urdu text is not displayed correctly, Rah Guzar, 2022/09/20
- bug#50951: 28.0.50; Urdu text is not displayed correctly, Visuwesh, 2022/09/11
- bug#50951: 28.0.50; Urdu text is not displayed correctly, Visuwesh, 2022/09/11