8000 [feaLib] name lexing is too permissive · Issue #3782 · fonttools/fonttools · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[feaLib] name lexing is too permissive #3782

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
cmyr opened this issue Feb 26, 2025 · 6 comments
Open

[feaLib] name lexing is too permissive #3782

cmyr opened this issue Feb 26, 2025 · 6 comments

Comments

@cmyr
Copy link
Contributor
cmyr commented Feb 26, 2025

From the spec:

A glyph name may be up to 63 characters in length, must be entirely comprised of characters from the following set:

ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
0123456789
.  # period
_  # underscore

and must not start with a digit or period. The only exception is the special character “.notdef”.

“twocents”, “a1”, and “_” are valid glyph names. “2cents” and “.twocents” are “not.

However it looks like feaLib will accept any glyph beginning with .. I noticed this because there are a few real fonts that seem to be using .null as a glyph name in their feature files, (see e.g. Triodion-Regular.ufo.)

Is this intentional, or an oversight? I could maybe imagine there being a reason to special case .null, but I don't think it makes sense to support this arbitrarily, and I would prefer to just match the spec unless there's a compelling reason..
@anthrotype
Copy link
Member

even the FEA spec says

There are two different contexts for glyph naming: final production names and development names.

the rule you quoted is for final production names. development names need not be so restrictive. E.g. Glyphs.app uses hyphens everywhere for script suffixes even though technically that's not valid PS name (but we strip those at the end)

@anthrotype
Copy link
Member

yeah it's true that it says

none of these characters are allowed at the start of a glyph name.

but this seems more like an implementation detail than a strict valid requirement, does it not?

@khaledhosny
Copy link
Collaborator

but this seems more like an implementation detail than a strict valid requirement, does it not?

Indeed. I don’t see why we would need to restrict glyph names in ways that are not actually needed.

@jenskutilek
Copy link
Collaborator

I think the .null glyph name was assigned by FontLab Studio 5, so it may be frequent in older font data.

@cmyr
Copy link
Contributor Author
cmyr commented Feb 26, 2025

yeah it's true that it says

none of these characters are allowed at the start of a glyph name.

but this seems more like an implementation detail than a strict valid requirement, does it not?

This doesn't really matter. Any language syntax contains arbitrary decisions. The reason that one should err strongly on following the specification is to avoid splintering an ecosystem, where there are multiple separate and non-documented syntax deviations, and you can no longer easily take code written for one compiler and use it somewhere else.

For a concrete example: I have a tool that will take a snippet of FEA and compile it with feaLib, afdko, and fea-rs. This is a great way to figure out how to handle various edge cases, or to figure out what should be expected in a given situation, but it becomes less helpful when the FEA in question only compiles with feaLib.

This is not to say there can't be good reasons to support something that isn't documented, only that the justification should be strong (for instance that the syntax in question has been widely used and exists in a bunch of existing fonts)

@khaledhosny
Copy link
Collaborator

Feature files are used in conjunction with other file formats, being unnecessarily restrictive about glyph names means potentially glyph name that can be represented in these formats will cause errors when used in features files. If we don’t need that restriction, why make peoples lives harder? Again. one of the reasons we have feaLib in first place it to not be too constricted by AFDKO’s (then) aging C implementation.

If someone compiling a source that that feaLib accepts and fea-rs does not and the spec allows fea-rs to not accept it, then fea-rs has the right to flag it as source error and move on. It has no obligation to follow feaLib route.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@khaledhosny @jenskutilek @cmyr @anthrotype
0