4298 ± : fontbakery check-googlefonts Karla-Italic\[wght\].ttf [37m] ✖ ✹ âœ
Validation of expected values failed:
fonts: Value is empty. (value: ())
usage: fontbakery check-googlefonts [-h] [-c CHECKID] [-x EXCLUDE_CHECKID]
[-v] [-l LOGLEVEL] [-m LOGLEVEL_MESSAGES]
[-n] [-C] [-S] [-L] [--json JSON_FILE]
[--ghmarkdown MD_FILE] [--html HTML_FILE]
[-g ITERATED_ARG] [-o ORDER]
[fonts [fonts ...]]
Expectation is that fontbakery will run as usual.
fontbakery 0.7.8
any similarly named font file should work.
i.e.
foofont-italic\[wdth\].ttf
typicalsans\[wght\].ttf
I get the same result with other ways of pointing to a font, as well.
For instance, I've renamed a font to be FiraCode[wght].ttf.
â–¶ fontbakery check-googlefonts distr/variable_ttf/FiraCode*.ttf
Validation of expected values failed:
fonts: Value is empty. (value: ())
usage: fontbakery check-googlefonts [-h] [-c CHECKID] [-x EXCLUDE_CHECKID]
[-v] [-l LOGLEVEL] [-m LOGLEVEL_MESSAGES]
[-n] [-C] [-S] [-L] [--json JSON_FILE]
[--ghmarkdown MD_FILE] [--html HTML_FILE]
[-g ITERATED_ARG] [-o ORDER]
[fonts [fonts ...]]
â–¶ fontbakery check-googlefonts distr/variable_ttf/*
Validation of expected values failed:
fonts: Value is empty. (value: ())
usage: fontbakery check-googlefonts [-h] [-c CHECKID] [-x EXCLUDE_CHECKID]
[-v] [-l LOGLEVEL] [-m LOGLEVEL_MESSAGES]
[-n] [-C] [-S] [-L] [--json JSON_FILE]
[--ghmarkdown MD_FILE] [--html HTML_FILE]
[-g ITERATED_ARG] [-o ORDER]
[fonts [fonts ...]]
brackets of death. https://github.com/google/fonts/issues/1817#issuecomment-477999366
I think everyone is well aware of the issue and they'll find a solution soon.
I suspect this could maybe be addressed with a blob.escape in Lib/fontbakery/fonts_profile.py ... but in initial experiments with FontBakery installed in editable mode, I wasn't able to make it work.
I've tried using
fontbakery check-googlefonts 'foo[wght].ttf'
as well and get the same result.
I hate these brackets!
I'll see what I can do about it for now, though...
As a quick workaround... you can invoke fontbakery passing the file name between quotes and using an asterisk in place of the brackets. That will work for now.
Like this:

This article explains what's the meaning of square brackets on bash:
https://www.linux.com/blog/2019/3/using-square-brackets-bash-part-1
I think it is tricky to change fontbakery to workaround this. We should really fix the naming scheme instead. And use the workaround from my previous message while the naming-scheme is not addressed.
It seems to me that the problem here is that Family[wght].ttf will be expanded by the shell into Familyw.ttf Familyg.ttf Familyh.ttf Familyt.ttf
and it seems that there's nothing fontbakery can do about it since this expansion is performed by the shell before passing the command line attributes to the program
@felipesanches your workaround works for a single axis, but seems to fail for more than one.
For example, this fails for me:
â–¶ fontbakery check-googlefonts Inter*slnt*wght*.ttf --ghmarkdown checks/Inter-Full-VF.checks.md
Validation of expected values failed:
fonts: Value is empty. (value: ())
usage: fontbakery check-googlefonts [-h] [-c CHECKID] [-x EXCLUDE_CHECKID]
[-v] [-l LOGLEVEL] [-m LOGLEVEL_MESSAGES]
[-n] [-C] [-S] [-L] [--json JSON_FILE]
[--ghmarkdown MD_FILE] [--html HTML_FILE]
[-g ITERATED_ARG] [-o ORDER]
[fonts [fonts ...]]
Can you think of any kind of workaround for this?
@thundernixon in which repo are these Inter*.ttf files published?
@felipesanches the specific files I am trying to check are here:
https://github.com/google/fonts/tree/ad24b23cdd1d220ecdbd5fc583684a576fe6dd3c/ofl/inter
oh! It is a subtle thing, it seems...
It is called Inter[slnt,wght].ttf
But is should be called Inter[slnt][wght].ttf
Sorry, are you saying that the variable font file should have that filename, or something else? If the filename should be that, was that decided and posted somewhere outside the main issue thread about VF naming?
ooooh. No, you're right. I am the one misteken here, sorry!
This means I have a bug in the fontbakery check. I will fix that now!
Now you won't need any further workarounds because I added a dirty hack to fontbakery source code itself. I dislike it. But that's the best we can do for now. I hope we'll soon have a different naming scheme so that I can remove the hack...
In https://github.com/googlefonts/fontbakery/issues/2570#issuecomment-506706910 @felipesanches says:
We should really fix the naming scheme instead.
I second that. today I encountered a work in progress case of @fonthausen. He tried to run
~/variable_ttf fontbakery check-googlefonts *.ttf
in a directory like this:
~/variable_ttf> tree
.
├── MulishPro[slnt,wght]-VF.ttf
├── NunitoPro[slnt,wght]-VF.ttf
├── NunitoSansPro[opsz,slnt,wdth,wght]-VF.ttf
├── NunitoSansPro[opsz,slnt,wdth,wght,xhgt]-VF.ttf
└── NunitoSansPro[slnt,wght]-VF.ttf
0 directories, 5 files
results in the message:
fonts: Value is empty. (value: ())
It worked with double quotes:
~/variable_ttf fontbakery check-googlefonts "*.ttf"
@davelab6 pointed out that these are different families and fonbakery is not really intended to be called like this, but I think the case is valid, but further, I tried to run it with a single font:
# escaped
$ fontbakery check-googlefonts NunitoSansPro\[opsz\,slnt\,wdth\,wght\,xhgt\]-VF.ttf
# escaped, in quotes
$ fontbakery check-googlefonts "NunitoSansPro\[opsz\,slnt\,wdth\,wght\,xhgt\]-VF.ttf"
# not ecaped, in quotes
$ fontbakery check-googlefonts "NunitoSansPro[opsz,slnt,wdth,wght,xhgt]-VF.ttf"
# not escaped, no quotes
$ fontbakery check-googlefonts NunitoSansPro[opsz,slnt,wdth,wght,xhgt]-VF.ttf
This is because the -VF suffix blocks the hacky workaround introduced in #2583. I think there should be a way to run the checks for a file name like this using the literal name in quotes or escaped for bash.
Maybe, we shouldn't use the glob pattern matching at all in fontbakery? Or, maybe make it optional, could be on by default but I'd prefer off?
There are a few very important things we need to do:
When these things are done, we will be able to pass a path to a directory (or many directories) on the command line and fontbakery should do the rest.
Most helpful comment
brackets of death. https://github.com/google/fonts/issues/1817#issuecomment-477999366
I think everyone is well aware of the issue and they'll find a solution soon.