GNU bug report logs - #50951
28.0.50; Urdu text is not displayed correctly

Previous Next

Full log

View this message in rfc822 format

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rahguzar <at> zohomail.eu, larsi <at> gnus.org, 50951 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: bug#50951: 28.0.50; Urdu text is not displayed correctly
Date: Wed, 21 Sep 2022 11:20:54 +0900

[Message part 1 (text/plain, inline)]

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 <at> math.s.chiba-u.ac.jp>
> > Cc: Visuwesh <visuweshm <at> gmail.com>,
> > 	Eli Zaretskii <eliz <at> gnu.org>,
> > 	larsi <at> gnus.org,
> > 	50951 <at> 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 <at> math.s.chiba-u.ac.jp

[unpatched.pdf (application/pdf, attachment)]

[patched.pdf (application/pdf, attachment)]

[hb-view.pdf (application/pdf, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.