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

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.

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.

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

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:

Value	Weight
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.

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).

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

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.

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!)....

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.

"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

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....