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

[YAMAMOTO Mitsuharu]

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