Hi Steve,
Le 20/04/2015 09:13, Steve White a écrit :
We did a lot of work on the MATH tables this weekend. Thanks for your
great test page!
You're welcome. And thanks for working on this. I plan to add more
tests to my page later. For now, I've regenerate it using the last
dev version of the font:
http://fredwang.github.io/MathFonts/GNUFreeFont/
Several were added or corrected, and some new glyphs were added to
make further extensible characters.
Nice! There are obviously many stretchy operators in
http://www.w3.org/TR/MathML3/appendixc.html and even "exotic"
characters like wave arrow and so on for which it's not clear how to
do the constructions... I think the top priority would be the
"largeop" operators and especially the double, triple, quadruple,
(clockwise/anticlockwise) contour integrals.
BTW regarding large operators, I've added tests to verify the size
of the operator in displaystyle mode. For example on
http://fredwang.github.io/MathFonts/GNUFreeFont/ the first line of
the sum show the base size (blue) and displaystyle mode (red) glyph.
You can see concrete examples with the integrals, sum and prod of
http://fredwang.github.io/MathFonts/. Normally, the
DisplayStyleMinHeight in the MathConstants subtable allow to control
the minimal size of the displaystyle mode glyph.
Also, I believe U+2229 and U+222A are just binary operators (as
opposed to the "Nary" largeops U+22C2, U+22C3) so I think they
don't need to have stretchy forms.
There are already several vertical sizes for sum, integral, and slash.
The largest sizes of these are already at the bounds prescribed by the
font. To go farther would cause serious line spacing issues  we
can't do that.
I'm not sure I know enough about font design to understand the issue
here. I'm cc'ing Khaled who might know more about how to include
large size variants without causing line spacing issues.
A simple mechanism of constructing larger characters from two halves
would permit a summation twice as high, as well as neatly shaped angle
brackets twice as high. However, on your advice we have removed the
table entries in the font that were meant to do this.
It escapes me why the existing font tables can't be used for that
purpose  I presume it's just forbidden in some standards document,
but I don't think I've seen that document.
Could you provide a link to the standards document governing the use
of the OpenType MATH tables, which makes this clear?
So my understanding is that
1) A constructions made of several glyphs without any extender will
have a fixed size anyway, so they can just be done using a size
variant (this is of course ignoring the line spacing issues
mentioned above).
2) Technically, there is no problem to define and implement the
concept of constructions made of several glyphs without any
extender. However, as Jonathan Kew pointed out, the layout described
in the OpenType MATH spec assumes there is at least one extender
(otherwise the suggested algorithm would lead to an infinite loop):

Assemble all parts by
overlapping connectors by maximum amount, and removing all
extenders. This gives the smallest possible result.

Determine how much extra
width/height can be distributed into all connections
between neighboring parts. If that is enough to achieve
the size goal, extend each connection equally by changing
overlaps of connectors to finish the job.

If all connections have
been extended to minimum overlap and further growth is
needed, add one of each extender, and repeat the process
from the first step.
See
https://wiki.mozilla.org/MathML:Open_Type_MATH_Table#References
for the references to the latest spec. You can also ask
clarification to Murray Sargent (Microsoft) who worked on this spec
for Microsoft Word...

Frédéric Wang
mathsinformatiquejeux.com/blog/frederic