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
0
Comments
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.)
Thanks! And to you Hrant, too.
Thanks.
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.
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
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
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.