[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" < ***@***.***> 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 <#1625 (comment)>, 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.