454514 - implement better style linking of font families under windows

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[John Daggett (:jtd)]

By default, Windows groups fonts with just four faces per family (regular, bold, italic, bold italic).  Families with more than just these four basic faces are broken out into separate families.  This is based on the Family name record within the name table of a TrueType/OpenType font.

Applications like Adobe Photoshop are "savvy" apps because they unify large families, so a font family containing 20 faces with different weights and styles will appear as a single font family.  They do this by using the "Preferred Family" name record within the name table.

From the Apple TrueType docs for the name table:
http://developer.apple.com/textfonts/TTRefMan/RM06/Chap6name.html

"Preferred Family (Windows only); In Windows, the Family name is displayed in the font menu; the Subfamily name is presented as the Style name. 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 and Preferred Subfamily IDs allow font designers to include the preferred family/subfamily groupings. These IDs are only present if they are different from IDs 1 and 2."

To allow more stylistic control, I propose:

1. Organize families based on 
      Preferred Family ==> Family

2. For compatibility, map older family names into the "savvy" names when different.

This won't actually affect a lot of fonts that ship with Windows today since most don't use the Preferred Family field but it allows better support for families that ship with apps like Photoshop and Flash.

Comment 1

[John Daggett (:jtd)]

From bug 441473, comment 65 (Kevin Newman):

There has always been an issue with font names and selection in various apps on
Windows when it comes to Postscript OpenType CFF fonts (.otf) vs. TrueType
OpenType fonts (.ttf).

Windows seems to have a compatibility mode that attempts to squeeze the more
robust font styles of OpenType into the 4 main categories that many GUIs use
(regular, bold, italic, bold-italic).

That's actually a huge nuisance in applications like Flash CS3 (and browsers
accessing system fonts with CSS) where you can't actually select some OpenType
fonts easily without selecting one of the items listed, and then hitting bold
to hope you get "Medium". Other applications though, like Photoshop CS3,
InDesign CS3, etc. utilize (as far as GUI) a second drop down instead of the
traditional bold and italic buttons (which CSS seems to attempt to duplicate in
it's keywords).

It would be great if the various browser implementations (and Adobe) could get
together and figure out how this should all work, crossplatform, so we don't
end up with compatibility issues like we do with Flash CS3 (and other apps,
where you often can't take an fla and move it from Mac to PC and vice versa if
it uses a Postscript CFF OpenType font). This problem would be worse in a
browser since that would be a runtime problem, not just an authoring problem
(like it is with fla).

Just to further illustrate the issue mentioned above, a font like
ClearviewText: 

http://www.terminaldesign.com/fonts/set/?ID=111

has many more than 2 styles, so in Windows it gets grouped by 4 fonts, so that
for example, to get ClearviewText-Medium, you actually have to choose
ClearviewText-Book and then make it bold using either the bold button in an app
like Flash CS3, or by specifying font-style: bold in css. On Mac, you just
choose "ClearviewText-Medium" as the font family/name and bold is ignored, or
faux.

I would recommend doing it the Photoshop/Mac OS X way, even on Windows. 

Apologies if this is too vague or otherwise not useful. :-)

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Would be great to fix this for 3.2.  I think Stuart had a patch that partially worked for win32, but I can't find a bug for it at the moment.

Comment 3

[Jonathan Kew [:jfkthame]]

I've begun work on a patch that refactors gfxQuartzFontCache (which handles font families and styles under OS X), moving most of the functionality into a platform-neutral font list manager. The idea is to share the family/style-matching behavior across platforms, with just a thin platform-specific layer to retrieve the fonts from the host system and create the right flavor of the concrete font objects.

If this goes as planned, it should give us a mechanism that will handle big families better, without the constraints of the old Windows model.

Comment 4

[Benoit Girard (:BenWa)]

Is this change still relevant today? Bug 493280 also hasn't been touches in years.

Comment 5

[Jonathan Kew [:jfkthame]]

Under DirectWrite, we get a better model of font families and faces (leading to the periodic "bugs" about Arial Black, etc...). So this issue is only relevant under GDI, which is probably not somewhere we want to invest a lot of effort.

Moreover, a fix for the GDI behavior would require either reading lots more font info on each startup (perf hit) or caching it (one-time perf hit, plus significant code/complexity to manage the cache, check for changes, etc).

So my take on this is that it's WORKSFORME under DirectWrite, and WONTFIX under GDI. John & others, WDYT?

Comment 6

[John Daggett (:jtd)]

Yeah, closing this seems reasonable.  Not much to be gained by fiddling with GDI since most users on XP aren't going to magically get full font families!

Comment 7

[Gregory Pappas [:gregp]]

Should this bug be closed since Firefox doesn't support WinXP anymore?

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

In these days, Windows has much better default fonts for CJK locales. Therefore, it's not reasonable to fix this.