Minutes: MathML core meeting 9/12/19

MathML Core Meeting of 25, 2019



Attendees:

   -

   Fred Wang
   -

   Brian Kardell
   -

   Bruce Miller
   -

   David Carisle
   -

   Murray Sargent
   -

   Neil Soiffer
   -

   Sam Dooley


Agenda:
https://github.com/mathml-refresh/mathml/issues/8#issuecomment-562473781



The meeting was recorded:
https://benetech.zoom.us/recording/play/HQ38_I14qAditiAD3enC5iuYZlSP_eKOAD0ssrldd7L0GLWeMh5XTZ18d4VW47Tn?continueMode=true


MathML meeting in A Coruna, Spain in May

FW: The plan is to include a MathML as part of a hackfest organized by
Igalia. There would be a special room for MathML for breakout sessions.
Fred is starting to send out invitations. Later in Jan we can invite more
people when the agenda is clearer.

NS: Who’s interested in coming?

MS: I’m interested. I like Spain :-) I want to meet people and want to talk
about pulling the math functionality of RichEdit and make it available to
others and talk about it at the meeting. In particular convert UnicodeMath
and LaTeX to MathML (and OMML, since that comes for free).

DC: I’ll probably come.

NS: Maybe work on a charter for a WG at the meeting.

BM: Not sure

SD: Like to go, but costs are an issue

FW: Let’s work on the agenda some more

TAG review (Brian) - can we close explainer issues? #156
<https://github.com/mathml-refresh/mathml/issues/156> #157
<https://github.com/mathml-refresh/mathml/issues/157> #158
<https://github.com/mathml-refresh/mathml/issues/158>

BK: I was there to introduce and answer questions. Talked to people who
would be doing review.

BK: Was well received, but not everyone was there. So need to talk with
more people.

BK: Looked at explainer and spec and felt that we had answered the things
they had questions about. They need more time to review and don’t have
anything negative to say.

BK: Hadley had some questions about the explainer so a few things might
need to be added.

Agree: close #156, #157
Operator Dictionary (David)

   - any updates on fixing up entries
   - Make things more consistent and general review & fixup #87
   <https://github.com/mathml-refresh/mathml/issues/87> #6
   <https://github.com/mathml-refresh/mathml/issues/6> #151
   <https://github.com/mathml-refresh/mathml/issues/151>

DC: No progress. I’ll try to work on it on the weekend. Not covered by my
work.

NS: I might be able to help. At least to help explain why some things are
the way they are.

OpenType questions for Microsoft (Murray)

   - https://lists.w3.org/Archives/Public/public-mathml4/2019Nov/0013.html
   - ink ascent/descent #128
   <https://github.com/mathml-refresh/mathml/issues/128>
   - interpretation of DisplayOperatorMinHeight: #95
   <https://github.com/mathml-refresh/mathml/issues/95>

MS: I read a bunch of this stuff. Stty is pretty cool, but has nothing to
do about math, so ignore it.

NS: Murray can you look at the stty mention in the core spec
<https://mathml-refresh.github.io/mathml-core/>.

MS: You shouldn’t use stty for superscripts.

FW: The open type mentions superscripts.

MS: That was for regular text, not math. I’ll take it up with the people
who wrote.

MS: I put superscripted digits into a real superscript.

FW: For MathML it works well. It is already implemented in Firefox.

FW: When you put a prime inside of a superscript, it is already
superscripted.

DC: The problem is that some fonts have the primes already as a superscript.

NS: Degree also has this problem.

MS: Also dagger and asterisk.

MS: At least I understand the problem and will think it about it some more.

FW: what about ink ascent/descent

MS: he uses “typo” for the ascent/descent in the OS 2 table, not from the
math table.

FW: the spec already says to use that for the whole font:
https://mathml-refresh.github.io/mathml-core/#text-layout

FW: the issue here is that each glyph has a separate ascent/descent. The
opentype font talks about ink ascent/descent. Clear for text. But what
about MathML boxes? Eg., square root requires some extra ascent space above
it. What is the ink ascent for the square root? What do the tables say
about this? Firefox has a complex definition for it. Not sure it is needed.

MS: The math table has a whole slew of metrics for ascents. Not sure of
descents.

FW: The example in the github issue is a square root in a fraction
denominator. When you want to place the square root in the denominator and
put space between it and the fraction line. The rule for square roots add a
little space above the line. The rule for placing the denominator is to use
ink ascent. What to do about square roots?

MS: The square root is just a box and so it should include the square
root’s spacing.

FW: In MathML you can add padding. But this would allow some simplification
in the spec.

MS: On the hand, being able to do padding is important. Knuth wants sqrt(x)
and sqrt(y) to have the same size for the sqrt.

<discussion of mphantom and mpadded and TeX’s phantom>

FW: to come back to the issue, all the engines were not making a
distinction between ink ascent for square roots. Sergey provided a screen
shot for Word. Couldn’t explain the results for how Word did it.

MS: I can look at this in a debugger after the call.

FW: I created a special font to make it clearer. Take a look at the issue
for details.

Action: MS to think about ssty and square root height

FW: What about DisplayMinHeight in OpenType table (#95)

FW: There is only one value, but sums and integrals are very different
sizes. What should happen?

MS: It is used by MS. <Looking at the code> -- it’s not obvious how it is
used by MS.

FW: In browsers, you look at the options and choose the first one that is
larger than the min size. But usually there are only two sizes. But
integrals are generally larger than sums.

MS: In our code, it uses the axis height inline and the minsize for display
style.

FW: It really depends on how the font is designed. In some fonts, the size
is too small and doesn’t get a bigger integral.

NS: Maybe this isn’t an issue any more with modern fonts. Should check some
to see if minsize is big enough

MS: <looking at code> …

NS: Seems like the font designer picks the size, so the minsize should be
able to make sum/integral large enough.

FW: In Firefox, we had to modify by sqrt(2) otherwise integral is too
small. I should try to find the Firefox bug again and look at the details.
Found it: https://bugzilla.mozilla.org/show_bug.cgi?id=407059#c8


Next meeting is Dec 16 and then we will take several weeks off for the
holidays.