John Daggett (:jtd) Assignee
	Description • 17 years ago

We don't match font names specified in the font-family CSS attribute in a way that's consistent with WebKit/Opera.

Given:

   font-family: "Tahoma Bold", Georgia;

trunk, IE6: font face used is "Tahoma", no bold
WebKit: font face used is "Tahoma Bold", bold
Opera: font face used is Georgia

	John Daggett (:jtd) Assignee
	Comment 1 • 17 years ago

Note: on Windows XP two faces exist for Tahoma, Tahoma and Tahoma Bold, that's why Tahoma Italic falls back to Georgia.

	John Daggett (:jtd) Assignee
	Comment 2 • 17 years ago

The screenshot shows, trunk, Webkit latest, and Opera 9.5 alpha.

On the Mac, given:

   font-family: "Tahoma Bold", Georgia;

trunk: font face used is "Tahoma Bold", bold
WebKit: font face used is "Tahoma Bold", bold
Opera: font face used is Georgia

So, I think the bug here is this:

* our Windows behavior is correct, our Mac behavior is not

The font name should map to the family name and the styling should be dictated by font-style, font-weight etc.

	John Daggett (:jtd) Assignee
	Comment 3 • 17 years ago

The reason for this is that in gfxQuartzFontCache::ResolveFontName we lookup the name in a table of all full font names, not just family names.  So names like "Tahoma Bold" and "Tahoma Bold Italic" end up being treated as separate families:

http://mxr.mozilla.org/seamonkey/source/gfx/thebes/src/gfxQuartzFontCache.mm#728

The effect of this is that someone can sloppily mix full fontnames and family names  when authoring pages on the Mac but on other platforms and browsers only styles with proper family names will display correctly.

Fixing this will depend on bug 404310 which requires some streamlining work to eliminate some of the font name lookups we're doing in gfxQuartzFontCache::InitFontList at startup, so that should get fixed first.

	John Daggett (:jtd) Assignee
	Comment 4 • 17 years ago

Under Mac OS X, we currently match against (1) family names (2) Postscript names (3) full fontface names and (4) localized full fontface names.  We should only be matching against family names, anything else should fall back.

Safari 3: in addition to family names, matches Postscript names
Opera 9.5: matches correctly

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900)
	Comment 5 • 17 years ago

John-san:

Please don't forget Gecko1.8.1.

	John Daggett (:jtd) Assignee
	Comment 6 • 17 years ago

(In reply to comment #5)

> Please don't forget Gecko1.8.1.

Ah, yes, right you are.  FF2/Mac matches correctly, same for FF2/Windows, FF3/Windows and IE6.

	John Daggett (:jtd) Assignee
	Comment 7 • 17 years ago

FF3/Mac: correct, except Hiragino Kaku Gothic Pro W6 should *not* be bold when using a normal font weight
FF2/Mac: with [ja] locale version, [en] system locale set, only ヒラギノ角ゴ Pro W3 and ヒラギノ角ゴ Pro W6 match
Safari3: only Hiragino Kaku Gothic Pro matches
Opera 9.5: similar to FF2, ヒラギノ角ゴ Pro W3 and ヒラギノ角ゴ Pro W6 match.  With bold applied to W6 face, text is rendered with additional synthetic bolding (wacky!)

We should allow for all flavors of family names but we need to unify families based on preferred family names.  Doing so will cause those who use ヒラギノ角ゴ Pro W6 as a font family name to see non-bolded text but it's more consistent and works better with lighter, bolder attributes.

	philippe (part-time)
	Comment 8 • 17 years ago

(In reply to comment #7)
> Created an attachment (id=296460) [details]
> Using a variety of Hiragino family names
> 
> 
> FF3/Mac: ... Hiragino Kaku Gothic Pro W6 should *not* be bold when
> using a normal font weight
Why not ? It _is_ a bold face.

But a stylesheet author should only use 'Hiragino Kaku Gothic Pro' (and ヒラギノ角ゴ Pro W3 for backwards compatibility for old Carbon users: Fx 2, Opera, IE5 Mac)

More to the point, Gecko 1.9 should do the same as WebKit here: only 'understand' 'Hiragino Kaku Gothic Pro', but trip over if both 'Hiragino Kaku Gothic Pro' and 'ヒラギノ角ゴ Pro W3' are used.

	John Daggett (:jtd) Assignee
	Comment 9 • 17 years ago

(In reply to comment #8)

> > FF3/Mac: ... Hiragino Kaku Gothic Pro W6 should *not* be bold when
> > using a normal font weight
> Why not ? It _is_ a bold face.

The font-family attribute specifies a _family_ not a face!!  The font-weight attribute (along with other attributes) controls which face is chosen within a family.  The mapping of family to face is controlled by:

   [font-family] + [font-weight] + [font-style] ==> font face

The current CSS3 fonts spec adds [font-stretch] to the mix which allows you to specify condensed faces but there are still font faces that cannot be specified by this scheme, this is a known limitation of CSS2.  Allowing [font-family] to specify faces leads to all kinds of problems figuring out what the meaning of [font-weight] and [font-style] implies.  For example, what do this combination imply?

   [Helvetica Neue Condensed Bold] + [bolder] + [normal] ==> bold face? black face?

We don't do recognize the full face name on Windows or on Linux, nor do other browsers, that's what this bug is about.

> But a stylesheet author should only use 'Hiragino Kaku Gothic Pro' (and
> ヒラギノ角ゴ Pro W3 for backwards compatibility for old Carbon users: Fx
> 2, Opera, IE5 Mac)

Sorry, why?  A Japanese user who looks in FontBook will find 'ヒラギノ角ゴ Pro' listed as the family name.  Unless there's some explicit "you must use English family names" in a CSS spec somewhere, I think the user should be able to use any of the family names defined by the font.

> More to the point, Gecko 1.9 should do the same as WebKit here: only
> 'understand' 'Hiragino Kaku Gothic Pro', but trip over if both 'Hiragino Kaku
> Gothic Pro' and 'ヒラギノ角ゴ Pro W3' are used.

Yes, I'm saying all these other family names should trip over to Hiragino Kaku Gothic Pro.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900)
	Comment 10 • 17 years ago

(In reply to comment #9)
> (In reply to comment #8)
> > More to the point, Gecko 1.9 should do the same as WebKit here: only
> > 'understand' 'Hiragino Kaku Gothic Pro', but trip over if both 'Hiragino Kaku
> > Gothic Pro' and 'ヒラギノ角ゴ Pro W3' are used.
> 
> Yes, I'm saying all these other family names should trip over to Hiragino Kaku
> Gothic Pro.

I think that John-san's approach is correct. However, I'm afraid the compatibility issue in *current* web pages. If we drop the quirk which is W6 being rendered as bold, can we keep the compatibility of the web pages?

I have added the quirk in bug 362665.

	John Daggett (:jtd) Assignee
	Comment 11 • 17 years ago

Using CSS rules, only 'Osaka' should be recognized as a font family name, that's the font family name for all Osaka faces for all locales.

FF2: Osaka−等幅 is recognized, Osaka-Mono is not
FF3: Both Osaka-Mono and Osaka−等幅 are recognized
Safari: Osaka-Mono is recognized (since it's also the Postscript name for the face)
Opera: Osaka−等幅 is recognized, Osaka-Mono is not

However, in the prefs panel for FF2 we list fonts using QD names and these include face names like Osaka-Mono:

http://mxr.mozilla.org/mozilla1.8/source/gfx/src/mac/nsDeviceContextMac.cpp#806

	John Daggett (:jtd) Assignee
	Comment 12 • 17 years ago

(In reply to comment #10)

> I think that John-san's approach is correct. However, I'm afraid the
> compatibility issue in *current* web pages. If we drop the quirk which is W6
> being rendered as bold, can we keep the compatibility of the web pages?

Yeah, that's a definite concern but if the difference is between Gecko supporting CSS correctly versus maintaining compatibility with past quirks for a small number of pages, I think I would be in favor of removing those quirks.  Web pages will still display with Hiragino Kaku Gothic Pro but a font-weight setting of 'normal' will outweigh the specification of a W6 weight via the font family name.

	John Daggett (:jtd) Assignee
	Comment 13 • 17 years ago

Fixed by changes in 404310.