Minutes: MathML Core meeting, Sept 21, 2020

Attendees:

   -

   Neil Soiffer
   -

   Brian Kardell
   -

   Louis Maher


   -

   David Carlisle


   -

   Rob Buis
   -

   Murray Sargent
   -

   Adam Frank
   -

   Charles LaPierre
   -

Regrets:

   -

   Bruce Miller




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

The meeting was recorded:
https://benetech.zoom.us/rec/share/LOuUN9Ic7jHa-MLI-WvRvjITuJQ6tRGLj5OSaNc39cCxiGsGG0iSb-iR2SyUbC9j.QJ2EjKvRMqQvYL_b
Passcode: 8mQ6.CQ5 Meeting starts at about 7:30


TPAC Breakout

Any date restrictions the week of Oct 26? <none>

Note: it will likely be at 2pm UTC
CSS/standards updates

BK: We've added a specref for MathML-Core
https://www.specref.org/?q=mathml-core - this is the system by which specs
refer to one another, basically

BK: We had a second math meeting with CSS group. Probably last one unless
more are needed. We made it through a bunch of things (
https://github.com/w3c/csswg-drafts/issues/5384).

BK: CSSOM was updated this morning with display style (normal/cramped).

BK: Updated how scriptlevel is handled and related to fontsize.

MS: Math docs defaults are not handled by CSS.

NS: Document metadata is typically used for this.

BK: That can be done, but not appropriate for presentational defaults. CSS
has environment variables, but those are read-only.  I looked at your list
https://docs.microsoft.com/en-us/archive/blogs/murrays/mathml-to-do-list

NS: UA stylesheet sets fonts, so defaults for them can be set that way.

NS: You can override the UA stylesheet with your own ‘math’ rule.

MS: Other things aren’t in CSS. E.g, differential d example -- what char
should be drawn for it.

MS: How you break at an operator -- it is different in different parts of
the world. In Russia, the operator is duplicated.

MS: Other meeting is looking at adding a lot of values.

DC: Other people use Javascript. Also, we haven’t done linebreaking in core
in level 1

BK: Agree about linebreaking not being ready to talk about.

DC: Neil has a linebreaking polyfill. That’s JS, so lots of scope for
playing with defaults there.

BK: It would be useful to go through Murray’s table and look at what things
are closer to where we are at and which should be looked at for CSS. If you
aren’t using CSS, then there needs to be a way to get at defaults.

MS: I would like to make it simpler than writing JS.
Resolving more issues:Applying visual effects #179
<https://github.com/mathml-refresh/mathml/issues/179>

Action Item from last week: RB: I’ll ping google to see if there is some
scenario that needs to be tested.

RB: I landed some tests last week. Pinged google about the potential need
for more tests.

automatic size adjustment: #225
<https://github.com/mathml-refresh/mathml/issues/225>

Action Item from last week: BK to talk with CSS folks.

BK: Fred also opened https://github.com/w3c/csswg-drafts/issues/5534 - we
seem to have several issues regarding fonts-sizing - I need to get my head
around them all.

RB: Chrome has font-size-adjust
https://developer.mozilla.org/en-US/docs/Web/CSS/text-size-adjust

U+002D HYPHEN-MINUS in mo operators: #146
<https://github.com/mathml-refresh/mathml/issues/146> => write a polyfill?

Action Item from last week: BK to reach out to the google folks to see what
they think in terms of how one would implement this.

BK: I talked to Ian Kilpatrick that a text-transform like the others is a
good way to solve this. Not clear if Elika will support this.

RB: I made a patch that adds a new text-transform. Fred hasn’t looked at it
yet.

RB: My patch
https://chromium-review.googlesource.com/c/chromium/src/+/2410479

BK: The issue is whether we expose it to authors.

NS: this is part of almost all TeX to MathML converters including Fred’s
Texzilla.

BK: text-transform is being used for mathvariant.

NS: only math-auto was approved by CSS

BK: other values are being used internally and browsers can do it the way
they want

NS: the same could be done for hyphen-minus.

BK: I know one part of Fred's hesitance was that last year in Toronto we
got kind of nowhere at all and the text-transform issue was especially
snarly and derailing things - I believe he was primarily concerned about
expanding that so immediately after we said this is all the things.  But, I
think we are in a pretty different spot now - we have lots of resolutions
and the ones we don't have aren't actively holding us back - rob has a path
to discuss that could work, Ian seems to think it makes sense -- let's just
give this one some time for now.
Include mo@accent attribute into MathML Core? #210
<https://github.com/mathml-refresh/mathml/issues/210>

NS: accents still not in chrome but in Igalia branch.

NS: How is this done in the internal branch?

BK: Latest status:
https://mathml.igalia.com/news/2020/09/07/upstreaming-status-Q3/#new
(follow news at https://mathml.igalia.com/news/ )

NS: Issue is that  mover in MathML 3 gets the accent property from the <mo>
or from mover/munder’s accent/accentunder attr. Fred feels that this is
redundant and getting the accent from the <mo> should be dropped,
particularly since it could be an embellished <mo> and CSS can’t deal with
that. At an early meeting, everyone agreed embellished <mo> in an accent
would be almost non-existent so spec should be changed to drop the word
“embellished” in that case and that problem no longer exists. It is
extremely common for generators to rely on the operator dictionary, so
following the guideline that core should not break very common MathML
usage, this seems like core needs to handle this.

NS: Rob, could you check to see what the Igalia branch does?

NS: Anyone want to argue Fred’s points?

<no one>

NS: I guess we need to wait for Fred to join a call.

NS: There is another issue about what characters you use at an accent.  As
an author of a mathml document it is inappropriate to put a combining
character without a character in front of it

MS: It doesn't look great - you can imagine that it would follow a greater
than, they might get combined in your text editor

NS: In terms of HTML it won't though

DC: There is one that combines, idk what it is.  There were W3C politics
here.

NS: If you were to put a hat over something for an accent, I have no idea
what you would use for that for example. Fred's point on that was it's a
font issue, not a MathML issue… But somewhere in MathML we should tell you
what you should use, because I am supposedly an expert and I don't know.  I
don't believe there is something that we've written that says this.

DC: As far as possible I would try to use ASCII - shift+6 and hope it
works.  In many ways the combining mark ones are the easiest ones to use
but were politically difficult at the time.

NS: I think we have two issues here and I'm not sure how to do anything
with them without Fred on the call. I suppose we could make a resolution
and Fred could object or whatever.

MS: here’s a table of spacing accents and the corresponding combining marks
(used in OfficeMath)

static const struct {WCHAR spacing; WCHAR comb_over; WCHAR comb_under;}

SpacingToCombiningTable[] = {

    {0x2D8, 0x306, 0x32E}, // BREVE (TeX breve)

    {0xB8,  0x312, 0x327}, // CEDILLA

    {0x60,  0x300, 0x316}, // GRAVE ACCENT (TeX grave)

    {0x2D,  0x305, 0x332}, // HYPHEN-MINUS/OVERLINE (TeX bar)

    {0x2212,0x305, 0x332}, // MINUS SIGN/OVERLINE (TeX bar)

    {0x2E,  0x307, 0x323}, // FULL STOP/DOT ABOVE (TeX dot)

    {0x2D9, 0x307, 0x323}, // DOT ABOVE (TeX dot)

    {0x2DD, 0x30B, 0x2DD}, // DOUBLE ACUTE ACCENT (no "below" form)

    {0xB4,  0x301, 0x317}, // ACUTE ACCENT (TeX acute)

    {0x7E,  0x303, 0x330}, // TILDE (TeX tilde)

    {0x2DC, 0x303, 0x330}, // SMALL TILDE (TeX tilde)

    {0xA8,  0x308, 0x324}, // DIAERESIS (TeX ddot)

    {0x2C7, 0x30C, 0x32C}, // CARON (TeX check)

    {0x5E,  0x302, 0x32D}, // CIRCUMFLEX ACCENT (TEX hat)

    {0xAF,  0x305, 0},     // MACRON

    {0x5F,  0,     0x332}, // LOW LINE

    {0x2192, 0x20D7, 0x20EF}, // RIGHTWARDS ARROW (TeX vec)

    {0x27F6, 0x20D7, 0x20EF}, // LONG RIGHTWARDS ARROW (TeX vec)

// TODO(MikhailB) investigate if we need to translate the following
characters

    //0x2190 LEFTWARDS ARROW

    //0x2194 LEFT RIGHT ARROW

    //0x294E LEFT BARB UP RIGHT BARB UP HARPOON

    //0x21BC LEFTWARDS HARPOON WITH BARB UPWARDS

    //0x21C0 RIGHTWARDS HARPOON WITH BARB UPWARDS

    //0x23DE TOP CURLY BRACKET

    //0x23B4 TOP SQUARE BRACKET

    //0x23DC TOP PARENTHESIS

    //0x20DB COMBINING THREE DOTS ABOVE

    //0x23DF BOTTOM CURLY BRACKET

    //0x23B5 BOTTOM SQUARE BRACKET

    //0x23DD BOTTOM PARENTHESIS

};

MS: Example of MathML accents written in OfficeMath apps


<?xml version="1.0" standalone="no"?>

<mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML" display="block">

    <mml:mover accent="true">

        <mml:mi>a</mml:mi>

        <mml:mo>^</mml:mo>

    </mml:mover>

    <mml:mo>+</mml:mo>

    <mml:mover accent="true">

        <mml:mrow>

            <mml:mi>a</mml:mi>

            <mml:mo>+</mml:mo>

            <mml:mi>b</mml:mi>

        </mml:mrow>

        <mml:mo>^</mml:mo>

    </mml:mover>

</mml:math>

Also works in MathML 3 browsers as:

<math display="block">

   <mover>

       <mi>a</mi>

       <mo>^</mo>

    </mover>

    <mo>+</mo>

    <mover>

       <mrow>

            <mi>a</mi>

            <mo>+</mo>

            <mi>b</mi>

        </mrow>

        <mo>^</mo>

  </mover>

</math>

Received on Tuesday, 22 September 2020 18:12:26 UTC