Open davelab6 opened 5 years ago
Agreed.
ATM, VFs are named by including the family name and the style name of the default instance:
FamilyName-DefaultInstance.ttf
I did start writing about this issue in #1580
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
We want the vf to be a transparent upgrade, so don't do this :)
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 :)
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.
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.
A few comments regarding previous comments:
@davelab6
I think filename
Family-Roman.ttf
andFamily-Italic.ttf
is better . . .Family-Regular.ttf
(400 static) is confusable withFamily-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
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.
To summarize what I'm reading above (and include a bit of what I know from other threads):
Encode-Sans-Roman.ttf
will have a similar name table to the old static Encode Sans Thinencode-sans-roman.ttf
will cover the weight (and eventual width) axis of upright styles in Encode SansEncode Sans Static Thin
, Encode Sans Static Bold
, Libre Caslon Static
(regular), Libre Caslon Static Medium Italic
etcHere's where I'm unclear ...What might we do for filenames in cases in which filenames will clash between VFs and statics, such as:
inter-ui.ttf
could be either "Inter UI Static` (regular) or "Inter UI with weight, width, and italic/slant axes"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?
Hi @thundernixon
Hum… I think it'll be better if we separate the name
table subject and the filename subject.
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).-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).
@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:
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.
- 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 :)
@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:
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).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.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
, orAveriaSerifLibre-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.
@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?
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.
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.
How is the sort order defined?
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?
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.)
@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)?
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 :)
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.
Agreed the impact on shell is undesirable, will fix at some point. Until I find time for that please use the []
format.
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
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:
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.
@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.
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?
Currently we name VFs filenames as
Family-Regular.ttf
I think filename
Family-Roman.ttf
andFamily-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) thatFamily-Regular.ttf
(400 static) is confusable withFamily-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.