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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 25 Sep 2022 16:18:26 +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
> 
> > 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.

OK, thanks.  Please install your patch on the master branch.