Spec: How to order font name particles?

[davelab6]

For ordering font naming particles, I think

1. family
2. optical-size
3. weight
4. width
5. slant
6. italic
7. 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.

Here's the rule:

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:

1. opinion
2. size
3. age
4. shape
5. colour
6. origin
7. material
8. purpose
9. 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/

Microsoft uses "WWS" for Weight, Width, Slope, and I think for families with both slant and italic, slant should be first, as slant is about shape, while italic is sort of more about 'material' (or even origin!)

[arrowtype]

Interesting way to frame this theory.

Typographically, “italic” tends to be more about “purpose” than material (it’s all digital) or origin (despite the naming, none of my type is made in Italy). The primary purpose of italics is to provide a modified typographic emphasis on certain text.

I haven’t simulated it in my head all the way through, but I suspect that most people would be confused if the slant were mentioned before width & weight.

Another way to look at this is: how much does each parameter effect the layout or overall line length? In that sense, the typical order is probably:

1. Width
2. Weight
3. Italic
4. Slant

But, it’s hard to say where Optical Size would tend to land in there.

So really, it’s probably more about a user's “decision tree.” How does the typical type user filter down to what they want for a given typographic moment? This might be:

1. Optical size (how big is this element?)
2. Width (how much room do I have?)
3. Weight (how intense should this be?)
4. Italic (is it special?)
5. Slant (should it be modified visually?)

[davelab6]

I haven’t simulated it in my head all the way through, but I suspect that most people would be confused if the slant were mentioned before width & weight.

Sorry, I just meant between slant and italic, which should be 1st/2nd

it’s probably more about a user's “decision tree.”

@dberlow calls this “the mantra,” I think :)

Eg

Roboto Latin 36pt Bold Condensed 9deg Italic Positive Grade

[m4rc1e]

We currently have the following:

opsz wdth wght

https://github.com/googlefonts/gf-docs/tree/master/Spec#instance-names

---

I'm starting to believe we shouldn't include every axis particle in the instance names. I'd prefer the non-registered axes to be included in the STAT table only. Even if no apps currently use the STAT, users still have sliders in DTP apps to control these axes.

I honestly think we should make a decent test case and run a UX test before we make a decision on this.

From my point of view, I don't want to see hundreds of instances. If i want precise control, I'll adjust a slider.

By not including every particle, we'll avoid font menu name clipping as well. "Roboto Latin 36pt Bold Condensed 9deg Italic Positive Grade" is definatley going to clip :-)

[dberlow]

I’m not sure how this order is chosen for the future. opsz wdth wght Most design thinking is ordered, opsz wght wdth Width before weight happened because both size and width needed to be part of the family name, (e.g. ITCFranklinGothicCondensed-Bold, or MillerDisplay-Regular), for technical reasons that led to separate families for sizes and widths. While this made for less complex style menus, the selection of styles was just being fragmented among multiple "family" selections. I agree we shouldn't include every axis particle in instance names, and that the instances should be at about the same stylistic granularity as non-variable font families. The issues as I see them are size and expression axes, and how to handle them without proliferation. My most conservative take would be to let apps that use opsz by default, (i.e. the app that uses the font size input by the user to set the opsz value), could only show styles with wght, wdth and posture changes. Apps that don't engage opsz automatically, are probably better off showing the same thing, and if the user is more sophisticated than the app, they can slide opsz to what they want. So in this take, menus are only going to contain a typical array of weights, widths and italic/slant. If there are expression axes, these perhaps can be broadly classed as coming in two forms; those that depend on a variation range, and those that depend on one or more locations along the axis where the expression changes. The former, expressions for animation, or how far a swash swashes, or how it ligates, are probably not menu-worthy. But other fonts, like Recursive and Decovar have expressions in axes extremes and combinations that can be valued instances. In such a case, if styles and expressions combine to make too long (or wide), a style menu, one could say it's because the user chose a variable font with lots of stuff.

…

On Fri, May 15, 2020 at 5:28 AM Marc Foley ***@***.***> wrote: We currently have the following: opsz wdth wght https://github.com/googlefonts/gf-docs/tree/master/Spec#instance-names ------------------------------ I'm starting to believe we shouldn't include every axis particle in the instance names. I'd prefer the non-registered axes to be included in the STAT table only. Even if no apps currently use the STAT, users still have sliders in DTP apps to control these axes. I honestly think we should make a decent test case and run a UX test before we make a decision on this. From my point of view, I don't want to see hundreds of instances. If i want precise control, I'll adjust a slider. By not including every particle, we'll avoid font menu name clipping as well. "Roboto Latin 36pt Bold Condensed 9deg Italic Positive Grade" is definatley going to clip :-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#63 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAO5VDTLCIJXGIWRHSPOCO3RRUDNLANCNFSM4NBADZ5A> .