Call for testing: Stretching of Operators

Hi folks!

As some of you probably know, there is undergoing work on MathML 
stretching. For the impatient, I set a TryServer here:

https://build.mozilla.org/tryserver-builds/[email protected]/

If I don't miss anything, the list of bugs reported by users and related 
to stretchy operators is:

1) Bug 414294: double vertical bar
2) Bug 416140: underbraces and overbraces
3) Bug 416065: tilde, check and hat accents
4) Bug 464592: square root rendering too large in MathML
5) Bug 491370: right and left angle brackets
6) Bug 516292: triple arrow
7) Bug 518330: large operator

and there are essentially three suggestions that have been made to fix 
these bugs:

I)   Bug 407101: Complete support for STIX fonts
II)  Bug 414277: Use a scale transform to improve stretching
III) Bug 534970: Update MathML Operator Dictionary

A patch has recently been pushed for I), fixing most of the issues 1-7) 
above when the user has STIX fonts installed. I've long been stuck on 
II) but a recent upgrade of the Cairo library seems to have solved my 
problem. The current set of patches for II) and III) fixes all the 
issues 1-7) above.

Unfortunately, the patch for II) possibly makes new bugs appear: some 
operators may stretch in situation where they should not, because of 
errors in our Operator Dictionary or in the way we determine the 
Operator Form. Normally, I've fixed all the issues I'm aware of, but it 
is possible that there are remaining ones. I would like to be sure that 
it is not the case, before asking for a review. That's why I've set a 
TryServer and ask people to test on "real-world" MathML markup. Please 
check improvements and report any unexpected behaviors. It could also be 
interesting to test *without* STIX fonts installed.

Some precisions on 7). MathML3 changed the properties of large operators 
(such that ∑ or ∫) to have the same behavior as TeX, i.e. 
they are only drawn larger, not stretched vertically. This is also what 
we are going to do and the size of the largeop operator are increased by 
a factor of sqrt(2) in display mode. I don't know if this factor is 
ideal, maybe 2 is better for integrals. The patch for II) will also give 
more flexibility to people, allowing them to enable/disable stretchy or 
largeop attributes as they want (on the trunk version, only 
stretchy="false" or largeop="false" have an effect).

Some precisions on the way the patch for II) works. Our current support 
for stretchy char is based on two methods: either using "char variants" 
of different sizes or assembling several glyphs to build "composite 
chars". Using these methods, we try to find a character as near as 
possible to the desired container size. With the patch for II), we apply 
an additional scale transform to this character, so that it exactly fits 
the container size. Of course, scaling is not the same as stretching: if 
the aspect ratio of the scaled character is too different from the 
original one, then we may obtain some unelegant deformation. So the idea 
is the following: if we are already able to stretch very closely to the 
container size, then the scaling gives a slight improvement (consider 
for instance the rendering of radical in the test 13 of torture test) ; 
if we don't support stretching by the classical methods (for instance 
6), for triple arrows) or if the user does not have the appropriate 
fonts installed, then the scaling is considered an acceptable fallback 
to use for stretching.

Frédéric Wang