Rationale for values chosen for "Font family name" vs. "Preferred family name" records in 'name' tables

[dspreadbury]

I have a question about the way the various fields in the 'name' table are set up for the Source Sans Pro family of fonts.

For regular, bold, italic, and bold italic weights, Name ID 1 ("Font family name") is set to "Source Sans Pro". For the fonts whose weights do not match the "base four" weights (i.e. Black, Semibold, Light, Extra Light) Name ID 1 ("Font family name") is set to "Source Sans Pro ".

This seems to cause most Windows applications, e.g. WordPad, to show the extra light, light, semibold and black versions of Source Sans Pro as separate fonts, while the "base four" weights can all be obtained by choosing "Source Sans Pro" from the font combo and using the bold and italic buttons.

However, it also means that these fonts are interpreted as being in separate families, e.g. the "Source Sans Pro Light" family, rather than the "Source Sans Pro" family.

I note that Name ID 16 ("Preferred Family") is set to "Source Sans Pro" for all weights.

My question concerns why this particular arrangement of settings was chosen, and how an application that wants to interpret all weights as being part of a single family should interpret the available data.

Thanks!

[frankrolf]

This has to do with a number of constraints imposed by operating systems. For instance, the behavior you are describing is tied to Style Linking, which allows for fonts to make use of the Bold and Italic button. However, Windows does not expect more than four fonts to be style linked, therefore a “new” family is opened for styles outside the ordinary Regular/Italic/Bold/Bold Italic range.
Within this new family context, it is also possible to use Italic and Bold buttons, e.g. to go from Light to Light Italic.

Your criticism is valid, however there is probably no workaround in the context of Windows consumer applications. An app that would show all the fonts within the context of a family is for instance InDesign.

You can read more about the name table here:
http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html#9.e

[grzegorzrolek]

Hi Daniel,

In the early days, Windows applications were limited to the four styles in a family that could be style-linked with the typical ‘bold’ and ‘italic’ switches. For this reason, families with more weight styles were often split into smaller ones, each having a separate family name and some sensible ‘regular-to-bold’ style relations (see the help page on font style linking from Adobe for more background on those issues).

Later, the ‘preferred’ name entries were added to allow applications that had no such limitations to group all the styles under a single family name. If available, those names should be used instead. From the Microsoft’s specs:

Preferred Family; For historical reasons, font families have contained a maximum of four styles, but font designers may group more than four fonts to a single family. The Preferred Family allows font designers to include the preferred family grouping which contains more than four fonts. This ID is only present if it is different from ID 1.

and:

Preferred Subfamily; Allows font designers to include the preferred subfamily grouping that is more descriptive than ID 2. This ID is only present if it is different from ID 2 and must be unique for the the Preferred Family.

Be sure to also check the Name ID’s 21 and 22, both part of another, style-based family model used by Microsoft in their Windows Presentation Foundation. It’s described in detail in the whitepaper on font selection mechanisms in WPF.

[twardoch]

This may be helpful: http://forum.fontlab.com/index.php?topic=313.0

[pauldhunt]

@readroberts do you care to impart any wisdom on this topic?

[readroberts]

First, I want to correct an error in the first post. For the faces which are not in the four style-linked faces, name ID 1 is NOT "Source Sans Pro". It is instead "Source Sans Pro " + [style name]. I think this is what you meant to say, as the rest of your observations and conclusions are correct. @frankrolf and @grzegorzrolek correctly describe the issues behind the choice. More practically, what an application should do to enumerate all the faces as a single family is to not use the GDI, but instead use an API that enumerates the Preferred Family name and style. For Source Sans Pro, you should be able to do this within the WPF. However, this is too limiting for a real typographic application, as it limits faces in a family to being only variants of weight, width and slope: any other variants, such as optical size, are forced into separate families.

[twardoch]

Read, do you know if my assumption is correct that these days, WPF is another "huge yet ephemeral Microsoft project" just like GDI+? I believe that the currently recommended API for Windows app development is DirectWrite, and many apps still use old GDI. Neither GDI+ nor WPF have caught much traction in the end, while some remnants of WPF still exist in Silverlight. AFAIK, the WWS font selection model is not used in DirectWrite.

Well, perhaps these questions would be better addressed at Microsoft...

[readroberts]

No, I don't know. WPF is alive and well in Internet Explorer and MS -developed web apps, but I have otherwise almost no app development experience or knowledge under Windows.

[dspreadbury]

Thank you, Paul, Read, Adam, Frank, and Grzegorz.

Your responses confirm what I believed to be true, and it is very useful in particular to see the recommendation in Microsoft's OpenType specifications to use IDs 16 and 17 if available.

By way of background: in the project we are working on, we are using Qt, and at present the Qt framework has issues correctly enumerating all styles for fonts, including Source Sans Pro, which we intend to use as our user interface font. I am advocating for the Qt font APIs to be extended to more properly handle modern font families, and I hope this discussion will help persuade their developers of the need to address these issues.

[twardoch]

Yes, something got badly broken in Qt 5.x. It all worked well in Qt 4.8.

[jobor]

@twardoch This particular issue (QTBUG-38482) was definitely not working in Qt4.
We'd appreciate it, if you'd report any findings of Qt5 regressions at bugreports.qt-project.org. ;)

[adrientetar]

Bug confirmed for Qt5, fixings in-progress: https://bugreports.qt-project.org/browse/QTBUG-38482