From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.bugs Subject: bug#50951: 28.0.50; Urdu text is not displayed correctly Date: Sun, 25 Sep 2022 16:18:26 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <83mtnsc63i.fsf@gnu.org> <83sfxjbox7.fsf@gnu.org> <87pmsnwlvo.fsf@igel.home> <837devbgrl.fsf@gnu.org> <8335pjbewj.fsf@gnu.org> <83zgrr9zn1.fsf@gnu.org> <87edwq7srx.fsf_-_@gnus.org> <87y1uy6mn5.fsf@zohomail.eu> <83wnaij974.fsf@gnu.org> <87tu5m6jrw.fsf@zohomail.eu> <835yhzifuw.fsf@gnu.org> <87o7vqxuvs.fsf@gmail.com> <87h71gwpr5.fsf@zohomail.eu> <87mtayymk5.fsf@zohomail.eu> <835yhixq1r.fsf@gnu.org> <83h710t1ez.fsf@gnu.org> Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40182"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?Q?Goj=C5=8D?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Cc: rahguzar@zohomail.eu, larsi@gnus.org, 50951@debbugs.gnu.org, visuweshm@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 25 09:19:43 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ocLvT-000AD4-1w for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 25 Sep 2022 09:19:43 +0200 Original-Received: from localhost ([::1]:51964 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ocLvR-0004Jn-IR for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 25 Sep 2022 03:19:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53874) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ocLup-0004Jf-Pj for bug-gnu-emacs@gnu.org; Sun, 25 Sep 2022 03:19:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46680) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ocLuo-0004d9-8f for bug-gnu-emacs@gnu.org; Sun, 25 Sep 2022 03:19:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ocLun-0001hO-Uv for bug-gnu-emacs@gnu.org; Sun, 25 Sep 2022 03:19:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: YAMAMOTO Mitsuharu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Sep 2022 07:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50951 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 50951-submit@debbugs.gnu.org id=B50951.16640903126493 (code B ref 50951); Sun, 25 Sep 2022 07:19:01 +0000 Original-Received: (at 50951) by debbugs.gnu.org; 25 Sep 2022 07:18:32 +0000 Original-Received: from localhost ([127.0.0.1]:45758 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocLuJ-0001ge-NP for submit@debbugs.gnu.org; Sun, 25 Sep 2022 03:18:32 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:57496) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ocLuH-0001gT-3I for 50951@debbugs.gnu.org; Sun, 25 Sep 2022 03:18:30 -0400 Original-Received: from mathent.math.s.chiba-u.ac.jp (mathent [192.168.32.5]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id D1A98F08E4; Sun, 25 Sep 2022 16:18:26 +0900 (JST) (envelope-from mituharu@math.s.chiba-u.ac.jp) In-Reply-To: <83h710t1ez.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:243573 Archived-At: On Thu, 22 Sep 2022 14:37:24 +0900, Eli Zaretskii wrote: > > > Date: Wed, 21 Sep 2022 11:20:54 +0900 > > From: YAMAMOTO Mitsuharu > > 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