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://fred-wang.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://fred-wang.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://fred-wang.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 "N-ary" 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): > > 1. > > Assemble all parts by overlapping connectors by maximum amount, > and removing all extenders. This gives the smallest possible result. > > 2. > > 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. > > 3. > > 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 maths-informatique-jeux.com/blog/frederic
signature.asc
Description: OpenPGP digital signature
