Design space to match GF

[RosaWagner]

Hi @dy I am looking at the UFOs, and I am a bit afraid of changing the design space values without breaking all your settings, so maybe you can do it?

We would need the axes to be in that order and these values:

<axis default="0" minimum="0" maximum="100" name="Roundness" tag="ROND"/>
<axis default="100" minimum="50" maximum="200" name="Width" tag="wdth"/>
<axis default="400" minimum="100" maximum="900" name="Weight" tag="wght"/>

cf https://googlefonts.github.io/gf-guide/variable.html#most-common-axes

The default instance of the font (master origin) should be named "Wavefont Regular" (0, 100, 400). So kind of in the middle in terms of weight and width, so users can see the shapes without having to move a slider. Step by step we'll make it ^^

[RosaWagner]

Weight can decrease until value 1 (Hairline) actually, but it must not be the default.

[dy]

Hi @RosaWagner! Do you mean that minimum can be set to 1?

[RosaWagner]

Yes

[dy]

These numbers of wdth, wght have literate meaning as upm s, so normally wdth >= wght in wavefont. I think it's fine to limit wdth to <=200, but limiting it to >=50 seems like losing some core use-cases. Is there something can be done to overcome that min limit? Can wdth axis be expanded to 10..200 (ideally 1..1000)? Or maybe there's a way to detach otf masters from designspace definition? opsz has better range limits, but has unfitting interpretation by CSS.

[RosaWagner]

You can have a wider range if necessary, but it won't be accessible through instances in GF, important is to keep a default at 100, and other 50 is half of that width etc.

You can use whatever values to generate your masters, but then we will have to re-map the axes locations so they match the expected user values (as explain in the doc linked above). In that case you would have to choose which value should be map to which value. I don't recommend opsz.

[dy]

The best I was able to do is to make <axis default="0" minimum="0" maximum="100" name="Roundness" tag="ROND"/> axis definition and rename font to Wavefont Regular.

As for the changing wdth/wght limits there's too many factors playing, any change breaks the build.

Details

Changing default values to wdth=100, wght=400 ```xml ``` throws build error `fontmake: Error: In 'source/Wavefont Regular/wavefont.designspace': Generating fonts from Designspace failed: No default source.` Likely needs additional master for default values, since generated masters are only for edge values. That's not recommended by [the guide](https://googlefonts.github.io/gf-guide/variable.html#font-zero-origin) though. #### ⁂ Creating additional master with default values: ```xml ``` breaks `ROND` and messes up `wdth` axes. Likely because it factors in as new interpolation point, whereas we need to basically ignore that master. #### ⁂ Limiting `wdth` to 50..200 with default value of 50: ```xml ``` messes up clipping replacements (glyphs with reduced radius, when weight >= glyph value). That happens due to screwed interpolation since masters are not extreme values. Normally it should look as:

Q1. I wonder if google building process can provide a workaround for default master? Like just pick particular interpolation values (instance) and call it "default", instead of introducing a new master?

Q2. It seems that any change of axes limits breaks interpolation. I wonder if there's a way to just externally limit axis sliders, rather than rebuilding the font?

---

Alternatively: dropping wdth axis support can solve axis incompatibility - advance width can be controlled via letter-spacing, a bit harder though.

[RosaWagner]

Ok, thanks for testing this. I am sure there could be a solution involving several designspace files, but I really see a limit to my skills here so I gonna summon my colleagues :)

[dy]

@RosaWagner I decided to remove wdth axis due to set of reasons #43. Mainly it's not useful enough. Now there's only wght and ROND axes. Please check if that would satisfy GF requirements.

[dy]

@RosaWagner thanks to @simoncozens helpful contribution (#44) the font structure is reorganized and building is in place. The old pipeline is still used for variable .woff2 generation. Please check.

[RosaWagner]

Hey! Very cool :) The only major thing that I see so far are the style names.

• The final file should be capitalised "Wavefont[ROND,wght].ttf" instead of "wavefont[ROND,wght].ttf" -> this should be fixed by naming the designspace file with a capital.
• "Round" needs to be in the "Family Name" part of the name. So instead of "Wavefont Regular Rond" (Wavefont-RegularRond.ttf), we should have "Wavefont Rond Regular" (WavefontRond-Regular.tff). Cf https://googlefonts.github.io/gf-guide/statics.html
• There should only be the conventional weight instances in the variable font, at every 100 stops, using the conventional naming. cf https://googlefonts.github.io/gf-guide/variable.html#fvar-instances (UltraLight should become ExtraLight)

[dy]

Hi @RosaWagner! Fixed font & style naming. Thanks for the hints!

[RosaWagner]

Great, thanks! I should have been clearer for the instances in the variable font; you can't have the instances with duplicated name either, you need to keep only one set, so the ones with default location on ROUND.

I know this is pretty restrictive, but it is the only way we can insured backward and cross platform compatibility.

In the script they can be removed from the VF, or usually with UFO we have 2 designspace files, one for VF and one for statics.

[dy]

Ok, removed rounded style. Now there's only rectangular static family.

[dy]

@RosaWagner I may need to recover ALGN axis (or find appropriate alternative). It seems Cyrillic range for centered values has inconveniences #37.