Update Wavefont

[RosaWagner]

Font Project Git Repo URL: https://github.com/dy/wavefont

Current version: 3.004

New available version: 3.005

Super short description of the upgrade: ~Addition of a WIDHT axis~ expanded weight axis' range and remap values

[dy]

Width axis wasn't added eventually. It's only linearized weight axis & expanded its range. Npm version is new, it's injected as font version, so it must be new already, 3.4.0

[RosaWagner]

@dy the font version (in the name table) in your repo is still 3.004

[dy]

Got it. Bumped

[RosaWagner]

@dy while reviewing my PR, my colleague @vv-monsalve asked why not mapping 20 to 1 to have an Hairline instance in the STAT table. I want to be sure my suggestion in https://github.com/dy/wavefont/pull/60 was not overlooked, are you sure you want to keep the minimal range at 20? It's okay if you don't want, but I'd like to confirm before merging.

[dy]

with default at 100 it's safe to extend to hairline indeed. The main limitation is compatibility with linefont, but maybe I should introduce default at 100 there too. I guess @vv-monsalve is right, I'll try hairline

[RosaWagner]

yes the default at 100 is also expected for Linefont

[vv-monsalve]

Excellent @dy, thank you!

[dy]

Ok, just experimented with weight=1 value, and there's multiple limitations making it not feasible.

• First, userspace wgth maps to designspace coords as 1:0.25, but .designspace doesn't support fractional values for axis mapping, gftools fails on

      <axis default="100" minimum="1" maximum="1000" name="Weight" tag="wght">
          <map input="1" output="0.25"/>
          <map input="100" output="25"/>
          <map input="1000" output="250"/>
      </axis>

• It's possible to avoid external mapping and just rescale font internally, but it creates inconsistency between x and y scale, which makes calculation a bit more complicated
• Somehow hairline style (wght=1) is not visible at any font-size, seemingly it's too thin for rendering engine

That reduces the worth of hairline style.

The premise about the wavefont/linefont is that they're not intended for rendering precise data, since they have only 127 values. Besides, rendering too much data with wght=1 is not performant and creates visual artifacts. Min value of wght=20 is more-or-less meaningful limitation in terms of healthy font usage, it seems reasonable to keep it.

[RosaWagner]

We were proposing to map this way: <map input="1" output="20"/>, is that problematic?

[dy]

This creates non-linearity, since mapping is a factor of 4. The furthest I can safely get is <map input="4" output="1">, but that doesn't reach hairline-style instance. Should I proceed with that?

[RosaWagner]

I reversed the value above so I edited my comment.

Honestly we are not picky on what a hairline style should look like. We just suggest a way to have the minimum range in the STAT table for future update of the API that could generate an instance for it in the future. If your user value (input) is 1, you choose whatever design value (output) you think would fit.

[dy]

Ah, ok. So should I add hairline instance in designspace then? I've expanded axis to wght=4

[RosaWagner]

Only in the STAT table, so in the config.yaml

[dy]

Ok, added