Add opentype-best-practices profile & FAIL if dnom/numr features exist

[davelab6]

Observed behaviour

In https://typedrawers.com/discussion/comment/45741/#Comment_45741 @tiroj explains

Expected behaviour

This isn't off-spec - just the opposite - but it is something everyone should know to check, and many don't, because the OT spec has been undermaintained...

So I propose a new profile like opentype-best-practices and a first check that FAILs if dnom/numr features exist.

he GF profile should include this profile.

[felipesanches]

I will look it up more carefully on Monday, but my gut feeling is that we do not want a opentype-best-practices profile because that's what the universal profile is meant to address.

[tiroj]

I should also note that while I think the numr and dnom features are unnecessary for implementation of the frac feature, and hence that the features as originally registered by Adobe should have been deprecated, I can't say for certain if or how the features might be being used today. We, like most other font makers, include them in fonts on the basis that 'The glyph exists, the features exist, they're not doing any harm'. Adobe's typography UI in InDesign provides direct access to the features, and other UIs and markup syntax might do likewise. So it is possible that someone is using them for something that I have not considered.

[khaledhosny]

I added numr and denm features to (some of) my fonts to enable automatic fractions with fraction slash in HarfBuzz. It is simpler than frac feature as it can be a simple single substitution lookup without the complexity of having to match the fraction slash. I don’t add a frac feature for the same reason.

[tiroj]

Interesting. I'm aware that Harfbuzz automates display of fractions when U+2044 is used, but thought it did so by applying the frac feature across the segment. Just tracked down the implementation discussion from 2013, and it looks like numr and dnom are indeed necessary for that to work (which should, therefore, be noted in a revision to the registered feature description.

BTW, it looks from Jonathan Kew's comments in the linked discussion that the existing feature descriptions were still being interpreted as describing how the frac should be expected to behave, then years after most font makers had started implementing the feature using contextual substitutions for arbitrary fraction sequences.

[khaledhosny]

HarfBuzz applies numr to the digit sequence before the fraction slash, denom to the digit sequence after the fraction slash, and frac to the whole sequence (including the fraction slash). This way numr/denom-only works, frac-only works, and having all of them also works. The benefit of fonts including numr/denom only is simpler lookups at the expense of working with basically HarfBuzz only (or manually selecting the features).

[tphinney]

I think the desirable check is “if it has numerators and denominators, do fractions work as expected in all environments.” But that is a lot more complex than this request.

Until then....

• 'numr' and 'dnom' require very little code/space
• they have no known negative effects
• are probably unnecessary (ASSUMING the font is built to use 'frac' only)

[simoncozens]

Reading the above, I don't believe there is anything to do here now; consensus is (a) universal is the opentype-best-practices Dave wanted, and (b) dnom/numr are fine. "Do fractions work?" is a different and more complex check, but feel free to open a new issue for that if we really really want it.