GNU bug report logs -
#41005
problem with rendering Persian text in Emacs 27
Previous Next
Full log
View this message in rfc822 format
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Pip Cet <pipcet <at> gmail.com>
>> Cc: hossein valizadeh <valizadeh.ho <at> gmail.com>, 41005 <at> debbugs.gnu.org,
>> nicholasdrozd <at> gmail.com
>> Date: Fri, 05 Jun 2020 13:05:43 +0000
>>
>> I think the attached patch is a fairly minimal fix; it's against master,
>> applies to emacs-27 but I haven't tested it there.
>
> Thanks, it LGTM.
>
> I think we should put this on emacs-27, because this is a regression
> caused by Emacs 27's support for HarfBuzz as the default shaping
> engine. The other shapers didn't want us to provide the direction,
> they determined it internally. We added the DIRECTION argument as
> part of integrating HarfBuzz.
Okay, will do that unless someone objects.
> We could do better than your patch by actually computing the resolved
> bidi level there, which would require start_display followed by
> move_it_to, in which case we probably won't need to call
> composition_reseat_it by hand at all, and could just pick up the
> result produced by move_it_to. Or maybe we should just use
> Fvertical_motion instead (which does all that internally). But these
> ideas are for the master branch, not for emacs-27.
That sounds good.
>> Given these two bugs, I wonder whether it wouldn't be more reasonable
>> always to let HarfBuzz guess the direction, at least for Emacs-27:
>> scripts which change direction, if they are supported by HarfBuzz, won't
>> work anyway.
>
> Please explain "scripts that change direction" and "won't work
> anyway", I don't think I understand that part.
I think your example (RLO..PDF in RTL text) is better: that won't work
anyway, right now, because if, for example, you type
<HEBREW LETTER SHIN> <RIGHT-TO-LEFT OVERRIDE> f i
and have set the char table to treat "fi" as a ligature, the result will
(at least sometimes) be an "fi" ligature, but it should look like the
word "if".
> The reason we don't let HarfBuzz guess in all cases is because the
> resolved bidi level, when we have it, is a more accurate indication of
> the required direction.
Yes, but we'll still cache the wrong direction. If we let HarfBuzz guess
in all cases, output will be consistent and usually correct
> For example, if you have RTL characters
> inside the LRO..PDF embedding, it would be wrong to let the shaper
> guess, because it could (and usually will) guess wrongly that the
> direction is R2L. It is true that these are rare and unusual use
> cases, but they do exist, and Emacs does want to support them,
> including with scripts that must use the shaping engine.
As I described, I don't think RLO..PDF works with shaping right now,
because other code might have already cached the non-overridden glyph
string.
This bug report was last modified 4 years and 337 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.