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

[YAMAMOTO Mitsuharu]

On Tue, 20 Sep 2022 20:07:12 +0900,
Eli Zaretskii wrote:
> 
> > 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.

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.

(The attachment is for comparison between unpatched, patched, and the
output of hb-view (optimal).)

                                     YAMAMOTO Mitsuharu
                                mituharu@math.s.chiba-u.ac.jp

unpatched.pdf
Description: Adobe PDF document

patched.pdf
Description: Adobe PDF document

hb-view.pdf
Description: Adobe PDF document