RE: [EXTERNAL] Minutes: MathML Core Meeting 22, June 2020

Note that ‘ssty’ is also used to get glyph variants for script and script-script sub/superscript levels. Heavier characters are used so that when they are scaled down to 70% or 60% of base height, they still have similar stem widths. This greatly enhances the typographic quality of math text containing superscripts and subscripts. I highly recommend that Chromium support this use of ssty. The code isn’t complicated.
Here’s an example of nested superscripts that uses this feature

[cid:image003.png@01D648B0.3CDCDE00]

This is also an example of where variable fonts could be useful in the future.

Thanks,
Murray

From: Neil Soiffer<mailto:soiffer@alum.mit.edu>
Sent: Monday, June 22, 2020 1:01 PM
To: public-mathml4@w3.org<mailto:public-mathml4@w3.org>
Subject: [EXTERNAL] Minutes: MathML Core Meeting 22, June 2020


Big thanks to Brian Kardel for copious minutes!


Attendees:

  *   David Carlisle
  *   Neil Soiffer
  *   Brian Kardell
  *   Murray Sargent
  *   Rob Buis
  *   Bruce Miller
  *   Louis Maher
  *   Patrick Ion
  *   Frédéric Wang


Agenda: https://github.com/mathml-refresh/mathml/issues/8#issuecomment-644531714<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmathml-refresh%2Fmathml%2Fissues%2F8%23issuecomment-644531714&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861198687&sdata=QmRjk%2FxwcmbHVVcSolPzoew4MZgLyjN0ZORVS4ZBQ38%3D&reserved=0>


The meeting was recorded: https://benetech.zoom.us/rec/share/9Z0vMY_g-FhLXc_QuUXDe5EAJJXuaaa8gHQfrPUPyUytdQadzc1YBw4BFIhA_CJs<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbenetech.zoom.us%2Frec%2Fshare%2F9Z0vMY_g-FhLXc_QuUXDe5EAJJXuaaa8gHQfrPUPyUytdQadzc1YBw4BFIhA_CJs&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861198687&sdata=MLMZoz0YFvQSeeDWenMjBdCnukuqozkeCs6cZql6YXI%3D&reserved=0> (Access Password: 8K+0u#5+)

More OpenType things:

  *   The "math" script tag #223<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmathml-refresh%2Fmathml%2Fissues%2F223&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861208683&sdata=JmMMJZdi%2F7NBuBT2LVbJhhfGuiS4e6dsUJfkvvtd98s%3D&reserved=0> [about <mtext>]
This seemed only needed for rtlm and ssty => move to level-2?

     *   FW: any element that uses mtext layout - basically all token elements except mspace.  Based on our changes last week I was updating the spec text and now that we removed rtlm/ssty I don't think this is necessary anymore.
     *   NS: The spec says mtext
     *   FW: But it is supposed to be for all token elements really, but we want to remove that.
     *   MS: I call them “cutins”; placement of superscripts relative to bases?  In other words, it's a kerning concept…
     *   FW: If you check the math table spec,  you have this tag at the end… https://docs.microsoft.com/en-us/typography/opentype/spec/math#opentype-layout-tags-used-with-the-math-table<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftypography%2Fopentype%2Fspec%2Fmath%23opentype-layout-tags-used-with-the-math-table&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861208683&sdata=k87T3y8emVSzGS%2BST8Gu9IlJs39zqjXY2BWlf7zOxdU%3D&reserved=0>
     *   NS: (reads relevant spec text about the script tag)
     *   MS: I will look to see how this is used in our code
     *   NS: If this got pushed to level 2, what difference does this make?
     *   FW: As I say, I'm not really sure - but as I understand there is this script tag, so in the case of this it is like a specific language for math that allows ssty and all of this.. I think if we drop ssty there is no use
     *   MS: if you are not doing right to left math it seems it doesn't matter.  Ssty is the wrong way to do that really, should do that all of that upfront before you get to the layout engine
     *   FW: So my question is just making sure that this is really only about ssty etc - because if so, we should remove it.
     *   MS: It is only in our code for right to left math
     *   NS: We pushed right to left off to level 2
     *   MS: Although, I really want to get all of that working everywhere
     *   FW: We all do, but keeping this bit of text that does nothing in core level one seems confusing, we should remove it if that is the case
     *   MS: I think it is very reasonable to push that one out
     *   NS: Resolved...




  *   Define fallback for OpenType MATH parameters
https://mathml-refresh.github.io/mathml-core/#layout-constants-mathconstants
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmathml-refresh.github.io%2Fmathml-core%2F%23layout-constants-mathconstants&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861208683&sdata=uI%2FMNow9DzxxXSMwRQXgNE23kTmW3kXVcoAsGbLOcCQ%3D&reserved=0>It does not seem something fundamental and hard to test and it's not clear whether complex fallback is acceptable.
Keep the current text and remove the ISSUE label?

     *   FW: I have just added some fallbacks, I don't know that they are all great, but I don’t know what you want to do here.
     *   NS/MS: We are good with pushing this off to level 2.  Any objections/other thoughts?
     *   NS: Resolved




  *   MathKernInfo / MathTopAccentAttachment
Put at risk and remove ISSUE label?
https://mathml-refresh.github.io/mathml-core/#glyph-information-mathglyphinfo<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmathml-refresh.github.io%2Fmathml-core%2F%23glyph-information-mathglyphinfo&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861218676&sdata=667occspSmiTLLtjVEFsfmffbZMXzjA7yms0l0DREmY%3D&reserved=0>

     *   FW: This is, I think an extension - it is kerning/subkerning. MS can speak better
     *   NS: I think integrals
     *   FW: No for those we use italic correction
     *   MS: It's important for good typography.  I call these cutins, it allows you to kern in a super/subscript into the base in a way that looks good.  Say you had a capital V and you put a subscript 2, the bottom of the V is narrow, so you want to pull the 2 in a little bit.
     *   FW: You said italic correction is not specific to the glyph, but in core it is
     *   MS: It doesn't depend on pairs of glyphs
     *   FW: It is more generic
     *   NS: Let's break this discussion apart:  MathKernInfo and MathTopAccentAttachment.  If I type sin, I assume that is when kerning would be used to make it look good
     *   FW: I think this is different - I think this is about having a base and attaching glyphs.  It's horizontal positioning of the scripts, but it is depending on the vertical position.  You have a table that gives a mapping of how much to apply
     *   MS: Each character has 4 corners, tlbr - you have a certain amount you can move in on all corners. In TeX what you have to do is different, I think this came up and we made it automatic based on discussions with Knuth - he would have done it if he could but because it can't break, he never went back to do it.
     *   NS: Seems like a problem. Suppose level 2 supports it - it's not like "here are some new features we can use". It is like "the rendering just changed" and nothing changed in my document.  It's sort of like CSS adding some features and it just starts rendering differently.  Is this a problem?
     *   DC: Even happens in TeX. Fonts change and the rendering changes… you can't say it is pixel identical in 50 years.
     *   FW: I was wondering if you know if STIX has this table, last I checked latin modern math didn't and maybe only cambria has it.
     *   BK: Would WPT tests break?
     *   FW: No
     *   BK: Then I think it is probably ok, because the font analogy seems pretty good to me
     *   FW: So, if we want to support this feature we will have to write some tests with some fonts that actually support this.  This is why I say it is kind of difficult to support, supporting the tests itself is involved.
     *   NS: I thought though that a goal of core was for rendering to be the same
     *   FW: Well, they will be the same on this in FF/Safari and we will get there - just can't achieve it all at once.
     *   MS: I think this is ok, if you shoot for the moon it's easy to miss
     *   NS: DC’s argument makes some sense, although it still seems problematic. However, I agree - we can move this out.  Let's go to MathTopAccentAttachment
     *   FW: Ok this is about how you position the glyph horizontally, and we had a number of  other issues with accents, I don't think we can fix them all in L1.  I think for at least large operators or mrow layout we use italic correction, but for scripts in general we don't (except for integral).  So I guess the question is that the spec is ahead of implementation in a way that we probably can't get it all, so we need to decide how much we want to leave in that won't be achieved the same.
     *   NS: So what is the proposal for the spec
     *   FW: I don't really have one - I am just pointing out that there are some things in the spec that are not in our plan and we probably can't get done at once.  I'm wondering what we want to do with that.  We don't have tests for it, there's a lot to do there.
     *   NS: It sounds like there are a number of changes to the spec that are necessary if we punt on this?
     *   FW: Yes, but it is removing text which is far easier than making tests and choices and implementations and so on…
     *   NS: What do other people think?
     *   MS: I have to agree that some of these are really hard to do well, I can appreciate that.  <shows examples>
     *    [https://lh3.googleusercontent.com/oyimR94xTXDa8xpxCncC2IIdoXVjASXeDFUIF80DXo3ssqbfReYUZRdFxRiUkBNUCo39tEYeJhm5zTtcEV2iBl7AkBxYDjYPJwFJuWG39868wz0t26fiFcNVyc6FEeLlvkFcLhZb]
     *   Example of cut-ins (math kerning)[https://lh6.googleusercontent.com/XQW-z8njLrKvL_2HEEsVLANZx_A1L9Qqm3EbrJnvNaTHaQIh_ejInPmmAp2YRybznKDSjaFNA96sRtyYtI8XeBX3OchxOd23Xx0Z0Bsd_v4mPAnqr5nc9yCEBYUFHO6meNlN2VBv]
     *   MS:: So, you can see that accents, for example, are tricky.
     *   FW: Firefox doesn’t do a good job now.
     *   NS: Does TeX use different characters for a hat depending on the character beneath it?
     *   DC: Not counting \widehat, LuaTex can do this, but not by default.
     *   FW: I guess we can keep the spec text for now and see if it is an issue and come back and decide.  We want to do italic correction for scripts, that is really similar.
     *   NS: My proposal is that if you can't do the really fancy stuff, at least do italic correction. The placement over an “f” will look terrible otherwise.
     *   FW: I don’t know if this is going to get perfect things, I was suggesting that the logic is very similar maybe we can do a little more to get it done -- as I say, we would still need to do more work and more tests and so on, so I can't promise, but we can try and we can come back to it.
     *   NS: Resolved we can wait and look at where implementations are in a bit and come back to this one, but not push to L2 yet - mark it as at-risk



  *   Variable fonts
Does not seem something under our control, but something to standardize at OpenType first and to be used by math font creator first. #135<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmathml-refresh%2Fmathml%2Fissues%2F135&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861218676&sdata=vDfjjF6rqulHMyYWg4cO1G5SsM6wHBkBlIUpYaP0b58%3D&reserved=0> Remove label?

     *   NS: I dont think there are any out there that I know of for Math fonts - are there?
     *   FW: they are gaining popularity and they are good because you have abilities for things like stretchy operators - you have just one glyph and you can in theory give parameters.  But what in math you want to do is give a target size, which is kind of the opposite of variable fonts.  I'm not sure what we do with that.
     *   NS: I think this is easy because there isn't much you can do right now anyway.
     *   MS: I think it is a very cool tech and it is something that will get into math font tech at some point - we've been talking about it… But as a practical matter, nothing has happened yet and your comments are valid, and there are other things too. So, an exciting thing for the future, but not relevant in the present.
     *   NS: Ok resolved not L1




Follow-ons from last week's meeting

  *   href (#125<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmathml-refresh%2Fmathml%2Fissues%2F125&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861228670&sdata=f7uiIBBCRpJCILJ%2F2VrUgwBr9laEudjnkAWNlkqbf7c%3D&reserved=0>) [TAG feedback?]
  *   BK: NS and I both left comments, I had some discussion as well, but it is waiting for their next breakout -- it is tagged for this week, but they have a long list, so we'll see.


  *   Character substitution ('-', primes, etc) #146<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmathml-refresh%2Fmathml%2Fissues%2F146&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861228670&sdata=x5f4G2kZwfYs3bKQo%2BjH7NgdAN7Z2GbaWHPpaUezRTE%3D&reserved=0>

Skipping for now

3.1 Visual formatting model

  *   Issue #18<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmathml-refresh%2Fmathml%2Fissues%2F18&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861238664&sdata=tNAERp1wWLRav5vkCSRR0RQWDyZENjtuDtA7tkM1Plo%3D&reserved=0>  Should a future version of this specification support vertical writing mode?
  *   FW: I think we previously agreed that we won’t do this.
  *   NS: We didn’t find much use for it.
  *   FW: Could be that there isn’t software to do it.
  *   NS: Resolved: put this off to level 2


  *   Issue #112<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmathml-refresh%2Fmathml%2Fissues%2F112&data=02%7C01%7Cmurrays%40exchange.microsoft.com%7Ceec9c2e242a84171444908d816e70a70%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637284528861238664&sdata=byBrDH7y3GtwBQylOXG%2BYrkdXkxpcHm3iH0s4JqonRM%3D&reserved=0> Should future a version of this specification support line breaking?

FW: I think we had agreed to postpone this already

NS: Right, but I had a request - I want to generate a polyfill, and I have currently no way to do that… Is there a way that I can keep it mathml and not just turn it into a table or something?

FW: Inline or display linebreaking

NS: display, I am thinking.  From what I have thought about so far, if core supported one value on the mo which would be linebreak=”newline”. Basically support a forced break and start a new line.

FW: I think mathml 3 had a way…

NS: Right, so if that got supported I could polyfill a forced linebreak/indent

FW: I'm not sure what the advantage…

NS: well, it's far less destructive to the code than to turn it into something completely different.

FW: This means you need tests for both things, it adds a lot.  If you have 2 lines,  you have to decide which baseline you align with on the next line

NS: I would say it aligns to the first baseline

FW: Right, but you remember during this whole year we have been having discussions that seem simple but the more you dig into them they get very complicated - I am not really confident that this is not a really long chain of discussions and questions.  I think the way google would like to handle this with Houdini…

NS: My thinking was the more we polyfill, the more we are showing and figuring out what it is we need to do.

BM: A forced line break is a first step component to automatic linebreaking. I've done a lot of experiments here myself, but like you say you don't have the right tools to experiment without really destroying the tree.

NS: It’s been a complaint for years about Firefox’s rendering.

FW: There are a lot of complications with interactions with CSS. It is too much to think about now.


Meeting next week.