Mike Beltzner [:beltzner, not reading bugmail] Reporter
	Description • 17 years ago

The blog post in the URL uses "Futura" as the base font. Firefox uses kerning, which makes it render a little tighter as compared to Safari, but when using Leopard the entire font seems squished both vertically and horizontally.

This is using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007102204 Minefield/3.0a9pre

Screenshots to be attached.

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

It is picking up Futura Condensed instead of Futura, see bug 396083 comment 13

	Mike Beltzner [:beltzner, not reading bugmail] Reporter
	Comment 4 • 17 years ago

Yeah, investigating with Vlad, Minefield on Leopard seems to be selecting Futura
Condensed Medium - maybe that font isn't available on the standard 10.5?

Marking as blocking? per request from Stewart, and also moving --> GFX::Thebes

	Mike Beltzner [:beltzner, not reading bugmail] Reporter
	Comment 5 • 17 years ago

Wow. That's an awful typo. s/Stewart/Stuart/

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

Testcase:

Use the testcase from bug 396083:

  https://bugzilla.mozilla.org/attachment.cgi?id=285702

Result:

  https://bugzilla.mozilla.org/attachment.cgi?id=285701

10.4 ==> body text uses Futura Medium
10.5 ==> body text uses Futura Condensed Medium

The CSS 2.1 standard only covers font weight, not font width, so which font to choose is up to the UA.  For the family name "Futura" we should be choosing "Futura Medium", since this represents normal weight, normal width.

	Mike Beltzner [:beltzner, not reading bugmail] Reporter
	Comment 7 • 17 years ago

Does this get RESO DUPE of bug 396083?

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

No, I don't think this is exactly the same issue.  The issue here is why we are picking up "Futura Condensed Medium" instead of "Futura Medium" under 10.5 when the font-family name of "Futura" is specified.  I think the issue in bug 396083 boils down to a font bug with the version of Arial Black that shipped with 10.4 (which has been corrected in 10.5).  It may make sense to add an explicit workaround so that 10.4 and 10.5 render identically but that's separate from this issue.

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

Source of the problem:  the AppKit FontManager has a slightly different way of selecting a font, given a font family and a set of traits.  When "Futura" is used as a font family name, the actual font to be used is resolved here, within gfxQuartzFontCache::ResolveFontName:

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

This is equivalent to the sample code below:

NSFontManager *fontManager = [NSFontManager sharedFontManager];
NSFont *font = [fontManager fontWithFamily:@"Futura"
                   traits:(NSUnboldFontMask | NSUnitalicFontMask)
                   weight:5
                   size:10.0];

On 10.4, the font returned by the font manager is "Futura Medium" but on 10.5 the font returned is "Futura Condensed Medium", hence this goofy bug.  The fonts have matching usWeightClass values of 500 (OS/2 table).  With weight unspecified, a "normal" weight of 400 is implied.  The 'weight' parameter in the 'fontWithFamily' method above, 5, is an Apple-defined weight value which should match a weight of 400.  The list is defined under the description of the convertWeight method of the NSFontManager reference:

http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSFontManager_Class/Reference/Reference.html#//apple_ref/occ/instm/NSFontManager/convertWeight:ofFont:

This seems like an Apple bug to me, given that NSCondensedFontMask is *not* included in the traits parameter.

http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSFontManager_Class/Reference/Reference.html#//apple_ref/doc/c_ref/NSCondensedFontMask

Not sure why this changed from 10.4 to 10.5 but it may either have something to do with the two fonts' Panose weights which differ slightly (5 for the condensed font, 6 for the regular width one) or it could just be a byproduct of changes to the CoreText API underneath.  Whatever the case, I think we need to be handling the weight/width mapping ourselves and not relying on the platform which may not be using the same rules as implied by the CSS spec.

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

Logged as Apple problem 5570368.

	Stuart Parmenter
	Comment 11 • 17 years ago

i'm not sure how common this font combination is and this is pretty clearly an OS bug.. we should push on apple pretty hard.

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

Response from Apple (via India):

Hi John,

This is a follow-up to Bug ID# 5570368.

<GMT16-Nov-2007 20:16:28GMT> Vanaja Pasumarthi:
Engineering has determined that this issue behaves as intended based  
on the following information:

Futura-Medium is weight 6 where as Futura-CondensedMedium is 5.
In absence of corresponding traits filtering, weight is honored and  
applied for matching.

This issue has been closed.  Thank you for taking the time to notify  
us of this issue.

Best Regards,

Vanaja Pasumarthi
Apple Developer Connection
Worldwide Developer Relations

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

Sent mail to a contact at Apple to see if we can confirm that Apple really believes this *isn't* a bug.

Potentially we can work around this by querying available fonts for a given family and matching the face ourselves.  My guess is that we'll need to do this anyways in the future to support CSS3 rules that specify the font width (e.g. CSS3 font-stretch property).

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

John-san, how about this? I cannot test on 10.5...

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

I think it would be better to first test the traits to see if we have an expanded or condensed font, then just call availableMembersOfFontFamily to get the list of weights and traits and iterate over those.  

That may end up being the same thing but it makes it clear that it's an exceptional case.  The for loop you set up in your patch will rarely iterate twice.

I'd like to investigate whether only Futura is affected by this or if there are other font sets that experience a similar problem.

Ultimately, we should really be handling this ourselves and not relying on flakey platform API's to follow rules determined by the CSS spec.

	Mike Schroepfer
	Comment 16 • 17 years ago

John how is this now?

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

Something like Masayuki's patch will fix this but I'd like to do it after the work for bug 404310 is complete, since that work will affect this area of the code.  Right now this is just an annoying Apple API problem that only affects families with an odd mix of fontfaces (i.e. those containing fontfaces other than Regular-Bold-Italic-Bold Italic).

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

The patch for 404310 will fix this but it looks like we will need to work around a bug in the 10.5 NSFontManager, the font traits are not set the same way.  Specifically the font traits value returned by availableMembersOfFamily does not have the NSUnboldFontMask and NSUnitalicFontMask bits set under 10.5.  No biggy, just an annoyance.

10.4 values:

family: Futura, psname: Futura-CondensedMedium, face: Condensed Medium, apple-weight: 6, css-weight: 5, traits: 0100004c
family: Futura, psname: Futura-CondensedExtraBold, face: Condensed ExtraBold, apple-weight: 10, css-weight: 8, traits: 0100004a
family: Futura, psname: Futura-Medium, face: Medium, apple-weight: 6, css-weight: 5, traits: 0100000c
family: Futura, psname: Futura-MediumItalic, face: Medium Italic, apple-weight: 6, css-weight: 5, traits: 0000000d


10.5 values:

family: Futura, psname: Futura-CondensedMedium, face: Condensed Medium, apple-weight: 5, css-weight: 4, traits: 00000040
family: Futura, psname: Futura-CondensedExtraBold, face: Condensed ExtraBold, apple-weight: 11, css-weight: 8, traits: 00000042
family: Futura, psname: Futura-Medium, face: Medium, apple-weight: 6, css-weight: 5, traits: 00000000
family: Futura, psname: Futura-MediumItalic, face: Medium Italic, apple-weight: 5, css-weight: 4, traits: 00000001

Logged as Apple problem 5710246.

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

Workaround 10.4/10.5 font traits differences by explicitly setting them in all cases.  Combined with the work done for 404310, this is enough to resolve this problem.

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

Note: the NSUnboldFontMask and NSUnitalicFontMask bits are used when looking for a font face to match a style.  In MacOSFamilyEntry::FindFont, we either look for faces that are italic or not italic, the code depends on NSUnitalicFontMask.  We don't currently use NSUnboldFontMask but to avoid nasty future "only on 10.5" bugs, set it also.

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

Checked in.

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

(In reply to comment #18)

> Logged as Apple problem 5710246.

Response from Apple:

Hi John,

This is a follow-up to Bug ID# 5710246.   

Engineering has determined that this issue behaves as intended based on the following information:

We're phasing out the old DPS-originated font traits and migrating to new definitions via NSFontDescriptor.

NSUnboldFontMask and NSUnitalicFontMask have been only recognized by -convertFont: variants so this change should not cause any real compatibility damages.

If the you have some specific compatibility needs, please provide the details.

We consider this issue closed.  Thank you for taking the time to notify us of this issue.

Best Regards,

Ted Fawcett
Apple Developer Connection 
Worldwide Developer Relations