Numeral values of weights

Dusan Jelesijevic

I was preparing promotional materials for an new family and noticed issue with weights order.
They are not displayed the way they should be (from thin to thick). Weights are done as MM instances.

These are all weights.
You can see values I set for each weight (this is 3rd version and each one gave no results).

What I want:

1 Thin 100
1 Thin Italic 100
2 UltraLight 200
2 UltraLight Italic 200
3 ExtraLight 200
3 ExtraLight Italic 200
4 Light 300
4 Light Italic 300
5 Book 300
5 Book Italic 300
6 Regular 400
6 Regular Italic 400
7 Medium 500
7 Medium Italic 500
8 SemiBold 600
8 SemiBold Italic 600
9 Bold 700
9 Bold Italic 700
10 ExtraBold 800
10 ExtraBold Italic 800
11 Heavy 900
11 Heavy Italic 900

What happens is this:

3 ExtraLight
1 Thin
2 UltraLight
3 ExtraLight Italic
1 Thin Italic
2 UltraLight Italic
4 Light
4 Light Italic
5 Book
6 Regular
5 Book Italic
6 Regular Italic
7 Medium
7 Medium Italic
8 SemiBold
8 SemiBold Italic
9 Bold 700
9 Bold Italic 700
10 ExtraBold 800
10 ExtraBold Italic 800
11 Heavy 900
11 Heavy Italic 900

What I also did:
– deleted font cache (and restart after that);
– filled in all necessary fields under Font Info (just like with all other families before this one);

Does anyone have idea what what might be the issue here?

Thanks,
Dusan

Hrant Հրանդ Փափազեան Papazian

http://typedrawers.com/discussion/comment/32118

Kent Lew

You will experience problems having multiple weights with the same OS2weight value — e.g., both UltraLight and ExtraLight at 200, and both Light and Book at 300.

You may also experience problems having both “Book” and “Regular” stylenames in the same family. Some apps have been known to assume that these are synonyms for the same thing. (Maybe that’s only a legacy issue these days.)

Dusan Jelesijevic

Kent, you were right. Assigning different values to each weight solved issue.
Thanks! And to you Hrant, too.

Nick Shinn

You can also use values between hundreds.

Dusan Jelesijevic

Yes, I did that also.
Thanks.

Michael Jarboe

Would it only be necessary to deviate from the hundred values if a family exceeds ten weights? Using 100-1000 will accomodate a twenty weight family (roman/italic) using only hundred values. Why or when would non hundred values be needed beyond certain edge cases, and are there any reasons for or against a certain methodology?

Dave Crossland

OTF/CFF fonts in Windows with an os2 font weight of 249 or below are autobolded 

Thomas Phinney

Are TTFs not similarly affected?

Also, my understanding has long been that the faux bolding issue depends on which Windows API the app uses and how it uses that API. But I have not looked closely at this in quite some time.

Michael Jarboe

I forgot about that autobold issue, but I've also noted that not many fonts adhere to that limitation. I regularly have seen weights designated at values of 100 or 200 in large families.

Dave Crossland

Thomas Phinney said:

Are TTFs not similarly affected?

No, Bold Monday folks pointed this out to me when the IBM Plex fonts were being released, and Marc Foley confirmed it. (Previously fontbakery checked for this on TTFs, apparently needlessly

My guess is that it was a workaround for the legacy CFF rendering engine in Windows being poor, but in the latest Windows APIs the CFF renderer is excellent - and so is freetype's

AbrahamLee

Dave Crossland said:

Thomas Phinney said:

Are TTFs not similarly affected?

...
My guess is that it was a workaround for the legacy CFF rendering engine in Windows being poor, but in the latest Windows APIs the CFF renderer is excellent - and so is freetype's

So,... We can ignore this limitation now? (of starting at 250)

Thomas Phinney

My impression is that the issue used to happen with TTF (TrueType) as well as OT-CFF — which if true would suggest the TrueType and OT-CFF limitations were removed at different times/places. Although admittedly, my focus was primarily on OT-CFF back at the time I was researching this, so maybe it was not a big deal that it didn’t happen with TTFs.

It wasn't a workaround for the rendering engine being poor, but an unfortunate combination of events and poor app (or API) assumptions. Back then, if an app called a font in GDI and ask for it with a weight of at least 150 more than its highest available weight, it would get a faux bold. So if an app blindly asked for the "regular" (400) of a font, but in fact the available weight was 200, Windows would take that 200 and apply a faux bold effect.

My understanding was that there were multiple ways to make the relevant API calls, and this did not have to happen. Back at the time, it only happened in about half of all Windows apps, but as that half included MS Office, it was a prominent bad effect.

When you threw in *actual* bold style-linked fonts, things got more complicated. Which weights could safely link to which other weights made an interesting chart, which was included in AFDKO along with the docs for the general problem. https://www.adobe.com/devnet/opentype/afdko/topic_font_wt_win.html

André G. Isaak

That chart is just plain weird. A font with a weight of 250 can be safely bold-linked to a font with a weight of 1000, but one with a weight of 500 can only be safely bold-linked to a font with a weight of 750?

Thomas Phinney

Yup.

That's why we made the chart, because it was, indeed, just plain weird. (It was even more fun when it was a color-coded 2D chart, but at some point that got retired in favor of a plain text listing.)

You can thank Ernie March for doing the painful testing of all the combinations to figure out what actually worked as expected, and what did not.