Fontbakery: [specifications/ttf|otf] discussion

[m4rc1e]

The googlefonts specification is 4500+ LOC. Many tests relate to the openType specification. It would be great to move these tests into their own module e.g specifications/opentype.

It will be a great opportunity to have other review our suggestions or add tests relating to the spec.

[davelab6]

Agreed

[felipesanches]

This will require:

• identifying which are these generic tests versus which are Google-specific
• renaming their IDs (possibly keeping track of the mapping to their original IDs)

The IDs could perhaps be non-numeric so that we don't get worried about rearranging their ordering in the codebase based on what they actually do, instead of keeping them numerically ordered just because that's the order in which they've been sequentially created as time goes by.

[felipesanches]

would we call them, perhaps something like:

spec.opentype/test/head/unitsPerEm instead of com.google.fonts/test/043

[felipesanches]

Proposed ID convention for tests targeting specific tables:

• [spec-name]/test/[table-name]/[field-name or purpose keyword]
• Example: spec.opentype/test/head/unitsPerEm

For all other tests:

• [spec-name]/test/[purpose keyword]
• Examples: spec.opentype/test/WhitespaceGlyphs (instead of com.google.fonts/test/047)

Where specname could be com.google.fonts or spec.opentype or some other future grouping of tests.

[felipesanches]

Except that perhaps the Whitespace Glyphs one is probably Google-specific.

[felipesanches]

It may be non-trivial to split the set, but we can try.

[felipesanches]

Also, there should be some simple way to run the full set of tests that are useful for a user (such as the collection of tests useful for Google Fonts). It could be, for instance, some sort of list of test IDs cherry-picked from all available specs to include in a certain target testsuite.

I say that because we don't want users (and ourselves) manually cherry-picking the desired tests on the command line once tests start to get spread among more than a single set. Today is easy because we simply run the full set by invoking the check-googlefonts subcommand.

[davelab6]

spec.opentype/test/head/unitsPerEm should
be com.microsoft.opentype/test/head/unitsPerEm

[felipesanches]

What about IBM's OS/2, Apple and others involved in the spec?

[davelab6]

Microsoft owns OpenType.

On Oct 26, 2017 3:51 PM, "Felipe Corrêa da Silva Sanches" <
[email protected]> wrote:

What about IBM's OS/2, Apple and others involved in the spec?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/googlefonts/fontbakery/issues/1625#issuecomment-339781269,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAP9yxEs6ZRt7Qmj0xHuTV_AYSxM6lEYks5swOLHgaJpZM4QHTVM
.

[felipesanches]

alright... ;-)

[graphicore]

This will require:

• renaming their IDs (possibly keeping track of the mapping to their original IDs)

I'm against renaming IDs at all. Anyways, if you all think it's beneficial, do it, once and then never again ;-) Keeping track can be done as a comment in the source code #was: fonts.google.com/tests/123, I wouldn't waste time tooling this unless we have an application for it.

The IDs could perhaps be non-numeric so that we don't get worried about rearranging their ordering in the codebase.

We really shouldn't worry interpreting these numbers, especially not about them as implying any order.

Also, there should be some simple way to run the full set of tests that are useful for a user (such as the collection of tests useful for Google Fonts). It could be, for instance, some sort of list of test IDs cherry-picked from all available specs to include in a certain target testsuite.

Sure.

I say that because we don't want users (and ourselves) manually cherry-picking the desired tests on the command line once tests start to get spread among more than a single set. Today is easy because we simply run the full set by invoking the check-googlefonts subcommand.

Of course. We already can use different "sections" to compose a "spec" we are just using only the "default" section at the moment. I.e. a "opentype" spec would likely be organized into different "sections", like 'head', 'name', 'os/2' etc. But I also think we'll need even finer control. We can easily just import specific tests from a module and include them in another section. We can make a helper function, that takes a module or section or spec and a list of function names or id's and puts them into another section/spec.

One thing, we need to take care of are @conditions their namespace is global for a "spec" so everyone has to share the condition for e.g. font or missing_whitespace_chars. At the moment, it would be easiest to have everyone use prefixes. Eventually, we also want to have proper documentation for these @conditions, that says what data-types are returned etc., so others can re-use them. I'd prefer to solve this with some discipline and collaboration instead of by coming up with more code to govern this.
The prefix for conditions defined by the opentype spec could be ot_, google spec goog_. We could have "private" @conditions prefixed with another underscore, _goog_ meaning that we can be less careful when we change them. No underscore is then like a public API and others can depend on them, as we won't change their documented behavior.
Finally, things without a prefix would just be the stuff everyone needs anyways, like font and ttfont for example.

[madig]

I suppose moving generally useful tests to their own spec doesn't need a renaming, and if the google spec then includes the general spec under the same name, nothing will change for users either.

[madig]

I'm going through the tests for what's generally useful, here's what I found, sorted by table:

• General: 002, 035, 036, 037, 038, 039, 046, 047, 048, 049, 052, 053, 058, 059, 060,
• post: 008, 015 (at least for desktop fonts),
• OS/2: 009, 010, 020, 034, 040?, 041, 042?
• cmap: 013, 076, 077, 078
• head: 014 (might want to include name id5 checks), 043, 044
• name: 031, 032, 033, 044, 057, 068, 071, 152, 163
• hhea: 041, 042?, 073, 079
• DSIG: 045
• hmtx: 050
• GPOS: 063, 065
• GDEF: 064
• kern: 066
• glyf: 069, 075
• prep: 072
• fvar: 167, 168, 169, 170, 171, 172

Duplicates: 041, 042, 044 -- keep to one table section? Make aliases and filter them out? People might eventually like to run just tests for the name table and that should include all tests that touch the name table.

Notes on exclusion:

• 011: We sometimes have extra glyphs in a specific weight upon client request...
• 016: We use this internally, actually. Yes, usefulness is debatable.
• 018: Probably better replaced by a foundry-internal check
• 019: Why do we actually need this?
• 055: We use version strings like "1.000-a3" internally.
• 061: Maybe something for the future?
• 062: We partly use custom GASP tables, so this is probably better done as an internal check, at least for us.
• 072: Depends on project I guess?
• 129, 130, 131, 156, 157, 158, 159, 160, 161, 162: We use different internal style names, so this would need to be configurable first
• 173: Include when ready.

[davelab6]

Amazing work! Thanks - very happy to prioritize this as it goes very well
with @graphicore typolabs presentation

[graphicore]

Yeah perfect, thanks a lot! Next week, I'll put out some directions how to mix and share specs and if needed fix up fontbakery. @madig I would just use at least some of the above to get started. Do you need this to happen soon?

[graphicore]

Oh and, both:

Duplicates: …

and

… this would need to be configurable first

are nice suggestions.

[madig]

I am probably paid to make it happen soon :grin: How about I start a new file where I carry the checks over and import them back in in check_googlefonts.py as a first measure? Can also put the helper functions in their own helper module. The next step would then probably to figure out how to compose specs, ideally without the command line changing.

[graphicore]

You can go ahead and do so, it may just happen that I'll come back with some of my ideas about how to do this. if you start with one file per table e.g. cmap.py in the specifications dir, we should be on the safe side.

Not sure about @conditions now. Maybe we start with a central module which contains/exports all of them, then in each spec: for condition in conditionsmodule: specification.register_condition(condition)

But a lot of what I want to do is also to set up guidelines to avoid namespace collisions and such.

[madig]

A central module is what I was thinking about. Basically a specifications/helpers.py with all the stuff that's needed by everyone.

Edit: Heh. Breaking things up into smaller files also presents the opportunity to reformat things with yapf, docformatter, sort imports and fix a few linter issues :)

[graphicore]

Basically a specifications/helpers.py

I don't like that name though, but go ahead, we'll see what ends up in there and will be able to act on that.

It's likely that @conditions will need special treatment of some kind eventually, because they end up in a global namespace, so we shouldn't take them lightly. As much as check-ids, condition names need some kind of governance.

[felipesanches]

Fontbakery 0.4.0 shipped with checks split into separate specs.