[Webkit-unassigned] [Bug 41535] "vertical-align: middle; " not working on a MathML element

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=41535





--- Comment #9 from François Sausset <sausset at gmail.com>  2010-09-06 12:25:20 PST ---
(In reply to comment #8)
> (In reply to comment #6)
> I am slightly confused here. CGFontGetXHeight() returns an integer. Is the integer returned for Apple Symbols not zero? Or are you saying that the result of static_cast<float>(0) / m_unitsPerEm is not zero? That is odd. By casting to int and comparing to zero you are treating all values smaller than 1 as zero.

Indeed the result of the cast to a float followed by a division gives a non-zero results (CPU rounding problem). It is zero + epsilon where epsilon is the smallest float possible.

I'm aware that the cast to an int is not perfect.
A solution should be to store the result of GFontGetXHeight() and to test it. But in that case, Tiger returns a float for xHeight through NSFont...

> 
> I still don’t understand the choice of either constant here. This is what <http://www.w3.org/TR/2009/CR-CSS2-20090908/syndata.html#length-units> says:
> 
> In the cases where it is impossible or impractical to determine the x-height, a value of 0.5em should be used.

I agree that 0.5 em is the most natural, but I wanted to have the same result between Apple Symbols and other fonts.
The green box in the test case is not correctly aligned if I use 0.5 em. If I use 2/3, it renders like others fonts.
Strange...
> 
> > The change is only needed for the mac port, as it is here to fix the Apple Symbols font problem.
> 
> The change is not font-specific, and there may be other fonts, which may be used on other platforms, that have a zero x-height. How do other platforms deal with it?

On Cairo and Pango, they seem deal internally with such problems.
On Haiku, Win, WinCE, and CairoWin they use: m_xHeight = m_ascent * 0.56f; when no "x" glyph exists or as default (depending on the implementations).
On Core Graphics on Windows, it is like on the mac.
On Linux and ChromiumWin they use 0.56, if no "x" glyph exists.

However, 0.56 is erroneous as can been seen when zooming to have big fonts.
Try with the test case and switch from apple symbol to arial or STIX fonts.

Should I correct other implementations?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.