Windows 8 doesn't like "Book" weight?

Yªssin Bªggªr

Encountering a strange problem that seems like a bug today.
We are mastering a typeface with Regular, Book and Medium weights + Italics. Everything looked good until we tried it in Windows 8, where the Book weight was always named Medium in the folder where fonts get installed, causing the family to have 2 Medium and 2 Medium Italics styles. If opened in Windows (with the waterfall view of the font), the proper name is displayed. In software the Book styles appear properly, except in NotePad where only Medium appears, making 2 styles unreachable.
I triple checked everything with TTX. Initially I had set up the Book style with 500 as usWeightClass, and the Medium with 600 (as I was hoping to keep round numbers if possible), and thought this might be the cause of the conflict, but even with 450 and 500 respectively, Windows continues to display Medium for the book style, despite the fact that "Medium" doesn't appear anywhere in the TTX file.

Also wondering what impact/how important the "WeightName" in the CFF table is? When usWeightClass is 500, this is automatically set to Medium by RoboFont, I've tried both "Roman" and "Book" but Windows still names it Medium.

Any ideas?

Chris Lozos

Did you try "Regular"?

Aaron Bell

Sent you a message

Dave Crossland

Aaron, you tease! What's going on?  

Nick Shinn

A Panose issue? I set all Panose values (except the first) to zero.

Aaron Bell

@Dave Crossland I just want to investigate! Nothing shady....yet. XD

Yªssin Bªggªr

Apparently It's the same thing in Windows 7…
It would be good to know which field or what serves/affect the naming in the Windows Fonts Folder (C:/Windows/Fonts), and in NotePad (same problem, forgot to mention that).

@Chris Lozos Did you mean "Regular" for the WeightName table in the CFF table? Because otherwise we already have a Regular style so we don't want those to conflict.

@Nick Shinn Are you aware of some problems with Panose? We always try to fill them as best as possible, including the weights. The book weight had Medium in Panose and the Medium had Demi. We just tested a version with Book in Panose: more of the same.

Chris Lozos

I seem to remember in some older Windows builds, that there was a confusion between Book and regular and medium.  My old brain is failing so I can't remember more details right now.

Thomas Phinney

(Adobe InDesign has had issues around families with both "Book" and "Regular" weights and not being able to recognize both. For some families InDesign hard-coded around this, on a family-by-family basis. This was a platform-independent issue, distinct from any Windows platform-specific issues.)

Nick Shinn

Yes, I have had problems with Panose weights.
I have very little idea how it is supposed to work, does work, or is interpreted, but it appears that it does not distinguish between Regular and Book.

**

In general, there is confusion amongst type users as to whether Book is the same weight as Regular, or lighter, or heavier.

Therefore I never use “Book”, with my weight naming system going from Light to Regular to Medium to Bold. If I need more weights, I add them at the extremities—Extra Light, Extra Bold, etc.

Chris Lozos

I never use the name "Book" as well because so many people are confused by it.

Mark Simonson

I used Book for one of my earliest families. It hasn't caused any problems for users that I am aware of (it is however one of my least popular fonts), but if/when I ever update it, I'm dropping it in favor of Regular.

Yªssin Bªggªr

I have considered this (confusion) but in this case it is purposeful since the idea is really that the Book is an alternative to the Regular as a default/normal weight, especially for print purposes, hence book.
Also I don't like SemiBold (and "Extra…") much as a name, it doesn't evoke anything to me in terms of what the weight is intended for. Half Bold sounds like Medium.

The styles display in the right order in font menus so it's not a problem. The issue is really only the Windows Fonts folder and NotePad. If there is no solution I'll be able to live with it with the hope that Windows gets its affairs in order

Chris Lozos

"Also I don't like SemiBold (and "Extra…") much as a name, it doesn't evoke anything to me in terms of what the weight is intended for. Half Bold sounds like Medium. "

But that is the problem, many people think "Book" is lighter than regular.

Stephen Coles

More arguments against Book. But I understand your dilemma, @ybaggar.

Ray Larabie

Is it possible to throw away weight names and go fully numeric? Can I call Bold 800 and Regular 600? If so, what would I have to do to make regular and bold backwards compatible? For example, to get the R,I,B,BI to work in Windows, would the family name for Bold be Fontname 600 with the bold flag turned on?

(in FontLab)

For the 600 weight (regular)

• Family name: Fontname 600
• Weight: Regular (600)
• Style name: Regular
• PS fontname: Fontname600-Regular
• Full name: Fontname600-Regular
• Menu name: Fontname 600
• FOND name: Fontname600 Regular
• OT family name: Fontname
• OT Style name: 600

For the 800 weight (bold)

• Family name: Fontname 600
• Weight: Bold (800)
• Style name: Bold
• PS fontname: Fontname600-Bold
• Full name: Fontname600-Bold
• Menu name: Fontname 600
• FOND name: Fontname600 Bold
• OT family name: Fontname
• OT Style name: 800

Chris Lozos

There was a discussion about this a few years ago.  As I recall, there is a technical reason why this should not be done.  They even had to avoid it with Univers when digitized , which had by far the most sensible numeric naming scheme ever.  I always new exactly what I was getting.  Today, they may need a 3 digit system today instead of Frutiger's 2 digit system. http://showinfo.rietveldacademie.nl/univers/images/univers 21 weights.jpg

Ray Larabie

Wasn't Univers was digitized about 3 decades ago? Isn't here a way in 2016 to have style names appear as 3 digit numbers in contemporary applications while maintaining a fallback for older systems?

Chris Lozos

I sure hope so, Ray. I just have not heard of it yet.  I think Thomas may know.
Univers was the very first digital typeface family I bought back in 1987.

LeMo aka PatternMan aka Frank E Blokland

Although I can’t guarantee that this will work in *all* circumstances, this seems to work for DTL fonts:



Above and below is in Windows 7.



The naming as shown in OTM (the left column looks a little bit weird because I combined two screendumps from my laptop):



And the weight/style info (OTM):



How the fonts show up in InDesign CC 2015 on macOS:

Yªssin Bªggªr

@LeMo aka PatternMan aka Frank E Blokland
Thank you for sharing that, it is very interesting. First things I see is that your version is without IDs 16 and 17 for Mac (I think I remember FontLab recommending to delete them too). More surprising, ID 2 for Mac is "Book", while for Windows it is Regular. I thought this field was R, I, B, BI only?
Last difference is that usWeightClass is also 400. So you use 400 for both Regular and Book in DTL Elzevir? That it doesn't cause conflict or misorder in font menus is interesting!
Will try the same…

Yªssin Bªggªr

After some tests, it seems that usWeightClass is the determining factor. With "400" the font displays as "Book" in the windows Fonts folder. But the weights order in InDesign and other software is not correct anymore, with Book moving to the top.

LeMo aka PatternMan aka Frank E Blokland

I thought this field was R, I, B, BI only?

Not necessarily, although I would restrict to this for the Windows entries and use ID16 and 17 for the preferred naming. That being said, I think at the end it is preferable to do the same on the Mac side and to use ID16 and 17 there too, i.e., to make the entries on both platforms identical.

But the weights order in InDesign and other software is not correct anymore, with Book moving to the top.

Everything comes at a price, but assuming that our customers know what they purchase when they buy the Book version, I can live with this. I must admit though that by default we only do this with the .ttf versions and not with the .otf editions, which are mostly sold to macOS customers (in that case 500 for Book and 600 for Medium).

Yªssin Bªggªr

I guess I misunderstood this part: A font with no particular differences in weight or style (e.g. medium weight, not italic and fsSelection bit 6 set) should have the string “Regular” stored in this position.
Not very clear… the information for field ID 2 could be written better I guess
Also, unfortunately the exemples are somewhat too basic and not very representative of current typeface families.

I would also prefere to follow the spec as much as possible and avoid possible troubles just to solve current bugs or oddities.

We essentially deliver OTF so the appearance of weights in proper order of Design software font menus is more important than the name in a windows folder. Also, since we have stopped supporting style-linking in our default retail fonts, it makes more sense to deliver office versions with style-linking per request for us. Seems like the best option.
Thanks a lot for your help!

Peter Constable

The behaviour in the Windows Fonts control panel and in the CHOOSEFONT common dialog seen in Notepad is due to a particular component that was introduced in Windows 7 that was trying to broaden the use of the weight/width/slope family model, with multiple weight or width values supported within a family, as opposed to the R, B, I, BI model that was so prevalent.

A challenge for trying to project fonts into WWS families is that there were lots of existing fonts that weren't built to utilize the full weight range allowed by OS/2.usWeightClass. Some fonts will tweak OS/2 values and name IDs 1 and 2 in an effort to get certain pairs treated as regular/bold linked pairs. As a result, software that actually understands and supports multiple weight values has to apply some heuristics to figure out that these are actually all alternate weights within a single family. And, in certain cases, the logic has to ignore strings that are in the font in order to get the fonts appearing together in one family. Such heuristics may not always get it right, however, as appears to be happening in this case -- though I can't say offhand what about the font data is tripping it up. The logic used in this component was first introduced for the Windows Presentation Foundation (WPF) in .Net, and is documented here:

WPF Font Selection Model

The component that has this logic is used only by three things: the Fonts control panel, the CHOOSEFONT common dialog, and the Windows "ribbon" common controls; and for certain reasons that would take a little longer to explain, the latter did not use the WWS family model. There wasn't time to create public APIs in Windows 7, and other priorities took over in Windows 8; so the only apps that are impacted by this component are those that use the CHOOSEFONT common control.

My general recommendations (not having actually been in the seat of a font developer struggling with how to get fonts working on different apps, including legacy stuff that still matters):

- Follow the suggestions for OS/2.usWeightClass wrt numeric values and corresponding sub-family names.

- Stick to conventional names for weight values.

- Always include name IDs 16/17.

- To help get better behaviour in new applications, include a STAT table in your font.

Yªssin Bªggªr

Hey, Sorry for the delay in answering.

Thank you for the detailed and precise post Peter. Indeed, the problem did not lie with the usWeightClass but with WWS. Aaron Bell very kindly looked into the fonts and was able to find that out, as well as providing some other very helpful advices (thanks again!).
After checking the WWS bit in the OS2 table for the Book and Medium weights (directly in RoboFont), the family displays properly in Windows, which also allowed me to go back to the rounded usWeightClasses I initially wanted for these styles, even though it doesn't follow the recommendation it doesn't seem problematic.

I'm still not clear why the Fonts folder needs to do some guessing with Font Names when there are clear name tables that could provide the exact name, but I'm sure there are some "good" (technically complicated) reasons behind it