[com.google.fonts/check/layout_valid_feature_tags] Fails when the font uses `Buzz` feature

[khaledhosny]

Observed behaviour

A font using Buzz feature fails with:

🔥 FAIL The following invalid feature tags were found in the font: Buzz [code: bad-feature-tags]

Expected behaviour

Don’t fail since this is a valid feature tag.

Resources and exact process needed to replicate

I repeat my concern that such a check has no place in universal profile, since it is an opinionated check. The feature registry is not part of the OpenType spec and fonts and layout engines are free to use whatever tags they like.

[felipesanches]

This is related to issue #3368

[miguelsousa]

The feature registry is not part of the OpenType spec

What is this then? https://docs.microsoft.com/en-us/typography/opentype/spec/featuretags

fonts and layout engines are free to use whatever tags they like.

That is true, and the document I linked to clearly says so:

Microsoft encourages font developers to use “registered” feature tags when implementing registered features. However, font developers also may define and register their own features.

To me, the way the feature tags registry documentation is presented makes it an unequivocal part of the OpenType spec. As such, I appreciate that running FB's opentype profile exercises checks that validate feature tags, script tags, and language tags.

I think this issue has more to do with the definition of the universal profile, which is something that I've struggled with as well.

[khaledhosny]

The feature registry is not part of the OpenType spec

What is this then? https://docs.microsoft.com/en-us/typography/opentype/spec/featuretags

Bad choice of words on my part, the registry lists the tags that MS recognizes, but does not say anything about the validity of tags not on the registry. From https://docs.microsoft.com/en-us/typography/opentype/spec/ttoreg (emphasis mine):

The tag registry defines the OpenType Layout tags that Microsoft supports.

And from https://docs.microsoft.com/en-us/typography/opentype/spec/featuretags:

By convention, registered feature tags use four lowercase letters. For instance, the 'mark' feature is used in managing the placement of diacritical marks, and the 'swsh' feature is used to select alternate swash glyphs.

The tag space of tags consisting of four uppercase letters (A-Z) with no punctuation, spaces, or numbers, is reserved as a vendor space. Font vendors may use such tags to identify private features. For example, the feature tag PKRN might designate a private feature that may be used to kern punctuation marks. Interoperability of private features is not guaranteed.

And from https://docs.microsoft.com/en-us/typography/opentype/spec/chapter2#features-and-lookups:

Features define the functionality of an OpenType Layout font and they are named to convey meaning to the text-processing client. Consider a feature named 'liga' to create ligatures. Because of its name, the client knows what the feature does and can decide whether to apply it. For more information, see the Feature Tags section of the OpenType Layout Tag Registry. Font developers can use these features, as well as create their own.

It is clear also that this is not a theoretical concern, HarfBuzz already uses 4 private features tags. I have seen also fonts that use unregistered feature tags for special purposes since many applications (most notably web browsers such as Firefox and Chrome) will enable any feature tag requested.

I think the check in universal profile should be limited to tag validity (ASCII letters and digits only, no control code points etc.) and make unregistered tags a WARN. Other profiles, e.g. googlefonts or adobefonts, might opt to making it a FAIL instead.

This applies to other tags as well, as in #3700.

[simoncozens]

39a7318d changed the check to allow private features, which, as the spec says and as you pointed out above, are tags

consisting of four uppercase letters (A-Z) with no punctuation, spaces, or numbers

Buzz does not consist of four uppercase letters, so it is not a private feature, nor is it a registered tag. Although it is occasionally in use, I find it hard to say that what fontbakery is doing here is wrong.

I think the check in universal profile should be limited to tag validity

So this is where there is confusion between the opentype and the universal profiles. The opentype profile just validates according to the spec. If this check was on the opentype profile it should absolutely just be about tag validity. universal is a bit more opinionated and, hopefully, helpful. If I accidentally put a rlif feature into my font, I want the universal profile to tell me about it.