- From: Neil Soiffer <soiffer@alum.mit.edu>
- Date: Mon, 27 Jul 2020 15:36:35 -0700
- To: public-mathml4@w3.org
- Message-ID: <CAESRWkBiWXvwBH95yL8gyHmnpvyqiCAafRoeafPat3U93PM=6g@mail.gmail.com>
Many thanks to Brian Kardell for taking the majority of the notes.
Attendees:
-
David Carlisle
-
Neil Soiffer
-
Brian Kardell
-
Murray Sargent
-
Bruce Miller
-
Louis Maher
-
Rob Buis
Agenda:
https://github.com/mathml-refresh/mathml/issues/8#issuecomment-664116846
The meeting was recorded:
https://benetech.zoom.us/rec/share/x-lsNZrBzl9OWIXx01j8VZMkA9_naaa8g3Ad_fdby0c6BL2N0m2YVjKVV40jz323(Access
Password: gjYb?5wp) starts about 8:30 into the recording
Charter:
-
We created a very basic starting point (not even a 'first draft') of MathML
WG charter
<https://docs.google.com/document/d/1W-oYUbOMueaqb3KFSWkjWVBwR6AzSEBizHwQhvSwfDc/edit>,
please have a look, comment, contribute
There are 30 MathML Core issues with "needs resolution". Let's try to
resolve some of them:
- Use fence/separator operator properties in MathML Core? #209
<https://github.com/mathml-refresh/mathml/issues/209>
- NS: Saw no use, I can't see how this is controversial, can we go
ahead and remove refs?
-
DC: I can't remember why this is in there. If we can't remember it,
chances are nobody else will
-
NS: Should we pull it from core?
-
DC: Should we pull it from full as well?
-
NS: we should probably check the usage once again on that
-
MS: we need it as an attribute in office
-
NS: I think this is covered already via ‘form’ and ‘spacing’. I can't
remember why we put these in here
-
DC: I think we can drop this from core definitely. There are a lot of
references to them in full, so we need to look at full more carefully.
-
MS: We have our own operator dictionary, it does call it out as a
delimiter - may be redundant.
-
DC: It comes from TeX.. I think we should drop it in core and look at
it in full.
-
NS: There are virtually no references in the core spec now… Any
objection?
-
Resolved: Remove from core, look at full in more detail.
- automatic size adjustment: #225
<https://github.com/mathml-refresh/mathml/issues/225>
-
NS: The issue is how do you match the size of the math font to the
regular text font, because they can differ. Somebody brought up
this issue
because MathJAX has a feature for this, and CSS Text L4 that
allows you to
adjust all of the fonts to have the same height. Fred said it
sounds like
a good idea, Brian should check in with CSS folks. If CSS is
introducing a
property for this it would be great to take advantage of it.
-
From a comment: font-size-adjust
<https://www.w3.org/TR/css-fonts-4/#font-size-adjust-prop> CSS
property already defined in css-text-4
- U+002D HYPHEN-MINUS in mo operators: #146
<https://github.com/mathml-refresh/mathml/issues/146> => write a
polyfill?
-
Skipped, we need fred for this one
- Include mo@accent attribute into MathML Core? #210
<https://github.com/mathml-refresh/mathml/issues/210>
-
NS: We discussed this in the past, it got conflated with cramped.
Fred had objected that the notion of an operator is really about an
embellished operator, with CSS you would have to dig down arbitrarily. In
this case, even Patrick Ion couldn’t think of an example where
the operator
would be embellished, so I proposed to drop “embellished” - but there was
kind of an impasse at how to resolve this. I had checked and none of the
generators use the property, they all rely on the defaults built into the
operator dictionary. If you ever use an operator it is not an
accent. Not
looking at the operator would break all existing MathML that wanted to
display an accent. Anyone have updates? Comments?
-
MS: In office math, we certainly distinguish between the two. We have
explicit objects and the spacing is a little different between
them. If you
get rid of it, we can't roundtrip very effectively with MathML.
-
NS: I think we have to wait for Fred to have this discussion.
- Definition of invalid markup for radicals #212
<https://github.com/mathml-refresh/mathml/issues/212>
-
NS: msqrt allows 0..n children, but mroot allows exactly two. We had
some discussion about what to do a few months ago.
-
RB: I'm pretty sure we are matching what the spec says today, which
is to display mroot as an mrow when there aren’t 2 children.
-
NS: I'm not sure if we have an issue here now.
-
RB: I don't think there is an issue.
-
DC: I don’t really care what happens in an “error” case because I
come from an XML world where errors should crash and burn.
-
NS: It sounds like we can close this out saying we've pretty much
agreed how this should go.
-
Resolved to close the issue as per what the spec says now
- Add menclose to MathML core #216
<https://github.com/mathml-refresh/mathml/issues/216>
-
NS: It's not currently in core, it's difficult to polyfill the
diagonal lines.
-
MS: Without it you can't put a box around it
-
DC: With CSS you can
-
MS: it seems like such a trivial thing, why not have it there?
-
NS: There's a linked issue about simplification of menclose- it's
been a source of confusion. Fred moved the text of menclose into another
branch.
-
MS: I guess we can push it off to the future
-
NS: It could be in core level 2. I haven't checked if it is in webkit
and ff?
-
BK: Is it supported in webkit and ff?
-
RB: There are some fixmes in webkit but it looks like it has some
stuff, most stuff
-
NS (after meeting) -- checked Safari and Firefox. Firefox supports
everything. Safari supports everything except: radical, updagonalarrow,
phasorangle.
-
NS: How does this change things?
-
BK: Well, maybe it doesn't… I'm just wondering what the gap is, if it
is mostly interoperable or there is a quick reasonable subset we can
support easily, maybe there is a fairly strong argument that we could
support it… But the facts are not really changeable - i guess it's mostly
how big a lift it is and what needs to be done.
-
NS: The thing that is simple to do is not hard to polyfill either -
the things that are hard to code, I imagine are the same things that are
difficult to polyfill (diagonal lines used for cross outs).
-
No resolution
ScriptLevel:
-
BK: discussed with Elecka scriptlevel and its interaction with
font-size. She doesn’t think the current text in core is right. Maybe a
font-size: math along with a scriptlevel, where “math” means it is
calculated by the math renderer.
-
MS: can’t just change the font size, the superscripts start to look
skinny. So you need to increase the weight of the font a little bit.
Variable fonts would be useful for this. The open type table just gives the
% of the font height, not an amount to adjust the weight. Office switches
to a bolder font.
-
DC: TeX traditionally used a font that was pre-scaled (i.e, Computer
Modern). But it doesn’t do that in STIX or Cambria. I don’t think we can
specify that. It’s something that MS can claim is an improvement.
-
BK: we may expose them or not. Google would like them exposed, but they
can remain internal.
-
RB: it could be a lot of work to adjust, depending upon the solution.
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Received on Monday, 27 July 2020 22:37:01 UTC