FAIL: Check variable font instances have correct names

[kosbarts]

Observed behaviour

I am testing a variable font with four axes. There are combinations of the unregistered and registered axes in the instance naming, for obvious reasons, i.e. Commissioner-Thin, Commissioner-FlairThin, Commissioner-LoudThin, etc.

When fontbaking the vf, I get the following FAIL:
`

🔥 FAIL: Check variable font instances have correct names

• com.google.fonts/check/varfont_instance_names

• 🔥 FAIL Instance name "Flair Thin" is incorrect. It should be "Thin" [code: bad-name]

• 🔥 FAIL Instance name "Flair ExtraLight" is incorrect. It should be "ExtraLight" [code: bad-name]

• 🔥 FAIL Instance name "Flair Light" is incorrect. It should be "Light" [code: bad-name]

• 🔥 FAIL Instance name "Flair Regular" is incorrect. It should be "Regular" [code: bad-name]

• 🔥 FAIL Instance name "Flair Medium" is incorrect. It should be "Medium" [code: bad-name]

• 🔥 FAIL Instance name "Flair SemiBold" is incorrect. It should be "SemiBold" [code: bad-name]

• 🔥 FAIL Instance name "Flair Bold" is incorrect. It should be "Bold" [code: bad-name]

• 🔥 FAIL Instance name "Flair ExtraBold" is incorrect. It should be "ExtraBold" [code: bad-name]

• 🔥 FAIL Instance name "Flair Black" is incorrect. It should be "Black" [code: bad-name]

• 🔥 FAIL Instance name "Flair Thin Italic" is incorrect. It should be "Thin Italic" [code: bad-name]

• 🔥 FAIL Instance name "Flair ExtraLight Italic" is incorrect. It should be "ExtraLight Italic" [code: bad-name]

• 🔥 FAIL Instance name "Flair Light Italic" is incorrect. It should be "Light Italic" [code: bad-name]

• 🔥 FAIL Instance name "Flair Italic" is incorrect. It should be "Italic" [code: bad-name]

• 🔥 FAIL Instance name "Flair Medium Italic" is incorrect. It should be "Medium Italic" [code: bad-name]

• 🔥 FAIL Instance name "Flair SemiBold Italic" is incorrect. It should be "SemiBold Italic" [code: bad-name]

• 🔥 FAIL Instance name "Flair Bold Italic" is incorrect. It should be "Bold Italic" [code: bad-name]

• 🔥 FAIL Instance name "Flair ExtraBold Italic" is incorrect. It should be "ExtraBold Italic" [code: bad-name]

• 🔥 FAIL Instance name "Flair Black Italic" is incorrect. It should be "Black Italic" [code: bad-name]

• 🔥 FAIL Instance name "Loud Thin" is incorrect. It should be "Thin" [code: bad-name]

• 🔥 FAIL Instance name "Loud ExtraLight" is incorrect. It should be "ExtraLight" [code: bad-name]

• 🔥 FAIL Instance name "Loud Light" is incorrect. It should be "Light" [code: bad-name]

• 🔥 FAIL Instance name "Loud Regular" is incorrect. It should be "Regular" [code: bad-name]

• 🔥 FAIL Instance name "Loud Medium" is incorrect. It should be "Medium" [code: bad-name]

• 🔥 FAIL Instance name "Loud SemiBold" is incorrect. It should be "SemiBold" [code: bad-name]

• 🔥 FAIL Instance name "Loud Bold" is incorrect. It should be "Bold" [code: bad-name]

• 🔥 FAIL Instance name "Loud ExtraBold" is incorrect. It should be "ExtraBold" [code: bad-name]

• 🔥 FAIL Instance name "Loud Black" is incorrect. It should be "Black" [code: bad-name]

• 🔥 FAIL Instance name "Loud Thin Italic" is incorrect. It should be "Thin Italic" [code: bad-name]

• 🔥 FAIL Instance name "Loud ExtraLight Italic" is incorrect. It should be "ExtraLight Italic" [code: bad-name]

• 🔥 FAIL Instance name "Loud Light Italic" is incorrect. It should be "Light Italic" [code: bad-name]

• 🔥 FAIL Instance name "Loud Italic" is incorrect. It should be "Italic" [code: bad-name]

• 🔥 FAIL Instance name "Loud Medium Italic" is incorrect. It should be "Medium Italic" [code: bad-name]

• 🔥 FAIL Instance name "Loud SemiBold Italic" is incorrect. It should be "SemiBold Italic" [code: bad-name]

• 🔥 FAIL Instance name "Loud Bold Italic" is incorrect. It should be "Bold Italic" [code: bad-name]

• 🔥 FAIL Instance name "Loud ExtraBold Italic" is incorrect. It should be "ExtraBold Italic" [code: bad-name]

• 🔥 FAIL Instance name "Loud Black Italic" is incorrect. It should be "Black Italic" [code: bad-name]

• 🔥 FAIL This will cause problems with some of the Google Fonts systems that look up fonts by their style names. This must be fixed! [code: bad-instance-names]`

Expected behaviour

Is there some clear guidelines for how instances in families with multiple axes should be named?

Resources and exact process needed to replicate

variable file
bakery report
source file

[felipesanches]

fontbakery inference of familyname/stylename is based on splitting on the dash character. That's why it thinks the style is "Flair Thin" instead of "Thin"

[felipesanches]

well... Flair and Loud should be part of the family name. Styles should remain a selection of the 18 canonical stylenames.

[kosbarts]

Hi @felipesanches and thanks for the answer, but I am not quite sure what it is you are suggesting.

The variable font has 18*3=54 instances. Yet it has one family name.

Should I split it in 3 Variable fonts so that the naming is accepted?
Do you have an example of what you are talking about?

[felipesanches]

yes, that's right! A total of 3 families, each with 18 styles.

[kosbarts]

@davelab6 suggested to look into Recursive for a similar multi-axes instance family. I ran it through fontbakery and it reports the same FAIL.

[kosbarts]

Doesn't splitting it into 3 families void the whole concept of it being a variable font?

[felipesanches]

@thundernixon, can you help us here?

[weiweihuanghuang]

Having the same problem with width axis

[arialcrime]

This is also (still) hampering work on Fraunces.

From what I can gather (and what @m4rc1e pointed out here), the problem seems to be the instance parser that is not able to deal with anything that is not width, weight, and italic.

[thundernixon]

Sorry to have missed this issue for so long. Yes, my theory is that a variable font project should have a single, primary variable font if it’s possible to, in order to deliver maximum savings & flexibility to end users. Some projects would have separate variable fonts that aren't compatible, like many type families that have one roman VF and one italic VF.

In Recursive, the static fonts are given four separate families names each with 16 instances (8 weights + italics), to work easily in software like Keynote, Figma, InDesign, etc:

• Recursive Mono Casual Static
• Recursive Mono Linear Static
• Recursive Sans Casual Static
• Recursive Sans Linear Static

However, the variable font family has 64 total instances, and these have names like Mono Casual Bold Italic, etc.

This separation of families also makes it easier to install all 5 families (4 static, 1 variable) but keep them separately available in font menus.

I can’t dedicate time to fixing this issue in the immediate future, as I need to work through open priorities in Recursive. For now, I suggest just making Fraunces work as well as possible in as many places as possible, and trusting that this issue will be resolved eventually.

[m4rc1e]

Fontbakery's name parser was updated a while ago to accept non-registered axes. For Commisioner, Fontbakery now produces:

* WARN: Instance "Flair Thin": contains the following unparsable tokens "['Flair']"
    * WARN: Instance "Flair Thin": cannot determine instance name due to unparsable tokens
    * WARN: Instance "Flair ExtraLight": contains the following unparsable tokens "['Flair']"
...
    * WARN: Check has either failed or produced a warning. See our wip spec for further info https://gist.github.com/m4rc1e/8f4c4498519e8a36cd54e16a004275cb

It's no longer a fail but a warn.

I still don't know if non-registered axis names should appear before or after registered axis? e.g

Before:
Flair ExtraLight Italic

After:
ExtraLight Italic Flair

For filenames we ask for non-registered to appear first.

@davelab6 ^

If we decide to have non-registered to appear first, then Commisioner's instance names are correct.

[thundernixon]

if non-registered axis names should appear before or after registered axis

In the case of this family, it looks to me like "Flair" and "Loud" are sort of like subfamilies, and should therefore go before weight and italic names. In general, also, I think that would tend to hold true.

However, it sounds like you might be seeking out a rule here, in which case I would be cautious about establishing any hard rules. It seems unlikely that every non-registered axis descriptor should necessarily be named before registered axis descriptor. I might be making this up, but I think that names have their current order as a way of describing font attributes in the way that people commonly see their order on the "decision tree" a designer might go through in selecting the correct style. So, presumably, someone could come up with a non-registered axis that would change names after the registered names.

In the example of Recursive, I don't but could have instances like "mono casual bold oblique," which would be like the "mono casual bold italic" but with the non-registered CRSV (cursive) axis turned to 0. So, this would affect the style name following registered descriptors. Presumably, other families might come up with other non-registered axes that would influence registered axes in ways that would be further down in the decision tree for the end user.

[davelab6]

Related discussion in google/fonts#2702

[ctrlcctrlv]

Is this really a good check?

I have this failure:

🔥 FAIL: Check variable font instances have correct names (com.google.fonts/check/varfont_instance_names)

🔥 FAIL Following instances are not supported:

• Narrow Regular
• Narrow Medium
• Narrow SemiBold
• Narrow Bold
• Narrow ExtraBold
• Narrow Black
• Condensed Regular
• Condensed Medium
• Condensed SemiBold
• Condensed Bold
• Condensed ExtraBold
• Condensed Black

Further info can be found in our spec https://github.com/googlefonts/gf-docs/tree/main/Spec#fvar-instances [code: bad-instance-names]

FontBakery can't be right here—can it?

Cf. indestructible-type/Besley#24 (comment)

[m4rc1e]

We've deliberately limited the fvar instances so we can only have Thin-Black and ThinItalic-BlackItalic, https://googlefonts.github.io/gf-guide/variable.html#fvar-instances.

[ctrlcctrlv]

I guess that leads me to ask, "what should I do?"

1. Remove the instances? Inkscape and other common free applications rely on them exclusively. (For my purposes I don't much care what any proprietary program does.)
2. Set the family name differently instead? That's how it was before, it was super broken in Pango and should have been I reckon. GNOME's font viewer also showed them repeating but did not prepend family names in its Info section.
3. Split the multi-axis font into single-axis? That's not a good solution.

Sorry out of ideas 😦

[m4rc1e]

We'd like developers to have decent STAT tables instead. If we allowed any fvar instances, many fonts would have hundreds of em which makes it difficult to select an individual style. A better approach is to have a STAT table with AxisValues for each individual axis.

[ctrlcctrlv]

I see. So you think applications ought to support STAT and not rely on fvar, essentially. Well, of course we write a proper STAT, and I tend to agree in general. But I can't drop these fvar instances so am just going to ignore this failure as not actionable at this time, until Pango/HarfBuzz (I really don't know which is at fault here or if it's even Inkscape itself or perhaps Fontconfig, the stack is a jumble and I'm but one critter) begin to work with combined STAT values as well as they do explicit fvar instances.

[khaledhosny]

If we allowed any fvar instances, many fonts would have hundreds of em which makes it difficult to select an individual style.

How is that different from STAT, if app wants to list individual instances it would still be listing 100s of them, whether it got them from fvar or STAT.

[ctrlcctrlv]

Strongly agree that there is no real difference, and actually that fvar is superior in the fact that it allows font developers to force a certain order of style name elements, not needing to rely on the implementation of reading from STAT. I think that all that should be checked is that all of the STAT elements exist, space separated, in the fvar instance style name.

[m4rc1e]

How is that different from STAT, if app wants to list individual instances it would still be listing 100s of them, whether it got them from fvar or STAT.

We're hoping that applications won't generate instances using a cross product of the STAT AxisValues. It makes far more sense from a UX experience to have a drop down for each Axis e.g Samsa:

Roboto Flex with 13 axes

In Roboto Flex's case, if we just did a cross product, we'd have 1,368 styles. Trying to select a style from a single drop down menu which contains this many items is insane.

I understand that Application developers may go ahead and do the cross product approach anyway but I will raise an issue with them regarding this.

Our current approach to limit the fvar instances isn't set in stone either. Perhaps we're being too restrictive but what I've written above must be considered by everyone.

[ctrlcctrlv]

I actually think that the current Google Fonts fvar limitation makes a STAT cross product ending up in end user software more likely and not less likely.

Because if your application already only supports dropdowns, and you find this issue (why are STAT and fvar out of sync?), the quickest way to fix it is to do a STAT cross product.

Meanwhile, in such a big font as you've shown above, it'd legitimately make sense to cut down on the fvar instances, and no one is likely to complain about it.

[davelab6]

MF: It makes far more sense from a UX experience to have a drop down for each Axis

100%. fvar flat lists of styles are only suitable for single axis (eg wght only) families. STAT can be used to store a flat list of style names, but it ought to be used to create structured dictionary data about named styles

FB: Because if your application already only supports dropdowns,

Sure, an app could flatten the dicts into a list if they want, but that's their prerogative - and would mean they were engaged in updating their thinking about what a font family "is", which is essential for the progress in digital typography that variations as a typographic medium, in the McLuhan sense, demands.

If an app to date only supports a single style dropdown, it can't really be said to completely support variable fonts.

[ctrlcctrlv]

I agree that that STAT ought to hold structured dictionary data. Limiting fvar will assure that some font developer (perhaps even I) puts what I want to put into fvar into STAT due to this rule.

If an app to date only supports a single style dropdown, it can't really be said to completely support variable fonts.

Most free software can't be said to completely support variable fonts, indeed.

[ctrlcctrlv]

It's not like there's one combined target for free software either, unlike the Adobe suite, where they can hire one expert to implement it correctly once and then it's in Illustrator, InDesign, Photoshop, Dreamweaver. There's GIMP, Inkscape, Krita, even KolourPaint. All of these programs use incompatible toolkits (GTK+2, GTK+3, Qt5, Qt6). If I want my variable font to work reliably with free software graphics programs I must use the fvar fallback to get the info into fontconfig, or put flat data into STAT to achieve the same. Otherwise users can't select all styles.

As I'm saying, continuing to limit fvar this way will lead a font developer to sully STAT to get their font to work regardless of what ought to ought. The right thing to do remains to lift the fvar limit.

[ctrlcctrlv]

Oh, and even if a font developer doesn't sully STAT, in one or all of those programs the fastest way to get it to work is to calculate the STAT cross product even if it's not there. Most users would be happy having all the choices rather than not, and a more complex UI would be marked someday-maybe.

These are just FOSS realities, and this is why I think this issue is so emblematic of how fontbakery enforces things it ought not, which the spec does not enforce, and which are guaranteed to lead to hacks up and downstream.

I was actually asked about the Inkscape issue recently and said "given fontbakery#2742 the fastest way to fix the issue is to calculate the STAT cross-product and make all its members available in the existing list". I don't understand why this is what y'all prefer, the forced flatten on the new table because of ill-advised protections on the old.

[davelab6]

Is this really a good check?

Yes, given its scoped to the GF profile - although it IS poorly worded.

In theory, the wording can be quickly improved - but it requires someone who has a deeper understanding of what The Right Thing To Do is (which is probably only me, alas, since it requires knowledge of the gf product, and gf axis registry), and #2820 and #2824 were logged to do this, but haven't moved since...

There is also history in #2573 as well as #2702.

FontBakery can't be right here—can it?

It is right, and the smallest change I can see to make it clearer would be to change the strings from

> Check variable font instances have correct names (com.google.fonts/check/varfont_instance_names)
Check variable font named-style instances have correct names in fvar table (com.google.fonts/check/varfont_instance_names)
> Following instances are not supported:
Following fvar instances are not supported, because fvar is for legacy support, so only the 9 OS/2 named weights plus italic are a good idea to use in fvar:

[ctrlcctrlv]

The level should be lowered to warning and GF should consider it on a case by case basis whether or not the fvar instances are appropriate given what the font does. Perhaps, perhaps, it could be gated on the number of fvar instances. E.g., if there are 100+, that's a fire emoji, fine.

But I won't change my fonts to follow this wght-only fvar limitation, it makes the free software user experience tangibly worse for users of my fonts, including myself. I'm being told to break my font for the users who care enough about software freedom to only use it and won't do that.

[davelab6]

It's not like there's one combined target for free software either, unlike the Adobe suite, where they can hire one expert to implement it correctly once and then it's in Illustrator, InDesign, Photoshop, Dreamweaver.

I think you'll be sad to learn that each app has its own silo'd text engine... When I was in college in the mid 00s it would have been wild that the "one expert" you describe would be @behdad because Adobe is consolidating on harfbuzz.

There's GIMP, Inkscape, Krita, even KolourPaint. All of these programs use incompatible toolkits (GTK+2, GTK+3, Qt5, Qt6).

At least they all have used freetype and harfbuzz, for a long time. Only the latest stuff like popOS' COSMIC and its deps is starting a break away from those badboys.

If I want my variable font to work reliably with free software graphics programs I must use the fvar fallback to get the info into fontconfig, or put flat data into STAT to achieve the same. Otherwise users can't select all styles.

C'mon Fred :) Let's be real: Users can't select style in the real world when there are 1,368 items in the list. If users can't see the styles within a shiny new VF because it isn't populated in legacy, old, stale, versions of libre software, I kindly suggest you ought to explain to the devs of the app, and fontconfig - or send them a patch - to properly deal with standards-compliant and freshly, better engineered, fonts, that use a sensible STAT data structure.

As I'm saying, continuing to limit fvar this way will lead a font developer to sully STAT to get their font to work regardless of what ought to ought. The right thing to do remains to lift the fvar limit.

Not for GF, and this check is in the GF profile. If you disagree with the GF profile policies and want to make your own "FRB Profile" for your own distribution points, I'll be happy to direct @felipesanches to accept it into this ur-upstream repo - same as the Adobe Fonts Profile.

If you are not concerned with getting your font into GF, you should not run the GF profile checks. But if you choose not to bring your GF-commissioned project into compliance with GF profile, or collaborate to fix the profile, then I'll arrange for someone to fork your project and publish the fork in GF.

Oh, and even if a font developer doesn't sully STAT, in one or all of those programs the fastest way to get it to work is to calculate the STAT cross product even if it's not there. Most users would be happy having all the choices rather than not, and a more complex UI would be marked someday-maybe.

Sure, if you are seeking the fastest way to get it to work in today's stable release (which I consider by definition stale legacy software ;) then you should do you.

But if you are suggesting that as the GF policy, I think this would mean painting GF users' end-to-end total experience over the long term into a corner.

These are just FOSS realities,

The whole point of software freedom is that reality is malleable. Even Steve Jobs can tell you that. youtu.be/kYfNvmF0Bqw

and this is why I think this issue is so emblematic of how fontbakery enforces things it ought not, which the spec does not enforce,

FB has a Spec profile. This isn't in that profile.

and which are guaranteed to lead to hacks up and downstream.

Not in the GF library.

I was actually asked about the Inkscape issue recently and said "given fontbakery#2742 the fastest way to fix the issue is to calculate the STAT cross-product and make all its members available in the existing list". I don't understand why this is what y'all prefer, the forced flatten on the new table because of ill-advised protections on the old.

Inkscape developers are free to choose to implement the fastest way that is actually not good for the user experience, or to implement it in a more thoughtful way that is actually functional, or do nothing at all. That's freedom.

[davelab6]

The level should be lowered to warning and GF should consider it on a case by case basis whether or not the fvar instances are appropriate given what the font does.

I (and the onboarding team) are (or should be, feel free to escalate to me if you think not) open to requests to make improvements or exceptions to the FB GF profile; and if those make sense, those are laundered into fontbakery issues to direct changes to the GF profile.

There's an upcoming family release named "Kablammo" which is a single axis display design, where I don't expect any additional axis soon, and there are only 4 named styles. So the fvar table might make sense for this one, and then the FB GF profile check will be updated (probably with a simple allowlist, since its so rare) to pass that family.

But I remain committed to a strategy to provide a broad library of high quality libre fonts that are built as if apps properly support variations, to create widespread pressure on all typography apps to evolve proper VF support, libre and non.

Perhaps, perhaps, it could be gated on the number of fvar instances. E.g., if there are 100+, that's a fire emoji, fine.

But I won't change my fonts to follow this wght-only fvar limitation, it makes the free software user experience tangibly worse for users of my fonts, including myself. I'm being told to break my font for the users who care enough about software freedom to only use it and won't do that.

Then I guess I'll have to fork it, strip FRB off the family name, and have someone else make a GF release. That's fine with me. Is it OK with you?

[ctrlcctrlv]

Libre fonts should prioritize the needs of free software. The fvar table in Besley is only 12 entries long. That's acceptable. The one in FRBACv3 will be longer but not much longer.

Then I guess I'll have to fork it, strip FRB off the family name, and have someone else make a GF release. That's fine with me. Is it OK with you?

Of course it is, that's freedom, as you just stated. I think that this is a potential "Scenario 3" for what libre fonts are going to look like in the future, where Scenario 1 is maximum adherence to fontbakery and Scenario 2 is maximum adherence to making it work as well as possible in free software.

Scenario 3 seems to be "the widening gulf in expected norms and spec adherence leads to a permanent impasse which leads to font releases coming in twos: one version that's inferior for free software users and one version that's inferior for proprietary software users".

That sounds confusing for all users but I see no other resolution as I clearly cannot accept Scenario 1 and you clearly won't accept Scenario 2.

[felipesanches]

But I won't change my fonts to follow this wght-only fvar limitation, it makes the free software user experience tangibly worse for users of my fonts, including myself. I'm being told to break my font for the users who care enough about software freedom to only use it and won't do that.

@ctrlcctrlv, I suggest we could get together to collaborate on an issue on the Inkscape issue tracker in which we could plan how to improve the variable fonts support in Inkscape so that we can change the current scenario you described.

[felipesanches]

That sounds confusing for all users but I see no other resolution as I clearly cannot accept Scenario 1 and you clearly won't accept Scenario 2.

The good solution is to fix any broken free software (such as the current state of variable fonts in Inkscape)

[twardoch]

Actually, the libre app community is generally in a better place because its very wide use of fontconfig. AFAIU it's fontconfig that's responsible for reading various font formats and then exposing the list of families and styles in its database, which then many many apps use to read what's available.

If the app doesn't do its own font handling on a deep level but relies on fontconfig — it's gonna do what fontconfig does.

I imagine that fontconfig right now uses the fvar mamed instances and exposes them as named styles. But there's nothing to prevent the fontconfig devs to change that — either as an option or as default behavior.

fontconfig could go through each axis in the STAT table, in the axis order, and concatenate with space each entry. Or it might read the fvar entries and then SUPPLEMENT them with the fuller list of concatenated STAT entries.

Overall, STAT is a better mechanism. It doesn't force any app dev to make UIs that have per-axis particle selectors. No, an app (or a font handler like fontconfig) can "explode & concatenate" the STAT. How apps make UIs is up to them.

The fvar named instance mechanism is ancient, effectively it's a legacy mechanism — kind of like the Windows style groups thing.

App developers should use STAT, which is why Microsoft insisted on making it a mandatory table in the OT Var spec. Some people originally disagreed but I think most people would agree now that STAT is a good thing, much better than the ancient fvar mechanism.

If you want to champion STAT usage in fontconfig & other libre projects — THAT would be a great thing.

fvar named instances should fade away, and at least for now limiting them is a good idea.

[twardoch]

Ps. You can control the order of STAT axis entries and that gives you control over which particle should be prioritized (so you can have a concatenation "Bold Condensed" if STAT order is wght wdth, or "Condensed Bold" if STAT order is wdth wght).

The STAT mechanism gives everyone a consistent experience. 99% of font devs make fvar entries by concatenating the STAT particles anyway, so the fvar entries are merely bloat in the font.

[twardoch]

However, the font dev community may choose to keep fvar instances as "recommended" or "top" instances. That's OK. UIs could display them in a list on top, and then display the longer list made from STAT later (possibly in a submenu or after the user clicks ... for show more). That's up to the apps, and in the libre community, luckily, mostly up to what fontconfig will do.

But really — do we want, for a 10-axes font with 5 STAT stops each, to ship a stupid fvar list of >1 million entries? (Well, those wouldn't fit into the name table anyway :) )

[twardoch]

The fvar table is particularly badly engineered. You can easily build a TTC which has multiple subfonts that share all the tables except name, STAT and fvar. In each subfont those three tables are unique, and they all provide different naming APIs for the VF. So you could have each subfont to have a unique family name (that for example includes the width particle) and then have that styles only expose the weight particles and maybe those of some other axes.

That's a perfectly valid strategy for any multiaxis VF — but the stupid thing is that in each subfont, the unique fvar table also has to reduplicate the axis definitions. Which is very silly, and leads to potential chaos.

The fvar axes definitions and the fvar named instances are two very different things, and Apple has unfortunately put them into one table in 1996, and we inherited that.

[davelab6]

Libre fonts should prioritize the needs of free software.

Kindly, no, this is wrong, in my opinion. I don't just mean incorrect, I mean an ethically poor choice. I believe it's better for libre fonts to prioritize the needs of libre fonts users.

The software freedom movement meme (in the o.g. Dawkins sense) ought to replicate, and a highly important way to recruit minds is with constructivism-based learning about the importance and benefits of software freedom - by using libre software, and exercising the freedoms, so you get used to life with them, and notice when they are missing.

This is why making libre applications run cross platform is incredibly important - more people start using them more when they are quick and easy to install and use, and then they are creating their important data in native formats of libre apps, and start participating in the software development process without alienation; then, they seek to use more and more libre software, and, once enough of their life is happening in libre data, they can swap out the underlying OS, and eventually be rid of all proprietary software.

It is a huge mistake for libre software activists further along the path to close the gate on people further back. I know it's hard to remember how you were before you experienced software freedom since you were still a kid - it's that way for me.

The fvar table in Besley is only 12 entries long. That's acceptable. The one in FRBACv3 will be longer but not much longer.

It's only acceptable from your current position that values a short term and past-facing solution, because it relieves pressure on all - libre and non - applications to continue the status quo of terminally broken VF support. I urge you to consider a longer term and future facing position, because the future is longer than the past, and VF support is far from widespread and the default way fonts are made and used - which I consider the ultimate goal, to completely revolutionize typography.

Then I guess I'll have to fork it, strip FRB off the family name, and have someone else make a GF release. That's fine with me. Is it OK with you?

Of course it is, that's freedom, as you just stated.

Good. However, what would be better, is that you continue to engage in meeting or changing the gf specs until gf can ship your version, since we ought to be able to do more and better together :)

I think that this is a potential "Scenario 3" for what libre fonts are going to look like in the future, where Scenario 1 is maximum adherence to fontbakery and Scenario 2 is maximum adherence to making it work as well as possible in free software.

Both scenarios are, kindly, incorrect, since you assume the way libre software works is a fixed variable in the equation, but in reality it's a libre variable; and fontbakery is libre software.

Moreover, you are deeply conflating fontbakery with the gf profile, and libre fonts with Google Fonts. The gf profile isn't set in stone, and you are a participant in it's development if you wish to be.

Scenario 3 seems to be "the widening gulf in expected norms and spec adherence leads to a permanent impasse which leads to font releases coming in twos: one version that's inferior for free software users and one version that's inferior for proprietary software users".

That sounds confusing for all users but I see no other resolution as I clearly cannot accept Scenario 1 and you clearly won't accept Scenario 2.

There are many scenarios! More abundance thinking, less scarcity mindset, please :)

[davelab6]

https://typedrawers.com/discussion/comment/59495/#Comment_59495 alsl relevant by @tphinney

[ctrlcctrlv]

Google's layoffs don't portend an abundance mindset, so I'll keep assuming scarcity for the time being, which has always been the norm in free software.

There's nothing ethically wrong with my position because writing an fvar table of lengths even up to 48 is allowable by the OT spec. My fvar is not incompatible with proprietary software. I would not write an fvar longer than 48. If I was writing an fvar for a font where more than 48 named instances could exist, I would choose the 48 most important ones. No user would complain about this if the alternative were thousands, or even hundreds, of entries.

Google wants¹ fonts, not software that makes fonts and certainly not patches to improve the free software user experience of the fonts. So I have no reason to assume incredible abundance, and so my fvar is pragmatic until such time the challenge is met with a real solution.

Perhaps libre graphics folks need to come together and agree that fonts have gotten too complicated and we² need to settle on one linked library to present the user with a dialog to choose a font, with software able to have simpler interfaces, but this library being required to generate the string that can be passed to fontconfig explaining exactly what to do.³

Perhaps that will happen. But this is just one in a sea of issues, and the gulf is only widening. The only thing we seem to have in abundance is laundered fonts.

¹ Increasingly, «wanted».
² At least, the major projects.
³ The irony is not lost on me that I've essentially just described xfontsel. I suppose we need a vfontsel.

[ctrlcctrlv]

I still think I'm right on this issue just in general but have a new argument: fvar should be let alone even if the max number of instances before FAIL will be far lower than 48 because it can be thought of as a list of what the designer thought were the most important instances in a font. If we cannot agree on 48, then perhaps we can agree on a lower number. I think 24 is fair.