Unexpected markAnchor format 3.

[typemytype]

While extracting variable fonts the message Unexpected markAnchor format 3. pops up with for example these fonts

it happens inside lookup type 4, a ligature substitution Mark-to-Base attachment positioning.

If Im correct @jenskutilek made the anchor extractor.

Those anchors could be nicely converted into anchor inside a glyph object.

[frankrolf]

I believe the reason for this problem is that the GPOS feature in question uses the Extension table.

This code I recently wrote for extracting anchors might be useful:
https://github.com/adobe-type-tools/drawBotProofing/blob/main/drawbot_proofing/glyphProof.py#L272-L414

[jenskutilek]

Thanks. I'll have a look, but not before some time next week :)

[frankrolf]

Oh, it’s just the addition of the Device Table.

From the spec:

Anchor format 3: design units plus Device or VariationIndex tables
Like AnchorFormat1, AnchorFormat3 specifies a format identifier and provides coordinates that locate an anchor point. And, like AnchorFormat2, it permits fine adjustments in variable fonts to the coordinate values. However, AnchorFormat3 uses Device tables, rather than a contour point, for this adjustment.
With a Device table, a client can adjust the position of the anchor point for any font size and device resolution. AnchorFormat3 can specify offsets to separate Device tables for the X and Y coordinates. If only one coordinate requires adjustment, the offset to the Device table for the other coordinate may be set to NULL.
In variable fonts, AnchorFormat3 is required to reference variation data to adjust anchor points for different variation instances, if needed. In this case, AnchorFormat3 specifies an offset to a VariationIndex table, which is a variant of the Device table used for variations. If no VariationIndex table is used for a particular anchor point X or Y coordinate, then that value is used for all variation instances. While separate VariationIndex table references are required for each value that requires variation, two or more values that require the same variation-data values can have offsets that point to the same VariationIndex table, and two or more VariationIndex tables can reference the same variation data entries.

I don’t know if there are any plans on making Extractor VF-capable – right now, just the origin source is opened, which is fine.

I played around a little here, and just changed it to

        if (markAnchor.Format not in (1, 3)):

This works, but somehow now the markAnchors are duplicated.

[benkiel]

Possible to filter and throw out dups?

[frankrolf]

That’s possible of course, but duplicate coordinates may well be deliberate. I think something’s wrong in my assumption that I can just accept another anchor format like this.

[jenskutilek]

I didn't write the code, @rimas-kudelis did. I'm not sure what best to do here.

[rimas-kudelis]

@frankrolf :

I played around a little here, and just changed it to

        if (markAnchor.Format not in (1, 3)):

This works, but somehow now the markAnchors are duplicated.

Would you mind adding a debug print statement, or otherwise check if the fonts in question do not in fact have duplicated anchors there?

I don't think I'll have much free time for the next couple weeks, and by then, I might just forget about this issue. 😮‍💨

[frankrolf]

I can quite confidently say that the fonts in question don't have duplicated anchors, since I produced them 😊

That said, this issue is just a minor inconvenience for me – I just wanted to make sure it is recorded and acknowledged.

I can have a look at fixing the code in the near future.