Things fea can't do: delete a glyph

[simoncozens]

In my workshop I've been telling people "You can't delete a glyph using a substitution rule". The OT spec says as much: "A Multiple Substitution (MultipleSubst) subtable replaces a single glyph with more than one glyph". But... you can, Uniscribe, Harfbuzz and CoreText all support it, and Arial Unicode relies on the fact in its Devanagari implementation.

So it would be nice if there were syntax for it.

[khaledhosny]

A possible syntax might be sub foo by <NULL>;.

[simoncozens]

In the workshop I suggested sub a by;

[khaledhosny]

In the workshop I suggested sub a by;

That was the first to come on my mind, but it feels like a typo. <NULL> is used in several places already to mean nothing to see here, move on.

[anthrotype]

yes, that looks like a typo to me, I prefer Khaled's proposal to use <NULL>.

[simoncozens]

Ok, I’ll work on a patch.

[josh-hadley]

Has anyone proposed a spec change for this yet? It would be nice to have the spec reflect reality and avoid having to explain why AFDKO supports something that is expressly prohibited (even if it is widely supported in implementations).

[mbutterick]

This proposal will break every tool that parses fea files.

[alerque]

@mbutterick No. It will mean old tooling that doesn't get updated won't be interoperable with tooling that does on projects that use this as a feature. It won't automatically break old tools across the board or even reduce interoperability with new tools that don't happen to use the new feature.

[mbutterick]

This is my last comment. Your point is true in the sense of concrete instances. But it is not true in the sense of abstract implementations, which is how tools interoperate. As a software author, I read a specification not just to learn what can happen but also what can never happen (and write tests accordingly). This is why, say, Unified Font Object is versioned: so that tool authors can make stable claims about their code.

[simoncozens]

The AFDKO spec is also versioned.

[moyogo]

Deleting a glyph sounds like the kind of thing that one would want to happen in a certain context. This case is supported.
If you want a feature that just deletes a glyph, there are ways to do it too but new syntax would be clearer.

[simoncozens]

Interestingly, the feature grammar already provided explicitly for "sub X by NULL;", creating a substitution lookup with null replacement. I've just added a little bit of logic to make that pass validation and emit a font. I'm going to leave it there for now to see what we think about NULL versus <NULL>.

[khaledhosny]

NULL is a valid glyph name, so unless it is already a reserved word it would be a breaking change (keywords can be escaped, but it would still be a breaking change).

[khaledhosny]

Ignore me, there is no change to the grammar whatsoever so there are no breaking changes here.

[simoncozens]

Yeah, NULL is marked as a keyword and the grammar has actually accepted it in substitution rules since forever.

[josh-hadley]

Has anyone proposed a spec change for this yet?

Looks like this has been proposed at MicrosoftDocs/typography-issues#673, thanks @simoncozens for continuing this effort!

[simoncozens]

Bump.

We're waiting a decision on this: sub X by NULL; (which is already supported by the grammar and is easy to implement) versus sub X by <NULL>; (which may be less confusable, but kind of looks like a value record).

[punchcutter]

How about something like sub X by NUL; to differentiate? Or NIL. Or if we go with NULL maybe it would be good to clarify it like the other uses so instead of just <NULL> it could be <glyph NULL> to line up with the existing <device NULL> and <anchor NULL>?

[simoncozens]

Definitely not NUL or NIL as they could be glyph names; I quite like <glyph NULL>.

But really, “by NULL” already has syntax so we could just assign that syntax the obvious semantics...

[punchcutter]

But NULL is also a glyph name and when there's a glyph named NULL like there are in hundreds or thousands of existing fonts we can't automatically know which substitution is meant. Oh...I guess you mean since it's required to escape it as a name already?

[punchcutter]

I'm totally fine with NULL so if you have a PR let's just go for it.

[simoncozens]

Yeah, I mean NULL is already a special case in the grammar. Anyhow PR #1251 should do the job.

[khaledhosny]

The spec need to mention this somewhere as well.

[simoncozens]

Yes, working on spec change and fontTools implementation now.