543329 - Incorrect heights calculation with @font-face embedding only on Mac

Status: RESOLVED INVALID

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

Description

[hannizkaos]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_2; de-de) AppleWebKit/531.21.8 (KHTML, like Gecko) Version/4.0.4 Safari/531.21.10
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2) Gecko/20100115 Firefox/3.6

I investigated a problem with different line-height across rendering engines. Firefox 3.6 (mac) and Safari 4.0.4 render several fonts with different heights. It’s especially eye-catching with big sizes above 100px. I tried to circumvent this by experimenting a lot of with the relevant css properties but had no success. Even forcing a subline pixel exact underneath a heading with absolute positioning was not successful a all! 

Try yourself at http://hannes.kunstreich.name/static/... or look at the 10px border above h1 in the attached image. In Firefox the font overlaps, in Safari it does not. The overal difference in height adds up to aprox 24px but Safari and FF shows the exact same height in inspector/firebug: 192px as specified... 

(reported first: http://tr.im/MgRZ)


Reproducible: Always

Comment 1

[hannizkaos]

Attachment: Screenshot

Comment 2

[hannizkaos]

I understand that there might be more major bugs than this one, as it is only visible to mac users and the few sites out there, which are using font-embedding. But the numbers grow and font-embedding in general is a big thing: Many many frontend developers and screendesigners using it and are trying to incorporate this permanently. So I suggest to leave this bug classified as major:

1. A buggy feature is no feature. Bugs which cannot be addressed in any way (except browser and platform sniffing) by frontend developers are huge showstoppers. In fact a buggy implementation is worse than no implementation at all. F.e. Opera doesn’t support font embedding. No Problem. Established fall back strategies take over. This cant be done for Firefox/mac. In this situation 
the bug renders the whole font-embedding kind of useless. 

2. Postponing this to 4.0 would mean: Firefox is breaking an important way of bringing the open web a step further. Serious frontend developers cant start to rely on this beautiful new feature as long as there is no timeframe for fixing bugs like this. 

3. Firefox crashing on rare edge cases is sure annoying. But I think it’s more annoying for more people to suffer from dealbreakers like the described bug. Better fixing a broken feature, which not only Firefox users themselves rely on and which slows down the adoption of exiting new features across the board, than making Firefox third 9 in 99,999% stable… 

I am unfortunately not able to work on this bug myself. But I am not the only one depending on you. Of course I dont have the big picture of Firefox/Gecko development and cant understand the priorities. But please: Fix this in an minor release. Dont postpone it for months and months. 

Thank you

Comment 3

[John Daggett (:jtd)]

(In reply to comment #2)
> I understand that there might be more major bugs than this one, as it is only
> visible to mac users and the few sites out there, which are using
> font-embedding. 

We need to figure out what the cause is, whether it's specific to this font or not, and figure out a fix.   Simple as that.

Comment 4

[hannizkaos]

Thank you John,

please feel free to contact me at anytime if there is something I can do to assist you!

(f.e. testing with different fonts and/or font-serving solutions like Typekit)

Comment 5

[hannizkaos]

I added a wide variety of different fonts to the example above (which was not linked correctly, sorry!) all served via Typekit. Maybe this is helpful. (Manipulate via the font-stack)

> http://hannes.kunstreich.name/static/typekitbug/

Comment 6

[Jonathan Kew [:jfkthame]]

It would actually be more helpful to have a testcase that does NOT involve Typekit. I realize this may restrict the selection of fonts to experiment with, but it would make investigation within Gecko simpler if the testcase uses a standalone .ttf or .otf file.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Do we know that this problem is specific to downloadable fonts?  That is, does it also happen with the same font if you stop using @font-face, and just have the font installed on your system instead?

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Also, it's not clear to me based on the testcase that there's a bug at all:  using font-size: 190px and line-height: 190px means that glyphs can overlap, since font designers are free to (and typically do) make the extents of the font larger than the em square.  'line-height: normal' does not have this problem.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #8)
> Also, it's not clear to me based on the testcase that there's a bug at all: 
> using font-size: 190px and line-height: 190px means that glyphs can overlap,
> since font designers are free to (and typically do) make the extents of the
> font larger than the em square.  'line-height: normal' does not have this
> problem.

To clarify:  it's not clear from the screenshot *alone* that there's buggy behavior.  That the behavior is different between platforms is probably a bug, and if it's different between the case of the font being downloaded via @font-face and being on the system (if that's the case), that's also probably a bug.  (But neither of those statements says which of the two behaviors you get is the correct one and which is the incorrect one.)

Comment 10

[John Daggett (:jtd)]

Attachment: simple test with Zapfino

Just a quick example with Zapfino, font of death.  Next draws identically in FF trunk / Webkit latest, overflowing the border in both cases.

Comment 11

[John Daggett (:jtd)]

Attachment: screenshot, ff trunk vs webkit nightly, side by side comparison

Text in FF Trunk draws 14px above where it draws in Webkit.

Metrics for the font:

Font: 0x1f2b3480 (ufu0pecoRKQ1eoDLqRh6ENRQ==) size: 190.000000
    emHeight: 190.000000 emAscent: 141.543624 emDescent: 48.456376
    maxAscent: 111.000000 maxDescent: 38.000000 maxAdvance: 210.709994
    internalLeading: 0.000000 externalLeading: 7.790016
    spaceWidth: 57.000000 aveCharWidth: 103.550003 xHeight: 99.749995
    uOff: -19.000244 uSize: 9.500122 stOff: 49.874998 stSize: 9.500122 suOff: 99.749995 suSize: 99.749995

Comment 12

[John Daggett (:jtd)]

Attachment: screenshot, ff rendering two different typekit fonts

Typekit is apparently serving different fonts, TTF vs. WOFF.  On the left is the font served to Webkit browsers (TTF form) and on the right is the same font served to Gecko browsers (WOFF form).  The TTF form of the font renders the same in both Gecko and Webkit.

My guess is that part of Typekit's font production process is producing slightly different font metrics across different formats.  The fonts have different emAscent/emDescent values and different x-height's.

Font served to Gecko in WOFF form:

Font: 0x1a718bb0 (uft+2noP0kRkSmkRLNv37S4w==) size: 190.000000
    emHeight: 190.000000 emAscent: 141.543624 emDescent: 48.456376
    maxAscent: 111.000000 maxDescent: 38.000000 maxAdvance: 211.709994
    internalLeading: 0.000000 externalLeading: 7.790016
    spaceWidth: 57.000000 aveCharWidth: 104.550003 xHeight: 99.749995
    uOff: -19.000244 uSize: 9.500122 stOff: 49.874998 stSize: 9.500122 suOff: 99.749995 suSize: 99.749995

Font served to Webkit in TTF form:

Font: 0x1113510 (ufNzFiPdPHSkmfIFrTPFKMXg==) size: 190.000000
    emHeight: 190.000000 emAscent: 149.664804 emDescent: 40.335196
    maxAscent: 141.000000 maxDescent: 38.000000 maxAdvance: 207.480001
    internalLeading: 0.000000 externalLeading: 7.790016
    spaceWidth: 0.000000 aveCharWidth: 0.000000 xHeight: 93.733329
    uOff: -19.000244 uSize: 9.500122 stOff: 46.866664 stSize: 9.500122 suOff: 93.733329 suSize: 93.733329

This probably should be resolved as invalid.

Comment 13

[Jonathan Kew [:jfkthame]]

Further detail - the <hhea> (horizontal header) table from the WOFF file that Typekit serves to Gecko:

  <hhea>
    <tableVersion value="1.0"/>
    <ascent value="580"/>
    <descent value="-200"/>
    <lineGap value="41"/>
    <advanceWidthMax value="1039"/>
    <minLeftSideBearing value="-42"/>
    <minRightSideBearing value="-43"/>
    <xMaxExtent value="1005"/>
    <caretSlopeRise value="1"/>
    <caretSlopeRun value="0"/>
    <caretOffset value="0"/>
    <reserved0 value="0"/>
    <reserved1 value="0"/>
    <reserved2 value="0"/>
    <reserved3 value="0"/>
    <metricDataFormat value="0"/>
    <numberOfHMetrics value="204"/>
  </hhea>

The <hhea> table from the OTF file served to Webkit:

  <hhea>
    <tableVersion value="1.0"/>
    <ascent value="740"/>
    <descent value="-200"/>
    <lineGap value="41"/>
    <advanceWidthMax value="1039"/>
    <minLeftSideBearing value="-41"/>
    <minRightSideBearing value="-43"/>
    <xMaxExtent value="989"/>
    <caretSlopeRise value="1"/>
    <caretSlopeRun value="0"/>
    <caretOffset value="0"/>
    <reserved0 value="0"/>
    <reserved1 value="0"/>
    <reserved2 value="0"/>
    <reserved3 value="0"/>
    <metricDataFormat value="0"/>
    <numberOfHMetrics value="98"/>
  </hhea>

What appears to be happening is that for Gecko, they're serving the complete font, WOFF-compressed; but for Webkit they're serving a subset (note the numberOfHMetrics value; checking the glyph list confirms this), and the subsetting tool they're using is presumably recalculating metrics and coming up with something quite different from the original metrics the designer specified.

So this is a Typekit issue; their subsetting tool should not be altering overall font metrics.

(It also indicates a potential optimization: if they're going to subset fonts, they could do this for Gecko as well, prior to WOFF compression. This should give the best overall font-load performance.)

Comment 14

[Matt Colyer]

Thanks John and Jonthan for catching this. There indeed was an error in our font processing and our switch to WOFF for Firefox 3.6 uncovered the error. We are currently working on rolling out a fix.

Also as an aside both the WOFF and the OTF files are subsetted (they do not contain the full character set of the original font). The OTF files are split an additional time as a an additional layer of protection against casual copying of the files. So in order to display a full font using the OTF format from Typekit, two fonts data uris are required (in this case the other OTF data uri contains 204 - 98 = 106 characters).

Comment 15

[hannizkaos]

Thanks to all of you resolving this problem!