To True Boldly Go Where No Font...(yada yada yada)

by Michael S. Kaplan, published on 2011/05/26 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/05/26/10167955.aspx


One of the interesting features discussed in articles like Script and Font Support in Windows and What’s New for International Customers in Windows 7 is True Bold support.

For example from that second link there is even an example which admittedly might have been picked to be more striking:

For instance, for bold texts the true bold font provides better text display than the simulated bold.

This is an example of text display in simulated bold versus true bold:

 

But it doesn't spend a lot of real time explaning why it's a good thing, does it?

Let's start by compring it to the non-bold font, with the same words (here in Windows 7 vs. Vista):

    

Can you see the differences? Aren't they a bit more striking, perhaps even with a great insight as to how it happened, when you cn see the base font that was being thickened? :-)

The basic problem comes in the algorithmic "thickening" done -- whether by GDI, GDI+, WPF, WPF/DWrite, DWrite, or Silverlight.

As good as it may or may not be, it can never be as good as when an actual typography expert is doing the work explicitly.

Though I may not be the only one who wonders why OpenType doesn't define features that act as "hints" for algorithmic Bold or Italics. That too would let typographers support a better story than the lowest level algorithmic boldng supported now!

This idea is not entirely new -- this is why so many fonts support regular, bold, italic, and bold-italic versions!

Of course some of the most well-known fonts do not -- like Microsoft Sans Serif:

Now the lack of true bolds and true italics for this font has a direct impact on fine typography when you use italic or bold.

But when you look at core fonts like Microsoft Sans Serif that always suppport large parts of the core scripts of the latest version of Unicode, the actual cost of creating bold, italic, and bold-italic versions can start to get bigger and bigger.

And with the heavy push toward using Segoe UI in Windows rather than the UI fonts of prior versions (Tahoma and Microsoft Sans Serif), makes a lot of sense in terms of investment.

Just as providing true bolds makes a lot more sense for all of these scripts like the Indics that aren't in the core fonts -- since they are the fonts the system goes to when you use the core fonts and ask for these other scripts.

Though the story doesn't end there....

Let's talk about Segoe UI, a font that was born with bold, italic, and bold-italic variants.

And also more:

Okay, so in addition to the expected gang of four that we expect in fonts, they added two more weights:

And they didn't just pick up these names in as thesaurus, these weights have been around for a while, as this table from LOGFONT->lfWeight "hints" at:

ValueWeight
FW_DONTCARE 0
FW_THIN 100
FW_EXTRALIGHT 200
FW_ULTRALIGHT 200
FW_LIGHT 300
FW_NORMAL 400
FW_REGULAR 400
FW_MEDIUM 500
FW_SEMIBOLD 600
FW_DEMIBOLD 600
FW_BOLD 700
FW_EXTRABOLD 800
FW_ULTRABOLD 800
FW_HEAVY 900
FW_BLACK 900

Though of course by not providing hinted versions of these two additional fonts (as people complin about like in the comments of blogs like this one), it makes them less useful overall:

I do not believe that the Segoe UI Light and Segoe UI Semibold weights have gone through the same rigorous hinting procedures as the original Segoe UI styles.

For example, it looks like counter control is not being used on the lower case letters b, d, p, and q. Look how their rounded overshoots and counter sizes are larger than they should be at normal "UI" font ppems. The numeral 1 in the Light weight and capital I in the Semibold weight also tends to protrude beyond the cap height at typical "UI" font ppems. I believe this may be because they are modifications of the outlines used in the Segoe marketing fonts to better match the style of the UI fonts.

The Light and Semibold weights also do not provide the same script and language support as the Regular and Bold weights. They have fewer glyphs overall (comparable to the original italic styles, which have no need for Arabic scripts, however). The OpenType feature sets are also divergent.

Developers should not presume to use these new alternative weights interchangeably with the originals. Depending on the users' display settings and locales, the users may experience a less than optimal result.

My guess is that these fonts were included mainly to render the text "Windows 7" in the fashion of "(semibold)Windows (light)7", to provide a consistent look with branding assets.

Perhaps these weights will receive more attention (and especially delta hinting for typical UI ppems) before Windows 7 ships.

Spolier: they didn't. :-)

And it does without saying that also not providing either a Segoe UI Light Italic or a Segoe UI Semibold Italic limits their usefulness further -- since now they will just be using algorithmic italics (which can at times be even more destructive of text than algorithmic bold).

So it is funny how all three axes:

are all done in the name of fine typograpy, yet there is so little overlap between the three of them....

There are also other uses for true italics, like the language specific issues I have discussed in blogs like You say ĭtalics, I say ītalics. It is much more complicated in Cyrillic.... for language-specific Cyrillic script issues and When the font is the boss of you for taking care of some Japanese-specific issues.

For the latter case, note that even people who object to the modified behavior of "ignoring" the italics request just suggested providing oblique support via other means -- no one who understands the language objects to the notion of using True Italics to providii9ng an experience superior to Algorithmic Italics.

Now as typography in Windows and within other Microsoft products improves, the cost and even the time issues can obviously keep every single improvement happening to every single font.

Though I do hope the grid gets to be filled in a little more completely, and with a little bit more overlap between features, than we see currently.

Don't you? :-)

And as a final point, and not for nothing, I'll point you at On why it's a bad thing to choose font information by name only and point out that more than ever you don't want to set fonts by name -- it leaves you in a really really bad place if you do (unless you don't mind your font selections being ignored, I mean!)....


Quppa on 26 May 2011 9:59 AM:

What weight does Segoe UI Semilight (found in WP7 and maybe Windows 8) correspond to?

RandomReader on 26 May 2011 10:04 AM:

Even if true bold and regular are installed, you can usually get the simulated bold font by specifying something close to FW_SEMIBOLD in CreateFont. Few people realize that Windows has always supported Arial Semibold!

By the way, I believe the additional weight variants in Windows 7 are in separate families, so applications can access them using only FW_NORMAL and FW_BOLD.

Joshua on 26 May 2011 3:30 PM:

Big push to Segoe UI, but Segoe UI depends on ClearType, and ClearType is bad for about 10% of people.

Sigh.

Michael S. Kaplan on 26 May 2011 11:06 PM:

Depends on may be an overstatement in this context....

Miguel Sousa on 31 May 2011 11:43 AM:

"I may not be the only one who wonders why OpenType doesn't define features that act as "hints" for algorithmic Bold or Italics."

That's like saying: I wonder why carmakers haven't put wings on automobiles to make them fly.

"That too would let typographers support a better story than the lowest level algorithmic boldng supported now!"

This is the common mistake that engineer-minded people make. Typography (and typeface design) cannot be done algorithmically because they are design trades, not mathematic trades. Engineers are the ones who need to come up with better algorithms for synthesizing faux bolds and italics. Designers will do their part of designing the true bolds and italics.

"OpenType hinting"

There's no such thing. OpenType is not in the business of hinting. Clarify your misconceptions of what OpenType is for by reading the spec's overview at www.microsoft.com/.../otover.htm

Michael S. Kaplan on 31 May 2011 9:34 PM:

There are certainly things that could be added to allow type designers to augment and suppress the automatic processes that the autobold an autoitalics too. This is possible even if some type designers might think this to be something of a betrayal of what they try to do....


referenced by

2011/05/30 Semijazzed about semilight!

go to newer or older post, or back to index or month or day