Fontbakery: Check glyphs are not constructed from transformed components

[m4rc1e]

Some families have glyphs which have been constructed by using transformed components e.g in Comfortaa the 'u' is constructed from a flipped 'n'.

From a designers point of view, this sounds like a win (less work). However, such approaches can lead to rasterisation issues. In the above example, since the 'u' is just a flipped 'n', we cannot assign cvts to it. When I run the font through ttfautohint, the 'u' doesn't sit on the baseline at certain sizes.

[felipesanches]

I want to work on this. @m4rc1e, can you point me to the commit in which the trick is used? (I presume you already fixed that on more recent commits)

[felipesanches]

@m4rc1e is this meant to be a general ban on component transforms? Or is this specific to hacks like this one?

I have myself used component transforms in Beth Ellen in order to not include 2 copies of the outlines of the glyphs that make-up some ligatures.

I can perhaps detect only rotate transforms and emit a WARN so that the user is notified about the potential raster issues. In this cases should we suggest the designers prioritize rasterization-safety over reduction of file-sizes?

[laerm0]

ttfautohint still has issues with transformed components? VTT doesn't and TT hints have been pretty cool with them for a while. Is this still a thing with newer versions of ttfautohint (this issue being ~1 year old)? Sounds like a bug over there, FWIW. This may still need to be a check we run, of course, as long as ttfautohint has this problem.

[m4rc1e]

@m4rc1e is this meant to be a general ban on component transforms? Or is this specific to hacks like this one?

I don't like them because I've found ttfautohint will assign cvts to transformed glyphs as if they haven't been transformed. The result is they render very badly.

[m4rc1e]

A user reported that a 'u' isn't rendering correctly in DM Sans, https://github.com/googlefonts/dm-fonts/issues/7. @colophon-foundry inspected the source file and found that the 'u' is simply constructed by rotating an 'n'.

@felipesanches Since this issue is identical to my first post, I would like rotations and flips to be banned. Only moves in the x,y dir are ok imo.

[m4rc1e]

Here's another reason why I only want x,y moves, https://github.com/googlefonts/fontmake/issues/595#issuecomment-554420850

I think I've got enough evidence for this to be unblocked.

[felipesanches]

Boom! Unblocked :-)

[felipesanches]

OK, let's sketch here the bare minimal we need for a new fontbakery check proposal:

• profile: universal
• level: FAIL
• check id: com.google.fonts/check/transformed_components
• description: "Ensure component transforms do not perform scaling or rotation."
• rationale:

"Some families have glyphs which have been constructed by using transformed components e.g the 'u' being constructed from a flipped 'n'.

From a designers point of view, this sounds like a win (less work). However, such approaches can lead to rasterization issues, such as having the 'u' not sitting on the baseline at certain sizes after running the font through ttfautohint.

As of July 2019, Marc Foley observed that ttfautohint assigns cvt values to transformed glyphs as if they are not transformed and the result is they render very badly."

Does it all look good? Please provide a sample file for me to write a code test as well.

[m4rc1e]

I'd just like to point out that vttLib doesn't support flipped components either.

cc @davelab6

[davelab6]

This is a p0, please focus on this as a delay will impact other projects

[kontur]

Just a comment, but this seems like quite a sledgehammer fix to a problem from another tool further down in the chain — is this even confirmed _not to be_ a bug/unexpected/unintended behaviour in ttfautohint? What about manually hinted fonts?

[m4rc1e]

@kontur here's a good read https://github.com/googlefonts/fontmake/issues/253.

I want this implemented for the following reasons:

• vttLib cannot compile flipped components
• GlyphsApp does this automatically (apparently)
• This issue has caused problems in the Deepmind fonts, Comfortaa and several other. Solution has always been to decompose them
• We have some fast approaching deadlines

I only want this added to the googlefonts profile. It shouldn't be in the universal profile since we haven't done enough research. Werner (ttfa lead) is aware of the issue. Perhaps when it's solved, we could deprecate this check.

[kontur]

@m4rc1e Thanks for the context 👍

[felipesanches]

Today @vv-monsalve and @RosaWagner suggested Priority Level: 8 (1=lowest, 10=highest)

[felipesanches]

The rationale text for this check should mention this:

When building the font with fontmake, this problem can be fixed by using the "Decompose Transformed Components" filter.