637027 - Font Edita rendered at the wrong size

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Basil Fritts]

Attachment: Screen capture of the problem, as displayed in the 2011-02-26 4.0b13pre nightly

At the website http://fontdeck.com/, a sample of the font "Edita" displays at the wrong size. Other browsers (Firefox 3.6.13, Safari 5.0.3) do not display this problem.

I have seen this in the latest nightly (2011-02-26 4.0b13pre) and in the last 3 versions (4.0beta10, 4.0beta11, 4.0beta12) of 4.0 beta.

Comment 1

[Jonathan Kew [:jfkthame]]

This is a font bug. Dumping the 'OS/2' table of the Edita font with ttx reveals:

  <OS_2>
    <version value="3"/>
    <xAvgCharWidth value="1016"/>
    <usWeightClass value="400"/>
    <usWidthClass value="5"/>
    <fsType value="00000000 00000000"/>
    <ySubscriptXSize value="1434"/>
    <ySubscriptYSize value="1331"/>
    <ySubscriptXOffset value="0"/>
    <ySubscriptYOffset value="287"/>
    <ySuperscriptXSize value="1434"/>
    <ySuperscriptYSize value="1331"/>
    <ySuperscriptXOffset value="0"/>
    <ySuperscriptYOffset value="977"/>
    <yStrikeoutSize value="102"/>
    <yStrikeoutPosition value="512"/>
    <sFamilyClass value="0"/>
    <panose>
      <bFamilyType value="2"/>
      <bSerifStyle value="0"/>
      <bWeight value="5"/>
      <bProportion value="3"/>
      <bContrast value="6"/>
      <bStrokeVariation value="0"/>
      <bArmStyle value="0"/>
      <bLetterForm value="2"/>
      <bMidline value="0"/>
      <bXHeight value="3"/>
    </panose>
    <ulUnicodeRange1 value="10000000 00000000 00000000 11101111"/>
    <ulUnicodeRange2 value="00000000 00000000 00100000 01011010"/>
    <ulUnicodeRange3 value="00000000 00000000 00000000 00000000"/>
    <ulUnicodeRange4 value="00000000 00000000 00000000 00000000"/>
    <achVendID value="TT  "/>
    <fsSelection value="00000000 01000000"/>
    <fsFirstCharIndex value="32"/>
    <fsLastCharIndex value="64260"/>
    <sTypoAscender value="1480"/>
    <sTypoDescender value="-520"/>
    <sTypoLineGap value="400"/>
    <usWinAscent value="1880"/>
    <usWinDescent value="520"/>
    <ulCodePageRange1 value="00100000 00000010 00000000 00001011"/>
    <ulCodePageRange2 value="11000000 11010100 00000000 00000000"/>
    <sxHeight value="320"/>
    <sCapHeight value="1320"/>
    <usDefaultChar value="0"/>
    <usBreakChar value="32"/>
    <usMaxContex value="4"/>
  </OS_2>

In particular, the value sxHeight here is wildly inaccurate - looking at the actual glyphs, it's more like 880 than 320. (The sTypo* metrics are not right either.) The ex-height value is important for applying the font-size-adjust property, which is used in the fontdeck.com CSS, and this leads to the unwanted scaling of the font.

So Firefox is behaving correctly given the font and CSS that it's being served. I don't think Safari supports font-size-adjust, and so it doesn't pay the same attention to these particular fields in the font.