[HarfBuzz] Documentation-requirements gathering

[Richard Wordingham]

On Mon, 16 Jul 2018 14:23:10 -0500
Nathan Willis <nwillis at glyphography.com> wrote:

> - If you are only casually using HarfBuzz but the shaping and layout
> issues have been a stumbling block in the past, what material would
> have helped

This is a big hole, and perhaps off-topic given your limited funds, but
OpenType semantics need to be defined somewhere.  The definition will
contain many "implementation-defined" areas, and perhaps the pitfalls
of CoreText will have to be skipped.  The problem is that OpenType fonts
are usually intended to run with all OpenType renderers.

One problem lies in the change of advancewidth for glyphs
categorised as marks - there is a subtle difference between
Uniscribe/DirectWrite and HarfBuzz.  It's also not at all clear to me
how position changes are supposed to interact with attachment.

Another nightmare area is the rendering of <base, mark, base, mark>
when the bases ligate and the marks are required to interact.  The root
of the problem is that Arabic requires that marks on components of
ligatures not interact, and that rule seems to apply even if the
ligature glyph is classified as a base rather than as a ligature. Some
fonts resort to including marks in the ligature. The specific problem
is with the rendering of Tai Tham <U+1A36, U+1A76, U+1A63, U+1A74>.
U+1A63 TAI THAM VOWEL SIGN AA generally functions as a base character,
but in the Chiang Mai style*, it always surrenders U+1A74 to the
preceding consonant, and just handling that and the consequent
rearrangement is fiddly.

*I don't have a good taxonomy of Northern Thai layout styles; there may
well be a better name.

One area where I have just had to assume that 'here be dragons' is how
mark exclusions affect substitutions invoked by (chained) context
substitutions.  Context substitutions seem to have odd limitations when
they invoke multiple ligations - perhaps I'm just seeing bugs in
Uniscribe. There is also the undocumented restriction that subsidiary
substitutions be applied from start to end.  Also, it seems that
invoked substitution have to have a matching context - invoking a
single substitution that has no effect, not even replacing a glyph by
itself, has seemed to cause trouble.

The issues over complex context substitutions have caused me to use
multiple lookups when rearranging glyphs, with the danger of
accidentally losing or duplicating a glyph.  Not all rearrangements can
be provided by the rendering engine, as some are style-specific.  The
shifting of U+1A74 TAI THAM SIGN MAI KANG and U+1A58 TAI THAM SIGN MAI
KANG LAI have caused me headaches, and John Hudson reports
rearrangements from other scripts.

Richard.