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

[YAMAMOTO Mitsuharu]

On Mon, 26 Sep 2022 16:18:50 +0900,
Eli Zaretskii wrote:
> 
> > 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.

I installed a slightly modified version because the previous one did
not adjust the last grapheme cluster when its width is zero.  Closing.

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