689087 - Firefox on Lion doesn't recognize the Baskerville font

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Alex Limi (:limi) — Firefox UX Team]

Attachment: Image with annotations that describe differences

See attached image. I'm pretty sure that these things used to work when I use Firefox on earlier versions of OS X, but I don't have one here to test with, so any help here would be appreciated. 

When loading http://limi.net/articles/safari-downloads/ in various browsers, notice how Firefox isn't rendering the fonts correctly. Annotations from the image (Firefox is top left, Safari top right, Chrome bottom left):

1. Should be a "fancy" italics version of the ampersand, but seems to either have the wrong typeface or doing a manual italicized version instead of picking the dedicated font variant.

2. The additional spacing here also seems to indicate that the wrong font and/or weight/spacing is being used.

3. Small-caps style doesn't seem to be working either.

4. Looking at the font, it renders slightly differently, especially noticable in the "p" in "proposed", which makes me think it's using the wrong font variant.

I'm pretty sure this used to work (or still works) on OS X 10.5/10.6, but seems broken in 10.7. I designed the layout in Firefox 3.6/4 on 10.6, and it looked correct at the time.

Comment 1

[Alex Limi (:limi) — Firefox UX Team]

This might be a better component, not sure if Text includes fonts/typefaces.

Comment 2

[Boris Zbarsky [:bzbarsky]]

It most definitely does.

Comment 3

[Jonathan Kew [:jfkthame]]

Offhand, it looks to me like much (all?) of the text is appearing in Times rather than Baskerville. The difference is fairly subtle for the Regular face, but much more obvious in Italic.

I notice that your font-family properties have Times as a fallback (e.g. font-family: Baskerville, Times, "Times New Roman", serif;), so this would be expected behavior if, for some reason, the browser doesn't recognize the existence of a family named Baskerville.

So the question is why FF isn't using Baskerville on your machine, if the other browsers can find it. Could you check in Font Book and verify that there's a Baskerville family? Then look in the font list in Firefox prefs (Content tab), and check whether it appears there.

On my Mac (running 10.6), Font Book shows me that the Baskerville family has 6 faces (regular and italic of three different weights), and (using the Preview/Show Font Info option) that they're installed as a TrueType Collection file at /Library/Fonts/Baskerville.ttc. The six faces are all marked as being version 6.1d5e1. I'm curious whether the Lion version is significantly different...

Comment 4

[Jonathan Kew [:jfkthame]]

(In reply to Alex Limi (:limi) — Firefox UX Team from comment #0)
> 3. Small-caps style doesn't seem to be working either.

This would be a separate issue from the failure to use Baskerville.

However, I suspect in this case Firefox may be right, and the other browsers wrong. I didn't study all your CSS, but I did notice

  p.documentDescription + p:first-line,
  hr + p:first-line {
      font-variant: small-caps;
      text-transform: lowercase;
  }

which looks like it's what sets that first line in small-caps. Notice that it also applies text-transform: lowercase. I'd expect this to make the "M" of Mozilla and the "F" of Firefox match the rest of the text, as seen in Firefox, rather than sticking up as full-size capitals (as I see in Safari). Looks to me like the other browsers are failing to apply the lowercase transform here for some reason.

Comment 5

[Alex Limi (:limi) — Firefox UX Team]

(In reply to Jonathan Kew (:jfkthame) from comment #4)
> (In reply to Alex Limi (:limi) — Firefox UX Team from comment #0)
> > 3. Small-caps style doesn't seem to be working either.
> 
> This would be a separate issue from the failure to use Baskerville.
> 
> However, I suspect in this case Firefox may be right, and the other browsers
> wrong. I didn't study all your CSS, but I did notice
>
> Looks to me like the other browsers are failing to apply the lowercase
> transform here for some reason.

You're right, Firefox actually does the right thing here in that particular case. :)


(In reply to Jonathan Kew (:jfkthame) from comment #3)
> Offhand, it looks to me like much (all?) of the text is appearing in Times
> rather than Baskerville. The difference is fairly subtle for the Regular
> face, but much more obvious in Italic.

Yup, that's exactly it, thanks for the fontspotting help.

> I notice that your font-family properties have Times as a fallback (e.g.
> font-family: Baskerville, Times, "Times New Roman", serif;), so this would
> be expected behavior if, for some reason, the browser doesn't recognize the
> existence of a family named Baskerville.
> 
> So the question is why FF isn't using Baskerville on your machine, if the
> other browsers can find it. Could you check in Font Book and verify that
> there's a Baskerville family? 

Yup, Baskerville is definitely there (and also standard in OS X, but smart to double check).

> Then look in the font list in Firefox prefs
> (Content tab), and check whether it appears there.

Yes, also listed in the font list in Preferences -> Content in Firefox.

> On my Mac (running 10.6), Font Book shows me that the Baskerville family has
> 6 faces (regular and italic of three different weights), and (using the
> Preview/Show Font Info option) that they're installed as a TrueType
> Collection file at /Library/Fonts/Baskerville.ttc. The six faces are all
> marked as being version 6.1d5e1. I'm curious whether the Lion version is
> significantly different...

Looks like they may have updated it? here's what's in the Info panel on Lion:

Version	7.0d4e2
Location	/Library/Fonts/Baskerville.ttc
Unique name	Baskerville; 7.0d4e2; 2011-03-16

Comment 6

[Jonathan Kew [:jfkthame]]

(In reply to Alex Limi (:limi) — Firefox UX Team from comment #5)
> Yes, also listed in the font list in Preferences -> Content in Firefox.

OK, so Firefox definitely knows it exists - it's in our list of installed fonts.

> Looks like they may have updated it? here's what's in the Info panel on Lion:
> 
> Version	7.0d4e2
> Location	/Library/Fonts/Baskerville.ttc
> Unique name	Baskerville; 7.0d4e2; 2011-03-16

Yes, that's a newer version (though of course it doesn't tell us what the changes are). My guess is that the Baskerville font on Lion has been updated in some way that confuses Firefox, so that although it's in the font list, we end up rejecting it at CSS font-matching time and falling back to the next font in the font-family property.

Taking a stab in the dark, I wonder if we're failing to read the 'cmap' table, with the result that FF believes the font doesn't actually support any Unicode codepoints, and so it gets rejected when matching fonts to the text. This could be due to either a bug in our code (failing to correctly interpret the table, even though it's valid) or a minor bug in the font that some code ignores, but that causes us to reject it.

Further analysis will require hands-on access to the Lion version of the font, to examine the font data in detail, and then possibly to a Lion system running a debug build in order to see where it's failing. I suppose it's time to consider upgrading........

Comment 7

[Jonathan Kew [:jfkthame]]

Looks like other people have run into this, too: http://support.mozilla.com/en-US/questions/853162

Comment 8

[Jonathan Kew [:jfkthame]]

The issue here is that there is an error in the 'cmap' table of the Baskerville font that ships with Lion. If you run a debug build of Firefox, you'll see messages of the form

WARNING: NS_ENSURE_TRUE((startCount > prevEndCount || i == 0 || startCount == 0xFFFF) && startCount <= endCount) failed: file /Users/jonathan/mozdev/mc/gfx/thebes/gfxFontUtils.cpp, line 366

printed to the console; this comes from the cmap-reading code, which detects the error and rejects the table. The result is that we regard the Baskerville font as supporting no characters, so all text falls back to the next font in the font-family list.

Although this is strictly speaking a font bug - specifically, a format-4 subtable has two successive segments for the same (single) character code - I think we can safely relax our validity checking slightly at this point, and allow the table to be used despite this.

Comment 9

[Jonathan Kew [:jfkthame]]

Attachment: patch, relax cmap format 4 checking slightly to allow Baskerville on Lion to work

Comment 10

[Jonathan Kew [:jfkthame]]

Filed Radar bug 10353973 to report the font error to Apple.

Comment 11

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

As requested by limi:

https://hg.mozilla.org/integration/mozilla-inbound/rev/e0cafbf433ea

Comment 12

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/e0cafbf433ea

Comment 13

[philippe (part-time)]

Question: did this patch also made Helvetica Neue Light 'work' in Mozilla 11 (it fails to load in Gecko 1.9.2 - Gecko 9 / Fx 9) ?

Test case: http://dev.l-c-n.com/_temp/helveN-L.html (the top two paragraphs)

Question 2: could this patch be backported to Gecko 1.9.2 ?
(Camino users would be happy - tia)