Closed
Bug 470713
Opened 16 years ago
Closed 15 years ago
otf fonts render with different metrics compared to ttf version
Categories
(Core :: Graphics, defect, P3)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jtd, Assigned: jtd)
Details
Attachments
(3 files)
screenshot, ttf vs. otf renderings of markA font
When the same font is produced in both otf and ttf form, the otf form uses slightly different metrics under Windows. Steps: 1. Open testcase page that uses .ttf version of test font: http://people.mozilla.com/~jdaggett/font-face/download-2-big.html 2. Open testcase page that uses .otf version of test font in a new tab: http://people.mozilla.com/~jdaggett/font-face/download-2-big-otf.html Result: the page using the .otf font renders slightly lower than the page using the .ttf version. Expected result: test pages should match (true under Mac/Linux)
|
Assignee | |
Comment 1•16 years ago
|
||
Note: the .otf font renders the same way whether used within a @font-face rule or installed locally.
|
||
Comment 2•16 years ago
|
||
The hhea table for these fonts suggests a line height of 700 - (-100) + 90 = 890, where em height is 1000. Having a line height less than the em size seems a bit strange so I wonder whether the fontconfig defaults for the hhea line gap are a bit weird here. while the typo metrics from the os/2 table suggest 800 - (-200) + 90 = 1090 which seems more reasonable. I wonder whether the otf font might be using the typo metrics?
Does the problem go away if you use 'line-height: 1.2'? (That would say whether it's a problem with the computation for 'line-height: normal' or not.)
|
|
Assignee | |
Comment 4•16 years ago
|
||
With line height set to 1.2, the .otf testcase renders identically, the .ttf testcase shift down a bit but not as much as the .otf testcase.
|
|
Assignee | |
Updated•16 years ago
|
Assignee: nobody → jdaggett
Priority: -- → P3
|
|
Assignee | |
Comment 5•16 years ago
|
||
With ttf font above, otf font below. otf font appears to be "riding low", it's a couple pixels lower than the ttf version of the same glyph. Safari 3.2 (Win) draws both identically.
|
|
Assignee | |
Comment 6•16 years ago
|
||
|
|
Assignee | |
Comment 7•16 years ago
|
||
I played around with this today and I'm not sure this is actually our bug, it may just be one of those "otf's are different on Windows" bugs. The test font was created in FontForge from the same glyph data but for some reason saves the .otf form with slightly different metrics, the metrics that Windows calculates in gfxWindowsFonts::ComputeMetrics are different: xHeight ttf=32, otf=25 internalLeading ttf=-9, otf=0 externalLeading ttf=4, otf=0 maxHeight ttf=39, otf=48 maxAscent ttf=34, otf=43 The difference in the leading values will lead to different line heights: http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsHTMLReflowState.cpp#2015 Not sure why Windows is calculating this differently. Below are the values in various TT tables, dumped out with ttx. Maybe Windows is using an Adobe library to analyze metrics in the CFF data?!? markA.ttf: <head> <flags value="00000000 00001011"/> <unitsPerEm value="1000"/> <xMin value="33"/> <yMin value="-100"/> <xMax value="1400"/> <yMax value="700"/> <lowestRecPPEM value="8"/> <fontDirectionHint value="2"/> </head> <hhea> <ascent value="700"/> <descent value="-100"/> <lineGap value="90"/> <advanceWidthMax value="1500"/> <minLeftSideBearing value="0"/> <minRightSideBearing value="0"/> <xMaxExtent value="1400"/> </hhea> <hmtx> <mtx name=".notdef" width="1500" lsb="33"/> <mtx name=".null" width="0" lsb="0"/> <mtx name="A" width="1500" lsb="100"/> <mtx name="nonmarkingreturn" width="1500" lsb="0"/> </hmtx> <OS_2> <version value="1"/> <xAvgCharWidth value="1500"/> <sTypoAscender value="800"/> <sTypoDescender value="-200"/> <sTypoLineGap value="90"/> <usWinAscent value="700"/> <usWinDescent value="100"/> </OS_2> markA.otf: <head> <flags value="00000000 00001011"/> <unitsPerEm value="1000"/> <xMin value="100"/> <yMin value="-100"/> <xMax value="1400"/> <yMax value="700"/> <lowestRecPPEM value="8"/> <fontDirectionHint value="2"/> </head> <hhea> <ascent value="700"/> <descent value="-100"/> <lineGap value="90"/> <advanceWidthMax value="1500"/> <minLeftSideBearing value="0"/> <minRightSideBearing value="0"/> <xMaxExtent value="1400"/> </hhea> <hmtx> <mtx name=".notdef" width="1500" lsb="0"/> <mtx name="A" width="1500" lsb="100"/> </hmtx> <OS_2> <version value="3"/> <xAvgCharWidth value="1500"/> <sTypoAscender value="800"/> <sTypoDescender value="-200"/> <sTypoLineGap value="90"/> <usWinAscent value="700"/> <usWinDescent value="100"/> <sxHeight value="0"/> <sCapHeight value="700"/> <usDefaultChar value="32"/> <usBreakChar value="32"/> <usMaxContex value="1"/> </OS_2>
|
|
Assignee | |
Comment 8•15 years ago
|
||
Using Windows GDI font metrics calls return different metrics for otf vs. ttf fonts, even if the font metrics are *identical*. This has been fixed in DirectWrite API's, I don't think it makes a lot of sense to try and reverse engineer and undo whatever metrics adjustments GDI is making in the .otf case.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
See also: http://hg.mozilla.org/mozilla-central/rev/73136638c630 Is using DirectWrite something we could check for in the reftest manifest (with a simple addition to the reftest harness based on information already in the build system) so that we can change the fails-if condition rather than switching to random-if()?
|
|
Assignee | |
Comment 10•15 years ago
|
||
I'm not sure this test (i.e. comparing a TTF to an OTF version of the same font) is entirely worthwhile, underlying font system differences can cause the rasterization to be different around the edges, especially on Windows where two separate rasterizers are involved. I was mainly concerned that Bas's Direct2D patch would be blocked by this reftest unexpectedly passing. It might be possible to construct a better testcase with a font specifically constructed to avoid rasterization issues but that's not really a high priority.
You need to log in
before you can comment on or make changes to this bug.
Description
•