makeotf MarktoBase offset overflow

[tntypography]

I have a font family of 5 weights, exported from FL with the AFDKO 'make instances' script.

When compiling the fonts, I've started getting a makeotf error that did not occur previously with the same typeface:

makeotfexe [FATAL] <Nassim-Semibold> MarkToBase lookup subtable in GPOS feature 'mark' causes offset overflow.

This applies to four out of five instances - the Regular compiles just fine. Could anybody point out where the issue might be coming from?

Thanks in advance,
titus

[miguelsousa]

Hey Titus, could you provide a bit more background? If I understood correctly, the fonts used to compile but they don't anymore. What did you do to them in the meantime? Added more anchors? More kerning?
Could you also clarify what script you're using for generating the mark and mkmk features? Is it this one https://github.com/adobe-type-tools/fontlab-scripts/blob/master/Anchors/MarkFeatureGenerator.py ?

[tntypography]

Thanks for your reply Miguel and sorry for being unclear.

The source is a MM .vfb from which I create instances with the FDK tool 'InstanceGenerator.py'. I've added additional anchors in additional glyphs, as well as modified the kerning - note that the latter works fine though, there are only issues if I include the mark.fea file. It's difficult to track which changes might have caused the problem, as I was testing only the Regular intermittently, without ever running into the problem I did now with the other instances.

I've also tried using the script you referenced directly, but I believe the instance generator uses the same modules for the creation of mark and kern features.

As far as I can see, the mark features of the 5 instances all look very similar and not conspicuous. They all have similar sizes too: around 70kb.

[miguelsousa]

Right, the InstanceGenerator.py you're using will call the same Python module to generate the mark features.

The reason why I mentioned the kerning was because it's a GPOS feature, and since the overflow is happening in a GPOS lookup the kerning data could be playing an indirect role in the situation. Tell me, if you comment out the kerning, does the font compile?

I don't remember ever running into this kind of overflow. The mark feature lookups may have to be rearranged or broken up to avoid the overflow. I've had to deal with kern feature overflows many times, and the solution there is sorting the class kerning pos adjustments by script, and then insert subtable breaks between them. I'm not sure if makeotf allows the insertion of subtable breaks in between mark or mkmk lookups. You may have to email me one of the fonts that doesn't compile so I can have a look and try out a few things.

[tntypography]

Your hunch was spot-on: when the kern feature is commented out, all compiles fine. I'll reply to you by email and send the files.

[tntypography]

Update: this issue is solved - the table overflow in the mark feature was caused by upstream overflow in the kern feature.

[miguelsousa]

Cool 👍