Remove wdth axis

[dy]

• saves 30kb to file size
• avoids conflict with google axis limits 50..200
• external letter-spacing can be arbitrary/unlimited, unlike font axis, so that can be unavoidable anyways
• external letter-spacing has better units via ch: either 1ch = 1bar

[dy]

Ok, removed wdth.

[dy]

The reason for internal width axis is these images:

It's quite problematic to adjust that via relative letter-spacing (measured relatively to char width). It's easier to set fixed char advance width and adjust weight within its bounds. Letter-spacing can also be used to regulate space between chars, but essentially the font becomes monontonic, in sense axes variation doesn't change characters distance. The problem is if we fix chars width to max width then thin chars will always be spaced.

We should match linefont:

• wght=900 will match wdth=200
• (extrapolation) wght=800 will match wdth=159
• (extrapolation) wght=700 will match wdth=125
• wght=600 will match wdth=100
• (extrapolation) wght=500 will match wdth=80
• (extrapolation) wght=400 will match wdth=63
• (extrapolation) wght=300 will match wdth=50
• (extrapolation) wght=200 will match wdth=40
• (extrapolation) wght=100 will match wdth=31
• (extrapolation) wght=0 will match wdth=25

The coef between each is 2 ** (1/3)

There's a problem with log relation: wght=100 is not mapped to minimal weight of 5. Besides, intermediate values are a bit hard to guess.
A better alternative is linear range: 100:1, 200:25, 300:50, 400:75, 500:100, 600:125, 700:150, 800:175, 900:200. That's a bit hard to guess though as well, also it's non-linear for min-weight.

Factor of 4 would work better: 40:10, 100:25, 200:50, 300:75, 400:100, 500:125, 600:150, 700:175, 800:200, 900:225, 1000:250. It perfectly gives width=100 for font-weight=400. It gives very predictable results. But very meaningless for manual linefont entry: values are very localized around ~50..200. Also it underutilizes mapping: we could've just left designspace coords.

An alternative is sqrt2 non-linearity:

• 100:18.75, 200:25, 300:37.5, 400:50, 500:75, 600:100, 700:150, 800:200, 900:300

• 100:20, 200:25, 300:40, 400:50, 500:80, 600:100, 700:160, 800:200, 900:320 (non-smooth)

• 100:16, 200:25, 300:32, 400:50, 500:64, 600:100, 700:128, 800:200, 900:256 (non-smooth)

• 0: 12.5, 100:17.5, 200:25, 300:35, 400:50, 500:70, 600:100, 700:140, 800:200, 900:280 (actual log) It makes much more sense for linefont wght, a bit less for wavefont, but 12.5 is too think for min value

  

• 0:10, 100:12.5, 200:20, 300:25, 400:40, 500:50, 600:80, 700:100, 800:160, 900:200 This makes min possible reachable value, spans nicely until 900, has 40 for 400 and 50 for 500,

• 0:10, 100:15, 200:20, 300:30, 400:40, 500:60, 600:80, 700:120, 800:160, 900:240 Closer to log2, but harder to pick exact values of 100, 200, 50, 25.

• 0:8.75, 100:12.5, 200:17.5, 300:25, 400:35, 500:50, 600:70, 700:100, 800:140, 900:200 This makes min possible even smaller, closer to log2, allows picking 100, 200, 50, 25, but has a bit meaningless intermediaries

• 🥇: 0:8, 100:12, 200:16, 300:25, 400:32, 500:50, 600:64, 700:100, 800:128, 900:200 Has a bit better intermediaries and close to log2. But difference from 0..100..200..300..400 is hardly noticeable

• 0:20, 100:25, 200:32, 300:40, 400: 50, 500: 64, 600: 80, 700: 100, 800: 128, 900: 160, 1000: 200 Has all major ratios/values: possible to predict. A bit too slow and too thick at mins, also min=20 is too thick.

• 0:6,100:9,200:12,300:18,400:24,500:36,600:48,700:72,800:96,900:144,1000:192 Classic typographic sequence; has too little difference on smalls; tailwind doesn't know 18. Also too shifted to the left (small) part.

• 0:8, 100: 12, 200:16, 300: 24, 400: 32, 500: 48, 600: 64, 700: 96, 800: 128, 900: 192, 1000: 256 Very standard values; classic typographic set; tailwind-compatible; hard to match against width span, eg. 312.5:25 and 200:9XX

• 🥈 0:9, 100: 12, 200: 18, 300: 25, 400: 36, 500: 50, 600: 72, 700: 100, 800: 144, 900: 200, 100: 288 Classic typographics scale; predictable 25,50,100,200 numbers; close to log2; good min value; extra range 0..100, 900..1000. Min is a bit too thick

Note that weight span is 1..1000, not 100..900 https://github.com/googlefonts/axisregistry/blob/main/Lib/axisregistry/data/weight.textproto#L4.

[dy]

@RosaWagner I am going to need to readjust linefont/wavefont weight mapping to better match 2 ** (1/3) coef. Also I am going to reintroduce wdth axis for wavefont - turns out it's very practical to have that - considering weight is limited to 5..200, wdth can be 25..200 safely as well without growing font size much. Also I am going to redo the first promo image, it must be more inspirational / showcase, rather than features list.

[RosaWagner]

@dy wavefont is already onboarded and live, we can't change the weight axis anymore otherwise it's going to break all website using it.

[dy]

@RosaWagner the change just better maps intermediate weights 800, 700, 500, 400, 300, 200, 100 to more precise log values (within 15%), because current values are handpicked and not precise. Would that be a breaking? Can we make a major iteration of font? In current form it's not as useful. New version will also look better in font tester - because wdth axis will introduce natural spacing between bars.

[RosaWagner]

If the wdth axis only adds space, with have a registered spacing axis

[dy]

I see. In wavefont wght and wdth play same role, if following axis definitions. But wdth would match linefont. So it's either linefont should use spacing instead of wdth or wavefont should use wdth and not spacing. Otherwise it would be difficult to match these two fonts - spacing has relative percentage units -100..+100, wdth has absolute-ish units 25..200. Besides wdth range nicely matches design-space wght range 5..200, so that these two axes play well, unlike spacing+wght.

One anticipated change introduced by wght: figma displays wavefont the following way:

With wdth it would look more like this:

So yes, it could be a breaking change

[RosaWagner]

Okay, please do the changes, better breaking sooner than later

[dy]

@RosaWagner I've just released v4. It includes wdth axis. .woff2 size didn't change, .ttf got +7kb, not +30% as I expected. Now font has way nicer default look, so everyone wins from that:

Also it has properly mapped typographic-scale widths.

I am going to come up with poster design using the new version. Looking forward to your feedback. Sorry for the post-changes.

[dy]

Cold shower from using new wdth axis.

• Now to ensure 0 spacing, a wdth axis must be adjusted to meet wght . Changing wgth with 0-spacing becomes problematic.
• Since wght axis is non-linear and measured in 1..1000 units, this becomes non-obvious procedure: need to find mapping wght -> wdth on every wght change.
  • Another complication of that - making proportional spacing, say, 1:2. With just spacing it's as simple as letter-spacing: 2ch;. With wdth that requires picking appropriate mapped value from 25..200 -> 1..1000, and then adding required spacing.
• Non-linear wght is asymmetric: white lines gradient here doesn't match black lines graient:

[dy]

Ok, linearized wght axis, removed wdth axis. It must be a good balance of simplicity / predictability now. No big damage introduced, in fact existing designs must be improved.

[RosaWagner]

Are you able to keep the default weight at 100 like before?

[dy]

It's a bit problematic - I'd need to add extra master, which increases font-size/source size. Is min value not desirable?

[RosaWagner]

Not this min value that can't be attached to any existing instance, it can create rendering issue and naming conflict in an environment that doesn't support variable fonts. What would be the size increase?

[dy]

Ok, I will add a master for default value. It won't be significant, just minor performance tax and /source increase up to 30%.

[dy]

Added default as 100. .ttf size increased from 77kb to 100kb, .woff2 size didn't change.

[RosaWagner]

it's a very acceptable increase ;)