bug-gnu-emacs
[Top][All Lists]
Advanced

[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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]