A tool for skeleton + marks Arabic font workflows — would love your feedback

Thanks Simon, this is a really useful point, and I think you're right that I didn't explain the "why" well enough.

You're absolutely right that any competent font editor or compiler handles isol/init/medi/fina, mark/mkmk, and curs automatically. And for a conventional font — where each encoded letter has its own glyph — that's exactly the right thing to do, and FFB would be pointless.

But the workflow FFB is built for is different: decomposed fonts. In this model, the encoded letters stay empty, and at runtime GSUB replaces them with a dotless skeleton plus separate mark glyphs. The point is to avoid the glyph explosion you get when every dotted letter, every positional form, and every diacritic combination needs its own glyph.

The problem is that the moment you go decomposed, the font editor's automatic features stop working — because there's nothing to attach init/medi/fina to. The editor sees an empty glyph and has no idea that this glyph should actually decompose into skeleton + marks. So the feature code has to be generated from somewhere else, and that somewhere is the decomposition table.

I work in FontLab 8, and I should say upfront that I have no experience with Glyphs — maybe the story is different there. Here's what I've found:

• FontLab's component feature lets you define a glyph's parts and their anchors, and then it composes a single composite glyph from those anchors. So it's doing essentially what FFB does — but it produces one glyph, not a feature rule. FFB does the same thing, but instead of building a glyph, it builds a feature rule. That's the opposite of decomposition, where what you need at the end is a substitution rule, not a merged glyph. Is there a way for FontLab — or any other font editor — to do this instead?

• I have never been able to get mark/mkmk to work correctly for Arabic fonts in FontLab. Whatever it generates, it doesn't work.

• FontLab generates isol/init/medi/fina using Lookup Type 1 (single substitution), but for decomposed fonts you need Lookup Type 2 (multiple substitution) — because the output is not one glyph, it's a sequence of glyphs.

• Many Arabic type designers I've spoken to do their glyph shapes in FontLab but write the features manually and painfully in VOLT instead. That's the workflow I'm trying to replace.

I haven't found any documentation showing how to make FontLab produce the correct lookup type for a decomposed Arabic font — or how to set up Arabic kerning in FontLab, or how GPOS features are supposed to be built there. There are checkboxes for the last one, but the result isn't what you'd expect, and what gets generated doesn't actually work. Maybe I'm missing something. Do you know of a way to make FontLab do this — to add a feature rule instead of building a glyph? Maybe there's a path I don't know about. If you know of a way, or a document that explains it, I'd be genuinely grateful.

That's what FFB does: it reads a decomposition table and writes the fea code that the editor would have written if the font weren't decomposed. It's not replacing the compiler — it's feeding it.

You're also right that anchor syncing is redundant in a normal workflow. But in the decomposed workflow, the anchors live on the skeleton glyphs, and the generated feature code needs to reference those anchors by name. When the designer moves an anchor in the UFO, that change has to propagate into the .fea before compiling. Without that, the two drift apart. It also lets us use kerning to make dots and diacritics fluid — so they pick the best position relative to their neighboring glyphs.

Thanks again for taking the time. I'd genuinely love to hear your thoughts on whether this is a real problem worth solving, or whether I'm mistaken and just reinventing the wheel.