bug#41005: problem with rendering Persian text in Emacs 27

[Eli Zaretskii <eliz@gnu.org>]

> From: Pip Cet <pipcet@gmail.com>
> Cc: hossein valizadeh <valizadeh.ho@gmail.com>,  41005@debbugs.gnu.org,
>   nicholasdrozd@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.

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.

> 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.

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.  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.