Font Validator error in GPOS

[psb1558]

Here's an oddity, possibly related to discussion #225 and issues #204 and #220 (though it is too much to hope that one fix could fix them all).

The Font Validator report for one of the static .otf fonts looks like this:

I noticed this a long time ago but decided to ignore it: after all, Font Validator is sadly out of date, and it report some pretty crazy stuff. But I decided to take another look this afternoon, and this is what I found. FV is reporting an error in the record of the anchors for a particular glyph, in this case the letter A, for which the TTX looks like this:

<BaseRecord index="0">
    <BaseAnchor index="0" empty="1"/>
    <BaseAnchor index="1" Format="1">
        <XCoordinate value="604"/>
        <YCoordinate value="0"/>
    </BaseAnchor>
    <BaseAnchor index="2" empty="1"/>
    <BaseAnchor index="3" Format="1">
        <XCoordinate value="325"/>
        <YCoordinate value="0"/>
    </BaseAnchor>
    <BaseAnchor index="4" empty="1"/>
</BaseRecord>

Notice that AnchorFormat = 2868 (an obviously ridiculous value, not coincidentally the number of entries in this subtable), is always reported for a BaseAnchor record that is "empty"—that is, the glyph lacks an achor of a particular type.

Font Validator is not coping well with an empty BaseAnchor Record: instead of reporting it as empty, it is "seeing" a garbage value and marking it as an error. Thinking about the InDesign bug, it occurs to me: what if InDesign actually tried to look up Format[2868] in an array of format records without doing any index checking? Crash!

I see that Brill goes to some lengths to avoid empty BaseAnchor records: every anchor type has its own BaseArray so that the BaseRecord array always has a length of exactly one. No empty BaseAnchor Records needed: rather, the BaseArray just skips over the entry in the coverage table.

I don't know if this is going to be the solution, but I'm going to look for a way to organize this section of the GPOS table the way Brill does.

Sorry if this explanation is unclear: I'm not a technical writer!

[kenmcd]

Is this only in the .otf fonts? And not the .ttf fonts? If yes, how can the GPOS table be different?

Edit: after thinking about this a bit, I can see some needed differences.

[psb1558]

Well, that is a thought, and I suppose it would mean that fixing this couldn't help with the one MS Word problem (difficulty only with .otf fonts). But it could very well help with the InDesign problem—if that app has two quite different blocks of code for handling GPOS: one for static (the values never change) and one for variable (deltas can be applied to any value in the table).

Or maybe it wouldn't help at all. Maybe I should survey my collection of fonts to see how many have empty entries in their anchor arrays. Junicode has an unusual number of anchors, and this wouldn't be the first time that caused problems.

[psb1558]

Okay, Inter and Libertinus have empty BaseAnchor Records. I suppose they're fine, and if they can be problematic in some apps, that's on the apps, not on the fonts.