CamelCase family name check

[yanone]

I discovered that our CamelCase family name check isn't firing for a font I'm working on. I have trouble understanding how the conditions are checked in Fontbakery. The check is currently SKIP'ping for the font in question. Even the test is weird, because I don't understand where the metadata comes from in check["font_metadata"] in the test.
I only added a test so far.
Please have a look.

[felipesanches]

What's the font family you're talking about here?

[felipesanches]

Is it the KonKhmer_SleokChher.ttf that you added to the PR?

[yanone]

Yes

[yanone]

Later I want to expand the check to FAIL for the underscore as well, but first I want to get it not skipping for CamelCase.

I added another older font with CamelCase to the exceptions list, and now the check is skipping 119 times for the GF library, but those could be all known exceptions.

However, it's skipping the current font, and I'm suspecting either of the two conditions of the check com.google.fonts/check/metadata/fontname_not_camel_cased not returning usable values and thus skipping the check.

[felipesanches]

Is this the full family name? "Kon Khmer Sleok Chher"? Or is it something else similar to that?

[yanone]

It's "KonKhmer_SleokChher"

[felipesanches]

Does the family name actually include an underscore?!
Between two camel-cased terms?!
oh boy...

[yanone]

For the test, is there a way to invoke the test exactly like as if it was invoked from the command line, as in just sending the font path and nothing else? This habit of constructing parameters in the test to hand over to the check is very error-prone.

[felipesanches]

Here, the check runs correctly:

Maybe you forgot to provide a METADATA.pb file with the correct filename field? That would cause the check to SKIP indeed.

I forged a fake METADATA.pb file here and that was enough to see the correct check results:

[yanone]

I wasn't done with this at all which is why I marked this as draft like you asked me to. Only just got started.

We need tests to run on the actual fonts as much as possible, not on additional metadata files that only exist much later in the onboarding process when making PRs to GF. While I author/QA fonts, METADATA.pb doesn't exist yet. In this case, the family name needs to be read from the font file and then checked.

[felipesanches]

I agree with the proposal of moving the checking to the values on the binaries, so that problems surface earlier during font development. (and then keeping a much simpler check for later in the pipeline ensuring METADATA.pb matches the value found in the binary)

And I'm glad to see you working on this at issue #4049 / PR #4050