From unknown Fri Aug 15 12:52:46 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#33944 <33944@debbugs.gnu.org> To: bug#33944 <33944@debbugs.gnu.org> Subject: Status: 27.0.50; harfbuzz: Noto Sans Mandaic not rendered correctly Reply-To: bug#33944 <33944@debbugs.gnu.org> Date: Fri, 15 Aug 2025 19:52:46 +0000 retitle 33944 27.0.50; harfbuzz: Noto Sans Mandaic not rendered correctly reassign 33944 emacs submitter 33944 Benjamin Riefenstahl severity 33944 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 01 09:36:55 2019 Received: (at submit) by debbugs.gnu.org; 1 Jan 2019 14:36:55 +0000 Received: from localhost ([127.0.0.1]:43809 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1geLA6-0004ib-Uw for submit@debbugs.gnu.org; Tue, 01 Jan 2019 09:36:55 -0500 Received: from eggs.gnu.org ([208.118.235.92]:34409) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1geLA4-0004iS-GW for submit@debbugs.gnu.org; Tue, 01 Jan 2019 09:36:52 -0500 Received: from lists.gnu.org ([208.118.235.17]:58992) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1geLA4-0006sy-5u for submit@debbugs.gnu.org; Tue, 01 Jan 2019 09:36:52 -0500 Received: from eggs.gnu.org ([208.118.235.92]:56579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1geLA2-0005LP-Vb for bug-gnu-emacs@gnu.org; Tue, 01 Jan 2019 09:36:52 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1geL9x-0006kZ-VJ for bug-gnu-emacs@gnu.org; Tue, 01 Jan 2019 09:36:50 -0500 Received: from odoacer.turtle-trading.net ([93.241.193.16]:36929) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1geL9x-0006er-C8 for bug-gnu-emacs@gnu.org; Tue, 01 Jan 2019 09:36:45 -0500 Received: from justinian.turtle-trading.net ([192.168.2.118]) by odoacer.turtle-trading.net with esmtp (Exim 4.80) (envelope-from ) id 1geL9s-0000lR-St; Tue, 01 Jan 2019 15:36:40 +0100 Received: from benny by justinian.turtle-trading.net with local (Exim 4.89) (envelope-from ) id 1geL9s-0002NP-Ii; Tue, 01 Jan 2019 15:36:40 +0100 From: Benjamin Riefenstahl To: bug-gnu-emacs@gnu.org Subject: 27.0.50; harfbuzz: Noto Sans Mandaic not rendered correctly Date: Tue, 01 Jan 2019 15:36:40 +0100 Message-ID: <87wonoo35z.fsf@turtle-trading.net> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 93.241.193.16 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) This may be a more general problem, but Noto Sans Mandaic reproduces it for me: I am running Emacs from the Harfbuzz branch. I have the font "Noto Sans Mandaic" installed (from https://noto-website-2.storage.googleapis.com/pkgs/NotoSansMandaic-hinted.zip). I save this code in a file "reproduce.el" and execute it with "emacs -Q -l reproduce.el": (set-fontset-font t '(?\u0840 . ?\u085B) "Noto Sans Mandaic 20") (set-char-table-range composition-function-table '(?\u0840 . ?\u085B) (list ["[\u0840-\u085B]+" 0 arabic-shape-gstring])) (setq bidi-paragraph-direction t) (insert "\u0856\u0844\u0845") The problem is that the second and third character from the right are not combined as they should. This works in hb-view and it also works, if I remove the setting of bidi-paragraph-direction. The commit that breaks this is the last one, 48776b7011 "Provide text directionality and language to HarfBuzz shaper". Before that commit it works for me. ---- In GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.11) of 2018-12-30 built on arrian Repository revision: 48776b70115edf3775df19d80f734048dadff198 Repository branch: harfbuzz Windowing system distributor 'The X.Org Foundation', version 11.0.11902000 System Description: Debian GNU/Linux 9 (stretch) Configured using: 'configure --with-harfbuzz --without-m17n-flt' Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS LCMS2 GMP Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Buffer Menu Minor modes in effect: shell-dirtrack-mode: t desktop-save-mode: t display-time-mode: t diff-auto-refine-mode: t delete-selection-mode: t cua-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t column-number-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc puny rfc822 mml mml-sec epa mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail pcmpl-unix tramp trampver tramp-compat tramp-loaddefs ucs-normalize parse-time format-spec nnheader gnus-util rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums time-date mail-utils dirtrack shell pcomplete eieio-opt speedbar sb-image ezimage dframe find-func thingatpt help-fns tabify imenu elec-pair desktop frameset highline benny-calendar-cfg ange-ftp comint ansi-color ring benny-unicode generic-x cl autoinsert cc-mode cc-fonts cc-guess cc-menus cc-styles cc-align cc-cmds cc-engine cc-vars cc-defs ps-print ps-print-loaddefs ps-def lpr advice dired dired-loaddefs benny-x-clipboard disp-table mm-util mail-prsvr time server protbuf cal-china lunar solar cal-dst cal-bahai cal-islam cal-hebrew holidays hol-loaddefs vc-git diff-mode easy-mmode diary-lib diary-loaddefs cal-menu calendar cal-loaddefs delsel cua-base .loaddefs benny-tools browse-url autoload radix-tree lisp-mnt mule-util cus-edit cus-start cus-load wid-edit info finder-inf package let-alist derived pcase cl-extra help-mode easymenu url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json map url-vars seq byte-opt gv bytecomp byte-compile cconv epg epg-config subr-x cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 01 10:28:59 2019 Received: (at 33944) by debbugs.gnu.org; 1 Jan 2019 15:28:59 +0000 Received: from localhost ([127.0.0.1]:44089 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1geLyV-00061M-7D for submit@debbugs.gnu.org; Tue, 01 Jan 2019 10:28:59 -0500 Received: from eggs.gnu.org ([208.118.235.92]:32777) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1geLyS-00061D-3T for 33944@debbugs.gnu.org; Tue, 01 Jan 2019 10:28:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1geLyO-0000ez-RF for 33944@debbugs.gnu.org; Tue, 01 Jan 2019 10:28:55 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1geLyO-0000et-OB; Tue, 01 Jan 2019 10:28:52 -0500 Received: from [176.228.60.248] (port=2895 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1geLyO-00005p-CD; Tue, 01 Jan 2019 10:28:52 -0500 Date: Tue, 01 Jan 2019 17:28:42 +0200 Message-Id: <83a7kk4ct1.fsf@gnu.org> From: Eli Zaretskii To: Benjamin Riefenstahl In-reply-to: <87wonoo35z.fsf@turtle-trading.net> (message from Benjamin Riefenstahl on Tue, 01 Jan 2019 15:36:40 +0100) Subject: Re: bug#33944: 27.0.50; harfbuzz: Noto Sans Mandaic not rendered correctly References: <87wonoo35z.fsf@turtle-trading.net> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 33944 Cc: 33944@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Benjamin Riefenstahl > Date: Tue, 01 Jan 2019 15:36:40 +0100 > > This may be a more general problem, but Noto Sans Mandaic reproduces it > for me: You mean, with other fonts that support Arabic shaping the problem doesn't happen? > I save this code in a file "reproduce.el" and execute it with "emacs -Q > -l reproduce.el": > > (set-fontset-font t '(?\u0840 . ?\u085B) "Noto Sans Mandaic 20") > > (set-char-table-range > composition-function-table '(?\u0840 . ?\u085B) > (list ["[\u0840-\u085B]+" 0 arabic-shape-gstring])) > > (setq bidi-paragraph-direction t) >From the doc string of bidi-paragraph-direction: If this is nil (the default), the direction of each paragraph is determined by the first strong directional character of its text. The values of ‘right-to-left’ and ‘left-to-right’ override that. Any other value is treated as nil. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Did you set it to t on purpose? If so, can you explain why? > (insert "\u0856\u0844\u0845") > > The problem is that the second and third character from the right are > not combined as they should. This works in hb-view and it also works, > if I remove the setting of bidi-paragraph-direction. What happens if bidi-paragraph-direction is set to one of the valid values? > The commit that breaks this is the last one, 48776b7011 "Provide text > directionality and language to HarfBuzz shaper". Before that commit it > works for me. Can you run Emacs under a debugger and see what value of 'dir' do we come up with in this snippet from ftfont.c: hb_direction_t dir = HB_DIRECTION_INVALID; if (EQ (direction, QL2R)) dir = HB_DIRECTION_LTR; else if (EQ (direction, QR2L)) dir = HB_DIRECTION_RTL; /* If the caller didn't provide a meaningful DIRECTION, let HarfBuzz guess it. */ if (dir != HB_DIRECTION_INVALID) hb_buffer_set_direction (hb_buffer, dir); Do we call hb_buffer_set_direction, and if so, with what value? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 01 13:34:24 2019 Received: (at 33944) by debbugs.gnu.org; 1 Jan 2019 18:34:24 +0000 Received: from localhost ([127.0.0.1]:44135 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1geOrw-00022V-Ij for submit@debbugs.gnu.org; Tue, 01 Jan 2019 13:34:24 -0500 Received: from odoacer.turtle-trading.net ([93.241.193.16]:55225) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1geOru-00022G-SM for 33944@debbugs.gnu.org; Tue, 01 Jan 2019 13:34:23 -0500 Received: from justinian.turtle-trading.net ([192.168.2.118]) by odoacer.turtle-trading.net with esmtp (Exim 4.80) (envelope-from ) id 1geOrn-0000qI-Sh; Tue, 01 Jan 2019 19:34:15 +0100 Received: from benny by justinian.turtle-trading.net with local (Exim 4.89) (envelope-from ) id 1geOrn-0003Ek-IS; Tue, 01 Jan 2019 19:34:15 +0100 From: Benjamin Riefenstahl To: Eli Zaretskii Subject: Re: bug#33944: 27.0.50; harfbuzz: Noto Sans Mandaic not rendered correctly References: <87wonoo35z.fsf@turtle-trading.net> <83a7kk4ct1.fsf@gnu.org> Date: Tue, 01 Jan 2019 19:34:15 +0100 In-Reply-To: <83a7kk4ct1.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 01 Jan 2019 17:28:42 +0200") Message-ID: <87zhsk6xco.fsf@turtle-trading.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33944 Cc: 33944@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > You mean, with other fonts that support Arabic shaping the problem > doesn't happen? Now that you asked, I get the same problem with some words in Syriac, like with this: (set-fontset-font t '(?\u0700 . ?\u07FF) "Serto Mardin 20") (setq bidi-paragraph-direction 'right-to-left) (insert "\u0718\u0726\u0720\u0713\u0717\u073F") The characters should all be connected, but the third and fourth are not in this case. >> From the doc string of bidi-paragraph-direction: > > If this is nil (the default), the direction of each paragraph is > determined by the first strong directional character of its text. > The values of =E2=80=98right-to-left=E2=80=99 and =E2=80=98left-to-righ= t=E2=80=99 override that. > Any other value is treated as nil. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Did you set it to t on purpose? If so, can you explain why? No, that was a mistake. OTOH it seems that "is treated as nil" is not true, because "t" has the same effect as "right-to-left". > What happens if bidi-paragraph-direction is set to one of the valid > values? With right-to-left the same happens, with left-to-right it's good again (same as with the default). >> The commit that breaks this is the last one, 48776b7011 "Provide text >> directionality and language to HarfBuzz shaper". Before that commit it >> works for me. > > Can you run Emacs under a debugger and see what value of 'dir' do we > come up with in this snippet from ftfont.c: > > hb_direction_t dir =3D HB_DIRECTION_INVALID; > if (EQ (direction, QL2R)) > dir =3D HB_DIRECTION_LTR; > else if (EQ (direction, QR2L)) > dir =3D HB_DIRECTION_RTL; > /* If the caller didn't provide a meaningful DIRECTION, let HarfBuzz > guess it. */ > if (dir !=3D HB_DIRECTION_INVALID) > hb_buffer_set_direction (hb_buffer, dir); > > Do we call hb_buffer_set_direction, and if so, with what value? With "t" or right-to-left we have dir =3D=3D HB_DIRECTION_LTR, and yes we go into that function. With the default (nil) or left-to-right we have dir =3D=3D HB_DIRECTION_RTL and we also call that function. Is this switched around somewhere? Thanks for looking into this, benny From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 01 14:17:20 2019 Received: (at 33944) by debbugs.gnu.org; 1 Jan 2019 19:17:20 +0000 Received: from localhost ([127.0.0.1]:44143 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gePXT-00036j-Tq for submit@debbugs.gnu.org; Tue, 01 Jan 2019 14:17:20 -0500 Received: from eggs.gnu.org ([208.118.235.92]:47428) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gePXR-00036a-S4 for 33944@debbugs.gnu.org; Tue, 01 Jan 2019 14:17:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gePXN-0005YI-Vd for 33944@debbugs.gnu.org; Tue, 01 Jan 2019 14:17:17 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51172) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gePXN-0005Y8-Rp; Tue, 01 Jan 2019 14:17:13 -0500 Received: from [176.228.60.248] (port=1708 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gePXN-0002nQ-8V; Tue, 01 Jan 2019 14:17:13 -0500 Date: Tue, 01 Jan 2019 21:17:03 +0200 Message-Id: <835zv8428g.fsf@gnu.org> From: Eli Zaretskii To: Benjamin Riefenstahl In-reply-to: <87zhsk6xco.fsf@turtle-trading.net> (message from Benjamin Riefenstahl on Tue, 01 Jan 2019 19:34:15 +0100) Subject: Re: bug#33944: 27.0.50; harfbuzz: Noto Sans Mandaic not rendered correctly References: <87wonoo35z.fsf@turtle-trading.net> <83a7kk4ct1.fsf@gnu.org> <87zhsk6xco.fsf@turtle-trading.net> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 33944 Cc: 33944@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Benjamin Riefenstahl > Cc: 33944@debbugs.gnu.org > Date: Tue, 01 Jan 2019 19:34:15 +0100 > > Eli Zaretskii writes: > > You mean, with other fonts that support Arabic shaping the problem > > doesn't happen? > > Now that you asked, I get the same problem with some words in Syriac, > like with this: > > (set-fontset-font t '(?\u0700 . ?\u07FF) "Serto Mardin 20") > (setq bidi-paragraph-direction 'right-to-left) > (insert "\u0718\u0726\u0720\u0713\u0717\u073F") > > The characters should all be connected, but the third and fourth are not > in this case. I asked whether the problem happens with other fonts, not with other characters. Because you specifically mentioned the font. > > If this is nil (the default), the direction of each paragraph is > > determined by the first strong directional character of its text. > > The values of ‘right-to-left’ and ‘left-to-right’ override that. > > Any other value is treated as nil. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Did you set it to t on purpose? If so, can you explain why? > > No, that was a mistake. OTOH it seems that "is treated as nil" is not > true, because "t" has the same effect as "right-to-left". It does? How do you see that? Does the paragraph direction change to R2L when you set bidi-paragraph-direction to t? > > What happens if bidi-paragraph-direction is set to one of the valid > > values? > > With right-to-left the same happens, with left-to-right it's good again > (same as with the default). > > >> The commit that breaks this is the last one, 48776b7011 "Provide text > >> directionality and language to HarfBuzz shaper". Before that commit it > >> works for me. > > > > Can you run Emacs under a debugger and see what value of 'dir' do we > > come up with in this snippet from ftfont.c: > > > > hb_direction_t dir = HB_DIRECTION_INVALID; > > if (EQ (direction, QL2R)) > > dir = HB_DIRECTION_LTR; > > else if (EQ (direction, QR2L)) > > dir = HB_DIRECTION_RTL; > > /* If the caller didn't provide a meaningful DIRECTION, let HarfBuzz > > guess it. */ > > if (dir != HB_DIRECTION_INVALID) > > hb_buffer_set_direction (hb_buffer, dir); > > > > Do we call hb_buffer_set_direction, and if so, with what value? > > With "t" or right-to-left we have dir == HB_DIRECTION_LTR, and yes we go > into that function. With the default (nil) or left-to-right we have dir > == HB_DIRECTION_RTL and we also call that function. When the value is nil, do you see the text that starts with Mandanaic or Syriac letters begin at the right margin of the window? IOW, do you see that the paragraph direction changes when the paragraph begins with a strong Right to Left letter? Or does the text still get laid out starting at the left margin of the window? > Is this switched around somewhere? Yes, this was the whole point of the changeset that succeeded in breaking the shaping. But I have an idea why this happens, and will try to fix it. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 01 16:40:24 2019 Received: (at 33944) by debbugs.gnu.org; 1 Jan 2019 21:40:24 +0000 Received: from localhost ([127.0.0.1]:44181 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1geRlv-0006qt-Su for submit@debbugs.gnu.org; Tue, 01 Jan 2019 16:40:24 -0500 Received: from odoacer.turtle-trading.net ([93.241.193.16]:55369) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1geRlt-0006qe-Gl for 33944@debbugs.gnu.org; Tue, 01 Jan 2019 16:40:22 -0500 Received: from justinian.turtle-trading.net ([192.168.2.118]) by odoacer.turtle-trading.net with esmtp (Exim 4.80) (envelope-from ) id 1geRlk-0000tb-Uz; Tue, 01 Jan 2019 22:40:12 +0100 Received: from benny by justinian.turtle-trading.net with local (Exim 4.89) (envelope-from ) id 1geRlk-0003zr-KX; Tue, 01 Jan 2019 22:40:12 +0100 From: Benjamin Riefenstahl To: Eli Zaretskii Subject: Re: bug#33944: 27.0.50; harfbuzz: Noto Sans Mandaic not rendered correctly References: <87wonoo35z.fsf@turtle-trading.net> <83a7kk4ct1.fsf@gnu.org> <87zhsk6xco.fsf@turtle-trading.net> <835zv8428g.fsf@gnu.org> Date: Tue, 01 Jan 2019 22:40:11 +0100 In-Reply-To: <835zv8428g.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 01 Jan 2019 21:17:03 +0200") Message-ID: <874lasf45g.fsf@turtle-trading.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33944 Cc: 33944@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > I asked whether the problem happens with other fonts, not with other > characters. Because you specifically mentioned the font. Ah, I got confused with you mentioning Arabic. Actually Noto is the only freely available font for Mandaic that I am aware of. I just mentioned it and its source to make it easier to reproduce the problem. As I said, other fonts seem to have similar problems with other characters. In the Syriac example, the same problem with the same characters happens with other fonts. OTOH all the fonts I have for Syriac are made by the same company in a single package, so I expect them all to contain the same shaping information. >> > If this is nil (the default), the direction of each paragraph is >> > determined by the first strong directional character of its text. >> > The values of =E2=80=98right-to-left=E2=80=99 and =E2=80=98left-to-r= ight=E2=80=99 override that. >> > Any other value is treated as nil. >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > >> > Did you set it to t on purpose? If so, can you explain why? >>=20 >> No, that was a mistake. OTOH it seems that "is treated as nil" is not >> true, because "t" has the same effect as "right-to-left". > > It does? How do you see that? Does the paragraph direction change to > R2L when you set bidi-paragraph-direction to t? I got confused there, because I expected the scratch buffer to use the default for b-p-d, when it actually has it explictly set to ltr. That explains what I see. Setting b-p-d to "t" in scratch changes the behaviour, because than it uses default detection. >> > Can you run Emacs under a debugger and see what value of 'dir' do we >> > come up with in this snippet from ftfont.c: >> > >> > hb_direction_t dir =3D HB_DIRECTION_INVALID; >> > if (EQ (direction, QL2R)) >> > dir =3D HB_DIRECTION_LTR; >> > else if (EQ (direction, QR2L)) >> > dir =3D HB_DIRECTION_RTL; >> > /* If the caller didn't provide a meaningful DIRECTION, let HarfBuzz >> > guess it. */ >> > if (dir !=3D HB_DIRECTION_INVALID) >> > hb_buffer_set_direction (hb_buffer, dir); >> > >> > Do we call hb_buffer_set_direction, and if so, with what value? >>=20 >> With "t" or right-to-left we have dir =3D=3D HB_DIRECTION_LTR, and yes w= e go >> into that function. With the default (nil) or left-to-right we have dir >> =3D=3D HB_DIRECTION_RTL and we also call that function. > > When the value is nil, do you see the text that starts with Mandanaic > or Syriac letters begin at the right margin of the window? IOW, do > you see that the paragraph direction changes when the paragraph begins > with a strong Right to Left letter? Or does the text still get laid > out starting at the left margin of the window? Yes. With b-p-d set to rtl or nil I get the text at the right margin but with the shaping error. With the default value ltr the text is at the left, and the shaping error is gone. This is always with changing the script and restarting Emacs. When I add an "x" at the beginning in the script and set b-p-d to nil, the text is at the left and with correct shaping. If I set b-p-d to nil and interactively add or remove an "x" at the beginning of the line, the place where the text goes changes accordingly but the shaping does not change, the form persists that the script initially causes. I executed clear-font-cache, but that does not make the shaping change in this scenario either. Can I test something else? benny From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 02 11:04:33 2019 Received: (at 33944) by debbugs.gnu.org; 2 Jan 2019 16:04:33 +0000 Received: from localhost ([127.0.0.1]:44878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gej0Q-0001lM-GI for submit@debbugs.gnu.org; Wed, 02 Jan 2019 11:04:32 -0500 Received: from eggsout.gnu.org ([209.51.188.92]:42961) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gej0O-0001lE-D8 for 33944@debbugs.gnu.org; Wed, 02 Jan 2019 11:04:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gej0J-0003tV-F4 for 33944@debbugs.gnu.org; Wed, 02 Jan 2019 11:04:28 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51517) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gej0J-0003tR-C7; Wed, 02 Jan 2019 11:04:23 -0500 Received: from [176.228.60.248] (port=2629 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gej0I-0005vt-Vx; Wed, 02 Jan 2019 11:04:23 -0500 Date: Wed, 02 Jan 2019 18:04:15 +0200 Message-Id: <834lar3v28.fsf@gnu.org> From: Eli Zaretskii To: Benjamin Riefenstahl In-reply-to: <874lasf45g.fsf@turtle-trading.net> (message from Benjamin Riefenstahl on Tue, 01 Jan 2019 22:40:11 +0100) Subject: Re: bug#33944: 27.0.50; harfbuzz: Noto Sans Mandaic not rendered correctly References: <87wonoo35z.fsf@turtle-trading.net> <83a7kk4ct1.fsf@gnu.org> <87zhsk6xco.fsf@turtle-trading.net> <835zv8428g.fsf@gnu.org> <874lasf45g.fsf@turtle-trading.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 33944 Cc: 33944@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Benjamin Riefenstahl > Cc: 33944@debbugs.gnu.org > Date: Tue, 01 Jan 2019 22:40:11 +0100 > > > When the value is nil, do you see the text that starts with Mandanaic > > or Syriac letters begin at the right margin of the window? IOW, do > > you see that the paragraph direction changes when the paragraph begins > > with a strong Right to Left letter? Or does the text still get laid > > out starting at the left margin of the window? > > Yes. With b-p-d set to rtl or nil I get the text at the right margin > but with the shaping error. With the default value ltr the text is at > the left, and the shaping error is gone. This is always with changing > the script and restarting Emacs. > > When I add an "x" at the beginning in the script and set b-p-d to nil, > the text is at the left and with correct shaping. If I set b-p-d to nil > and interactively add or remove an "x" at the beginning of the line, the > place where the text goes changes accordingly but the shaping does not > change, the form persists that the script initially causes. I executed > clear-font-cache, but that does not make the shaping change in this > scenario either. > > Can I test something else? Please test the latest branch, I tried to fix this problem. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 02 18:12:27 2019 Received: (at 33944-done) by debbugs.gnu.org; 2 Jan 2019 23:12:27 +0000 Received: from localhost ([127.0.0.1]:45057 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gepgY-0008MR-Nt for submit@debbugs.gnu.org; Wed, 02 Jan 2019 18:12:26 -0500 Received: from odoacer.turtle-trading.net ([93.241.193.16]:56599) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gepgU-0008M9-FU for 33944-done@debbugs.gnu.org; Wed, 02 Jan 2019 18:12:25 -0500 Received: from justinian.turtle-trading.net ([192.168.2.118]) by odoacer.turtle-trading.net with esmtp (Exim 4.80) (envelope-from ) id 1gepgN-0001VY-DR; Thu, 03 Jan 2019 00:12:15 +0100 Received: from benny by justinian.turtle-trading.net with local (Exim 4.89) (envelope-from ) id 1gepgN-0001vp-2E; Thu, 03 Jan 2019 00:12:15 +0100 From: Benjamin Riefenstahl To: Eli Zaretskii Subject: Re: bug#33944: 27.0.50; harfbuzz: Noto Sans Mandaic not rendered correctly References: <87wonoo35z.fsf@turtle-trading.net> <83a7kk4ct1.fsf@gnu.org> <87zhsk6xco.fsf@turtle-trading.net> <835zv8428g.fsf@gnu.org> <874lasf45g.fsf@turtle-trading.net> <834lar3v28.fsf@gnu.org> Date: Thu, 03 Jan 2019 00:12:14 +0100 In-Reply-To: <834lar3v28.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 02 Jan 2019 18:04:15 +0200") Message-ID: <8736qa64dt.fsf@turtle-trading.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 33944-done Cc: 33944-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > Please test the latest branch, I tried to fix this problem. That works for all my tests. I'm closing the bug. Thank you very much, benny From unknown Fri Aug 15 12:52:46 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 31 Jan 2019 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator