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

Previous Next

Full log

Message #142 received at 50951 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: rahguzar <at> zohomail.eu, larsi <at> gnus.org, 50951 <at> debbugs.gnu.org,
 visuweshm <at> gmail.com
Subject: Re: bug#50951: 28.0.50; Urdu text is not displayed correctly
Date: Mon, 26 Sep 2022 10:18:50 +0300

> Date: Sun, 25 Sep 2022 16:18:26 +0900
> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> Cc: rahguzar <at> zohomail.eu, visuweshm <at> gmail.com, larsi <at> gnus.org,
>   50951 <at> 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.

Previous Next

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