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.

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

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

Bug 74821?

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

Taking. This is needed for nicer MathML alignments.

--> meant to re-assign.

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.)

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.]

roger, your patch works correctly for me.

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.

rbs@maths.uq.edu.au, are you saying that bug 107146 depends on this bug being fixed?

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 on attachment 91775 [details] [diff] [review] patch - tested r=ftang

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

Comment on attachment 91775 [details] [diff] [review] patch - tested a=asa (on behalf of drivers) for checkin to 1.1

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

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.

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

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

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

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.

verified