Hyphens in glyph names are illegal

Glyphs uses -ar and -cy in glyph names for Arabic and Cyrillic. But the hyphen is used as range indicator in FDK, making fonts with hyphenated glyph names not work in FontLab. I’d like to use cross-app-compatible friendly glyph names, unfortunately hyphens can’t be used…

You can employ your own naming scheme:

I suggest to draw in Glyphs, export to TTF (that is what I suspect you need in the end to do the TT instructions) and import the TTF into FLS. The exported font will not contain any hyphen in names.

I would also welcome no hyphens in glyph names.
Hyphens are an issue when UFOs are exported with “friendly” glyph names, and have to be processed in other applications.

no TT, want to use Glyphs for more efficient design of Arabic and Hebrew, without having to use Volt in the design process. Being Dutch, I know that I can roll my own, but I’d prefer cross app friendly names and be able to use your automation efforts. And Adam instructed me to complain here instead of at FontLb about the hyphens. Great forum by the way :slight_smile:

The hyphen it really handy to distinguish letters of different scripts. There are some scripts that can work with short script suffixes (a for arabic, hb for hebrew, d or dv for devanagari) but I need a system than works with a lot more scripts. That requires much longer names. If you need to make ligature of those it gets really long and difficult to read: e.g. lepchaBa_lepchaOoVowel. Compare that to ba_ooVowel-lepcha. I added the script to the end and only add it once per ligature. To still being able to process the names by code (to generate Feature code), I need to have a separator glyph. The specs only allow periods and underscores. Both already have a meaning. So I needed to go out of the spec and looked for a glyph that would make the most sense and add mechanisms that generates production names when writing final fonts.

That mechanism is the basis for support for the non latin support in Glyphs so it is not going away. So we need to find ways around the append problems.

1 Like

What issues do you have? As fare as I know, tools like MetricsMachine has not problems with the hyphens. And if you need to export the fonts, you need production names anyway then you should export the files with production names. If you like to use a manually makeOTF workflow, you could borrow the makeOTF version that ships with Glyphs. How to get to it, you can find out in the generateFont.command file in the fonts folders in temp folder. ~/Library/Application Support/Glyphs/Temp/FontName-Regular/generateFont.command. That folder contains some resources that you might reuse for other means.

Each glyph should have 2 names, production name and (optional) friendly name. When friendly name is empty, it equals production name. Proposed that to FontLab guys some years ago…

This is how it is done. I do it the other way around (if production name is empty the nice name will be used on export, mostly aglfn names).

I asked Tal to add friendly glyph name to UFO.

To add a extra name field is only one part of the problem. You need to take care of the OT features, too. You could generate a glyphOrder file that does the translation.

I thought you take care of the OT features :smile:
The app must know production names that compile, without hyphens. I don’t want to do custom translations no more, but I love your optional friendly name with fewer restrictions.

The problem is that the hyphen stands for a range of letters in OT feature file syntax, e.g.
@smallcaps = [ A.sc - Z.sc ];

Adobe’s friendly names don’t include hyphens – OT features are also written in friendly notation. makeotf chokes when encountering a hyphenated glyph name; simply because it is not expected:

NOTE: The PostScript glyph name must be no longer than 31 characters, include only uppercase or lowercase English letters, European digits, the period or the underscore, i.e. from the set [A-Za-z0-9_.] and should start with a letter, except the special glyph name “.notdef” which starts with a period.
(from https://www.microsoft.com/typography/otspec/recom.htm)

The result: Lots of post-processing.
Using a makeotf that ships with Glyphs sounds like a hack to me.

Let’s be honest, this syntax is hardly ever used because it is bound to a lot of restrictions. Again, the hyphenation is not the way the glyphs are exported into the OTF. The hyphens are removed.

And again, if you feel uncomfortable with the suggested naming scheme, you are not forced to use it. You can use your own.

Why? What do you need to post-process?

If you stick to the naming scheme, you have the added advantage of automatic OT features. Naturally, the app cannot do that if you employ a custom naming scheme.

makeotfGlyphs does that.

I think there is a difference between requirements of the final font format and what we use during design. (You also could argue that PostScript fonts don’t support components and thous we should not use them.)

makeOTF is a tool we use to build our font. I think the tool should follow our needs and not define what we can do.

I am not sure whether this helps the discussion, but I employ hyphens in the production names for the glyphs in Source Han Sans / Noto Sans CJK, which include 65,535 glyphs (the architectural limit), and because these are CID-keyed fonts, the names go away during pre-processing of the features. Of the 65,535 glyphs in these two joined-at-the-hip-and differ-only-by-name fonts, 49,519 of the production names use hyphens.

The raw (in the sense that production names are specified) ‘calt’ GSUB feature definition looks like the following (note how the hyphens that are used to specify a range have an intentional “space” on its left, which allows the pre-processor to distinguish a hyphen used in a production glyph name versus a one to specify a range):

feature calt {
  substitute [uniAC00 -uniD7A3 uni1100uni1161uni11F0 -uni1159uni1175uni11D9 uni1160.vjmo01 -uniD7FB.tjmo04] uni0020' [uniAC00 -uniD7A3 uni1100uni1161uni11F0 -uni1159uni1175uni11D9 uni1100.ljmo01 -uniA97C.ljmo06] by uni0020-KR;
} calt;

The processed ‘calt’ GSUB feature looks like this:

feature calt {
  substitute [\47566-\58737 \63157-\63656 \64407-\65144] \1' [\47566-\58737 \63\
157-\63656 \63657-\64406] by \62995;
} calt;
1 Like