GNU bug report logs - #41005
problem with rendering Persian text in Emacs 27

Previous Next

Package: emacs;

Reported by: hossein valizadeh <valizadeh.ho <at> gmail.com>

Date: Fri, 1 May 2020 18:34:01 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: Pip Cet <pipcet <at> gmail.com>
To: hossein valizadeh <valizadeh.ho <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 41005 <at> debbugs.gnu.org,
 nicholasdrozd <at> gmail.com
Subject: Re: bug#41005: problem with rendering Persian text in Emacs 27
Date: Thu, 04 Jun 2020 08:28:24 +0000
hossein valizadeh <valizadeh.ho <at> gmail.com> writes:

>  And finally, please try this with the version on the master branch, where a few fixes were
>  installed lately.

I can reproduce the very similar issue described (Farsi Wikipedia entry
for Emacs), on current master. I believe I've figured it out, but I can
also debug further if required.

What happens is that font-shape-gstring is called with direction == L2R,
mis-shapes the text, then caches that version in the composition gstring
cache. The cache doesn't distinguish directions, and it's never cleared,
so this "infects" other buffers, but only if they're opened afterwards,
and only for the same words.

shr appears to force bidi-display-reordering off. Removing that let
binding from shr-insert-document avoids the problem.

We should consider adding direction to our gstrings, on master. While
we're there, let's also add script, language, and harfbuzz features to
the gstrings so we know we've captured the precise harfbuzz parameters?




This bug report was last modified 4 years and 329 days ago.

Previous Next


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