Closed
Bug 400717
Opened 17 years ago
Closed 17 years ago
[10.5] Futura family name maps to condensed face on Leopard
Categories
(Core :: Graphics, defect, P5)
Tracking
()
RESOLVED
FIXED
People
(Reporter: beltzner, Assigned: jtd)
References
()
Details
Attachments
(6 files)
24.67 KB,
image/png
|
Details | |
47.19 KB,
image/png
|
Details | |
22.52 KB,
image/png
|
Details | |
2.14 KB,
patch
|
Details | Diff | Splinter Review | |
461 bytes,
text/html
|
Details | |
1.75 KB,
patch
|
vlad
:
review+
vlad
:
superreview+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•17 years ago
|
||
Reporter | ||
Comment 2•17 years ago
|
||
Reporter | ||
Updated•17 years ago
|
Summary: Futura looks squished on Leopard → [10.5] Futura looks squished on Leopard
Comment 3•17 years ago
|
||
It is picking up Futura Condensed instead of Futura, see bug 396083 comment 13
Assignee | ||
Updated•17 years ago
|
Assignee: nobody → jdaggett
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
Assignee: jdaggett → nobody
Component: GFX → GFX: Thebes
Flags: blocking1.9?
QA Contact: general → thebes
Reporter | ||
Comment 5•17 years ago
|
||
Wow. That's an awful typo. s/Stewart/Stuart/
Assignee | ||
Updated•17 years ago
|
Assignee: nobody → jdaggett
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.
Assignee | ||
Updated•17 years ago
|
Summary: [10.5] Futura looks squished on Leopard → [10.5] Futura family name maps to condensed face on Leopard
Reporter | ||
Comment 7•17 years ago
|
||
Does this get RESO DUPE of bug 396083?
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.
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.
Assignee | ||
Comment 10•17 years ago
|
||
Logged as Apple problem 5570368.
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.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P5
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
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).
Comment 14•17 years ago
|
||
John-san, how about this? I cannot test on 10.5...
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.
Comment 16•17 years ago
|
||
John how is this now?
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).
Depends on: 404310
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.
Assignee | ||
Comment 19•17 years ago
|
||
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.
Attachment #300120 -
Flags: superreview?(vladimir)
Attachment #300120 -
Flags: review?(vladimir)
Attachment #300120 -
Flags: superreview?(vladimir)
Attachment #300120 -
Flags: superreview+
Attachment #300120 -
Flags: review?(vladimir)
Attachment #300120 -
Flags: review+
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.
Assignee | ||
Comment 22•17 years ago
|
||
Checked in.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
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
You need to log in
before you can comment on or make changes to this bug.
Description
•