Weight -> Outline

[davelab6]

This family could have a 'true' weight axis, so I'd like the axis currently set up as Weight to be recalibrated as 'outline.'

http://variationsguide.typenetwork.com/#otln

@dberlow where is the best place to learn about how to gauge 'per mille of em' values for an axis like this? :)

[sursly]

That's great! I didn't know otln was a thing. I'd be happy to make the switch from wght to that. What would the styles be here (since I'm assuming we'd ditch "bold", "black", etc.)?

[sursly]

Hey @davelab6 in looking at that spec, I'm curious how Google is handling it. I see:

Valid numeric range: Values must be in the range 1 to 1000
Scale interpretation: Values can be interpreted as per-mille-of-em
Recommended “normal” value: default is 0

In that example gif pulled from typenetwork 👆 default looks to sit in the middle of minimum outline and maximum outline (where it is completely solid). But if the "normal" value is 0, then our range of 1-1000 doesn't seem like an option. Unless I'm confusing everything (which is possible). Are any other GF typefaces using "otln" as an axis?

[dberlow]

Thanks for your question. You are correct, everything (which is possible), is what we tried to account for. In the example, the full range allowed is not possible because the demo weight is not bold enough. At wght max of the same design space as the example though, if the H stem weight was e.g. 2001/1000ths, it’d be unlikely bold, and unlikely anyone would make a 1000 unit outline weight of that weight, but that is the maximum we decided to propose. Put another way, the possible weights of an outline can vary over the weight range, as well as over the width and optical size ranges. And in variable fonts, the value range of the outline in the default does not have be the same range over the entire design space. But as implemented, we can only specify one value range for the outline for the whole design space. Recording the actual value accurately over the entire wide Designspace of width, weights and sizes will require extension of the avar table, aka avar2. This implies that a Developer serious about a wide ranging outline axis now, might be better off describing it as a percentage ranging from 0 to 99% or so. Whatever value is selected could be consistent over the entire design space, though the exact value of the outline per/1000 would not be known. Cheers, dberlow

[davelab6]

Thanks DB. However, I still need to know how to gauge 'per mille of em' values for this Tourney typeface :)

(off topic but related thoughts: A ppem is useful for matching other ppem values; this is more important for opsz spacs. A percentage is okay for a more simple design space like this. A breakdown of opq in x and y would not be too useful, its better to blend those into the single axis as it is here.

[sursly]

@davelab6 what would the ideal style names be? (assuming that the current weight is regular)
In looking at this spec https://github.com/googlefonts/gf-docs/tree/master/Spec I'm not sure how to rename things. And I like @dberlow's idea of using the OTLN value as a percentage in this manner. Keeping the width first makes sense, so would something similar to this be okay?

• Tourney Condensed OTLN20
...
• Tourney Condensed OTLN100
...
• Tourney OTLN 500
...
• Tourney Expanded OTLN 700

etc.

[davelab6]

Please use the axis name instead of the 4 char tag, regular people don't know how to make sense of the tags :)

[davelab6]

For ordering the style particles, I think $family $size $weight $width $slant $italic $custom is good; this seems to roughly adhere to the English grammatical rule for order of adjectives, and perhaps $custom has to do so recursively as well.

a book called The Elements of Eloquence: How to Turn the Perfect English Phrase. Adjectives, writes the author, professional stickler Mark Forsyth, “absolutely have to be in this order: opinion-size-age-shape-colour-origin-material-purpose Noun. So you can have a lovely little old rectangular green French silver whittling knife. But if you mess with that order in the slightest you’ll sound like a maniac.”

– https://qz.com/773738/how-non-english-speakers-are-taught-this-crazy-english-grammar-rule-you-know-but-youve-never-heard-of/

[davelab6]

cc @m4rc1e as we are discussnig how to handle VFs

[davelab6]

@sursly what is your proposal for the style names? A spreadsheet draft might make sense :)

[sursly]

@davelab6 It's tough, I'm not sure what the specific styles should be. Decovar (https://v-fonts.com/fonts/decovar) uses "inline" which is what Tourney is also doing, but Outline is clearly proposed in that typenetwork spec.

The only reason I rolled with "weight" was because I knew it would work well in applications, and it made sense to me from a user's perspective. I'm not arguing for keeping that, just explaining my thought process by "thin" being a thin outline (or huge inline) and "black" being solid.

The other thing I considered was optical size, since at even a relatively large font size, the current "ExtraBold" has a really subtle inline style (looks great HUGE though).

I think it depends on what axis name we decide to use. I'm flexible 🤷‍♂️