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

Previous Next

Full log

Message #136 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: Thu, 22 Sep 2022 08:37:24 +0300

> Date: Wed, 21 Sep 2022 11:20:54 +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
> 
> > 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?

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?

Thanks.

Previous Next

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