search

fonttools / fontbakery

🧁 A font quality assurance tool for everyone
https://fontbakery.readthedocs.io
Apache License 2.0
550 stars 102 forks source link

Suggested check: tnum glyphs have same metrics, across glyphs and styles #2278

Open thundernixon opened 5 years ago

thundernixon commented 5 years ago

Observed behaviour

I noticed that the tabular figures (tnum) of Libre Caslon Text Italic didn't share the same horizontal width metrics.

This, of course, means that glyphs marked as .tnum and in the OpenType tnum feature are not yet actual tabular figures.

In the case of Libre Caslon Text, the Regular and Bold masters have proper tabular figures and .tnum glyphs:

image image

However, in Libre Caslon Text Italic, many of the glyphs named as .tnum are not yet modified to be tabular:

image

In the image above, then /yen.tnum is 1222, the dollar.tnum is 1007, and several other glyphs are also completely wrong.

Especially as we process fonts more quickly, this sort of broken OpenType feature will be easy to miss.

Expected behaviour

I think it would be relatively simple to add a check for this problem. My thought is, we could make a list of all width values for glyphs named .tnum, then check if a set of those widths is great than 1. If so, the test fails. I'm not sure whether it's possible to cross-check other weights in a set of static fonts, but this simple test would go a long way, especially in variable fonts.

Resources and exact process needed to replicate

If you wish, the source files for LC are available at https://github.com/thundernixon/Libre-Caslon. I'm fixing the problem now, however, so you may need to go back to older versions to see this in action.

felipesanches commented 5 years ago

I'm fixing the problem now, however, so you may need to go back to older versions to see this in action.

Can you please mention the commit id of the version that has the problem? This will help us keep track of it in the future. Otherwise, we'd have to look at the repo looking for a commit that is older than the timestamp of your comment above.

felipesanches commented 5 years ago

OK. This makes a lot of sense. All .tnum in a given font should have the same width. Any .tnum glyph that diverges from that common value should trigger a FAIL. Right?

felipesanches commented 5 years ago

Should we name this com.google.fonts/check/tnum_horizontal_metrics ?

felipesanches commented 5 years ago

The title of the issue states "across glyphs and styles". Will the .tnum glyphs in a Thin always have the same exact width as the ones in a corresponding Extra-Bold?

felipesanches commented 5 years ago

In other words, is the user expected to use different styles of the same typeface and still get consistent tabular alignment? I would guess that this is a reasonable thing to expect but may be hard to achieve when designing a family. How does that work?

m4rc1e commented 5 years ago

I would guess that this is a reasonable thing to expect but may be hard to achieve when designing a family. How does that work?

In many super families, only the RIBBI styles have the same advance widths for tabular glyphs.

felipesanches commented 5 years ago

So is it reasonable to make this a FAILing check across the RIBBI styles?

And maybe with a WARN for inconsistent .tnum widths in the other styles?

thundernixon commented 5 years ago

Can you please mention the commit id of the version that has the problem?

@felipesanches Definitely! Specific commits which include the problem:

Libre Caslon Roman; Dec 10, 2018

Libre Caslon Italic; Dec 10, 2018

thundernixon commented 5 years ago

is the user expected to use different styles of the same typeface and still get consistent tabular alignment

100% yes, between all styles (assuming styles have a constant value for width axis).

By definition, if figures have different widths in different styles, they are not tabular figures. If the width changed between styles, it would be similar to a "monospace" font with different widths (it would fail to meet a central piece of criteria).

Tabular figures need to have the same metrics in all styles in order to allow tables to be set with proper typographic control, but to maintain the placement of decimals and numeric columns between rows. Designing them this way certainly takes some effort, but that's no different from many other aspects of making type properly. I would consider it a FAIL if they don't meet this criteria.

Here's a good explanation of this:

https://www.typography.com/techniques/fonts-for-financials/#tabular-figs

image

felipesanches commented 5 years ago

So, the plan is to emit a FAIL whenever any .tnum glyph of any style of a whole super-family diverges from a unique glyph-width, right?

felipesanches commented 5 years ago

@thundernixon, while the build instructions on that repo are not updated, could you send me a copy of the relevant font binaries, please?

felipesanches commented 5 years ago

@thundernixon, I would like to add a code-test for this, but I was not yet able to get binaries to replicate the problem. Please try to run this check on your bad files and let me know if it is good. Then, once you send me the sample files, I will be able to create a good code-test using them.

m4rc1e commented 5 years ago

I still think this test should only run on RIBBI styles. The non RIBBI weights of Source Sans do not share the same tabular width. I've seen this in other families as well.

@felipesanches Before we merge a check, we should run the check on the whole collection to see what the potential damage could be. Imo this check is beneficial but its current implementation will cause more harm than good.

felipesanches commented 5 years ago

ok, thanks. I will restrict it to RIBBI-only.

thundernixon commented 5 years ago

(Sorry, I missed the updates to this thread last week. I've updated some notification preferences so that I can keep more on top of conversations like this.)

It still seems like an error that fonts would have different widths for tabular figures, whether or not a given popular font happens to have the issue. If there is a logical reason I'm not seeing for non-RIBBI styles to be have non-tabular tabular figures, I will reconsider my position.

At the very least, I still think it should at least be a warn if fonts have different widths between tabular figures, so that we can hopefully prevent the problem in new fonts.

davelab6 commented 5 years ago

I think the logical reason for non-RIBBI styles to be have their own width per style for tabular figures, is that the Thin 100 weight and the Black 900 weight are going to need to have more or less space around them generally. Whereas in the middle of the range of weights, there can be more of a compromise to enable the same width to look ok on both 400 and 700.

davelab6 commented 5 years ago

So, there's a few checks i can propose here:

  1. All tnum glyphs in a style should be the same width. If not, fail.

  2. All tnum glyphs in core Weight range - 400, 500, 600, 700 - in Roman and separately in Italic should match widths. If not, fail.

  3. If 300 is not matching core's widths, strong warn.

  4. If 100, 200, 800, 900 is not matching core's widths, weak warn.

  5. If each weights Roman and Italic tnum do not match widths, strong warn.

thundernixon commented 5 years ago

Belated reply, but I'm aligned with Dave's proposal. People must have the same widths for 400–700 roman & italic. If they don't match this in other weights, they should get a nudge (warn) to do it correctly, and they should have a good reason to ignore the warning.

hyvyys commented 3 years ago

Tabular figures should have the same width across weights, but not widths! When generating fonts from UFO + designspace sources with a Width axis, this check gives false positives.