Subject: Re: bug#50951: 28.0.50; Urdu text is not displayed correctly

From: Eli Zaretskii <[email-masked]>
Date: Thu, 22 Sep 2022 08:37:24 +0300

> Date: Wed, 21 Sep 2022 11:20:54 +0900
> From: YAMAMOTO Mitsuharu <[email-masked]>
> Cc: [email-masked],
> 	[email-masked],
> 	[email-masked],
> 	[email-masked]
> 
> > 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.