Ethiopic: Transformed components

[RosaWagner]

NotoSansEthiopic contains several transformed components. It can be an issue in the variable font since the components are not decomposed and can create:

• contour direction issue
• bad instanciation if you decide to keep components in static ttf — the picture shows a glyph that contains a mirrored component: when an instance is created (with components) from the variable, then the component coordinates are shifted.

This is the list of glyphs containing transformed components: ba.eth, bo.eth, bu.eth, bwi.eth, ca.eth, co.eth, difat.eth, dzo.eth, fee.eth, fya.eth, hhe.eth, hho.eth, ko.eth, kxwaa.eth, mya.eth, nye.eth, nyoa.eth, qe.eth, qhwaa.eth, qu.eth, qwaa.eth, qyee.eth, qyu.eth, rwa.eth, rya.eth, sho.eth, so.eth, ttho.eth, zhe.eth, zho.eth, zo.eth

or

u1260, u1266, u1261, u1385, u1278, u127E, u1394, uAB16, u134C, u135A, u1215, u1216, u12AE, u12C3, u1359, u129D, u2D89, u1245, u125B, u1241, u124B, u2DC4, u2DC1, u122F, u1358, u123E, u1236, uAB06, u12E5, u12E6, u12DE

[anthrotype]

hi Rosalie. Pardon my ignorance, I don't immediately see what's wrong in the screenshot above. Could you provide more concrete examples (e.g. actual font as rendered in specific implementations) whereby transformed components in Noto Ethiopic are creating issues related to path direction (not an issue per se, unless maybe in some situations when contour overlap), or to generating instances from VF?

For one thing, it is true that current VF format can only interpolate the component offsets, not their scale, shear or rotation (affine 2x2 affine matrix). So it is important that only the XY offset is allowed to vary across VF masters. If any other parts of a component's transformation matrix are different between masters, the components must be decomposed in all masters (likewise in the final VF).

This could well be a feature request for our ufo2ft compiler actually.

[RosaWagner]

In the screenshot: I created an instance from the variable font (in a very random way with Samsa, as a normal user could do), and when I open it I see all the mirrored components shifted (the one in the screenshot should be inside the white space, not with a negative right sidebearing).

I just tested some VF builds that Marek sent me, and the components were not decomposed in that version. He asked me to make a quick fix and to report a list of problematic outlines that I could find. I don't know the tools used to build the Noto fonts so maybe it is not a problem if the components get decomposed in the final VF. Although, there is a lot of overlapping components in the sources…

[anthrotype]

I created an instance... with Samsa

can you reproduce that issue by typesetting the VF at the given instance location in a browser?

maybe it is not a problem if the components get decomposed in the final VF

in fontmake pipeline for TTFs, components only get decomposed when the source glyph has a mix of simple contours and components (as glyf table's glyph entries can only contain either simple or composite kind, not both).

a lot of overlapping components

that's not an issue in itself, as long as they display correctly

[RosaWagner]

can you reproduce that issue by typesetting the VF at the given instance location in a browser?

I also tested a given fvar insatnce: SemiCondensed ExtraBold (800, 87.5).

in fontmake pipeline for TTFs, components only get decomposed when the source glyph has a mix of simple contours and components (as glyf table's glyph entries can only contain either simple or composite kind, not both).

Yes, that's why we generally decompose the transform components in our production workflow.

[RosaWagner]

The VF seems to behave correctly at any location when using the sliders. Only the exported instances from the VF (defined in the fvar and custom) has this problem.

[anthrotype]

The VF seems to behave correctly

hm.. It might be a bug in the way Samsa creates those instances?

Could you also try fonttools varLib.instancer InputFont-VF.ttf wght=700 wdth=80 [...] python script and see if it also produces the same result?

[RosaWagner]

The instance looks good with fonttools 👍

[moyogo]

/cc @Lorp

On Wed, 23 Sep 2020, 09:29 Rosalie Wagner, notifications@github.com wrote:

The instance looks good with fonttools 👍

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/googlefonts/noto-source/issues/232#issuecomment-697216129, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOVVI553CIYAZGD6OOVWH3SHGWWHANCNFSM4RV666WA .

[Lorp]

@RosaWagner can you point me to the exact file you’re using? I’d like to try the VF in Samsa myself. And are you using an up-to-date Samsa? (The versions on GitHub and axis-praxis.org are up-to-date.)

On composites, the Samsa initial release did not handle composites at all. Export of fonts with composites was fixed, I believe, around February. Visualization of composites with arbitrary depth and transformations was fixed in July (https://github.com/Lorp/samsa/commit/ed207a6be04026bf4af1167827c92c03db22945d) but no significant changes were made to export at that time.

[Lorp]

Ok I am using https://github.com/googlefonts/noto-fonts/blob/master/unhinted/variable-ttf/NotoSansEthiopic-VF.ttf

I made an arbitrary instance in Samsa, exported it, then loaded it into Glyphs. There you can see a definite problem in the metrics of so.eth. However in the Finder quickview on the same font, the metrics of that glyph seem fine. See attached image.

In any case, this reminds me that I should check that the bounding boxes are ok for these glyphs. A bad bbox could conceivably befuddle Glyphs but not faze Apple.

Please don’t consider Samsa’s exported instances “production ready” at this point — use fontTools to make final fonts. I hope Samsa’s exports are nevertheless useful for quick tests.

[RosaWagner]

Please don’t consider Samsa’s exported instances “production ready” at this point — use fontTools to make final fonts. I hope Samsa’s exports are nevertheless useful for quick tests.

I use Samsa to test the user experience and to see the output of some font metadata.

In my tests, the metrics were looking odd also in the finder quickview.