googlefonts / ufo2ft

A bridge from UFOs to FontTools objects (and therefore, OTFs and TTFs).
MIT License
151 stars 43 forks source link

Composite glyph not propagated correctly into font #695

Open yanone opened 1 year ago

yanone commented 1 year ago

A unicase font I'm working on shows an anomaly where the glyph ohorntilde, which is composed of Ohorntilde, is showing only the Thin master outlines in the VF while the glyph width is adjusted properly.

ohorntilde is composed of nested components (Ohorntilde itself contains the component Ohorn), but when I decompose everything to bare outlines I still get the same result.

I’ve confirmed in the intermediate master UFOs that glyphsLib propagates the outlines correctly, so it’s not in glyphsLib for once.

What could I try? Where could I check?

VF:

Bildschirm­foto 2023-01-27 um 15 16 28

Black Master UFO via glyphsLib:

Bildschirm­foto 2023-01-27 um 15 25 17
yanone commented 1 year ago

Sorry, the lower screenshot is showing Ohornacute when it was supposed to show ohornacute, but both look the same, as they're supposed to

anthrotype commented 1 year ago

do you see any logging warnings from fontTools.varLib about incompatible composite glyphs across masters?

I suspect in your case the components of different masters have different 2x2 transforms and thus can't be variated (only x/y offset can be at the moment), so varLib is ignoring them when generating gvar:

see https://github.com/fonttools/fonttools/pull/2857

We have an open issue about automatically decomposing glyphs when building VFs when transforms differ across masters, see https://github.com/googlefonts/ufo2ft/issues/507#issuecomment-1110876311

anthrotype commented 1 year ago

what do you mean by "propagate" in this context?

yanone commented 1 year ago

"Propagate" as in the wrong outline ends up in the font, Thin outline ends up in all masters for this glyph.

After your input I was able to trace down the problem to a transformed component indeed that differs across masters, and I can confirm that the glyph in question is decomposed in the binary.

But decomposition isn't my problem then. More like faulty decomposition. Shouldn't the filter decompose each master separately? What's happening here is that the Thin master’s outlines propagate to all masters for the glyph in question (while the glyph width propagates correctly).

Btw, I tried both PyPI as well as git/main versions of all major tools involved, to identical results.

anthrotype commented 1 year ago

/cc @simoncozens

yanone commented 1 year ago

I'm going to move on and fix the problem in the source. Since the linked repo will reflect this, use https://github.com/duongtrtype/DTPhudu/commit/d69db5d496d4bc805d7fe28b69ef8c0a1b36f707 as a point of reference for the affected glyphs and . They appear to be the only affected glyphs in the font, and it's hard to say why. There are more transformed components in the font and they get decomposed fine.

I thought that maybe it's components being nested that causes this behaviour: contains , which contains Ơ, which in turn contains O.

If that's the case, nested components alone aren't the problem. Only in combination with component transformations. Scaling the component back to 100%, which is very possible in this design, produces correct outlines.