What could make a family name change to a style name in menus?

[EbenSorkin]

I was generating without this issue for a while but then for reasons I can't seem to trace Merriweather becomes Merriweather Narrow Light in menus on Axis Praxis, Samsa etc.

This name I see now is the name of the first master listed in the series in the Glyphs file. It is also not an instance name).

talking to @thundernixon he speculated that Fontmake might be looking for a regular master. This is a good thoeory except that there wasn't one before the problems started. Could fontmake have changed?

I could add a regular Master if that's what Fontmake expects but that would make the VF bigger. If that is a way - Is there another way?

Also, I speculated that adding a preferred family name to instances might have caused the problem because that was new to the file but removing that from instances didn't change anything.

I also added a font level custom parameter in Glyphs ( Variable Font Family Name ) but that also had no impact on the problem.

[EbenSorkin]

Additional note: Samsa calls this the Full name

[sursly]

I have been running into the same issue. Adding a Regular master solves it, but yeah, that isn't something I want to do either.

[sursly]

Actually, in Glyphs if I rename the first master from Thin to Regular, it also works properly (but again, isn't ideal).

[EbenSorkin]

That's what I ended up doing too a few min before you wrote. That's funny.

Yeah - I did that because My design space doesn't contain a regular it goes from black to thin and from small opsz to display and from semi condensed to semi-wide. With all those masters I didn't want another one if I could help it but this solution is very much a hack I feel.

It would be better to be able to take the fullname data from a more conventional place. Why a master? Why not the family name?

[EbenSorkin]

Also - Thanks to Mirko for solving this one for me!

[arrowtype]

Nice! What was the solution?

[EbenSorkin]

What Sursley ( Tyler ) said - but there is a bit more. Here it is a bit more step by step and with more attitude than I'm actually entitled to but...

1. You take one of the your masters and name it regular. Maybe it was "Thin" before because it is thin for goodness sake. But now it's halloween or some such similar thing because Fontmake - so we rename it "Regular". Seemingly any of them will do.

2. In the Info panel in Glyphs you go to first tab ( font ) and you make a Custom Parameter called "Variable Font Origin". You name this "Regular". That's elidable or something - so boom! No more unwanted style name creeping in.

3. And for the record I am not 100% sure this step is required but it may be. Also add in that same first tab ( font ) a Custom Parameter called "Variable Font Family Name". Add your family name there.

Then run fontmake and it works. Hacktastic - no?

[EbenSorkin]

But it all seriousness I do get how this could happen. It makes sense. Normal/Typical master sets have a Regular. But I also don't think it should stay like this.

[sursly]

I mean, I think this hack works even without steps 2 and 3 above (at least, it did for me).
Weird, but I'll take it (for now) 👍

[EbenSorkin]

@sursly That's good to know. I'll try it.

[arrowtype]

Okay, yes I do feel like your fixing steps were a little saltier than they needed to be, but I understand how it can feel very frustrating in the moment if software doesn’t do everything you want it to do. It is also pretty frustrating that there isn’t super-clear guidance on font naming, and that an area which seems so simple is actually very complex and easy to mess up.

However, it’s also good to remember that software developers are people too, so being salty will only dissuade people from being helpful. More importantly, it’s good to remember that issues like this might be due to an important additional perspective that the developers might have. What if FontMake is working exactly as it needs to?

You cite this as the problem you are trying to solve:

Merriweather becomes Merriweather Narrow Light in menus on Axis Praxis, Samsa etc

But, it is possible that:

1. This isn’t a problem in the font, but rather in how these tools are parsing the font. If you use TTX to inspect the name tables of these fonts, it’s clear that these web tools are looking at name ID 1, when they should instead be checking first for name ID 16.
2. Your actual users aren’t going to be using these tools, anyway. What apps are actually important to support? MacOS handles the previous version of Merriweather just fine, looking at name ID 16 for what it puts in the menu.
3. It may be (and I think it is) important for Name ID 1 to be the name of the base instance, e.g. Merriweather Light Narrow, so that the font works in a sensible way in old software that can’t parse variable fonts. Consider: with the hack, it is likely that if a user downloads this and tries to use it on a computer that is a couple years old (and can’t handle variable fonts), when they select Merriweather in MS Word, they will see the narrowest, lightest version of the font, but they will think that this is the “Regular.” This will leave them confused, and they will probably revert to a different font that is more what they expect.

The variable fonts I have worked on also appear in similar ways in Axis-Praxis & Wakamai.

But the important thing is whether they follow the OpenType spec, which will give them the best chance of actually working in real apps that end users use. For example, these fonts all look fine in the menus of Keynote, TextEdit, etc.

Testing your latest variable font, I’m not convinced that it has been improved in this regard.

Here’s the latest Merriweather Roman VF, tested in TextEdit. When I click to apply the “Regular” instance, it instead snaps to the “Big Light” Master:

This could be an issue in macOS rather than in the font. However, when I test the same thing with an earlier version of Merriweather VF, instance selection works more as I expect it to:

I’m not exactly positive why macOS selects “Big Light” in the latest VF when I try to select “Regular.” Taking a quick look at the Glyphs source, it seems that you gave the “Regular” name to the master that is min opsz, min wght, default wdth – not to the master corresponding to “Big Light.” I think, however, it does indicate that the hack may not be the best approach.

[arrowtype]

This could be an issue in macOS rather than in the font. However, when I test the same thing with an earlier version of Merriweather VF, instance selection works more as I expect it to

Looking closer at this second test, I don’t actually think it is selecting the real “Regular” – it looks more like a Display opsz to me. But, looking at the source at that point, it doesn’t jump out why that would be happening, either. Font naming & results in apps are tricky. 😐 But, I do think that it still indicates that the hack may not be the best approach.

[anthrotype]

This has popped up elsewhere (undercasetype/Fraunces#202).
Let me try to recap the issue.

When fontmake builds a VF it first creates interpolatable TTF for each master then passes them to fontTools (varLib.build) to create the VF from these. FontTools takes the default (aka neutral or origin) master as the basis onto which the VF tables are added; however it does not further modify the family or style names in the VF name table; these are simply inherited from the default master. That's the way it works right now. If you can't rename your default master to match the way your VF family/style names should be, then you will have to post-process the VF name table and fix it accoridingly.

Maybe the designspace specification could be extended to define some metadata for modifying the VF family and style names. I suggest that you open an issue in fonttools, where the Designspace document spec is hosted.

[EbenSorkin]

Thanks Cosimo and Stephen!

Cosimo, Extending designspace specification sounds great especially if we can do things like specifying the content of specific name tables. Partly I think this is key because as smart as fontmake is it can't and should not be expected to anticipate everything. Partly too I think that letting people name optical sizes in evocative ways and even widths and weights in ways that are not orthodox can be a good idea from time to time. I'm thinking of Fred Smeijer's "blonde" type for weight for example. It may not be ideal core or standard practice but if a designer is willing to test and make sure the meta data works and that the alternative data fits the design intent better I think that can add real value. To be able to do this and let the process be replicable would be great.

I'll take some time and try to understand what's there in the existing spec. IDK how much I'll understand right away but I'll definitely try and begin asking about what I can't figure out.

Stephen re: saltiness - point taken.

Also I did find that Merriweather was acting as expected in the web based font testing tools but if it isn't elsewhere e.g. Keynote & Textedit then clearly that's not good at all. So clearly I need to widen the testing I'm doing and not treat the web based tests as primary indicators.

Given your test results I think in the meantime the best thing to do will be to de-hack and add a Regular master in the place that I think will be most useful to start as a user. When there is a good workaround that doesn't require that master to be there for it to work I can remove it. Anyway I hope that Dave will be happy with that because I think the alternative is to have the font be broken somewhere and I would prefer not to choose that it be either app users or web based users.

[davelab6]

Adding a master will increase the filesize, so please don't do that :)

I agree with @thundernixon that we should make fonts to the OT spec and not worry if the current releases of any software do not work against the spec. They will be updated; the fonts can be updated, of course, but they shouldn't be churned to chase implementations (especially when some implementation do work as spec'd.)

@anthrotype do you know which projects have done the post-processing you describe?

[anthrotype]

just to clarify that fontmake does not require that the default master is called "Regular". It can be anything. I simply meant that the name table of the default master is going to be inherited by the VF font, which is built upon the latter.

For .glyphs-based projects, you choose the default master by setting the Variable Font Origin custom parameter. For designspace-based projects, it is implicitly defined by its location in relation to the <axes> default values.
That's because, by definition, the neutral master is the one that is on the default value along all the axes.

[anthrotype]

do you know which projects have done the post-processing you describe?

I don't, but it should not be too hard to make a script to modify a font's name table with fontTools. As last resort there's always ttx -m to merge in an XML file.
If you try to explain to me (as succintly as possible ;) what you are trying to do, I can point you in the right direction.

[EbenSorkin]

Cosimo
• But what if the design space doesn't include a central/neutral master - and this is done to reduce file size in the VF?
• Are you aware of a ttx -m workflow I can study/adapt?

But also could we not have fontmake to take the fontname/fullname from something other than a single VF master?

Dave - In the meantime maybe ttx -m with an XML file is the way to go? Would you be OK with that? (Because Cosimo's suggest of using Variable Font Origin won't make the name of the font correct in web based menus unless I hack.)

[EbenSorkin]

Thanks too for the quick replies!

[anthrotype]

what if the design space doesn't include a central/neutral master

there is always a neutral or default master. There can't be any VF without one. Think of it as the non-variable part of your VF, what remains when you strip all the variable tables; or if you like, what an old rendering engine that only supports OpenType < 1.8 would see and use when you give it a VF.

I think you mean that you want to be able to define a custom style name for the VF that is distinct from the style name of the default master, is that correct?

[arrowtype]

there is always a neutral or default master.

Right, this is something I didn't grock at first. VFs store one set of “glyph outlines” in the glyf table, just as OT fonts did pre-variable fonts. Then, the way those points move along different axes is recorded in the gvar table. Samsa provides a very good visualization of this: the initial visual it gives is the neutral/default master, and the arrows that appear as axes are changed show the deltas from the gvar table. So, the "default" master isn't the same concept as a “Regular” style – it is simply the set of points that are in the glyf table. Users on old systems will only see this style. Users on newer systems will (typically) see this as the first style when they select a variable font without adjusting instances or axes.

Are you aware of a ttx -m workflow I can study/adapt?

A better tool for changing data in post-processing a font is TTFont, used in Python, with its functions getName() and setName(). I have created some helper functions to make these simpler to use. A good example of where I am using this is in a script to instantiate and rename Recursive fonts for code, lines 181–203.

This approach is slightly more complex up front, but allows you to be more specific and certain of the changes you are making, and is quite a bit faster as a build step than using TTX.

Cosimo‘s suggestion of using Variable Font Origin won't make the name of the font correct in web based menus unless I hack.

What web-based menus are you trying to build for? If it’s just Axis-Praxis and Wakamai Fondue, I would again say that:

1. You shouldn‘t worry about how your font names look there, as almost zero end users use those tools. Additionally, you can see in Axis-Praxis that almost all the font names in the menu are a bit odd (e.g. many include the word “Regular” when they probably shouldn’t).
2. Those tools should probably be using name 16, not name 1. If they did, you would just see the Preferred Family Name, as name 16 describes, rather than the legacy-app family name, which is basically what name 1 is.

So, to the original question of this thread: What could make a family name change to a style name in menus?

• Name 16 makes that name change in modern apps. The weird name comes from name 1, and is there for legacy apps.
• If you do edit font names, it’s useful to use TTFont for this, and it’s very important to test the results in desktop apps.
• Some (many?) implementations aren’t very good yet, but that shouldn’t dictate your font design choices (at least not too much). For an example of where I’m struggling with this, see Duplicate style names in Sketch & Keynote menus – not necessarily an issue in Recursive arrowtype/recursive#316. This is why it’s still useful to build & release static fonts for users who want to use the fonts on desktop software, where support is still catching up.

[EbenSorkin]

Cosimo Apologies, I see that I genuinely didn't make this idea clear enough. There are two issues that are being treated as one by fontmake as of now and I'm advocating that they be separate.

The issues are

1. that there has to be a default master ( clearly agreed!) and
2. that this default can/will always be designed and named in a neutral ( e.g. Regular & elidable ) way. That is not always going to be true I think.

Let me give my project as an example. In my project I started atypically with two weight masters. The reason was that the design space to be controlled was small enough that we didn't need three masters to control it well. Two would really do the job. So I have a Black and a Light master. With the expansion this has continued all the widths and optical sizes Masters are in Weight pairs with no Neutral Regular anywhere. Again, this really saves on file size. There are 12 masters now.

Applying this to my project then - I do see that a user needs a default master - a style that is shown when the VF is seen as a single style by software that doesn't understand VF. I think ideally this would be the new "Text Regular" which is an instance, not a master. But if I can't have that I would be willing to let the Text Light which is a master take on that role. It will be OK.

So far everything is fine :-) - or I think it is.

But the problem is that because that Master isn't called Regular the style name ( Text Light ) makes it into the fullname/ID 1 of the font in the name table after the font is made by Fontmake.

This ID is used by fontbakery too e.g. >>Directory name in GFonts repo structure must match NameID 1 of the regular.<< And also Windows and Office apps. So I maybe see where Stephen would say legacy.

So i am suggesting that ideally speaking it would be good if we don't take the fullname from any master and instead took it from some other part of the available data in a Glyphs file. Unfortunately I don't know what that consists of precisely. But intuitively it seems like there aught to be something. Maybe I'm wrong.

Stephen I am excited to look at and test TTFont. If it is effective maybe fontmake doesn't need to change at all.

[davelab6]

So, there is not really an issue here. The behavior @EbenSorkin originally posted about here is actually correct and expected.

So, this seems to be what I'd say about what to do about this:

- - - 8< - - -

If the nameID 1 string (and glyf table outlines) is not what you want, you can choose another master to be used instead. In GlyphsApp, do this 'implicitly' by going to Font Info, Masters (second tab), and move your preferred master to the first position in the list. Typically this is a Regular, but if you don't have a Regular master, use the closest; eg, a opsz-min wght-min such as Text Light.

Or, if you want to keep the order, then go to Font Info, Font (first tab), and add a Custom Parameter Variable Font Origin and give it the name of the master you want to be used.

You should also always set a font-level Custom Parameter, Variable Font Family Name, and add your family name there, without any style particles. Eg, Merriweather

[anthrotype]

I didn't know about this Variable Font Family Name, is that a new parameter?
What does it do? I think glyphsLib doesn't support that yet. Can you please open a feature request to glyphsLib repo with details of how that's supposed to work? thanks

[davelab6]

Looks like it was suggested in December 2018 @ https://forum.glyphsapp.com/t/separate-variable-font-family-name/10595/6 and shipped in August 2019 in 2.6.1 @ https://glyphsapp.com/blog/glyphs-2-6-1-released

[davelab6]

@EbenSorkin can this issue be closed?

[EbenSorkin]

I think so. Yes.