Minutes: MathML core meeting Sept 23, 2019

Apologies for the late minutes -- I was away a few days last week...


MathML Core Meeting of Sept 23, 2019

The meeting was recorded:
https://benetech.zoom.us/recording/share/P1V02djAvBnOWzOAPzED8jSPEnIpB0kUCiiXn_hyfHiwIumekTziMw

Attendees:

   -

   Neil Soiffer
   -

   David
   -

   Fred Wang
   -

   Rob Buis
   -

   Brian Kardell
   -

   Sam Dooley
   -

   Patrick Ion

Agenda:

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

TPAC summary (Brian)

BK: meeting went really well wrt to MathML.

BK: Talked with LayoutNG primary architect (Ian Kilpatrick from Google)

BK: We were on the agenda for the CSS agenda for Tuesday for
  1. Text-transform -- didn’t get to it but had conversation afterward with
James Craig from Apple accessibility and some
  2. Got three minutes at end to ask for review of MathML interactions with
CSS. E.g., new ‘display’ property value “math” or “math-auto”. Generally
positive responses.
  3. No disagreement about adding three properties (script-level, etc). No
formal agreement though.

  4. Talked with fantasai and Florian Rivoal (consultants), who tend to be
critical/have comments on new additions. Promised to review within the next
quarter

BK: demos during the event, meeting with the publisher working group. Went
very well. Prepared for 7 minutes but went on for 30 minutes. Very excited
that MathML is finally going into browsers. Will support MathML in any way
they can.

All: Someone from group should definitely attend TPAC next year (in
Vancouver).

Operator Dictionary updates #6
<https://github.com/mathml-refresh/mathml/issues/6> #6 (comment)
<https://github.com/mathml-refresh/mathml/issues/6#issuecomment-532673415>
#87 <https://github.com/mathml-refresh/mathml/issues/87> (Neil, David) #142
<https://github.com/mathml-refresh/mathml/issues/142> #143
<https://github.com/mathml-refresh/mathml/issues/143>

FW: Last week I was writing some tests for this - they are generated from
unicode.xml that David wrote.  After writing that I noticed some
differences - 2 or 3 new operators have changed regarding accent. We
noticed that webkit and chromium still lack support for multichar
operators.

NS: I added some comments, David added some comments. I think they broke
down into 3 categories: Some multichar operators were there for compat with
programming languages (++, etc) - I feel we should keep those, although I
don’t know how much they are really used.

DC: Originally we had sine and cos and others and we threw those out since
they are mi.  At NAG, use them all over - == mostly, it's a software
manual. If it wasn't in the dictionary, we would cope.  We should be
careful to not claim they are stretchy.

NS: None of the programming language ones would be.  There were some that
were added because they weren't in unicode at the time, those were
indicated stretchy/fence type operators.  I agree, just take off stretchy
for all of those and just deprecate the ones that were there for unicode
compat. Do we have to specify stetchy at a font level in the spec?

DC: We just defer to the open type spec.

NS: I agree - the spec just needs to add some statement about/link to it.

DC: There was a question about 2 arabic operators.  I really can't read
them, I did reach out to Kahled but otherwise it is kind of pointless for
us to speculate or guess - we wouldn't even notice if it was wrong.

FW: Separating the multichars - currently in webkit and chromium we have
tables.  If we want to support multichars, we should have a separate table
or make this accept strings of variable length.  If Firefox supports them I
think we need to keep it for compat. Currently we only rely on open type
math - we check for the corresponding glyph in the font, there is an
associated entry in the table - if we have an entry we can stretch it - so
it is ultimately controlled by the font.  We can fallback to something like
a scale transform, but we have to define it and how it doesn't work.

NS: This happens, it's like if you give a plus sign and say it is stretchy
that just doesn't work.

FW: There is still the question of checking each individual character in
the string - but that creates a lot of complexity.

NS: I am ok with just saying multi-character strings can't be stretched.

DC: I think that is fine.

*Resolved*… multi character strings can't be stretched

DC: If you don't use an open type math font, we could fallback to scale
transform.

PI: Should content producers be using those fonts? No

NS: Correct me if I am wrong but I think a lot of open type fonts have math
tables.

DC: Depends on your definition of 'lots'  The main issue we find is that
you can just write text and it will work - but there isn't a single open
type math font installed on every browser.

NS: Ok, maybe not a lot; an acceptable number have math table.

NS: Fred, what was your thought on how we handle this? Always download or
use system ones?

FW: We just follow the webkit approach and use a list of fonts and it just
tries them as standard CSS - we can list the last one as a webfont… Or
well, people can add a webfont if they want, but all we do is use the
default font family.   I think this is a separate issue I opened.

NS: Do we have a resolution that if it is in the table (a character) it
stretches, if not it doesn't stretch, if it doesn't have an open type math
table it doesn't stretch.

FW: It will be annoying, it still has this scale transform if the default
is not installed.

DC: In TeX we find this all the time - people go through all kinds of
effort and they choose some wacky font.  It's not totally unreasonable if
there is simple math, most fonts provide some basic characters. People
stretch brackets all over.

FW: There is already in mathml core a list of unicode constructions for
fences even if there is no math table - and vertical bars and simple
brackets.  I'm not sure we need to address this today, this basic solution
has been in the browsers for a long time. A lot of fonts are already
obsolete. On mobile devices, maybe they don’t want to waste space on a math
font.

NS: How big are the math fonts these days?

FW: I think there is an open issue with this with variable fonts which
would allow for smaller fonts.  As I say it is probably a complicated issue
and we can't solve it today probably.

NS: Just looked - Cambria Math Font is 1.7mb. Doesn’t seem that big to me.

FW: I guess for windows this is ok, but for mobile, I'm not so sure.  I
guess we just keep the fallback when you don't have a math table.

NS: My concern was for what David said when people choose these wacky
fonts. Let's keep it simple - it's got to be a fair amount of code to deal
with fonts

PI: If people want to get their math to look good they should use fonts
with math.

FW: I think some of it is that like with k-12 math you don't want to use
those, they want to use something like comic sans - they don't have complex
needs for stretching.  Even if it is ugly with scale transform, it's enough
for them. We do that in firefox, I'm not sure we are going to remove that -
people complained.

NS: So we will do something like this in chrome too?

FW: I think Rob already did? Maybe it was extra work...

Rob: Yes. Just copied from WebKit, not hard.

NS: Ok, I was just trying to help you out and make it simple.

FW: I guess we just have to write all the tests now, and it's not really
easy to test.  I'm not sure what will happen if someone specifies a
stretchy plus for example, I think it will try.   There's a direction on
this horizontal or vertical. I think a plus would stretch vertically.


NS: 142 was make the operator dictionary normative.  I think david said it
shouldn't be in full, but it could be in core.

FW: 142 was done, to help testing.

DC: We just can't make it normative in full because things that don't use
the web platform won't work.

NS: I'm in favor of resolving it as not normative in full, normative in
core - point full to core.

DC: I think when we come back to full we will have to just use some clever
wording to say try to match core as closely as you can.

Resolved: do that on 142.

FW: There was 87 too…

NS: Fixes for the operator dictionary.   I don't see any resolutions here,
we have to go through again.

FW: At least for browser vendors, they don't have this so it doesn't matter
to core I think.  On issue 6 we need some expert feedback about how things
should work in arabic.

NS: I thought David said we have to wait

FW: Then there were new accents that were added by david some time ago, I
think he said he wasn't sure if it was on purpose.

DC: I think that it was wrong.  I'll put a comment in the ticket, and check
the accents.

NS: I think the whole operator dictionary needs another pass.  It's a good
thing to focus on the accents.

SD: David weren't some of these listed as accents because of assumptions
about the position?

DC: We listed a bunch of pseudo primes but I think in the process we, or
me, or someone at the time added a lot of accent = true, which I think is
wrong.

FW: The suggestion is to use msubsup instead

NS: We have a number of semi-equivalent characters - do we want to be
saying anything about this? In the wild, the number of characters that get
used like this is huge.  In firefox, if you have an mover, what character
do you use to get an overbar? Is it “-” or “_” or some other horizontal
line-like character?

FW: Basically you use what the user has specified, which might look wrong.

NS: But a line over “x+y” needs to stretch, but neither “-” nor “_”
stretch. So what should be used if we don’t remap?

FW: If we look in the math table we just use this construction, we can
redirect the character to a stretchy one.

(somehow transitioned to combining characters and equivalents)

NS: I'm not really sure how the web does this, but Unicode says they should
always be canonicalized into composed or decomposed (software choice).

FW: The issue with combining is basically that they are combining - it
causes a bunch of issues.

NS: Returning to equivalents. Should we put into the spec something about
all of these characters should get mapped to these other characters
somehow. In the wild, these happen a lot.  My impression was that every
good implementation, if they want to account for the randomness of mathml
that comes out of editors, they will map these so that they will stretch or
be equivalent.  I guess, let's take this offline. I’ll create an issue.

PI: Returning to combining chars. The MathML 3 spec speaks of these as
being combined before you do much.

NS: The unicode spec says they are equivalent.  That's why I was thinking
browsers must do this at a pretty low level.

FW: I see what you mean. I guess for those that are equivalent that is
true.  I think Rob was mentioning there was a function that does something
like this?

RB: in JavaScript there is normalize, which you can use on a string, with
different normalize options.

NS: Does negative and minus wind up different? I believe it is less wide?
Let me look this up.

SD: I've seen this when in a pre-superscript

NS: I must be misremembering something.

DC: only spacing differs.