- From: Neil Soiffer <soiffer@alum.mit.edu>
- Date: Wed, 17 Apr 2024 00:35:25 -0700
- To: "www-math@w3.org" <www-math@w3.org>
- Message-ID: <CAESRWkBiK2o5grwnjretnwL_8RXPE19cgUOX67JDFkgZmrbmXg@mail.gmail.com>
Attendees: - Neil Soiffer - Louis Maher - Bert Bos - Deyan Ginev - Bruce Miller - Paul Libbrecht - David Carlisle - Bert Bos - Murray Sargent - Moritz Schubotz - Patrick Ion <https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-13#cp-md-0-regrets> Regrets <https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-13#cp-md-0-action-items>Action Items *ACTION* MuS will add CGS (Centimeter, gram, second) units to the units list. Please indicate which CGS units are not already on the list. *ACTION* DC will reach out to Chinese TeX groups and ask them about units used in Asian languages. Do they see these symbols in publications? From Deyan Ginev to Everyone: Chinese units: https://en.wikipedia.org/wiki/Chinese_units_of_measurement *ACTION* DC will check Fred's changes in issue 103: percentage of minsize/maxsize <https://github.com/w3c/mathml-core/issues/103>. *ACTION* DC should reply that neither TeX nor Word support asymmetric stretching. DC will make a comment about this in this PR. *ACTION* MoS will add an issue of how does TeX use big or bigger and convert it to MathML. He should do this on the MathML list. How to represent brackets equivalent to \big( and friends )(issue 491) <https://github.com/w3c/mathml/issues/491> *action* DC will open an issue on stretchiness. *ACTION* NS will open an issue on larger parens and Matching requested fixed sizes. He will open this on the MathML core list. <https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-13#cp-md-0-agenda> Agenda <https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-13#cp-md-0-1-announcements-updates-progress-reports>1. Announcements/Updates/Progress reports NS: The Open Collective (https://opencollective.com/mathml-core-support) that is funding MathML work has some money. What would be the top priority for that funding? NS wants Firefox and Safari to support CSS. It is difficult to deal with cross-platform incompatibilities. DG: These funds can be used to fix bugs because there is little funding for fixing bugs. DC: Some of the delimiter bugs need attention. BM: I'm still waiting for the Canary Build to migrate its way to Linux. This makes cross-platform development almost impossible. DC is concerned with stretching delimiters. You see this in expressions with three or four nested brackets. NS: to BM: Have you reported the Safari and Chrome bugs? BM: I am not sure which of the bugs have been reported, and which ones have been distilled enough to be actually reportable. BM: There is another problem: Is the problem in the spec or implementation. BM: We need to clearly understand our expectations. One way to do this is to compare our results with MathJax. MathJax is mostly correct. MUS: I think pretty much that MathJax just mimics TeX. NS: If bugs do not get reported, they do not get fixed. NS: The funds could be used to encourage compatibility among browsers. DC: There are a couple of dozen math fonts, and they are widely inconsistent. BM: You can work around Safari bugs. From Deyan Ginev to Everyone: chromium bugs are here: ( https://issues.chromium.org/issues?q=customfield1222907:BlinkEMathML). MuS: This link works: (https://issues.chromium.org/issues?q=mathml). NS: Is the implementation or spec wrong? BM: His complex conjugates were not visible in Chrome. NS: MathPlayer accepted five or six different characters for the complex conjugate. NS: A complex conjugate character is an overbar. What character do you use for that? NS Do we have a favorite bug to fund? DC: Getting CSS support would be good. NS: It is easier for an implementer to fix a bug rather than implement a new thing. DG: I'm actually quite happy that minsize and MaxSize got addressed on all sides. So, I do not want to pick anything so that something else can get worked on. NS: We do not have a particular bug to fund. NS: People who donate money get more say on where the money is spent. DG: I have this preview platform for Archive called ARX5IV which is serving MathML core since 2022. I got a fresh number from Charles. We currently have over one million views a day viewing MathML on the website. NS: What is the feedback you've gotten about your version? DG: No one has complained about something being completely unusable. There are complaints about the LaTeX conversion side. DC: The LaTeX project has published well-tagged PDF files with MathML. It is now mostly automatic using MathML. ( https://github.com/latex3/tagging-project/discussions/72). <https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-13#cp-md-0-2-quick-review-of-action-items-from-last-week-we-had-a-lot->2. Quick review of action items from last week (we had a lot): - *ACTION* MuS will add CGS (Centimeter, gram, second) units to the units list. Please indicate which CGS units are not already on the list. Consider this item next week. - *ACTION* DC will reach out to Chinese TeX groups and ask them about units used in Asian languages. Do they see these symbols in publications? From Deyan Ginev to Everyone: Chinese units: https://en.wikipedia.org/wiki/Chinese_units_of_measurement Consider this item next week. - *ACTION* DC will check Fred's changes in issue 103: percentage of minsize/maxsize <https://github.com/w3c/mathml-core/issues/103>. Consider this item next week. - *ACTION* MuS can try the test cases out in word for issue 205: Vertical Alignment of delimiters <https://github.com/w3c/mathml-core/issues/205> What does Word do? MuS should play around with the sizes in word and see what the automatic scaling does for parentheses. MuS: Unicode math has a way of specifying The sizes of delimiters. Mus: Word doesn't support the auto correct file for the things like \big. It is not in the AutoCorrect file. Ronkok closed issue 205 as completed. DC: If we find another problem, we will open a new issue. - *ACTION* DC should reply that neither TeX nor Word support asymmetric stretching. DC will make a comment about this in this PR. Consider this next week. - *ACTION* MoS will add an issue of how TeX uses big or bigger and convert it to MathML. He should do this on the MathML list. How to represent brackets equivalent to \big( and friends )(issue 491) <https://github.com/w3c/mathml/issues/491> NS: We were just saying that word does not have the equivalent to \big. MuS: Basically, the Unicode math input is identical to TeX. It is just \big or capital BIG, etc.,. They are defined for Unicode math. They do not work when I type them into the AutoComplete file. NS: What do they end up doing? Do they use an em or some other equivalent Font relative size to produce those? MuS: I will check this. I know that you can overrule any of the sizing by putting a backslash in front of a delimiter, then it will just be treated like an ordinary character. NS: Is the big relative to the parent size, or relative to the inclosing Mrow? DC: The real discussion is how do you make it larger? Do you use a larger font, or do you stretch the character? NS: I would think you force a larger character, otherwise you end up with thicker lines. MoS: It is OK the way it is. MoS The vertical line does not stretch. DC: People usually put big to make the bracket bigger, in which case you only need min size, and it'll just grow to that size. DC: So, using a minsize and maxsize is ok. MoS: The next thing would be that it does not work. NS: Do you mean that the vertical line does not stretch? MoS: Yes. BM: Firefox gets confused by strange extraneous forms. BM: I have not worked out a comprehensive series of tests; however, that is my suspicion. DC: Chrome does not usually get the math access correct. They are flush at the bottom, but not at the top. They have lost their symmetric nature. DC: We are trying to see if it is the browser's fault. Mos: If you want to use vertical or horizontal stretching, it is not clear which characters you can use. MoS: There must be some magic that explains how you can get stretching for every character. Ns: I suggested we add a list of "magic" chars that stretch (e.g., for overbars or underbars, do you use "_" or "¯" (U_00AF), or something else. Does one work for mover and the other for munder? Fred and I disagreed on putting it in the spec. I said that we should know which characters can stretch. Fred said that it all depends on the font. NS: I just felt it should be in the non-normative section, that of a spec that says, these are the characters that stretch. NS: Maybe we should add this to MathML 4. DG: Can there be a stretchy key that can stretch all parameters? NS: Why can't you say which parameter is stretchy? DG: So, isn't this a missed opportunity from a Unicode standpoint? Couldn't there be a stretchy key, and have it standardized for the entire Unicode, indicating which ones are stretchy and meant to be supported by fonts? NS: Is there anything in Unicode which talks about stretchiness, and is that a property of characters? MuS: My technical note Unicode tr 28 talks about that a little bit. I agree that it should be in UTR 25, though we must add that if it's not there. From Microsoft Copilot: UTR 25: Unicode Support for Mathematics. This report discusses the Unicode mathematics character repertoire and provides information on the default math properties for Unicode characters. ( https://www.unicode.org/reports/tr25/tr25-6.html) ( http://www.unicode.org/reports/tr25/tr25-15.pdf) There is a document referred to as UTR #28, but it’s important to note that it is not a current document. UTR #28 pertains to Unicode 3.2, which is a previous version of the Unicode Standard. It was a Unicode Standard Annex that defined Version 3.2 of the Unicode Standard and has since been superseded by later versions ( https://www.unicode.org/reports/tr28/tr28-3.html). For the most up-to-date information and technical reports, you can visit the Unicode Consortium’s official website (https://www.unicode.org/reports/ ). DG: Can core lean on Unicode and say, if Unicode says it's stretchy, it should be stretchy, but not all the stretch ones are correct? DC: It has math class. DC: Unicode has information about this, but fonts don't always follow it. DC: In Unicode there is a list of ones that should stretch. We could point to this list and say that users depend upon these list of characters to be stretchable. NS: In MathML 4, should we have an appendix saying which are the stretchy characters? (It's in the math operator dictionary). DC: Should Unicode and MathML agree on stretchiness? Someone should check this. (http://www.unicode.org/reports/tr25/tr25-15.pdf MuS: Word does not stretch the underscore. DG: I just wanted to make a note about what is stretchy. The current support for web browsers should have a discussion on the stretchy attribute. That page could be extended with a couple of math fonts and examples. *action* DC will open an issue on stretchiness. NS does not know what character to use for stretching, and Fred tells him that it depends upon the font. - *ACTION* NS will open an issue on larger parens and Matching requested fixed sizes. He will open this on the MathML core list. Consider this next week. - *ACTION* DG should add this comment to issue 142 Should all MathML elements really be potential hyperlinks / match :visited? <https://github.com/w3c/mathml-core/issues/142> DG proposed to degrade less than sign mrow href greater than sign to less than sign a href greater than sign, which would then be the only official carrier of href in MathML. This would allow existing documents to be translated. DG put in the comment and started a discussion. <https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-13#cp-md-0-3-units->3. Units: <https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.0-13#cp-md-0-potentially-a-full-list-of-units-with-all-their-prefixes-as-intent-concept-names>Potentially a full list of units with all their prefixes as intent concept names NS to DG did you come up with the full list of units? DG: I have the main ones but not the exotic ones. DG has an unpublish spreadsheet that he is working on.
Received on Wednesday, 17 April 2024 07:35:35 UTC