Open Bug 454514 Opened 14 years ago Updated 11 years ago
implement better style linking of font families under windows
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.
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. :-)
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.
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.
Is this change still relevant today? Bug 493280 also hasn't been touches in years.
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?
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!
Assignee: jdaggett → nobody
You need to log in before you can comment on or make changes to this bug.