[varLib] Add avarPlanner

[behdad]

Currently deduces "correct" weight axis mapping based on glyph average weights of axis min/default/max.

EDIT: Plans width and slant axes now too.

[behdad]

I have to generate waterfalls and observe whether the generated output makes visual sense.

[behdad]

I made some waterfalls, and the results look good! In each picture, the left column is the results produced by this tool, and the right column is the original font, with any avar mapping it might have. Click on the pictures for better view.

NotoSansArabic-VF:

RobotoFlex: (has no avar table)

NotoSansCJKtc-VF:

[behdad]

cc @twardoch

[behdad]

For reference: https://www.diacritics.club/family-steps

[Lorp]

Can you clarify what this is doing? Have you implemented Lucas and Pablo curves as HOI in avar2? (which would be a fabulous new use case)

[behdad]

Can you clarify what this is doing? Have you implemented Lucas and Pablo curves as HOI in avar2? (which would be a fabulous new use case)

No. It's just avar1. It's an alternative to Lucas & Pablo curves. I think it produces better results than those. It works by calculating the font's gray "color" using fontTools areaPen, and then treating the weight as log-linear in the gray color.

[behdad]

It's an alternative to Lucas & Pablo curves. I think it produces better results than those.

What's curious is that @LucasFonts has the right idea that the stem-widths (in his case) / blackness (in my case) should be proportionally the same across adjacent weights:

https://www.lucasfonts.com/learn/interpolation-theory

That cleanly maps to a exponential function though. I'm not sure why he didn't arrive at that and arrived at a more complicated formula there.

[jenskutilek]

The slant code basically implements the same idea as:
https://twitter.com/jenskutilek/status/1083243100036837384
but using real calculated slant values.

As my tweets may not be visible to anyone not logged in, this is the code linked in the tweet: https://gist.github.com/jenskutilek/f328f2ca250e8b9ebad0fb398a5a64c1

[behdad]

I also implemented opsz axis mapping. Picture (left: after; right: original font):

The rows here have optical-sizes that proportionally (NOT linearly) get larger, between 8 and 144. So a smooth straight line is desirable in my opinion.

[tiroj]

Can we see that waterfall at target sizes and, more importantly, the individual text size targeting from 8–16pt?

[behdad]

Can we see that waterfall at target sizes

Left the tool's, right the font's existing avar'.

[behdad]

Can we see that waterfall at target sizes and, more importantly, the individual text size targeting from 8–16pt?

[tiroj]

This looks promising, but I will need to find some time to play with it with a better opsz test font. This sans serif is pretty tightly spaced even at its smallest size. I’ll look around for a more traditional text face in which the spacing between 6pt and 10pt changes more significantly.

[LettError]

I would like to test it on an opsz thing I have on my desk but can not share.

[behdad]

I would like to test it on an opsz thing I have on my desk but can not share.

Sure. With fonttools main branch, do:

fonttools varLib.avarPlanner varfont.ttf

Let us know how it goes!

[behdad]

waterfall-opsz.zip

[Lorp]

Shouldn’t this be calibrated against a corpus of Regular and Bold fonts, Regular and Condensed fonts, etc?

[behdad]

Shouldn’t this be calibrated against a corpus of Regular and Bold fonts, Regular and Condensed fonts, etc?

From my cursory look around, the actual weights of Regular/Bold and their ratio varies widely across families (specially when you look across different scripts). So the tool cannot suggest any absolute numbers for those. Instead it logarithmically interpolates between Regular/Black to suggest where Bold should be perceptually. Given Blacks I've seen, this undershoots the designer-set Bold. That is, there's just not enough variance between most Bold and Blacks. The difference is not as pronounced as Regular to Bold.

[weiweihuanghuang]

No. It's just avar1. It's an alternative to Lucas & Pablo curves. I think it produces better results than those. It works by calculating the font's gray "color" using fontTools areaPen, and then treating the weight as log-linear in the gray color.

Could you please explain the curve and are you calculating the gray 'color' using a key glyph?

[behdad]

No. It's just avar1. It's an alternative to Lucas & Pablo curves. I think it produces better results than those. It works by calculating the font's gray "color" using fontTools areaPen, and then treating the weight as log-linear in the gray color.

Could you please explain the curve and

From what I wrote on Twitter:
https://twitter.com/behdadesfahbod/status/1729557135862780000

I think it's first good to review this: https://diacritics.club/family-steps

My method is closer to Luc(as)'s. Except that it uses actual ink area instead of adjusting the stem widths only.

I think it's first good to review this: https://diacritics.club/family-steps

In my understanding, you are suggesting the linear progression.

My method is closer to Luc(as)'s. Except that it uses actual ink area instead of adjusting the stem widths only.

The way it works is that it first samples the weight axis at a few points (8; doesn't matter) to build a function of from the axis value to the actual ink percentage on the page. This is done using the fontTools.pens.areaPen.

After that, it inserts the requested number of in-betweens, such that the ratio of ink between successive ones are the same.

That is, it produces a geometric progression of the ink percentage.

are you calculating the gray 'color' using a key glyph?

I'm calculating the color from the entire glyphset.