[HarfBuzz] Documentation-requirements gathering

Tue Jul 17 20:48:35 UTC 2018

On Tue, 17 Jul 2018 11:25:01 +0200
Behdad Esfahbod <behdad at behdad.org> wrote:

> On Tue, Jul 17, 2018 at 4:18 AM, Richard Wordingham <
> richard.wordingham at ntlworld.com> wrote:  

Dear Behdad,

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

> I don't see a bug open about that.

That's because you closed it -
https://github.com/harfbuzz/harfbuzz/issues/242.

>  No bug, no fix.  No bug, no clarification. :)

You gave the solution, which I found useful.

However, this is not intended as a list of bugs.  It is a list of
behaviours that font writers would benefit from help to work with or
round.  It is naturally largely based on my struggles.

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

> The first time I heard that this is a problem was a couple weeks ago
> from Zachary.  I don't remember anyone filing a bug about this.
> Again, no bug, no fix.

I'm not sure there's a bug.  Calling the glyphs <A, B, C, D> what I
want to do is something that could be simplified to:

1. Skipping marks: A C > E
2. B D > F
3. F > D B

The needs of Arabic seem to dictate that lookup 2 have no effect.  Now,
it's possible to work round various limitations that make writing
Arabic fonts much easier (perhaps even _possible_), but it would be
much easier if one could predict the effects of one's lookups rather
than trying them out on the various renderers.

I also had difficulties with the Tai Tham analogue of the Thai tone +
SARA AM rearrangement when the preceding consonant does not ligate.
Even the SEA shaper would have found it awkward to support - in most
languages, the rearrangement only happens when the base consonant
ligates. Northern Thai is exceptional, and I strongly suspect the
influence of Bangkok. Having sorted it out, I then got bitten by the
rendering of a final MAI SAM acting as a superscript repetition mark.

> > One area where I have just had to assume that 'here be dragons' is
> > how
> > mark exclusions affect substitutions invoked by (chained) context
> > substitutions.

For example, suppose we have a sequence of marks A B C, and a context
substitution that skipped mark B.  If a ligature substitution that
skipped no marks fired at position A, should the ligation A B > D
have any effect?  Similarly, can I use mark skipping to define A B C >
D B by an input context A B C and a ligation A C > D that skips B?

> > Context substitutions seem to have odd limitations
> > when they invoke multiple ligations - perhaps I'm just seeing bugs
> > in Uniscribe.  

> I know of one bug in HarfBuzz about that. But that's it.  In my
> experience they work fine.  Need specific examples.

You make it sound like a Uniscribe bug.  I've mainly needed it to deal
with one grammar Nazi decision spawning a whole set of dotted circles.
HarfBuzz doesn't work like that.  One wrong decision can cause 3 dotted
circles; I'd like to remove them by one context substitution.  At
present I reduce sequences of 3 or 4 wrongful dotted circles to 1 or 2
in one lookup, and complete the removal in a second lookup. 

Incidentally, there's a difference between dotted circles in Uniscribe
and HarfBuzz.  Uniscribe adds U+25CC characters to the string to be
rendered.  HarfBuzz adds the glyph mapped to from U+25CC.  In HarfBuzz
one can use a trick with the locl feature so that glyphs for U+25CC in
the input are a different glyph to those denigrating the input
character sequence.  It looked very handy, but it's not compatible with
Uniscribe.

> > There is also the undocumented restriction that subsidiary
> > substitutions be applied from start to end.  

> I don't understand this.

The lookups triggered by a context lookup are specified by a position
in the input sequence and the lookup to apply.  HarfBuzz requires that
they be listed in ascending order of position.  The order listed is, by
definition, the order in which they are executed.  So, if in the
context A B C D, I want A B > E and C > F, I can't order the
substitutions

2 C > F
0 A B > E

I have to have them in the order

0 A B > E
1 C > F # Correct location
2 C > F, D > D # Work around buggy implementation - bug fixed in
HarfBuzz years ago, recently present in iOS.

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

> Need specifics.  What trouble?

Substitutions terminate or text vanishes.  I think the former.  It may
not be a HarfBuzz problem.

Richard.