axisregistry: Axis order of user defined axes #2702
Comments
|
How do designSpace instances go into fvar and STAT and static fonts is indeed something we need to better define :) This will need to be a superset of the axis registry fallbacks, because those have to be limited because of the combinatory explosion. I'm guessing we will get min, default, max, or default, mid, max/min, so only 3, for most user axes. But I know designers will want to include more named instances than that. Handjet's element shape axis is a great example, but opsz probably also has this issue. The problem with sorting them alphabetically by axis tag is that eg XPRN would sort late but by axis label Expression would sort early. English grammar has sorting rules for adjectives (https://qz.com/773738/how-non-english-speakers-are-taught-this-crazy-english-grammar-rule-you-know-but-youve-never-heard-of/ & https://slate.com/culture/2014/08/the-study-of-adjective-order-and-gsssacpm.html & etc etc) and so I believe we ought to have a defined order that is done with respect to that grammar. The registered axes set needs to account for families with both Family name (nameid 1) I forget what the WWS nameid 18 (+19?) can do... |
|
So I guess a text file with # for comments will be the most simple way to make an ordered list of axes, by label not tag, and there will be at least 8 commented lines to segment the list into these sections, and then a test will be to check that all axes in the registry are listed in the file. opinion-size-age-shape-colour-origin-material-purpose |
|
So, this is the order I propose If defaults are not elided and a 'franken-font' was made with all the axes, it would be like this:
Or, with non-default values, like this:
A more realistic couple of examples of real-world Recursive, Fraunces and Handjet axes:
However, So perhaps the Cursive fallback for the The Anyway, this is as far as I got today, and isn't my final recommendation. I also said earlier,
I looked into this. To recap, https://docs.microsoft.com/en-us/typography/opentype/spec/name lists the nameIDs, and the relevant ones are:
https://glyphsapp.com/tutorials/naming is also a great explanation of this topic, and has section titled "WWS Names: Name IDs 21 and 22" that well explains:
It also has these 2 important notes:
I note that WWS is (1) Weight, (2) Width, (3) Slope, not (1) Width, (2) Weight, (3) Slant, as I've seen it ordered/named. If we do go with the second ordering, that might mean more work to map to MSOT/OFF systems, which seems undesirable. |
|
If also like to resolve #2701 as the spaces in the particles in my examples are a bit ambiguous. |
|
There's also some undocumented trick that @twardoch figured out to fix the ordering in Adobe apps |
|
Why do we need to impose a sigle order for the axes names to all google fonts? Can't the font developer decide this for each specific project at hand depending on whatever they think is more important? The ordering of the STAT table's DesignAxes should be enough, I think. |
|
See the
https://docs.microsoft.com/en-us/typography/opentype/spec/stat |
For generating static fonts from the list of fallback instances.
We'll need to make sure that field matches our registry order. I'll file a fontbakery issuue. |
|
I understand this is for generating static fonts from VFs. What I don't understand is why we have to come up with an artificially general ordering for all the fonts in our library when font naming is, in my view, the responsibility of the font designer and specific to each font project. If that design intent is encoded in the font somewhere (e.g. the STAT axis records' ordering), then the fonttools instancer tool can use it to generate the instances names without needing access to an external, and GF-specific AxisRegistry database. |
This is my main concern. Imo axis particles should be ordered in a consistent manner when we instantiate static fonts. The existing statics we serve do have an explicit order so we shouldn't be breaking this. |
consistent with what? With the rest of the other fonts in GF library (i.e. there should be an enforced common ordering across all fonts)? Or consistent with the static fonts that are produced by the font developer alongside a VF (but not from it)? |
yes and there already is an enforced ordering. You won't ever see "familyName-ItalicBold.ttf", you'll always get "familyName-BoldItalic.ttf". Weight always appears before italic in our collection. |
|
Having worked or interacted wiith many hundreds of type designers (as part of my MyFonts and FontLab work), I can say that the vast majority prefers strong recommendations and will happily follow them. There may be a handful who will want their own ordering, who are also willing to accept the risk that the font will not work very well on some environments. Most people will follow the publisher/distributor guide — this is the same realm as standardized glyph sets. Axis ordering is not an area where type designers desperately want their creative freedom. |
|
As a general rule, type designers want freedom when it comes to “numbers”: point coordinates (i.e. the actual glyph design), widths & sidebearings, italic angle, x/caps height, kerning, total line height. Then, they'll also want some freedom in forming collections: glyph repertoire (beyond minimal sets), kerning class composition, number of OT features. But they prefer recommendations in anything beyond, esp. font names (except the family name), licenses, glyph names, ways to order items within the said collections, and pretty much everything that influence that their font may work “better” vs. “worse” in existing apps & OSes. |
|
Ok fair enough. I just want to insist that whatever the publisher's recommended ordering, it should be encoded in STAT and the instancer should look at that only, not to an external vendor-specific Axis Registry. If the STAT ordering doesn't match the expected order, it should be fixed in the source, rather than discarded/overwritten. |
|
That's a “management issue”. I mean the question at what level a problem should be fixed. |
|
The really important question is: should wght or wdth come earlier. Tradition dictates: wght (so: Bold Condensed). That's Adobe-made tradition, which is actually recommended somewhere (I can dig it up). But the more advanced Adobe tradition for their Pro fonts is "wght wdth ital opsz" (Minion Pro Bold Condensed Italic Caption). Or is it wght wdth opsz ital? Need to check. In my view, the opposite ordering would be better, because the ordering of particles should guide the user in first separating fonts that you don't mix within the same line, and then leading you to choices where you can combine fonts within a line.
Another way of expressing that is that the trait that changes the geometry and color of the entire text more should be ordered earlier. Not sure how GF currently does it — but I think we should either follow the old Adobe tradition OR adopt a new one (like the one I outlined). Whatever we do (be it as enforcement or recommendation) will impact other makers, so this is a sort of industry-wide decision. Opinions? |
|
One more approach would be to adopt the general principle I described, but make the exception as a nod to the prevailing tradition, and sort wdth after wght, not before. So: opsz wght wdth ital — and use the “principle” for any axes beyond. |
Minion (one big family): Minion Pro, Semibold Cond Italic Display |
|
Not sure whether this is relevant, but putting weight and italic axes last makes it convenient to generate name ID 1 and 2 style families consistent with naming of larger family and style groupings. |
|
“Purpose” should be higher in the hierarchy, probably second only to the primary family name. The purpose of a font determines so much about whether a designer should even bother reaching for it; all other considerations of specific styles come after that. Basically, the “Purpose” is a logical sub-family. For example, As another example, stencil fonts are common sibling families to other fonts. But, they are often not really compatible for the same contexts/purposes as their non-stencil counterparts. So, House Industries’ Yet another example is Commerical Types Dala family, which has two stencil families (Dala Floda is a serif, while Dala Moa is a Sans), plus a multi-line family, Dala Prisma. Or, perhaps, this is missing “Category” as a categoryPerhaps, “Monospace” is misplaced under “Purpose,” if “Category” and “Purpose” are separate ideas. “Monospace” and “Stencil” could be called font categories, similar to “Sans” and “Serif.” When considered like this, it is pretty clear that those terms should immediately follow the primary family name. And, maybe “Purpose” means something else, such as whether a particularly style is meant for screen/print media or light/dark backgrounds. Then again, often these purposes would still be useful to sort earlier in the decision tree, for less-noisy font menus, so I’m still unsure that putting these close to the end is best. |
|
This is the current status of the STAT table axis ordering on the entire Google Fonts collection:
|
|
I agree i misplaced Monospace. Category seems like a synonym for opinion :) |
|
I suppose if we find it important to map to that grammatical structure, then that might be a way to do it. One layer of complexity: A font could contain multiple terms within one name level. For example, there may be a hierarchy within categories (or maybe these are "opinion" or "shape"): Serif / sans-serif / Script would usually come before Monospace / Stencil, as the latter could be maybe layered by onto the former. E.g. there could be a Futura Serif Mono, or a Recursive Script Stencil. I don't think Futura Mono Serif or Recursive Stencil Script make quite as much intuitive sense. Or maybe "stencil" is a shape name. It isn't so dissimilar from Casual/Linear. In this case, however, it may also need hierarchy within the Shape tier. Also... I think opsz may be a "purpose" name. For Recursive, it would make sense to have "Recursive Mono Casual 144pt," but not as much to have "Recursive Mono 144pt Casual", as your first ranking suggested, davelab6. |
I'm currently working on a tool which will update a designspace's instances based on our axis registry. Have we established an order yet for the user defined axes e.g CASL, GRAD etc?
For registered axes, we have the following order:
opsz wdth wght itale.g12pt Condensed Black ItalicIf we don't have an order, shall we just sort the user axes alphabetically?
For variable fonts we currently only include the wght and ital axes in the fvar instances so this request isn't relevant. However, for the static fonts, this info is important since a family which is constructed from multiple axes should be split into many different sibling families. If we take a look at Literata's static fonts we can see that it consists of four different families. Same situation for Fraunces as well.
The text was updated successfully, but these errors were encountered: