Fontbakery: VF naming convention results in "Value is empty."

Created on 26 Jun 2019  Â·  21Comments  Â·  Source: googlefonts/fontbakery

Observed behaviour

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 ...]]

Expected behaviour

Expectation is that fontbakery will run as usual.

Resources and exact process needed to replicate

fontbakery 0.7.8
any similarly named font file should work.
i.e.

foofont-italic\[wdth\].ttf
typicalsans\[wght\].ttf
P0 Urgent

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.

All 21 comments

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:

Screenshot at 2019-06-28 08:46:13

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...

This file:
https://github.com/google/fonts/blob/ad24b23cdd1d220ecdbd5fc583684a576fe6dd3c/ofl/inter/Inter%5Bslnt%2Cwght%5D.ttf

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?

https://github.com/google/fonts/issues/1817

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:

  • fix the VF naming scheme once and for all.
  • remove hacky workarounds
  • make fontbakery smarter to auto-detect which files in a given folder belong to the same family
  • use that info to run checks on multiple families at once
  • detect if the families are siblings and, if so, run super-family checks (we still don't have such checks, but we know we will need them at some point)

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

josh-hadley picture josh-hadley  Â·  6Comments

chrissimpkins picture chrissimpkins  Â·  7Comments

vv-monsalve picture vv-monsalve  Â·  6Comments

felipesanches picture felipesanches  Â·  6Comments

madig picture madig  Â·  9Comments