update WONK axis to close issue #2741

[arrowtype]

Summary:

• Updates axis name to “Wonky” to grammatically align with other binary axes such as Italic, Casual, Monospace (these are all 0–1, false / partly true / true axes, so they should probably all have adjectives for names
• Updates “Normal” style name to “NonWonky” for more clarity to users, and to avoid a naming clash with Italic/Normal values for font-style in CSS

See #2741 for details.

[davelab6]

Can you explain the Normal clash? I don't ever see font-style applying to this axis, and "the wonky axis is non wonky" sounds worse to me than "the wonky axis is normal"

I agree with the axis label change, because it's shorter and simpler.

[arrowtype]

Can you explain the Normal clash? I don't ever see font-style applying to this axis, and "the wonky axis is non wonky" sounds worse to me than "the wonky axis is normal"

There wouldn’t ever be a directly clash as far as I know; it’s more that I see "Normal" as sort of a significant word for font styling, and that significance is on the Italic axis due to CSS.

In this specific case, I see the bigger reason actually being that Wonky/NonWonky make more sense in a potential STAT-based font menu. The default of this axis is intended by @sponcey to be Wonky/WONK=1 because it allows fun/wonky letter shapes at higher optical sizes. Because Wonky is the "normal" value, it would be confusing if the non-default option were called Normal in a menu. NonWonky is the exception that turns off the wonk, so it is a more direct label.

[arrowtype]

(Side note: this axis is somewhat like the Cursive CRSV axis in Recursive, in that it modifies shaping behavior, but probably shouldn’t be included in automated static fonts generated from a variable font. In the static fonts, the 72pt & 144pt styles have wonk, while the 9pt styles don’t. Adding the extra dimension would just increase the number of static fonts in a not-very-meaningful way, and create duplicate fonts at the 9pt optical size.)

[davelab6]

I think, like fvar, it's better to start out with less, and perhaps add in more later. So let's just not have any fallbacks.

If the 0.5 value is "auto" then that should be the default, I guess

[davelab6]

Similarly i wonder if we should remove the fallbacks from https://github.com/google/fonts/blob/master/axisregistry/cursive.textproto

[arrowtype]

Maybe I’m unsure what fallback means, precisely. Are these stops along the STAT table used for naming/navigating designspaces, or do they have a distinct purpose? I would hesitate to remove that information...

Also, just to be clear, WONK operates on a somewhat similar idea to CRSV, but it doesn’t use 0.5 as the default.

WONK has two states:

• On (1) [default], which makes wonky shapes appear above 22pt opsz but not below 22pt
• Off (0), which prevents wonky shapes from appearing at any size

By contrast, CRSV has three states:

• Off (0), which asserts roman-style letters regardless of slant
• Auto (0.5) [default], which allows cursive alts at slants of 14 or more
• On (1), which asserts cursive-style letters regardless of slant

Not sure whether this impacts whether they have fallback names or not, but it is my understanding that WONK needs two names in the STAT table, and CRSV needs three names in the STAT table.

[RosaWagner]

We have several axes with 0=normal, as default, and it makes sense because the default value gets elided in the STAT and therefore don’t appear in the instance names.

If you want wonky and cursive to work the same way, and to be consistent with the rest of the axis a registry, it would be:

Wonk[0]=normal
Wonk[1]=wonky

Crsv[0]=normal
Crsv[1]=cursive

(With appropriate ranges and elided values in the STAT.)

The default and the origin would also be consistent (Fraunces Regular), with all axes set up to Regular/Normal/Roman.

[RosaWagner]

But I maybe didn’t understand something.. Is the Regular master already wonky?

[arrowtype]

If you want wonky and cursive to work the same way, and to be consistent with the rest of the axis a registry...

Please no. This would break both typefaces. Neither of them work quite as 0="normal", 1="styled". Please see my comment above for a description of how they work.

Just like not every font should look the same, not every font should act the same.

But I maybe didn’t understand something.. Is the Regular master already wonky?

Short answer: yes.

Long answer for anyone who is interested in understanding this subject a little further:

In Fraunces, there isn’t a "Regular master" per se – it defines the corners with 8 sources/masters:

• 9pt [Sharp] Thin & Black
• 9pt SuperSoft Thin & Black
• 144pt [Sharp] Thin & Black
• 144pt SuperSoft Thin & Black

It has the same in Italics.

(Not that this should dictate the defaults in the final variable font, but) the fonts are drawn to have the “Wonky” glyphs as defaults, e.g. the wonky n has the unicode 006E.

They may help show the designer’s intent. However, I also have to say that the way sources are drawn shouldn’t necessarily determine what is or isn’t the default in final variable font. Sometimes, things are just drawn in a certain way for convenience or to cover legacy software (more on this in a moment). The designspace <rules>, compiled into rvrn or rclt, are what should determine the default states of the VF. In Fraunces, you can see that "NonWonky" glyphs are activated under certain conditions:

<rule name="NonWonky">
      <!-- If the opsz is <18, activate NonWonky glyphs -->
      <conditionset>
        <condition name="Optical Size" minimum="9" maximum="18"/>
        <condition name="Weight" minimum="100" maximum="900"/>
        <condition name="Softness" minimum="0" maximum="100"/>
      </conditionset>
      <!-- If WONK is < 0.49, activate NonWonky glyphs -->
      <conditionset>
        <condition name="Wonky" minimum="0" maximum="0.490000"/>
      </conditionset>
      <!--Glyph substitutions -->
      <sub name="ampersand" with="ampersand.alt"/>
      <sub name="h" with="h.alt"/>
      <!-- etc -->

Full rule at Fraunces.designspace, Lines 29-L64

I say that “the way sources are drawn shouldn’t necessarily determine what is or isn’t the default in the final variable font,” because Recursive is a little different. Because it fits Mono & Sans styles into a single variable font, the default glyphs in the sources aren’t the default for any of the styles, but rather shapes that are acceptable if software ignores or can’t parse the rvrn rules at all. The l is neither the simple l.sans nor the serifed l.mono, but the "italic" version which can look okay in upright Sans or Mono text. Several other characters are the "sans" versions, which ended up being the default for the VF, but don’t indicate the defaults for the Mono.

This way, if a user opens Recursive on an old OS or app that ignores rvrn/rclt, they will still see letters that have okay shaping. If they had a Recursive Mono VF and I had just put the l.sans as the main form of l, then every l in their code would look pretty bad, with a huge “hockey stick” shape.

Similarly, I suspect that Fraunces was drawn with Wonk as default partly because it is at heart a display font based on fonts like Windsor and so intends these to be default. The more-normal, NonWonky shapes are then needed in the Text styles to make small running text more readable, or there if a user wishes to use large sizes of Fraunces in a way that is a bit more formal.

One thought: instead of “Wonky” & “NonWonky” we could instead call the 0 style "Formal" ...

@sponcey, what do you think?

[sponcey]

👍 vote on "Formal". Also I like that it rhymes with "Normal" :P

[arrowtype]

👍 vote on "Formal". Also I like that it rhymes with "Normal" :P

Nice! It sounds good to me, too. I’ll update this PR & Fraunces to fit that.

Thanks for weighing in. Hopefully once this is updated, the team agrees and we can merge it.

[davelab6]

I wonder if the antonym of wonky is true...

[arrowtype]

Hmm, I think it is fairly true.

The main reason I can think that “NonWonky” is better than “Formal” is that the term “informal” is used by some to describe display styles that are offshoots of standard fonts. TypeMedia teacher Peter Verheul uses this term a lot, so potentially, someone may come along with a FRML axis at some point.

[arrowtype]

(I would add that “Normal” doesn’t seem to be much truer of an antonym to “Wonky” than “Formal” is. But, in the way “Wonky” is used in Fraunces, I think that either are antonyms, but because “Normal” incorrectly suggests a default, it is untrue.)

[arrowtype]

So, I’m quite convinced that Normal isn’t the best name, but I don’t know what to do here.

@davelab6 do you think I should change this to Formal or leave this as NonWonky?

[davelab6]

My suggestion was "True". Like when you "true up" a wonky bicycle sheet.

[davelab6]

@sponcey what's your final preference?

[sponcey]

Hmm. "True" seems a little more esoteric to me... maybe not as straightforward as "Wonky" and "NonWonky". I think I would prefer the later.

[rsheeter]

Spaces to match others, e.g. "Extra Light" not "ExtraLight."

[rsheeter]

Might want "Not Wonky" over "Non Wonky"?

[RosaWagner]

@thundernixon, does this change (noT instead of Non) would require to regenerate the fonts with a new stat table ie. go through the all process again ?

[rsheeter]

The space is mandatory so if that's true you can't get out of going through the process again.

[RosaWagner]

In the fonts we send, we don't have space for any fallback names. So the space would be added only in the axis registry. Although a difference of letter may be a bigger inconsistency.

[arrowtype]

I’m okay to rebuild the fonts to change this if needed, once we land on a solution. 🙂

Hmm, as for "Not Wonky" vs "Non Wonky," I think it could probably go either way. I gravitate towards "Non Wonky" because non- is a prefix, and in my head this binds it better as a single style descriptor, whereas "Not Wonky" sounds more like a statement or near-sentence. I can’t really decide whether there is a meaningful difference between "The font style is nonwonky" and "The font style is not wonky." To me, using specific style terms as single words does help suggest that they are specific values, rather than generalized statements. E.g. "The font weight is SemiBold" indicates a specific wght of 600, whereas "The font weight is Semi Bold" suggests that the weight is somewhere less than 700.

Perhaps, though, an important thing I got wrong in "NonWonky" is that it mistreats the prefix. It should probably be a choice between "Not Wonky" and "Nonwonky." I somewhat lean to the latter, but I don’t have a strong feeling one way or the other. I just want to get this font out to The People, and will happily accept any decision.

[rsheeter]

"Normal" seems like it could be a position that applies to many axes; it's where the text isn't , the intersection of various axes in some sense. That said, as long as you fix the spacing, LGTM.

[arrowtype]

I’ve added a space. If we’re okay with Non Wonky in the axis registry and NonWonky in the font (per the typical GF naming convention for font style names), then this is good to go.

[davelab6]

Thanks @rsheeter for approving!