[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: |
Thu, 22 Sep 2022 08:37:24 +0300 |
> Date: Wed, 21 Sep 2022 11:20:54 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: rahguzar@zohomail.eu,
> visuweshm@gmail.com,
> larsi@gnus.org,
> 50951@debbugs.gnu.org
>
> > 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.
>
> IIUC, the only "unsound" case is that the width of a grapheme cluster
> is exactly 0 before rounding. I think such a case is quite rare. And
> even for such a case, Emacs needs to put at least extra 1 pixel to
> move the cursor to the position of the grapheme cluster. So the
> adjustment made by the patch is minimum and necessary.
>
> The current (unpatched) master may put multiple pixels (space width of
> the font as in Line 32433 above), and moreover the corresponding
> glyphs are not displayed. If we keep this behavior for the "unsound"
> case, the result would be much more apart from the optimal.
Can you please point me to the place(s) in our code where this
rounding takes place?
Also, I asked whether you could elaborate on the rationale for
adjusting the zero width to be 1 pixel, and I don't think you answered
that particular question. What you are saying (AFAIU) is that
heuristically the results of using this adjustment are better, at
least in this case. I don't argue with that, but I wonder whether
there's some rationale for this that isn't just heuristics? IOW, do
you know how come hb-view doesn't have this problem? what do we do
that produces the zero width where hb-view doesn't?
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, 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, YAMAMOTO Mitsuharu, 2022/09/20
- 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/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