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

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

On Thu, 22 Sep 2022 14:37:24 +0900,
Eli Zaretskii wrote:
> 
> > 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?

For the HarfBuzz shaper, the width rounding happens at Line 595
directly, and at the callee of Line 586 indirectly:

  hbfont.c:
   585	      unsigned code = info[i].codepoint;
   586	      font->driver->text_extents (font, &code, 1, &metrics);
   587	      LGLYPH_SET_WIDTH (lglyph, metrics.width);
   588	      LGLYPH_SET_LBEARING (lglyph, metrics.lbearing);
   589	      LGLYPH_SET_RBEARING (lglyph, metrics.rbearing);
   590	      LGLYPH_SET_ASCENT (lglyph, metrics.ascent);
   591	      LGLYPH_SET_DESCENT (lglyph, metrics.descent);
   592	
   593	      xoff = lround (pos[i].x_offset * position_unit);
   594	      yoff = - lround (pos[i].y_offset * position_unit);
   595	      wadjust = lround (pos[i].x_advance * position_unit);

The value of position_unit is usually 1.0 / 32.

For the callee of Line 586, rounding may happen either at the Emacs
side as in the ftcrhb font backend,

  ftcrfont.c:
    99	      cairo_scaled_font_glyph_extents (ftcrfont_info->cr_scaled_font,
   100					       &cr_glyph, 1, &extents);
   101	      cache->lbearing = floor (extents.x_bearing);
   102	      cache->rbearing = ceil (extents.width + extents.x_bearing);
   103	      cache->width = lround (extents.x_advance);

or at the library side as in the xfthb font backend.

  xftfont.c:
   469	  block_input ();
   470	  XftGlyphExtents (xftfont_info->display, xftfont_info->xftfont, code, nglyphs,
   471			   &extents);
   472	  unblock_input ();
   473	
   474	  metrics->lbearing = - extents.x;
   475	  metrics->rbearing = - extents.x + extents.width;
   476	  metrics->width = extents.xOff;

For the Uniscribe shaper, rounding seems to happen at the library
side:

  w32uniscribe.c:
   297	  int *advances;
    :
   346	  advances = alloca (max_glyphs * sizeof (int));
    :
   399		  result = ScriptPlace (context, (SCRIPT_CACHE) &(uniscribe_font->cache),
   400					glyphs, nglyphs, attributes, &(items[i].a),
   401					advances, offsets, &overall_metrics);
    :
   501			  LGLYPH_SET_WIDTH (lglyph, advances[j]);
    :
   563			      ASET (vec, 2, make_fixnum (advances[j]));
   564			      LGLYPH_SET_ADJUSTMENT (lglyph, vec);

If rounding happens at the library side, we don't know whether the
width before rounding was exactly 0 or not.

> 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?

The output of hb-view was in PDF, and its coordinate system does not
directly correspond to the integral number of physical pixels unlike
in Emacs.

The display engine of Emacs only accepts positive integer as
pixel-width of a glyph (in Emacs terminology).  If the actual grapheme
cluster has width zero (after rounding), then it is replaced to some
positive integer (space width) in gui_produce_glyphs.  Because some
grapheme cluster in the result of shaping can be in very small width
and rounded to 0, adjusting it to 1 is almost the best approximation.

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