How to best set the filenames of VFs

[davelab6]

Currently we name VFs filenames as Family-Regular.ttf

I think filename Family-Roman.ttf and Family-Italic.ttf is better, especially as esteemed superuser @thlinard, @eliheuer and others have pointed out (at https://github.com/google/fonts/pull/1814#issuecomment-454889240 and elsewhere) that Family-Regular.ttf (400 static) is confusable with Family-Regular.ttf (roman VF)

Also, if the file is named differently on Github, will the download-ZIP get a renamed file?

For now, Marc has set up PRs for VFs with "normal" names (Family-Regular.ttf) and I'm going to merge these, with static fonts in each family's subdirectory, but @rsheeter suggested on a IM chat to file this separate issue to ponder VF file naming, as it's very much something we can alter and the GF eng team has not yet fully considered it.

[m4rc1e]

Agreed.

ATM, VFs are named by including the family name and the style name of the default instance:

FamilyName-DefaultInstance.ttf

[m4rc1e]

I did start writing about this issue in #1580

[thundernixon]

A related question: Should we have any strategy around naming the family in the nameID 16 (typographic family name, for apps which separate family and style names into separate menus), in order to differentiate VFs from statics? For instance, we could have "Encode Sans Var" and just "Encode Sans." Presumably, it might make sense for the suffix to be the same in the filename and nameID 16.

Related to fontbakery fails described at https://github.com/googlefonts/fontbakery/issues/2297

[davelab6]

We want the vf to be a transparent upgrade, so don't do this :)

[davelab6]

To clarify:

I want the VFs to be transparent upgrades, so don't do this to the name tables of VFs :)

I think the filenames should be different so it is possible to have in the same directory both a static 400 roman style (eg Family-Light.ttf or Family-Regular.ttf or Family-Bold.ttf) and a VF that supplies those (and other) family-styles (Family-Roman.ttf)

Whereas, I think the "expected" family name metadata in the name table should be found in the VF, because that is the latest version of the font family. I can see that it would be good to adjust the static fonts' name metadata so that they can also be installed together for legacy apps/platforms; sadly the version numbers in fonts are not used very much by platforms/apps to allow sets of the same family with the same name table metadata to be installed concurrently.

But I think the GF API wants only 1 version, the latest version, and where that is a VF, the API could send the VF to browsers that support it, and statics instantiated from the VF to browsers that don't (which is mostly MSIE at this point, according to www.caniuse.com/variable :)

[thlinard]

Hi @davelab6 In this case, and in echo to @thundernixon's question: could the static name be "Encode Sans Static" or "Encode Sans Legacy"? The variable version is "Encode Sans" (transparent upgrade), but if, for any reason, someone insists to use the static version, it's clearly identified.

[davelab6]

Yep those are both good candidates. I prefer Static to Legacy because there are situations where you don't want a VF, and I expect those to not go away entirely for a long time... For example, instantiation of a (set of) static instance(s) from a VF, is likely to be a needed workflow for a long time.

[adamrooney]

A few comments regarding previous comments:

@davelab6

I think filename Family-Roman.ttf and Family-Italic.ttf is better . . . Family-Regular.ttf (400 static) is confusable with Family-Regular.ttf (roman VF)

Naming italic VF filenames Family-Italic.ttf is a straightforward solution, but similar to the Family-Regular.ttf issue, it will be unclear whether the filename is home to the 400 italic or the italic VF, no?

@thlinard

Could the static name be "Encode Sans Static" or "Encode Sans Legacy"? The variable version is "Encode Sans" (transparent upgrade), but if, for any reason, someone insists to use the static version, it's clearly identified.

Wouldn’t this cause undue confusion? With this example, existing static “Encode Sans” files would be easily confused with variable “Encode Sans” files. Since we are unable to amend past naming conventions, it’s suggested to do so for VFs moving forward.

Suggestion: Use Family-Variable-Roman.ttf and Family-Variable-Italic.ttf for VF filenames.

Reason: While not the most elegant or transparent of upgrades, this conveyance is more often necessary than not, especially in a world where miscommunication should be anticipated.

“Variable” is suggested over “VF” in order to avoid confusion. “Variable” is suggested to precede “Roman/Italic” in order to: 1) keep related VFs adjacent when font files are sorted alphabetically en masse, and 2) establish “Variable” as a category of importance preceding that of “Roman” and “Italic.”

[thlinard]

@thlinard

Could the static name be "Encode Sans Static" or "Encode Sans Legacy"? The variable version is "Encode Sans" (transparent upgrade), but if, for any reason, someone insists to use the static version, it's clearly identified.

Wouldn’t this cause undue confusion? With this example, existing static “Encode Sans” files would be easily confused with variable “Encode Sans” files. Since we are unable to amend past naming conventions, it’s suggested to do so for VFs moving forward.

Hi @adamrooney

To quote @davelab6: "I want the VFs to be transparent upgrades, so don't do this to the name tables of VFs"

In this case, if we intend to prevent confusion, we can only change the name table of the static fonts.

[thundernixon]

To summarize what I'm reading above (and include a bit of what I know from other threads):

• We want VFs to be a transparent upgrade – that is, where VFs are supported, they should replace existing statics without people noticing any change
  • Therefore, VFs will have name tables that look like the name table of their base master. E.g. Encode-Sans-Roman.ttf will have a similar name table to the old static Encode Sans Thin
  • Also, VF filenames will use a style-based suffix that indicates the range they cover, e.g. encode-sans-roman.ttf will cover the weight (and eventual width) axis of upright styles in Encode Sans
• To support legacy apps, static fonts will gain suffixes in their name tables. E.g. Encode Sans Static Thin, Encode Sans Static Bold, Libre Caslon Static (regular), Libre Caslon Static Medium Italic etc

Here's where I'm unclear ...What might we do for filenames in cases in which filenames will clash between VFs and statics, such as:

1. weight+italic VFs vs regular statics – e.g. inter-ui.ttf could be either "Inter UI Static` (regular) or "Inter UI with weight, width, and italic/slant axes"
2. italic VFs vf regular italic statics – e.g. libre-caslon-italic.ttf could be either "Libre Caslon Italic" (regular) or "Libre Caslon Italic variable font with weight axis"

Should static filenames have a -static suffix? Or, should VF filenames have a -VF suffix? I don't think that either of these would prevent transparent upgrades on the web, as that will (as far as I know) be handled by the name tables and updated links in the GF API. If we want transparent upgrades to happen in desktop apps with downloaded fonts, then I suppose that would support adding a suffix to static fonts. However, there are less-tangible benefits to upgrading to VFs in most desktop software (bandwidth doesn't matter, and most will simply use preset instances anyway), so I would lean towards suffixing VF files instead.

@davelab6 am I wrong on this, or should we aim for transparent changes in desktop software, too?

[thlinard]

Hi @thundernixon Hum… I think it'll be better if we separate the name table subject and the filename subject.

1. The name table (nameID 1, nameID 4, nameID 6, nameID 16): @davelab6 wants the VFs to be transparent upgrades: fine! The name of the static fonts could receive a suffix (Static, for example), preventing confusion in desktop software (I don't see the need for the Web).
2. The filename (before .ttf): a suffix (probably -VF) could to be added to the variable fonts filename, allowing to store the VF and statics fonts in the same folder.

Btw, about "less-tangible benefits to upgrading to VFs in most desktop software", I think you're underestimate the use of Google Fonts by creative people for print work (and, for example, see What You Can Do with Variable Fonts in Illustrator CC).

[thundernixon]

@thlinard I agree with you on all fronts! Just wondering if Dave agrees on the suffix choice for file naming, or has a different perspective.

Re: benefits to upgrading VFs on desktop I 100% agree, VFs are awesome in design tools, and will hopefully get better and better. If others come across this, another nice article is "Practical Uses for Variable Lettering" from OHno Type. I should have been more clear in saying, "I don't think desktop apps benefit from transparent upgrades in the same way that websites do." My statement was driven by several things:

1. The vast majority of desktop font users are in apps like MS Word, PowerPoint, and Excel. They can't use fluid axes, and (for the most part) won't ever know the difference between static and variable fonts. Additionally, the latency/filesize benefits that are a primary benefit of VFs on the web aren't really applicable in these general work apps. So, 98% (?) of desktop app users don't benefit in a straightforward way from the change.
2. People using design software that supports fluid axes (e.g. Illustrator, Photoshop, InDesign at some point soon, etc) are generally more familiar with fonts, and may have specific reasons to want to differentiate between variable and static fonts. So, they should have both choices available with all font files in the same /fonts folder. These users may also suffer more from transparent upgrades. Reflowed text can be problematic on a webpage, but could be disastrous in a book. At the very least, this is a definite reason to suffix static font names. I think we all agree on this, though.

[adamrooney]

Hi @adamrooney

To quote @davelab6: "I want the VFs to be transparent upgrades, so don't do this to the name tables of VFs"

In this case, if we intend to prevent confusion, we can only change the name table of the static fonts.

@thlinard Apologies—misread your comment as though it concerned filenaming, not name tables. My comment purely concerns filenaming.

2. The filename (before .ttf): a suffix (probably -VF) could to be added to the variable fonts filename, allowing to store the VF and statics fonts in the same folder.

Also, it appears that most here agree to using "VF" within filenames, as opposed to "Variable" (or even "Var"). Wanted to make sure this intention is understood—is this acronym preferred for its simplicity, or is there more to it?

This topic of filename conveyance is of particular importance to me, as I work for a global company with multiple language barriers. I'd like to share the benefits of using VFs—both online and on desktop—with our many regions' designers, and details such as quickly establishing what a variable font is is significant. In this case, including "Variable" within a filename is more easily explained than having "VF," which hides its meaning behind an acronym. I believe this would be an issue for others as well.

Separately, from a more literal perspective "VF" seems a bit redundant; since it stands for "variable font," the "F/font" aspect is what I consider redundant.

Lastly, I'd again like to suggest to include "VF"/"Variable" before "Roman/Italic," since this:

AveriaSerifLibre-Bold.ttf AveriaSerifLibre-Bold-Italic.ttf AveriaSerifLibre-Italic.ttf AveriaSerifLibre-Light.ttf AveriaSerifLibre-Light-Italic.ttf AveriaSerifLibre-Variable-Italic.ttf AveriaSerifLibre-Variable-Roman.ttf AveriaSerifLibre-Regular.ttf

looks a bit nicer than this:

AveriaSerifLibre-Bold.ttf AveriaSerifLibre-Bold-Italic.ttf AveriaSerifLibre-Italic.ttf AveriaSerifLibre-Italic-Variable.ttf AveriaSerifLibre-Light.ttf AveriaSerifLibre-Light-Italic.ttf AveriaSerifLibre-Regular.ttf AveriaSerifLibre-Roman-Variable.ttf

Keeps everything neat I think :)

[thundernixon]

@adamrooney good points on file naming! In a global context, clarity is definitely a good reason to avoid acronyms where possible.

For me, the -VF suffix comes from a convention that FontMake happens to use as a file suffix for variable fonts. Obviously, "because it's already done that way" isn't a great reason to do something, and I don't know the original reason that exact suffix was chosen. Brevity does matter in name metadata (font names longer than 28/29-ish characters can have issues in some legacy contexts, plus the MS word font menu is simply width-constrained and will cut off long names). However, I don't know of any problems cause by longer filenames.

I think we're in agreement that the "Static" / "Stat" / "St" suffixes are a decent approach in font names, to allow for a (mostly) transparent upgrade.

There is not yet consensus on filenames. I see two primary options, both of which would allow files to coexist in the same folder and prevent confusion/clashes between variable and static files:

1. The suffix variable be applied, possibly/probably before the roman/italic designator to better group similar files together. This route would call out variable fonts as something special/different. It would be applied to few files, so fewer filenames would need suffixes (not sure how much of a benefit this is).
2. The suffix static be applied, possibly/probably before the style name. Assuming we attach "Static" as a suffix for font names, this would make it a more 1-to-1 naming update. That is, both the font name and filename are changed to mark a static font as a legacy font, which may be simpler for users to understand and remember.

[sladen]

In the @adamrooney example of AveriaSerifLibre, the suffixes "Bold" "Regular" "Light" already convey to the user that a font instance is (a) static, and (b) on along a particular axis (weight in this case).

A proposed suffix of Variable tells the user that it is variable, but not which axis; contrast this to a suffix of:

• AveriaSerifLibre-Variable-Weight, or
• AveriaSerifLibre-Weight, or with an axe + range:
• AveriaSerifLibre-Weight100to900

This is not to say that such a scheme is better, but such a filename schemes conveys information equivalent to what is already used for filenaming of static weights.

[adamrooney]

@sladen Good first point!

Regarding bullets 2 and 3 from your second point: is it necessary to convey axis in filenames? From what I understand, VFs will likely have no more than two files—one for roman and one for italic—making it somewhat unnecessary to go into further detail. Not sure what the added benefit would be.

Also, wouldn't this naming convention also get out of hand for multi-axis files?

[thundernixon]

wouldn't this naming convention also get out of hand for multi-axis files

While the idea of conveying the stylistic information about a font in its filename is appealing at first, this was my main concern, as well. I think that this approach might break down after 2 or so axes.

With axis abbreviations, EncodeSans-wght-wdth.ttf is okay, but EncodeSans-wght-wdth-opsz-slnt-GRAD.ttf starts to get a bit unruly.

I expect fonts to get more axes over time as tools become more efficient to use in designing multi-axis fonts. So, this approach doesn't seem like it would be as sustainable as just using the family name, maybe a suffix, and allowing people to see axes in other ways.

[rsheeter]

We're going to try out the following:

FamilyName(-Italic)[axistag-csv].otf/ttf
  [...] omitted from dirname
  -Italic for the case where family has two VF files
  > 2 VF files or a split other than ital unspecified until it actually comes up
  tags listed in sorted order

Example

BEFORE (instances)
apache/opensans
  OpenSans-BoldItalic.ttf
  OpenSans-Bold.ttf
  OpenSans-ExtraBoldItalic.ttf
  OpenSans-ExtraBold.ttf
  OpenSans-Italic.ttf
  OpenSans-LightItalic.ttf
  OpenSans-Light.ttf
  OpenSans-Regular.ttf
  OpenSans-SemiBoldItalic.ttf
  OpenSans-SemiBold.ttf

  OpenSansCondensed-Bold.ttf
  OpenSansCondensed-LightItalic.ttf
  OpenSansCondensed-Light.ttf

AFTER (vf)
apache/opensans
  OpenSans[opsz,wdth,wght].ttf
  OpenSans-Italic[opsz,wdth,wght].ttf

We are OK with EncodeSans[GRAD,opsz,slnt,wdth,wght].ttf. If it emerges that very large axis counts are going to be a thing we may have to rethink but we don't currently anticipate that.

[davelab6]

How is the sort order defined?

[adamrooney]

If it emerges that very large axis counts are going to be a thing we may have to rethink but we don't currently anticipate that.

@rsheeter What about fonts such as Spectral which have more than 20 parameters?

[davelab6]

Prototypo doesn't offer "OpenType Variable Fonts", rather it is a "generative font" system (like metafont, metapolator, infinifont, and others)

This scheme will work until we have an actual OTvar font with a large set of axes, and the current OTvar fonts AmstelvarAlpha and DecovarAlpha will work fine; and the scheme is easy to change in the future.

(The OTvar format does allow up to 64k axes, and the NTFS and ext3 filesystems character limits are 255, I think.)

[eliheuer]

@rsheeter

One possible problem with the new spec is the use of square brackets in the filenames.

When writing shell scripts and working with files in Unix shells like Bash and Zsh, needing to escape the square brackets could cause a lot of unnecessary friction. We want to make PRing new fonts as easy as possible, so more people with varying technical skill levels will be able to make PRs to GoogleFonts.

For example, FontBakery currently doesn't work with filenames with square brackets in them. I had to rename the files to generate reports for this PR, so now it's not perfectly clear that the FontBakery report represents the font from the PR.

Could we instead use something like:

OpenSans-Italic.opsz.wdth.wght.ttf

And then when parsing the filename on the backend just make a list from each string between periods, excluding the first string (filename) and last string (ttf)?

[davelab6]

EncodeSans[GRAD,opsz,slnt,wdth,wght].ttf

@m4rc1e pointed out that this doesn't account for when there's 2 VFs in a family, one for Roman and one for Italic.

And echoing what Eli said, I think there was an internal discussion within the GF eng team about the use of [] meaning annoying shell escaping...

For now, we are adding files as Family-Default.ttf (eg https://github.com/google/fonts/pull/2021/files) and will need to go back and rename them when this is settled :)

[davelab6]

The internal onboarding system now has lint checks for file naming, so currently the policy is firmly in place, and the solution for italics is:

Literata[wght].ttf
Literata-Italic[wght].ttf

I'd like to revisit this but for now we have to make sure FontBakery checks and the public METADATA.pb generator are using this file naming schema.

[rsheeter]

Agreed the impact on shell is undesirable, will fix at some point. Until I find time for that please use the [] format.

[felipesanches]

Fontbakery check was updated to enforce this new VF naming scheme. The current status of the complete GFonts collection can be see in the report that I posted at https://github.com/googlefonts/fontbakery/issues/2549#issuecomment-503837945

[felipesanches]

Decovar will now have a huge filename :-)

Note: the family name is currently inferred by reading the name table, that's why Decovar is called "DecovarAlphaRegular24" in the sample output below:

[nathan-williams]

Just to update this thread, the naming schema in the ZIP downloads and within the git repo diverged somewhat. Here's an example of how the font files are named in the Crimson Pro ZIP:

  CrimsonPro-VariableFont_wght.ttf
  CrimsonPro-Italic-VariableFont_wght.ttf
  static/CrimsonPro-ExtraLight.ttf
  static/CrimsonPro-Light.ttf
  static/CrimsonPro-Regular.ttf
  static/CrimsonPro-Medium.ttf
  static/CrimsonPro-SemiBold.ttf
  static/CrimsonPro-Bold.ttf
  static/CrimsonPro-ExtraBold.ttf
  static/CrimsonPro-Black.ttf
  static/CrimsonPro-ExtraLightItalic.ttf
  static/CrimsonPro-LightItalic.ttf
  static/CrimsonPro-Italic.ttf
  static/CrimsonPro-MediumItalic.ttf
  static/CrimsonPro-SemiBoldItalic.ttf
  static/CrimsonPro-BoldItalic.ttf
  static/CrimsonPro-ExtraBoldItalic.ttf
  static/CrimsonPro-BlackItalic.ttf

IIRC, we opted to spell out VF for the sake of user understanding. Of course, the git repo and fonts.google.com have fairly different audiences. I personally don't think it's worth the effort to bring the naming back into sync.

[m4rc1e]

@nathan-williams We have an issue regarding STAT tables in our VFs. If we do a pass to fix all STAT tables, it may be worth updating the filenames as well.

[tagoh]

I just found this but I'm not sure if it is the best place to add a comment; I got some complaint about the filename format of Google Noto variable fonts at Fedora. some shell scripts failed because of the use of the brackets in filenames of variable fonts. Is it possible to reconsider not using brackets in filename?