How many weights are too many / style linking in large families

In current project, I'm considering 23 weights per subfamily, six subfamilies. I thought it might be useful to be able to equalize stroke weight between words in different point sizes, like stacked vertically and sized so that they fill the container horizontally. I'm not all that sure if that's a common use case. But I've seen families with as many as 18 weights, so why not?
My question is regarding what naming scheme would be most readable. I tried something like this:
  • 5 Hairline
  • 11 Ultrafine
  • 17 Extrafine
  • 24 Fine
  • 31 Ultrathin
  • 38 Extrathin
  • 45 Thin
  • 52 Ultralight
  • 59 Extralight
  • 66 Light
  • 73 Demilight
  • 80 Regular
  • 87 Demidark
  • 94 Dark
  • 102 Extradark
  • 110 Ultradark
  • 118 Demibold
  • 126 Bold
  • 134 Extrabold
  • 142 Ultrabold
  • 150 Black
  • 158 Extrablack
  • 165 Ultrablack
Weights are prefixed with stem weight, so that it is clear how much one differs from the next, and also what is the ratio of their stroke weight. Technically this makes it possible to mathematically calculate the appropriate weight for the given font size.
The main reason for adding in the numbers though, is simply the amount of weights. Without the numbers, it would be daunting to find the file for the desired weight in a directory, let alone decide whether Thin is thinner than Fine.
I found that it works fine, but I'm concerned whether style linking is feasible with this scheme. I linked 80 Regular and 126 Bold successfully I tested in InDesign and LibreOffice (and GIMP, MS Paint...), but:
* The Windows "Fonts" folder only displays one at a time instead of a neat font group. It is possible to uninstall them one after the other, as when one is removed, the other appears in its place.
* Doesn't work in MS Notepad. Only '80 Regular' is shown and accessible.
How much of a concern would you assess this is, given it's a display-exclusively font? Also, as I don't own a Mac yet, would you expect any roadbumps there?
Is it better to just neglect style linking at all in this case? Or the contrary, would you link even more styles together, e.g. Light with Ultradark, Thin with Demidark, etc.?

Comments

  • Do you envision the user wanting to embolden selected text within running text? That’s where linking is most useful. If that’s not a common use-case then maybe leave it out. 

    BTW to me “ultradark” sounds bolder than “demibold.”
  • Adam JagoszAdam Jagosz Posts: 689
    edited December 2019
    At first glance, I envision more advanced users selecting a weight precisely, and the less advanced ones just using Regular and Bold. But that's just a thought.
    Good point, I was hesitant whether to include Demibold at all as I used the Demi- prefix in other places (Demidark, Demilight) as a diminutive opposite from Extra. But in truth it means "half" so maybe it's not a good match.
    I wanted something symmetrical to "Light..."  between Regular and Bold so that they can have enough contrast. "Dark" just seemed like a good match. Maybe "Ultra-" is the problem?
  • I think dark is confusing, as well... I would suggest the below, as a user. Also, when Demi is used on both sides of regular it seems confusing — when is it lighter or heavier? I know, but others may not. 
    • 5 Razor (?)
    • 11 Hairline
    • 17 Ultra Fine
    • 24 Extra Fine
    • 31 Fine
    • 38 Ultra Thin
    • 45 Extra Thin
    • 52 Thin
    • 59 Ultra Light
    • 66 Extra Light
    • 73 Light
    • 80 Regular
    • 87 Book (Could switch with Reg. depending on your opinion of the book weight)
    • 94 Medium
    • 102 Bold
    • 110 Extra Bold
    • 118 Ultra Bold
    • 126 Heavy
    • 134 Extra Heavy
    • 142 Ultra Heavy
    • 150 Black 
    • 158 Extra Black
    • 165 Ultra Black
  • Adam JagoszAdam Jagosz Posts: 689
    edited December 2019
    One more thing I wanted was to have Light to have the weight class around 300 as in typical Light. This would mean I need something between Regular and Light.
    As for Medium, Regular is the “medium” weight here, so I'm not going to add another.
  • Adam JagoszAdam Jagosz Posts: 689
    edited December 2019
    I though Dark could be interpreted as the opposite of Light. As in not "completely dark", just "typographically dark".
    As for precedent, there was some cut of Lucida with Thick, ExtraThick, Dark, ExtraDark, and Bold, ExtraBold, UltraBold. https://bigelowandholmes.typepad.com/bigelow-holmes/2015/07/on-font-weight.html
  • How would you feel about this scheme?
    •     5 Razor
    •     11 Hairline
    •     17 Extrafine
    •     24 Finer
    •     31 Fine
    •     38 Extrathin
    •     45 Thinner
    •     52 Thin
    •     59 Extralight
    •     66 Lighter
    •     73 Light
    •     80 Regular
    •     87 Thick
    •     94 Thicker
    •     102 Extrathick
    •     110 Bold
    •     118 Bolder
    •     126 Extrabold
    •     134 Heavy
    •     142 Heavier
    •     150 Extraheavy
    •     158 Black
    •     165 Ultra
    If anything, remember that the numbers are there exactly for the purpose of disambiguation.
  • I will probably be releasing a Variable version too, so maybe it'd be for the best to limit the number of static instances to a reasonable, smaller quantity?
  • Thomas PhinneyThomas Phinney Posts: 2,732
    edited December 2019
    If you do that—which you probably shouldn’t without a better rationale for making so many nearly-identical weights—I would suggest you use leading zeroes in the numeric prefixes. That way you will get correct style sorting even in non-savvy apps, and the styles will “line up” better in menus and lists.
    When you say “six subfamilies” do you mean six separate families, perhaps by width? So that they have completely separate menu listings in apps? As for “why not” it is because fonts with a zillion styles become pretty unmanageable, AND splitting up fonts like that into separate families really sucks for the user.
    Adobe did that split for Acumin, and it stinks. I hate it with a passion. I was trying to switch between Acumin and another family, in InDesign, and the style mapping was broken because Acumin is a separate family for each width. I had my styles all set up so that with a “normal” family I would just have had to change one style and everything else would cascade.
    On the other hand, with my current team’s Science Gothic variable font, once we added the italic (slant) axis, that final doubling of instances makes for over 200 predefined instances. Which is too damn many in one family, for apps that use font menus. Around 100 is still useable on a jumbo monitor. But 200+ not so much.
    Hence, I am thinking about actually un-defining some stops on the SG width axis, so as to make for fewer predefined instances.
  • Adam JagoszAdam Jagosz Posts: 689
    edited December 2019
    Leading zeros make sense. Actually InDesign or Windows Explorer doesn't need them, but I did see the weights mixed app in some other app. Thanks.
    It would make sense to make the progression tighter in lighter weights where the differences are far more noticeable, and gradually increase the delta between weights, right? The thing is, with the heavier weights the differences in the inner light are equally noticeable. So maybe the delta should increase and then decrease again.
    The six subfamilies are not by width, there are three stops on a custom "Mid-height" axis, and there are two separate cuts regarding texture: solid and stencil. They are separate families, which makes sense as they are perhaps intended to be switchable between each other during the typesetting. Here they are:
  • Adam JagoszAdam Jagosz Posts: 689
    edited December 2019
    I could cut down the number of weights to 18. Three questions:
    1. Does any of these progressions seem more reasonable?
    Stem width? ...or OS/2 weight? or simply or actually maybe
    005 Hairline 050 Hairline Hairline Hairline
    012 Extrafine 088 Extrafine Extrafine Extrafine
    020 Fine 133 Fine Fine Fine
    029 Extrathin 183 Extrathin Extrathin Extrathin
    038 Thin 233 Thin Thin Thin
    048 Extralight 288 Extralight Extralight Extralight
    058 Light 344 Light Light Light
    068 Regular 400 Regular Regular Regular
    079 Medium 461 Medium Medium Medium
    090 Thick 522 Thick Thick Demibold
    101 Extrathick 583 Extrathick Extrathick Thick
    112 Demibold 644 Demibold Demibold Extrathick
    122 Bold 700 Bold Bold Bold
    132 Extrabold 755 Extrabold Extrabold Extrabold
    141 Heavy 805 Heavy Heavy Heavy
    150 Extraheavy 855 Extraheavy Extraheavy Extraheavy
    158 Black 900 Black Black Black
    165 Ultra 938 Ultra Ultra Ultra
    2. Should Demibold come before Bold or not?
    3. I tried to keep weightClass here proportional to the variable axis for consistency. Do you think it would be better to try to stick to multiples of 100 (and 50 or 25)?
    Btw, I decided for a lighter weight for Regular, and dropped in Medium.
  • I could cut down the number of weights to 18. 
    ....
    2. Should Demibold come before Bold or not?
    3. I tried to keep weightClass here proportional to the variable axis for consistency. Do you think it would be better to try to stick to multiples of 100 (and 50 or 25)?
    Btw, I decided for a lighter weight for Regular, and dropped in Medium.
    1. 18 still seems like a crazy lot of weights. But that’s just my take. I mean, even 9 seems like a lot.

    2. Well demibold is certainly lighter than bold. Then again, “Thick” seems like it would be heavier than demibold. Heck, maybe even heavier than bold.

    3. No worries about sticking to some particular multiples. I am a bit perturbed by things like Medium at 421 instead of 500, and Light at 344 instead of 300. As far as I understand it, WeightClass is a set of labels that also have numbers, but not a scale that has a direct relationship to stem thickness. I understand you want to make it so, and that's not a bad thing, except that it means sacrificing the label<>number relationship that people expect. Not convinced that’s a good thing.
  • I must admit I was inspired by Positype's recent release, Hype, in 18 weights.
    About OS/2 weightClass, what is it actually used for? For automatic CSS generators? From docs, "usWeightClass values use the same scale as the 'wght' axis that is used in the 'fvar' table of variable fonts", so I wanted consistence here. And I do want the variation weight axis to be mathematically calculable, I'm planning to make a demo app for this.
    I guess I could also KISS, like this:
    • Hairline
    • Fine
    • Thin
    • Light
    • Semilight
    • Regular
    • Medium
    • Semibold
    • Bold
    • Heavy
    • Black
    • Extrablack
    • Ultrablack

    13 weights is still *still* a lot, but note that the extremes are indeed extreme. The black maybe not so much, but I couldn't go darker in the high-waisted cut and I wanted the variation axes to be independent.
    The last three weights are basically only for adjusting the counter in the Hi cuts to the font size, hence the similar naming. Got rid of the other prefixes different than the standard though! Without a variable-font supporting app, though, no more fancy stuff like this:

  • Adam JagoszAdam Jagosz Posts: 689
    edited December 2019
    I totally agree with everything you said. I could go a bit darker in the Lo cut but that would misalign it with Hi. I'd say with the current state of the project, it is not well suited to emboldening. I'd have to take a different strategy and lower the cross-stroke height with increasing weight.
    But I guess that the dark weights are not perceived as that too-light at larger sizes.
    I guess that five or six weights would be enough within the normal weight range applicable to medium point size. How about keeping some more lighter weights for really large display use? Or does that hardly ever happen?
  • Adam JagoszAdam Jagosz Posts: 689
    edited December 2019
    As I said, I wanted a more granular distinction near the ends of the axis, because the Hairline is really fragile and the counters in the ‘barely bold’, heaviest weight in the Hi cuts are too.
    So this should in fact go like this:
    • Hairline
    • Fine
    • Thin
    • Light
    • Semilight
    • Regular
    • Medium
    • Semibold
    • Bold
    • X Bold
    • XX Bold
    • XXX Bold
    • XXXX Bold
    Edit: to the Disagree-er: just kidding, obviously :grimace:
  • Thomas PhinneyThomas Phinney Posts: 2,732
    edited December 2019
    You just don’t have enough dynamic range to justify cluttering up people’s font menus that much, IMO. But, that’s me.
    font-weight is a CSS property that (in CSS 3) can take numeric values 100-900 in 100-unit increments. This is in no way restricted to “automatic CSS generators” but is a standard property that any CSS author can use.
    (In CSS 4, it will be any number from 1-1000)
  • Adam JagoszAdam Jagosz Posts: 689
    edited December 2019
    I mean, you define font-weight yourself in CSS, OS/2 weightClass is just an indication, in no way does it have to be equal.
    I still see 7-10 weights here, not 5-6, I'd just cut some of the bolder weights. I can live with the closing counters of the Black weight in Hi cut — you can always use Lo or default cut for smaller sizes. I guess I'll just have to sleep on it some more. About cluttering — for apps displaying StyleGroups people can install just the weights they want to use, for apps grouping preferred families it's just a couple more rows in the Style dropdown. Am I missing something?
  • Ray LarabieRay Larabie Posts: 1,376
    edited December 2019
    I don't like using Thin, Book or Medium because I think it's hard for users to guess where they belong. 
    • Ultra-Light
    • Extra Light
    • Light
    • Semi-Light
    • Regular
    • Semi-Bold
    • Bold
    • Heavy
    • Black
    • Extra-Black
    • Ultra-Black
    If you need to go extreme on the ends, add obviously extreme names like Mega-Black, Blackout, Singularity, Nano-Light, Hairline, Razor or whatever. But keep the core simple. The heavies might logically track better as Extra-Bold, Ultra-Bold, Semi-Black, Black, Extra-Black etc. but I think it's already well established that Heavy is heavier than Bold and Black is heavier than Heavy...I assume.
  • Thank you everyone for your input so far.
    Down to 9 weights. Letting go of Black, as none of the weights are black enough. I felt Heavy didn't bear that implication. Hairline could be Ultralight, but I think Hairline reflects the extremity better.


  • Adam JagoszAdam Jagosz Posts: 689
    edited December 2019
    Thank you everyone for your input so far.
    Down to 9 weights. Letting go of Black, as none of the weights are black enough. I felt Heavy didn't bear that implication. Hairline could be Ultralight, but I think Hairline reflects the extremity better.

    I wanted to drop in a PDF as well but it appears I chose the wrong thread category to do so.
  • That's a pefect font for a sphinx of quartz! :)
  • Since it’s clearly a titling typeface, I would decide the maximum number of weights based on how you’d personally use it. I think it would benefit to test it (or have people test it) in a variety of samples or actual projects. This way you’ll see if the number of weights is redundant.
    I think it always depends a lot on the actual dimensions in which it will be used. Clearly on screens it’s pretty relative and device-depending, but in general you still have a rough idea (i.e. it will be hardly used under certain point sizes).
    In that way, you’ll come up with a good economy of weights, keeping the family stronger (I would do with six weights max myself).
  • The user and all related content has been deleted.
Sign In or Register to comment.