154007 - Mozilla's computed x-heights don't match real font x-heights

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Greg K.]

When an "x" character glyph is displayed next to an image whose height is
defined to be 1ex in CSS, the height of the x glyph and the image aren't the same.

Comment 1

[Greg K.]

Attachment: Minimal testcase

Comment 2

[Greg K.]

See also bug 18814. This may just be broken on Mac.

Comment 3

[Hixie (not reading bugmail)]

This is a dup of the bug to implement getBoundingMetrics on Mac (or something).

Comment 4

[Greg K.]

Bug 74821?

Comment 5

[Greg K.]

I think this should stay open, but depend on that bug.

Comment 6

[rbs]

Taking. This is needed for nicer MathML alignments.

Comment 7

[rbs]

--> meant to re-assign.

Comment 8

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

Attachment: testcase showing multiple fonts

Note that the width of the images makes it easy to see whether we're varying
the definition by font.  (We currently are on Linux.)

Comment 9

[rbs]

Attachment: patch - tested

Does this do the trick? I read the documentation at:
http://developer.apple.com/technotes/te/te_21.html#Section8
http://www.mactech.com/articles/develop/issue_09/Ressler_article.html

[BTW, there seems to be a difference of GfxMac vs. other platforms. It seems
that the Mac gets its CSS metrics (e.g., emheight, maxAscent, maxDescent, etc)
from the first font, instead of the first ASCII font. So if somebody uses
"font-family: Symbol, Times", the metrics might come from Symbol. That isn't
the case on other platforms where the CSS metrics are taken from the first
ASCII font. Also, I am not sure if the CSS ordering (i.e., font switching) is
totally honored when hunting for glyphs. There seems to be some voodoo going on
w.r.t. the 'script' business and since I can't test, I cannot confirm / deny
what I am alluding.]

Comment 10

[rob raguet-schofield]

roger, your patch works correctly for me.

Comment 11

[rbs]

dbaron/peterv/sfraser, either of you care to r/sr based on schofield's testing?
http://bugzilla.mozilla.org/attachment.cgi?id=91775&action=edit

I will be driving his patch for bug 107146 and closing this little gem will 
clear the way (and my tree...). Also, the API that I used is the same that he is 
using over there.

Comment 12

[Greg K.]

[e-mail], are you saying that bug 107146 depends on this bug being fixed?

Comment 13

[rbs]

No. I am saying that I am the one who will apply and checkin the bigger patch
for the other bug -- and it would be convenient if my tree is clean, and that it
isn't bad to checkin a little snippet that is using the measuring API that is
being used for the other bigger patch.

Comment 14

[Frank Tang]

Comment on attachment 91775 [details] [diff] [review]
patch - tested

r=ftang

Comment 15

[Simon Fraser [no longer active]]

Comment on attachment 91775 [details] [diff] [review]
patch - tested

sr=sfraser

Comment 16

[Asa Dotzler [:asa]]

Comment on attachment 91775 [details] [diff] [review]
patch - tested

a=asa (on behalf of drivers) for checkin to 1.1

Comment 17

[rbs]

Checked in -- When I hit enter, I realised that I forgot to add the a= on the
checkin comment...

Comment 18

[Greg K.]

This does appear to be fixed in FizzillaCFM/2002080203. However, there does
appear to be occasional discrepancy due to text antialiasing. I'll attach a
screenshot of testcase 2.

Comment 19

[Greg K.]

Attachment: Screenshot of testcase 2 in FizzillaCFM/2002080203

Note that, in examples 4 and 5, the 5em x is 1px taller than the img.

Comment 20

[rbs]

Do you have a comparative screenshot using an earlier build without the patch?

Comment 21

[Greg K.]

Attachment: Screenshot in Moz 1.1b, before patch

Sure, here's one. This shows how bad it was before your patch.

Comment 22

[Greg K.]

Attachment: New testcase with size change capability

Use this testcase to observe what I'm talking about. The difference is most
apparent at even px sizes between about 74 and 90. This may not be a problem
with your patch, or even with Mozilla, but could be related to the text
antialiasing. Or, it could be a rounding error in Mozilla, who knows.

Comment 23

[Madhur Bhatia]

verified