[HarfBuzz] HarfBuzz shaping of R2L text

[Khaled Hosny]

On Wed, May 29, 2019 at 06:30:08PM +0300, Eli Zaretskii wrote:
> Hi,
> 
> While testing the results of hb_shape_full called to shape R2L text, I
> observed behavior that surprised me: shaping an R2L base letter with a
> diacritical produces a sequence of glyphs in reverse order, i.e. the
> glyph for the diacritical comes first, before the base letter.
> 
> For example, if I shape the sequence (in the logical order)
> 
>   U+05EA HEBREW LETTER TAV
>   U+05BB HEBREW POINT QUBUTS
> 
> the glyphs left in the buffer by the shaper are in reverse order,
> first QUBUTS, then TAV.  I thought that this was because of bidi
> reordering, but the result doesn't change if I set the buffer
> direction to LTR before calling the shaper.  The order of the clusters
> does change with the direction, i.e. with LTR the first cluster is
> zero, followed by 1, etc., whereas with RTL the clusters are in the
> decreasing order.  But the glyphs are always in the same order: the
> point first, then the letter.
> 
> I see the same with the Arabic script if I shape U+0633 followed by
> U+0651 (in logical order).
> 
> This doesn't happen with LTR text in unidirectional scripts, including
> with Latin text when shaping a base letter followed by a diacritical.
> 
> Is this expected behavior?  If so, what are the reasons?  Also, can it
> be controlled by the client application?  E.g., Uniscribe can be told
> to produce glyphs in the logical order, after shaping them for RTL
> display.

AFAIK, yes this is expected. Usually the glyph order shouldn’t matter,
one just draws them as they are ordered by HarfBuzz and for anything
that requires glyph to glyph to character mapping, the clusters provide
all the information needed.

As it happens, somewhere in Emacs does not like that for whatever reason
and would raw the glyph in the wrong order, so it my HarfBuzz in Emacs
integration code I used hb_buffer_reverse_clusters() right after shaping
to get the glyph correctly drawn. No idea how Emacs would deal with
reordered Indic glyphs which don’t always follow the input order.

Regards,
Khaled