E4100 AnchorFormat field is invalid -- can't tell what the problem is

[StevanWhite]

Hi,

I do not know if this is a Font-Validator issue, a FontForge issue, or something else.
In builds of FreeFont, hundreds of complaints like:

E4100	The AnchorFormat field is invalid	LookupList, Lookup[23], SubTable0(MarkBasePos), BaseArray, BaseRecord[52], BaseAnchor[1], AnchorFormat = 241

I look at the entry using FontForge, but I'm not sure what I'm looking for. What is "invalid" about it?

[HinTak]

E4100 is described in around line 3654 of https://github.com/HinTak/Font-Validator/blob/master/GenerateFValData/OurData.xml .

(this is the source file from which the chm help file is generated - you should have a copy of the help.chm together with FontVal ? Anyway, you can download the chm from https://github.com/HinTak/Font-Validator/blob/master/bin/FontValidatorHelp.chm )

[HinTak]

Well, I looked at the code and opentype spec. Only value 1, 2 or 3 are valid, and the message above says 241... I'd say try using ttx to extract the GPOS table and see if ttx is happy with it... I am going to close this unless / until ttx says it isn't 241... And please post a font if you do. (github issue allows attaching zip files up to 10 or 30MB, can't remember which, but quite adequate for even CJK fonts. As I have done so in one of fontforge's issues about the 1glyph multiple codepoint issue)

[StevanWhite]

ttx FreeSans.otf
produces a very big file FreeSans.ttx

grep "<Mark.*Format" FreeSans.ttx | sed -E 's/.*<Mark.*Format="([^"]*)".*/\1/'

produces a long row of 1's and 2's.

There is also a <MarkSetTableFormat value="1"/>

However, I see a lot of lines like
<Mark2Anchor index="0" empty="1"/>
usually followed by something like
<Mark2Anchor index="1" Format="1">
I wonder if the absence of the "Format" when the thing is "empty" causes the problem.

Attached find the OTF file. N.B. this is a work-in-progress, not for re-distribution!
FreeSans.zip

[HinTak]

@StevanWhite thanks for the test file. Btw, you can do "ttx -t GPOS ...' if you are only interested in one table.

[HinTak]

Okay, I see that some of the anchors are "empty" - it is actually quite difficult to tell, as the data structure does not have a size field, but just an offset. Basically, there is a "next" block starting at the same offset. There are two issues with this: is "empty" allowed? And a 2nd , how are the blocks ordered? Sometimes it is easier as it is a group index'ed 0,1, etc - the lower one is empty; in other cases where the highest index is empty, it is next clear what follows.

The GPOS part of the spec is 60 pages (out of about 600 pages) , and not easy to read.

I am inclined to have 2.1.5 out first...

[StevanWhite]

As to priority: it is your project of course. However, this issue is the one that fills my screen with error messages.

If you could provide the table type that is involved here, and which table seems to be "empty", I could look at the spec. Where exactly in the code is this happening?

For all I know, this is a FontForge bug. On the other hand, maybe I am missing something, and setting something wrong in the font. Let me know!

[HinTak]

Re-reading what I last wrote, I think I was slightly mistaken - what I noticed is that the valid anchors are all contiguous - so I assume the invalid ones are in the middle(and overlapping). But overlapping does not make invalid anchors - it makes anchors which are the same as next (and valid).

It is, on the other hand, possible that ttx is doing silent error handling - one way to find out is to get it to build the gpos table again, and see if its round-trip output is the same as the original.

The spec is not clear about whether anchors could be empty, but it is full of cross-referencing so some anchors are likely meaningless (and not used); it is possible that fontforge is filling those with (harmless) garbage. Still, I need to know what those invalid/empty anchors are, since the valid ones are tightly-packed.

Since this looks like it will take more than a few days, but I could probably get 2.1.5 out in less than that (people been asking for a new build to fix issue with unsigned binary on Mac os x for a while), I am inclined to spend time doing the release, then come back to this and hope to do this for 2.1.6 .

[Jongware]

It is not an error in the font. Inspecting lookup list 40 in your FreeSans – a mkmk lookup –, you'll find it starts with these class definitions:

glyph: gid1421
    class 0 : ( --,-- )
    class 1 : ( -108 836 )
    class 2 : ( --,-- )
glyph: gid1422
    class 0 : ( --,-- )
    class 1 : ( 44 640 )
    class 2 : ( --,-- )
glyph: gid1477
    class 0 : ( --,-- )
    class 1 : ( -11 700 )
    class 2 : ( --,-- )

where the --,-- entries are empty, that is, the corresponding value in Mark1ArrayOffset is not a value "from beginning of MarkMarkPos subtable" but 0.

DTL OTMaster Light shows the values as (0,0); ttx lists them (slightly more explicit) as

<Mark2Anchor index="0" empty="1"/>

I cannot find any comment in Microsoft's GPOS documentation mentioning this is allowed for mkmk, but for similar lists in other lookup types it is said to be possible. It should probably be added to the paragraph starting with

A Mark2Record declares one Anchor table for each mark class ...

just like it is at the end of the preceding table for Lookup Type 5:

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

(I cannot tell why FontValidator states the AnchorFormat is 241, because if you inspect what value it (erroneously) reads, it would be 242, the fifth Mark1Array offset value.)

[HinTak]

Thanks for the info. I'll try to find some time to look at this after 2.1.5 .

[bobh0303]

I can confirm that in mark-to-base lookups, if a base glyph does not have an anchor for a particular mark class, then FontVal generates E4100 with a bogus AnchorFormat value.

(and that this bogus error message helped me detect the missing anchor! But that isn't a reason for FontVal to emit this error ;-) )

[HinTak]

I am pretty sure that this is a bug in the sense it was not complete, because back in 2003/2007/2009 nobody uses these so the Microsoft folk didn't put in the correct code in :-). Unfortunately the GPOS part of spec is the hardest to read and understand, as evident in recent exchanges in the opentype list :-( . I'll try to look at this at some point in time.