NULL offsets to anchor tables in GPOS lookups

[HinTak]

Discussion on opentype list 26th April 2016:

Sasha Brawer pointed out that the AFDKO makeotf program is inconsistent in how it builds MarkToBase and MarkToLigature GPOS lookups. For MarkToBase and MarkToMark records, makeotf writes a default anchor (x= y = 0) when a mark class is defined in the lookup, but no anchor for that mark class is specified in the feature file rule.   However, for MarkToLigature GPOS lookups, makeotf writes a NULL anchor (aka offset = 0) when a mark class is defined in the lookup, but no anchor for that mark class is specified in the feature file rule.

It makes sense to me that makeotf should write a NULL anchor offset rather than a default anchor entry for the MarkToBase and MarkToMark lookups. However, I see that the OpenType spec explicitly says the an anchor table offset may be NULL for MarkToLigature and Cursive lookups, but does not say this for MarkToBase and MarkToMark lookups. I would like to think that this is an oversight, but before changing the makeotf behavior, I’d like to confirm what others have supported for these cases. Comments?

As I remember it, in the early days of OTL I made mark-to-base lookups with Null offsets if a base did not need an anchor for all mark classes. It worked fine. But at some stage I received message from Microsoft that this was no longer allowed and all bases must have an anchor for all classes. Since then I have been making separate lookups for separate mark classes. If you do not mind me saying, that is preferable over adding additional anchors at the origin… If you have a base which does not need an anchor for a mark at all, then the origin is a particular bad place to have the anchor.

I had a quick look at https://github.com/Microsoft/Font-Validator/blob/master/OTFontFileVal/val_GPOS.cs and did not see any obvious check in this direction, but probably it should.

[HinTak]

But I remember two changes being made to the original spec, where I needed to update fonts and the tool that made them: The removal of the sentence that you can use NULL offsets for mark to base and mark to mark being one. The other change being that the original spec explicitly stated that you can use the multiple substitution lookup to remove glyphs, which changed into a prohibition.

[HinTak]

DWrite/Uniscribe doesn't support NULL in all types of  mark attachment lookups. Cursive attachment requires NULL support to function properly, i.e. interrupt sequence of attached glyphs, so we naturally support NULL here.

DWrite/Uniscribe doesn't do any special processing for NULL here. It does't break, just treats this as offset equal to 0 and processes bytes of LigatureAttach structure as anchor data. Given that VOLT never produces NULL value I think this should be safe for us to fix (porting it down to older versions of Windows may be a problem, though)

[HinTak]

A bit more discussions on "Null offsets to Anchor tables in GPOS lookups 4, 5, and 6" on 29 Jul 2019:

...
In my memory the first OTL specification explicitly allowed the use of null offsets in the base array of attachment lookups. So I made some fonts with null offsets. Then I got the word from Microsoft not to use them.

Since then I made sure to create separate lookups for separate anchor classes.
...

> In GPOS lookups type 4 (mark to base),  format 1 (the only format),
    > there is a 2-D array of offsets, indexed  by base glyphs and mark glyph
    > classes. The spec is silent on whether those offsets can be null. The
    > natural interpretation would be that no positioning of the mark glyph
    > should be done for those combinations. It is a useful interpretation:
    > for example, it could be a combination can never occur (e.g. because of
    > a contextual substitution), and if offsets cannot be null, then one must
    > create a dummy anchor table, or split the lookup in multiple lookups.
...
    > My proposal is to clarify the spec to explicitly allow null offsets in
    > all three cases and to spell out that this should be interpreted as "no
    > positioning of the mark".
    >

[HinTak]

The new thread started on 26 Jul.

    > There is a similar situation in lookups type 5 (mark to ligature). There
    > the spec says "If a component does not define an attachment point for a
    > particular class of marks, then the offset to the corresponding Anchor
    > table will be NULL."
    >
    > There is a similar situation in lookups type 6 (mark to mark). The spec
    > is silent.

[HinTak]

> issues with null offset anchors in
> mark-to-base lookups?

macOS Mojave 10.14.5 and 10.14.6
applications Pages and Safari