The
*Planet MathML* aggregates posts from various blogs that
concern MathML. Although it is hosted by W3C, the content of the
individual entries represent only the opinion of their respective
authors and **does not reflect the position of
W3C.**

- Re: [MathML4] Deprecation/Removal of the mfenced element • July 26, 2016
- Re: [MathML4] Deprecation/Removal of the mfenced element • July 26, 2016
- [MathML4] Removal of the menclose notation "radical" • July 26, 2016
- Re: [MathML4] Deprecation/Removal of the mfenced element • July 26, 2016
- Re: [MathML4] Deprecation/Removal of the mfenced element • July 26, 2016
- Re: [MathML4] Deprecation/Removal of the mfenced element • July 25, 2016
- RE: [MathML4] Deprecation/Removal of the mfenced element • July 25, 2016
- [MathML4] Deprecation/Removal of the mfenced element • July 25, 2016
- Re: Recent MathML Improvements in WebKit • July 21, 2016
- Recent MathML Improvements in WebKit • July 21, 2016
- Recent MathML Improvements in WebKit • July 21, 2016
- Recent MathML Improvements in WebKit • July 20, 2016
- RE: [DPUB][A11Y] Agenda 07082016 • July 08, 2016
- [DPUB][A11Y] Agenda 07082016 • July 07, 2016
- Speaking of math… • June 30, 2016
- RealObjects released PDFreactor version 8.1, an XML-to-PDF f… • June 27, 2016
- American Physical Society continues as MathJax Supporter • June 27, 2016
- Pearson becomes a MathJax Supporter • June 23, 2016
- Re: Houdini and MathML in Blink • June 22, 2016
- Re: Houdini and MathML in Blink • June 22, 2016
**[List of feeds]**

On 26/07/2016 08:09, Frédéric WANG wrote: > Certainly, one can write <mo>+<mrow> without proper grouping as that's > unfortunately often the case for markup generated from text > representation like TeX or ASCII. But the existence of an mfenced > element in MathML does not magically force converters or people to do > this grouping. Yes I agree with Frédéric here that as long as you put all the mrow back in, there is no loss of information in expanding out mfenced. Speaking personally, for this and for the msqrt suggestion (and I suspect others to follow:-) I don't really have a problem if as a browser rendering environment we end up specifying some more minimalist profile of MathML that provides all the rendering functionality needed with less duplication in the markup possibilities. People who are generating mathml and want the markup to closely follow the underlying dom and rendering trees (perhaps to ease interactive behaviour such as selecting subterms) would want to stick to that profile. People wanting to generate (or render existing) MathML 2 and 3 style markup could be provided with a very lightweight javascript that expands out mfenced and does whatever else is needed. This means that mfenced<->mrow/mo equivalence is moved out of the core rendering engines into user javascript space which, if it helps get mathml into the core rendering engines, isn't too high a price to pay, I think. Such a javascript would be at the same level as the original asciimathml javascript for example, something that takes a specified user input syntax and modifies the DOM to the mathml elements supported on the platform. (The same can of course be done with content mathml) which means that these aspects are not browser specific and the same transformation code can be used across browsers, and just used at the option of the page author if they reference the appropriate code. David ________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Microsoft Office 365. ________________________________

Indeed, but the appropriately grouped structure could be represented with mrow, as well as mfenced. Likewise, the inappropriately grouped structure can be represented with mfenced. bruce ________________________________________ From: Stephen Watt <smwatt@gmail.com> Sent: Monday, July 25, 2016 6:00:04 PM To: Frédéric WANG Cc: www-math@w3.org Subject: Re: [MathML4] Deprecation/Removal of the mfenced element I see your point, but have to say that I am not really satisfied with the current spec language regarding equivalence. Mfenced can also give information about grouping that is lost with the mrow formulation, e.g. an mrow containining [a, b [ f ] d, e] may be a list of three things or a pair of half open intervals with an f in the middle. Stephen On Mon, Jul 25, 2016 at 12:01 PM, Frédéric WANG <fred.wang@free.fr<mailto:fred.wang@free.fr>> wrote: Hi everybody, Le 21/07/2016 à 08:52, David Carlisle a écrit : > While it's true that the math WG is currently "on hold" as there were no > planned date to do a MathML4 to give implementations time to catch up > with MathML3, this mailing list is still active and specific suggestions > can be posted here. Assuming that David's response implies that the old Math WG is indeed inclined to collaborate with Web engines developers and to take into account feedback for a future MathML 4, we are going to start proposing improvements on this mailing list. One of the most serious design issue in the MathML specification is the existence of the mfenced element. It is described as a "convenient form in which to express common constructs involving fences" but is strictly equivalent to an expanded form using mrow and mo elements [1]. So while it may be helpful to the rare people writing MathML by hand it is a redundant and poorly designed feature that has been the source of troubles for implementers: 1) Implementers must ensure that all the cases listed on the MathML specification are correctly handled to ensure perfect equivalence. This has always been a source of complexity, errors, and code duplication. We wrote a short list of tests covering the basic cases described in the specification [2] and neither Gecko nor WebKit correctly handle all these cases. And this list does not even take into account all the features of operators (stretchiness, spacing etc). We found similar inconsistencies/bugs in the past in WebKit accessibility code and/or assistive technologies. 2) In the case of Web engines, you have to maintain the equivalence when open/close/separators attributes or the list of children change. And indeed, there are known bugs in WebKit related to dynamic modification of mfenced. 3) In the case of WebKit, mfenced is implemented by creating anonymous nodes for each operator and trying to keep them in sync with the DOM. In the past, this kind of implementation has led to rendering, performance and design/security issues. During phase 1 of our refactoring [3], mfenced has caused many troubles and still has not been rewritten so far. We could follow Gecko's implementation to get rid of these anonymous nodes, at the price of more code duplication. 4) Phase 3 of our refactoring [3] now tries to move all parsing of MathML attributes from renderer classes to DOM classes in order to follow standard practice in WebKit's code base and improve synchronization between the renderer and DOM classes. mfenced is causing troubles because of its entanglement with the implementation of operators. Again, it seems that addressing the design issue targeted by phase 3 will lead to more code duplication if mfenced is kept. 5) The mfenced element is designed in a way that the text of fences and separators is included in DOM attributes instead of DOM elements as it is generally the case for text content. This means that by default (i.e. unless some specific code is added to handle mfenced) it may not be possible to search, select or copy that text using browser user interfaces or to read the text using assistive technologies. In order to simplify the code and make maintenance easier, we are going to propose on WebKit & Mozilla mailing lists to remove support for the mfenced element, maybe first to deprecate it. We also definitely do not want to include support for the mfenced element in the MathML implementation we have been working on for Blink. The only other argument we heard in favor of the mfenced element was that it gives "better semantic" to express fenced expressions with opening/closing fences and separators. However, this is a misunderstanding of the MathML specification: the semantic equivalence is provided via the (perhaps implicit) fence & separator attributes on the mo elements and via their relative positions inside the mrow container. Also, note that "authors cannot be guaranteed that MathML preprocessors won't replace occurrences of mfenced with equivalent expanded forms". This means that even if equivalence may not be true for e.g. CSS style or DOM manipulation it is anyway wrong to use CSS selectors or Javascript code that make assumption on whether mfenced or its expanded form is used. Last but not least, the mfenced element is not used in the vast majority of pages or authoring tools (Wikipedia, LibreOffice, latexml, itex2MML, etc). [2] actually contains a simple Javascript function to do the required mfenced expansion and hence keep some backward compatibility. Frédéric, for the Igalia Web Platform team [1] https://www.w3.org/TR/MathML3/chapter3.html#presm.mfenced [2] http://people.igalia.com/fwang/mfenced-polyfill/ [3] https://trac.webkit.org/wiki/MathML/Early_2016_Refactoring

Hi everybody, Continuing on proposal for MathML4, there are two equivalent notations for square roots: * <msqrt> child1 child2 ... child3 </msqrt> * <menclose notation="radical"> child1 child2 ... child3 </menclose> The latter does not bring anything new but duplicate code or inconsistencies in implementation. In WebKit, the msqrt and mroot elements share implementation and menclose@radical was implemented by creating anonymous nodes. In the past, this kind of implementation has led to rendering, performance and design/security issues. During phase 1 of our refactoring [1], we thus removed support for menclose@radical. In Gecko, the msqrt and menclose elements share implementation but then mroot has duplicate logic, which is bad and Gecko should probably be aligned on WebKit here. So we would like menclose@radical to be removed in future versions of MathML (it is optional in MathML3 anyway). We expect this removal to be safe for the users given that (except in examples and tests) msqrt is always preferred over menclose@radical in math documents. The only rationale for menclose@radical would be to write overlapping notations (e.g. <menclose notation="radical circle horizontalstrike">) but again we are not aware of any concrete use cases for that and it's always possible to nest <msqrt> and <menclose> to get similar rendering without overlapping notations. Frédéric, for the Igalia Web Platform team [1] https://trac.webkit.org/wiki/MathML/Early_2016_Refactoring

Le 26/07/2016 à 00:00, Stephen Watt a écrit : > I see your point, but have to say that I am not really satisfied with > the current spec language regarding equivalence. Mfenced can also > give information about grouping that is lost with the mrow > formulation, e.g. an mrow containining [a, b [ f ] d, e] may be a > list of three things or a pair of half open intervals with an f in the > middle. So the only thing you are saying is that expanding to plain text without explicit grouping implies loss of information compared to using mfenced. That's true, but that's not my point. If you really follow the expansion rules in MathML3 instead of using plain text then you see that nothing is lost in your example and that the mfenced element is again useless. Certainly, one can write <mo>+<mrow> without proper grouping as that's unfortunately often the case for markup generated from text representation like TeX or ASCII. But the existence of an mfenced element in MathML does not magically force converters or people to do this grouping.

Le 25/07/2016 à 20:39, Murray Sargent a écrit : > > Hmm. I like <mfenced>. It's an element that says up front what it > means. <mrow> is abstract and requires parsing before you know what it > means. In Microsoft Office math, there is the "delimiters" element <d> > that maps neatly into <mfenced>. The LineServices math handler formats > such elements automatically expanding to fit their arguments. The > result is math typography very much like TeX, but without the need for > control words like \biggl. > > > > Our products can generate and input MathML using <mrow> instead of > <mfenced>, but parsing similar to that used for the math linear format > <http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf> is used > to convert to <d>. > > As I see, this is an internal implementation details for the Microsoft Word / LineServices that does not need to be exposed to the Web or handled everywhere. You already have import/export features between MathML to OfficeMath including between <mrow>/<mo> and <d> so I don't see how it helps to have an <mfenced> element when you have to handle the general case anyway. MathML is centered around mrow and mo elements with a dictionary of properties. Whether or not it is a good idea is a separate discussion, but it's a core feature of MathML and is unlikely to be changed in the future. That implies that you must implement these general cases anyway and so mfenced or Office's n-ary elements are duplicate features that do not bring anything new but pain for implementers. I would really be curious to hear progress from the Edge developers regarding the implementation of MathML. I'm dubious that the design of mfenced (renderer text provided in attributes, parsing needed to expand the element, duplicate of mrow+mo) make them happy. -- Frédéric Wang

I see your point, but have to say that I am not really satisfied with the current spec language regarding equivalence. Mfenced can also give information about grouping that is lost with the mrow formulation, e.g. an mrow containining [a, b [ f ] d, e] may be a list of three things or a pair of half open intervals with an f in the middle. Stephen On Mon, Jul 25, 2016 at 12:01 PM, Frédéric WANG <fred.wang@free.fr> wrote: > Hi everybody, > > Le 21/07/2016 à 08:52, David Carlisle a écrit : > > While it's true that the math WG is currently "on hold" as there were no > > planned date to do a MathML4 to give implementations time to catch up > > with MathML3, this mailing list is still active and specific suggestions > > can be posted here. > > Assuming that David's response implies that the old Math WG is indeed > inclined to collaborate with Web engines developers and to take into > account feedback for a future MathML 4, we are going to start proposing > improvements on this mailing list. > > One of the most serious design issue in the MathML specification is the > existence of the mfenced element. It is described as a "convenient form > in which to express common constructs involving fences" but is strictly > equivalent to an expanded form using mrow and mo elements [1]. So while > it may be helpful to the rare people writing MathML by hand it is a > redundant and poorly designed feature that has been the source of > troubles for implementers: > > 1) Implementers must ensure that all the cases listed on the MathML > specification are correctly handled to ensure perfect equivalence. This > has always been a source of complexity, errors, and code duplication. We > wrote a short list of tests covering the basic cases described in the > specification [2] and neither Gecko nor WebKit correctly handle all > these cases. And this list does not even take into account all the > features of operators (stretchiness, spacing etc). We found similar > inconsistencies/bugs in the past in WebKit accessibility code and/or > assistive technologies. > > 2) In the case of Web engines, you have to maintain the equivalence when > open/close/separators attributes or the list of children change. And > indeed, there are known bugs in WebKit related to dynamic modification > of mfenced. > > 3) In the case of WebKit, mfenced is implemented by creating anonymous > nodes for each operator and trying to keep them in sync with the DOM. In > the past, this kind of implementation has led to rendering, performance > and design/security issues. During phase 1 of our refactoring [3], > mfenced has caused many troubles and still has not been rewritten so > far. We could follow Gecko's implementation to get rid of these > anonymous nodes, at the price of more code duplication. > > 4) Phase 3 of our refactoring [3] now tries to move all parsing of > MathML attributes from renderer classes to DOM classes in order to > follow standard practice in WebKit's code base and improve > synchronization between the renderer and DOM classes. mfenced is causing > troubles because of its entanglement with the implementation of > operators. Again, it seems that addressing the design issue targeted by > phase 3 will lead to more code duplication if mfenced is kept. > > 5) The mfenced element is designed in a way that the text of fences and > separators is included in DOM attributes instead of DOM elements as it > is generally the case for text content. This means that by default (i.e. > unless some specific code is added to handle mfenced) it may not be > possible to search, select or copy that text using browser user > interfaces or to read the text using assistive technologies. > > In order to simplify the code and make maintenance easier, we are going > to propose on WebKit & Mozilla mailing lists to remove support for the > mfenced element, maybe first to deprecate it. We also definitely do not > want to include support for the mfenced element in the MathML > implementation we have been working on for Blink. > > The only other argument we heard in favor of the mfenced element was > that it gives "better semantic" to express fenced expressions with > opening/closing fences and separators. However, this is a > misunderstanding of the MathML specification: the semantic equivalence > is provided via the (perhaps implicit) fence & separator attributes on > the mo elements and via their relative positions inside the mrow container. > > Also, note that "authors cannot be guaranteed that MathML preprocessors > won't replace occurrences of mfenced with equivalent expanded forms". > This means that even if equivalence may not be true for e.g. CSS style > or DOM manipulation it is anyway wrong to use CSS selectors or > Javascript code that make assumption on whether mfenced or its expanded > form is used. > > Last but not least, the mfenced element is not used in the vast majority > of pages or authoring tools (Wikipedia, LibreOffice, latexml, itex2MML, > etc). [2] actually contains a simple Javascript function to do the > required mfenced expansion and hence keep some backward compatibility. > > Frédéric, for the Igalia Web Platform team > > [1] https://www.w3.org/TR/MathML3/chapter3.html#presm.mfenced > [2] http://people.igalia.com/fwang/mfenced-polyfill/ > [3] https://trac.webkit.org/wiki/MathML/Early_2016_Refactoring > > >

Hmm. I like <mfenced>. It's an element that says up front what it means. <mrow> is abstract and requires parsing before you know what it means. In Microsoft Office math, there is the "delimiters" element <d> that maps neatly into <mfenced>. The LineServices math handler formats such elements automatically expanding to fit their arguments. The result is math typography very much like TeX, but without the need for control words like \biggl. Our products can generate and input MathML using <mrow> instead of <mfenced>, but parsing similar to that used for the math linear format<http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf> is used to convert to <d>. Murray

Hi everybody, Le 21/07/2016 à 08:52, David Carlisle a écrit : > While it's true that the math WG is currently "on hold" as there were no > planned date to do a MathML4 to give implementations time to catch up > with MathML3, this mailing list is still active and specific suggestions > can be posted here. Assuming that David's response implies that the old Math WG is indeed inclined to collaborate with Web engines developers and to take into account feedback for a future MathML 4, we are going to start proposing improvements on this mailing list. One of the most serious design issue in the MathML specification is the existence of the mfenced element. It is described as a "convenient form in which to express common constructs involving fences" but is strictly equivalent to an expanded form using mrow and mo elements [1]. So while it may be helpful to the rare people writing MathML by hand it is a redundant and poorly designed feature that has been the source of troubles for implementers: 1) Implementers must ensure that all the cases listed on the MathML specification are correctly handled to ensure perfect equivalence. This has always been a source of complexity, errors, and code duplication. We wrote a short list of tests covering the basic cases described in the specification [2] and neither Gecko nor WebKit correctly handle all these cases. And this list does not even take into account all the features of operators (stretchiness, spacing etc). We found similar inconsistencies/bugs in the past in WebKit accessibility code and/or assistive technologies. 2) In the case of Web engines, you have to maintain the equivalence when open/close/separators attributes or the list of children change. And indeed, there are known bugs in WebKit related to dynamic modification of mfenced. 3) In the case of WebKit, mfenced is implemented by creating anonymous nodes for each operator and trying to keep them in sync with the DOM. In the past, this kind of implementation has led to rendering, performance and design/security issues. During phase 1 of our refactoring [3], mfenced has caused many troubles and still has not been rewritten so far. We could follow Gecko's implementation to get rid of these anonymous nodes, at the price of more code duplication. 4) Phase 3 of our refactoring [3] now tries to move all parsing of MathML attributes from renderer classes to DOM classes in order to follow standard practice in WebKit's code base and improve synchronization between the renderer and DOM classes. mfenced is causing troubles because of its entanglement with the implementation of operators. Again, it seems that addressing the design issue targeted by phase 3 will lead to more code duplication if mfenced is kept. 5) The mfenced element is designed in a way that the text of fences and separators is included in DOM attributes instead of DOM elements as it is generally the case for text content. This means that by default (i.e. unless some specific code is added to handle mfenced) it may not be possible to search, select or copy that text using browser user interfaces or to read the text using assistive technologies. In order to simplify the code and make maintenance easier, we are going to propose on WebKit & Mozilla mailing lists to remove support for the mfenced element, maybe first to deprecate it. We also definitely do not want to include support for the mfenced element in the MathML implementation we have been working on for Blink. The only other argument we heard in favor of the mfenced element was that it gives "better semantic" to express fenced expressions with opening/closing fences and separators. However, this is a misunderstanding of the MathML specification: the semantic equivalence is provided via the (perhaps implicit) fence & separator attributes on the mo elements and via their relative positions inside the mrow container. Also, note that "authors cannot be guaranteed that MathML preprocessors won't replace occurrences of mfenced with equivalent expanded forms". This means that even if equivalence may not be true for e.g. CSS style or DOM manipulation it is anyway wrong to use CSS selectors or Javascript code that make assumption on whether mfenced or its expanded form is used. Last but not least, the mfenced element is not used in the vast majority of pages or authoring tools (Wikipedia, LibreOffice, latexml, itex2MML, etc). [2] actually contains a simple Javascript function to do the required mfenced expansion and hence keep some backward compatibility. Frédéric, for the Igalia Web Platform team [1] https://www.w3.org/TR/MathML3/chapter3.html#presm.mfenced [2] http://people.igalia.com/fwang/mfenced-polyfill/ [3] https://trac.webkit.org/wiki/MathML/Early_2016_Refactoring

On 21/07/2016 07:00, Frédéric WANG wrote: > Hi everybody, > > People following native MathML developments may know that some work has > been done in WebKit by Igalia developers in the past few years. Igalia > [1] is a free software consultancy with experts working on all open > source web engines (maybe some of you have heard about developments in > e.g. CSS Flexbox and Grid layout, ECMAScript, WebRTC, Streams API or > ARIA). In the past, I got the opportunity to collaborate with some > Igalia employees. In March I joined Igalia's web platform team. > > During my first months at Igalia I have been in charge of upstreaming > many of the MathML patches and to continue the improvements. > Essentially, all the design issues of the flexbox-based implementation > raised by reviewers in the past are now addressed. And although there is > still some work to do and known bugs, we believe we have made some > significant improvements in the MathML support and rendering quality. > People interested can find details on by blog [2] [3]. > > We are very interested to hear any feedback from MathML enthusiasts [4] > that could help future developments, for example those that will be made > during the next Web Engines Hackfest in September [5]. OS X users will > be able to test the new features in the next Safari Technology Preview > [6]. Linux users will have to build WebKitGTK+ themselves [7] or > otherwise wait the next release of GNOME in september and the > integration in their respective distributions. As usual, you must have > math fonts installed on your system to get proper rendering [8]. In > addition, you can add a few CSS lines to your user agent stylesheet in > order to test it on Wikipedia [9]. > > We also have feedback to provide to the authors of the MathML > recommendation from the point of view of web engine developers > (including many similarities with what was reported for Gecko in the > past). It seems that the Math WG is now inactive but hopefully comments > can be taken into consideration for future documents. If members of the > former Math WG are interested to improve the compatibility and > consistency with the web browser code base, then we will provide this > information in follow-up messages. > > The most important point is that the MathML in HTML5 implementation note > [10] and its accompanying test suite [11] from the MathML Association > were very important to write a good MathML implementation in WebKit and > to have MathML features verified in the integration testing framework. > Volunteer developer James Kitchener has also relied on it to continue > improvements in Gecko and to add many tests to Mozilla's own framework. > Several web engine people have been enthusiast about these > implementation note and test suite and suggested to move them into an > official Math WG's document and to the W3C's web-platform-tests [12] so > that all the web engines developers and specification authors can work > on it. > > We believe that with the experience in Gecko and WebKit as well as our > experimentation in Blink, we can now be confident enough on this > document and tests to move it under the W3C's umbrella and continue > improvements there. The implementation proposed by the note relies on > TeX rules and on the OpenType MATH table and some Microsoft employees > seem inclined to consider that approach for Edge too [13]. So again we > would really like to know if any members of the former Math WG are > willing to collaborate with web engine developers on this note, test > suite and hence help native MathML implementations? > > Frédéric, for the Igalia's Web plaform team. > > [1] https://www.igalia.com/ > [2] http://frederic-wang.fr/mathml-refactoring-in-webkit.html > [3] http://frederic-wang.fr/mathml-improvements-in-webkit.html > [4] https://bugs.webkit.org/enter_bug.cgi?product=WebKit&component=MathML > [5] http://www.webengineshackfest.org/ > [6] https://developer.apple.com/safari/technology-preview/ > [7] https://trac.webkit.org/wiki/WebKitGTK > [8] http://trac.webkit.org/wiki/MathML/Fonts > [9] > https://www.mediawiki.org/wiki/Extension:Math/advancedSettings#CSS_for_the_MathML_with_SVG_fallback_mode > [10] http://www.mathml-association.org/MathMLinHTML5/ > [11] http://tests.mathml-association.org/ > [12] https://github.com/w3c/web-platform-tests > [13] http://lists.w3.org/Archives/Public/www-math/2016Apr/0014.html, > https://twitter.com/SampsonMSFT/status/727199790736384001 > > I've been following recent webkit bug activity and this is really excellent news, thanks for the work that's going into webkit. While it's true that the math WG is currently "on hold" as there were no planned date to do a MathML4 to give implementations time to catch up with MathML3, this mailing list is still active and specific suggestions can be posted here. Once it's clearer exactly what documents would make sense to move to W3C it's certainly not impossible that some activity could be proposed to be re-chartered to enable that. David ________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Microsoft Office 365. ________________________________

Hi everybody, People following native MathML developments may know that some work has been done in WebKit by Igalia developers in the past few years. Igalia [1] is a free software consultancy with experts working on all open source web engines (maybe some of you have heard about developments in e.g. CSS Flexbox and Grid layout, ECMAScript, WebRTC, Streams API or ARIA). In the past, I got the opportunity to collaborate with some Igalia employees. In March I joined Igalia's web platform team. During my first months at Igalia I have been in charge of upstreaming many of the MathML patches and to continue the improvements. Essentially, all the design issues of the flexbox-based implementation raised by reviewers in the past are now addressed. And although there is still some work to do and known bugs, we believe we have made some significant improvements in the MathML support and rendering quality. People interested can find details on by blog [2] [3]. We are very interested to hear any feedback from MathML enthusiasts [4] that could help future developments, for example those that will be made during the next Web Engines Hackfest in September [5]. OS X users will be able to test the new features in the next Safari Technology Preview [6]. Linux users will have to build WebKitGTK+ themselves [7] or otherwise wait the next release of GNOME in september and the integration in their respective distributions. As usual, you must have math fonts installed on your system to get proper rendering [8]. In addition, you can add a few CSS lines to your user agent stylesheet in order to test it on Wikipedia [9]. We also have feedback to provide to the authors of the MathML recommendation from the point of view of web engine developers (including many similarities with what was reported for Gecko in the past). It seems that the Math WG is now inactive but hopefully comments can be taken into consideration for future documents. If members of the former Math WG are interested to improve the compatibility and consistency with the web browser code base, then we will provide this information in follow-up messages. The most important point is that the MathML in HTML5 implementation note [10] and its accompanying test suite [11] from the MathML Association were very important to write a good MathML implementation in WebKit and to have MathML features verified in the integration testing framework. Volunteer developer James Kitchener has also relied on it to continue improvements in Gecko and to add many tests to Mozilla's own framework. Several web engine people have been enthusiast about these implementation note and test suite and suggested to move them into an official Math WG's document and to the W3C's web-platform-tests [12] so that all the web engines developers and specification authors can work on it. We believe that with the experience in Gecko and WebKit as well as our experimentation in Blink, we can now be confident enough on this document and tests to move it under the W3C's umbrella and continue improvements there. The implementation proposed by the note relies on TeX rules and on the OpenType MATH table and some Microsoft employees seem inclined to consider that approach for Edge too [13]. So again we would really like to know if any members of the former Math WG are willing to collaborate with web engine developers on this note, test suite and hence help native MathML implementations? Frédéric, for the Igalia's Web plaform team. [1] https://www.igalia.com/ [2] http://frederic-wang.fr/mathml-refactoring-in-webkit.html [3] http://frederic-wang.fr/mathml-improvements-in-webkit.html [4] https://bugs.webkit.org/enter_bug.cgi?product=WebKit&component=MathML [5] http://www.webengineshackfest.org/ [6] https://developer.apple.com/safari/technology-preview/ [7] https://trac.webkit.org/wiki/WebKitGTK [8] http://trac.webkit.org/wiki/MathML/Fonts [9] https://www.mediawiki.org/wiki/Extension:Math/advancedSettings#CSS_for_the_MathML_with_SVG_fallback_mode [10] http://www.mathml-association.org/MathMLinHTML5/ [11] http://tests.mathml-association.org/ [12] https://github.com/w3c/web-platform-tests [13] http://lists.w3.org/Archives/Public/www-math/2016Apr/0014.html, https://twitter.com/SampsonMSFT/status/727199790736384001

Hi, 1. I’ll be on a cell phone today. 2. . Perhaps in the new 5.4 or a separate section 5.5 or in an accessibility section, which relates to metadata x.x.x Accessibility metadata must describe the whole publication Accessibility metadata of a PWP relates to the whole publication; the components as an aggregate must be accessible. For example, a publication that has chapters 1,2,3 as accessible, but chapter 4 is not accessible, the metadata would indicate that the publication is not accessible. x.x.x Accessibility Metadata must be Discoverable Before a person, school, or university decides to use a PWP, the accessibility of the PWP must be available. For example, a professor is looking for digital textbooks to use in the course. The professor knows that there are regulations that require accessible educational materials. In addition, the professor is a moral person and would never knowingly use inaccessible educational materials. The professor uses the available metadata about a PWP to determine if the publication is appropriate for the class. I don’t know if these types of use cases relate directly to PWP, but I thought I would bring them up. Best George From: Charles LaPierre [mailto:charlesl@benetech.org] Sent: Thursday, July 07, 2016 12:44 PM To: public-dpub-accessibility@w3.org Cc: public-digipub-ig@w3.org Subject: [DPUB][A11Y] Agenda 07082016 Hello everyone, just a reminder for tomorrow’s accessibility DPUB call [1] Agenda [2] Date/Time [3] WebEx Call In [4] IRC Channel Regards Deborah and Charles [1] Agenda We will continue our discussion on a11y use cases for PWP. Link to PWP Use cases http://w3c.github.io/dpub-pwp-ucr/ Editable version https://github.com/w3c/dpub-pwp-ucr/blob/gh-pages/index.html [1.1] Review of Use-Case 8.2 Adding Alternative Media Braille There is an important difference between just sending the raw text to a braille display which will translate the text to the default braille grade and language the braille display is using and having a pre-formatted braille rendition using a specific braille table. Example As a publisher wanting to fulfill my legal requirements in creating an accessible Math textbook, I wish to include my math equation examples in Braille as well as MathML since not all reading systems fully support MathML. Nemeth Braille is primarily used so I have added separate preformatted Nemeth Braille examples to my publication in addition to the MathML. [1.2] Continuing in section "Use Cases - Accessibility” We never really finished these two from last week. Personalized Experience Assisted Reader Technology [2] Friday July 8 at 10AM PDT / 1PM EDT / 17:00 UTC [3] https://mit.webex.com/mit/j.php?MTID=me61494d75b248018777b1bbf0b87dd3b Meeting number: 642 567 899 Dial in: +1-617-324-0000 Password: (Ask Charles, Tzviya, or Deborah) [4] DPUB IRC Channel irc.w3.org Group: #dpub

Hello everyone, just a reminder for tomorrow’s accessibility DPUB call [1] Agenda [2] Date/Time [3] WebEx Call In [4] IRC Channel Regards Deborah and Charles [1] Agenda We will continue our discussion on a11y use cases for PWP. Link to PWP Use cases http://w3c.github.io/dpub-pwp-ucr/ Editable version https://github.com/w3c/dpub-pwp-ucr/blob/gh-pages/index.html [1.1] Review of Use-Case 8.2 Adding Alternative Media Braille There is an important difference between just sending the raw text to a braille display which will translate the text to the default braille grade and language the braille display is using and having a pre-formatted braille rendition using a specific braille table. Example As a publisher wanting to fulfill my legal requirements in creating an accessible Math textbook, I wish to include my math equation examples in Braille as well as MathML since not all reading systems fully support MathML. Nemeth Braille is primarily used so I have added separate preformatted Nemeth Braille examples to my publication in addition to the MathML. [1.2] Continuing in section "Use Cases - Accessibility” We never really finished these two from last week. Personalized Experience Assisted Reader Technology [2] Friday July 8 at 10AM PDT / 1PM EDT / 17:00 UTC [3] https://mit.webex.com/mit/j.php?MTID=me61494d75b248018777b1bbf0b87dd3b <https://mit.webex.com/mit/j.php?MTID=me61494d75b248018777b1bbf0b87dd3b> Meeting number: 642 567 899 Dial in: +1-617-324-0000 Password: (Ask Charles, Tzviya, or Deborah) [4] DPUB IRC Channel irc.w3.org Group: #dpub

This post discusses how a combination of the Office in-memory built-up format (“Professional” in Word) and the math linear format is ideal for generating speech for math zones. Neither format was designed with speech in mind. The built-up format was designed to aid the creation of beautiful math typography. The linear format was designed to aid math keyboard input by looking as close as possible like real math. That goal is often achieved. For example, (a+b)/2 is, in fact, a valid mathematical expression. Fortuitously this goal also brings the notation closer to speech. One can understand the literal translation “open paren a plus b close paren over 2”.

Understand at the outset that two granularities of math speech are needed: coarse-grained, which speaks math expressions fluently in a natural language, and fine-grained, which speaks the content at the insertion point. The coarse-grained granularity is great for scanning through math zones. It doesn’t pretend to be tightly synchronized with the characters in memory and cannot be used directly for editing. It’s relatively independent of the memory math model used in applications.

In contrast, the fine-grained granularity is tightly synchronized with the characters in memory and is ideal for editing. By its very nature, it depends on the built-up memory math model (described below), which is the same for all Microsoft math-aware products, but may differ from the models of other math products. Coarse grained navigation between siblings for a given math nesting level can be done with Ctrl+→ and Ctrl+← or Braille equivalents, while fine-grained navigation is done with → and ← or equivalents. The latter allows the user to traverse every character in the display math tree used for a math zone. The coarse- and fine-grained granularities are discussed further in the post Math Accessibility Trees. In addition to granularity, it’s useful to have levels of verbosity. Especially when new to a system, it’s helpful to have more verbiage describing an equation. But with greater familiarity, one can comprehend an equation more quickly with less verbiage.

To represent mathematics linearly and unambiguously, the linear format may introduce parentheses that are removed in built-up form. Speaking the introduced parentheses can get confusing since it may be hard for the listener to track which parentheses go with which part of the expression. In the simple example above of (a+b)/2, it’s more meaningful to say “start numerator a plus b end numerator over 2” than to speak the parentheses. Or to be less verbose, leave out the “start”. This idea applies to expressions that include square roots, boxed formulas and other “envelopes” that use parentheses to define their arguments unambiguously. For the linear format square-root √(a^2-b^2), it’s clearer to say “square root of a squared minus b squared, end square root” instead of “square root of open paren a squared minus b squared close paren”. This is particularly true if the square root is nested inside a denominator as in

which has the linear format 1/(2+√(a^2-b^2)). By saying “end square root” instead of “close paren”, it’s immediately clear where the square root ends. Simple fractions like 2/3 are spoken using ordinals as in “two thirds”. Also when speaking the linear format text ∑_(n=0)^∞, rather than say “sum from open paren n equal 0 close paren to infinity”, one should say “sum from n equal 0 to infinity”, which is unambiguous without the parentheses since the “from” and “to” act as a pair of open and close delimiters. This and similar enhancements are discussed in the ClearSpeak specification and in Significance of Paralinguistic Cues in the Synthesis of Mathematical Equations. Such clearer start-of-unit, end-of-unit vocabulary mirrors what’s in memory. The parentheses introduced by the linear format are not in memory since the memory version uses special delimiters as explained below. Parentheses inserted by the user are spoken as “open paren” and “close paren” provided they are the outermost parentheses. Nested parentheses are spoken together with their parenthesis nesting level as in “open second paren”, “open third paren”, etc.

Such refinements can be made by processing the linear format,
but some parsing is needed. It’s easier to examine the built-up
version of expressions, since that version is already largely
parsed. The built-up format is a *display tree* as described
in the post
Math Accessibility Trees. For example, to know that an exponent
in the linear format equation a^2+b^2=c^2 is, in fact, a 2 and not
part of a larger argument, one must check the character following
the 2 to make sure that it’s an operator and not part of the
exponent. If the letter z follows the 2 as in a^2z, the z is part
of the superscript and the expression should be spoken as “a to the
power 2z”. In memory one just checks for a single code, here the
end-of-object code U+FDEF. If that code follows the 2, the exponent
is 2 alone and “squared” is appropriate, unless exponents are
indices as in tensor notation.

The built-up memory format represents mathematical objects like
fraction, matrix and superscript by a start delimiter, the first
argument, an argument separator if the object has more than one
argument, the second argument, etc., with the final argument
terminated by the object end delimiter. For example, the linear
format fraction a/2 is represented in the built-up format by
{_{frac} *a*|2} where {_{frac} is the start
delimiter, | is the argument separator, and } is the end delimiter.
Similarly a^2 is represented in the built-up format by
{_{sup} *a*|2 }. Here the start delimiter is the
same character for all math objects and is the Unicode character
U+FDD0 in RichEdit (Word uses a different character). The type of
math object is given by a rich-text object-type property associated
with the start delimiter as described in
ITextRange2::GetInlineObject(). The RichEdit argument separator
is U+FDEE and the object end delimiter is U+FDEF. These Unicode
codes are in the U+FDD0..U+FDEF “noncharacters” block reserved for
internal use only.

Another scenario where the built-up format is very useful for speech is in traversing a math zone character by character, allowing editing along the way. Consider the integral

When the insertion point is at the start of the math zone, “math zone” is spoken followed by the speech for the entire math zone. But at any time the user can enter → (or Braille equivalent), which halts the math-zone speech, enters the numerator of the leading fraction, and speaks “1”. Another → and “end of numerator” is spoken. Another → and “2 pi” is spoken. Another → and “end of denominator” is spoken and so forth. In this way, the user knows exactly where the insertion point is and can edit using the usual input methods.

This approach is quite general. Consider matrices. At the start
of a matrix, “*n* × *m* matrix” is spoken, where
*n* is the number of rows and *m* is the number of
columns. Using →, the user moves into the matrix with one character
spoken for each → up until the end of the first element. At that
end, “end of element 1 1” is spoken, etc. Up and down arrows can be
used to move vertically inside a matrix as elsewhere, in all cases
with the target character or end of element being spoken so that
the user knows which element the insertion point is in.

Math variables are represented by math alphabetics (see Section 2.2 of Unicode Technical Report #25). This allows variables to be distinguished easily from ordinary text. When converted to speech text, such variables are surrounded by spaces when inserted into the speech text. This causes text-to-speech engines to say the individual letters instead of speaking a span of consecutive letters as a word. In contrast, an equation like rate = distance/time, would be spoken as “rate equals distance over time”. Math italic letters are spoken simply as the corresponding ASCII or Greek letters since in math zones math italic is enabled by default. Other math alphabets need extra words to reveal their differences. For example, ℋ is spoken as “script cap h”. Alternatively, the “cap” can be implied by raising the voice pitch.

Some special cues may be needed to convince text-to-speech engines to say math characters correctly. For example, ‘+’ may need to be given as “plus”, since otherwise it might be spoken as “and”. The letter ‘a’ may need to be enclosed in single quotes, since otherwise it may be spoken as the ‘a’ in “zebra” instead of the ‘a’ in “base”.

Another example of how the two speech granularities differ is in how math text tweaking is revealed. First, let’s define some ways to tweak math text. You can insert extra spaces as described in Sec. 3.15 of the linear format paper. Coarse-grained speech doesn’t mention such space but fine-grained speech does. More special kinds of tweaking are done by inserting phantom objects. Five Boolean flags characterize a phantom object: 1) zero ascent, 2) zero descent, 3) zero width, 4) show, and 5) transparent. Phantom objects insert or remove precise amounts of space. You can read about them in the post on MathML and Ecma Math (OMML) and in Sec. 3.17 of the linear format paper. The π in the upper limit of the integral above is inside an “h smash” phantom, which sets the π’s width to 0 (smashes the horizontal dimension). Notice how the integrand starts at the start of the π. Coarse-grained speech doesn’t mention this and other phantom objects and only includes their contents if the “show” flag is set. Fine-grained speech includes the start and end entities as well as the contents. This allows a user to edit phantom objects just like the 22 other math objects in the LineServices math model.

The approaches described here produce automated math speech; the content creator doesn’t need to do anything to enable math speech. But it’s desirable to have override capability, since the heuristics used may not apply or the content author may prefer an alternate phrasing.

W3C - Found Jun. 27, 2016Other features include support for HTML5 (including the element), MathML, SVG, XSLT, JavaScript, and accessible PDF. This version adds PDF/UA... |

The American Physical Society (APS) continues to support the MathJax project as a MathJax Supporter.

Founded in 1899, the American Physical Society (APS) is the world’s largest organization of physicists and involved in several activities to advance and diffuse the knowledge of physics, including a strong publication program with landmark titles such as Physical Review Letters, the Physical Review journals, and Reviews of Modern Physics. As an influential supporter of SGML-based math notation in the 1990s and an early adopter of MathML, the APS has long been furthering innovation in academic communication.

“APS is very pleased to continue our support of MathJax, both financially and through our participation on the new technical committee”, said Mark Doyle, Chief Information Officer, American Physical Society. “Recent efforts on accessibility and the current work on updating the core of MathJax are exciting enhancements that will benefit all readers of math on the web.”

“As one of the earliest MathJax sponsors, APS has helped push MathJax forward from Day 1.”, said Peter Krautzberger, MathJax manager. “Thanks to their continued support we are able to keep MathJax the most reliable, high-quality solution for math and science on the web.”

We look forward to continuing the collaboration with APS, and welcome their ongoing support for the MathJax project.

Pearson is giving the MathJax project a boost by joining our sponsorship program as MathJax Supporter.

Founded in 1844 as a small building firm in Yorkshire, Pearson is the largest education company in the world today. With Pearson School, Pearson Higher Education and Pearson Professional, Pearson’s focus today lies solely on education.

“Pearson is proud to become a MathJax sponsor as we often rely on MathJax to deliver our web-based math and science assessment and instructional content in our digital products.”, says Wayne Ostler, VP Content Systems and Publishing. “We look forward to working with the MathJax community to develop and improve MathML rendering and accessibility tools in our digital products”.

“The support as a MathJax sponsor demonstrates Pearson’s commitment to being a partner to the math and science community on the web”, comments Peter Krautzberger, MathJax manager. “Becoming a MathJax Supporter allows Pearson to make optimal use of MathJax, and makes an important contribution to keeping MathJax the reliable, flexible, and open technology it is today.”

The MathJax team looks forward to the collaboration with Pearson, and welcomes their support for the MathJax project.

**About Pearson**

Pearson is the world’s leading learning company, with expertise in educational courseware and assessment, and a range of teaching and learning services powered by technology.

Pearson’s mission is to help people make progress through access to better learning. We believe that learning opens up opportunities, creating fulfilling careers and better lives.

**About MathJax**

MathJax was initiated in 2009 by the American Mathematical Society (AMS), Design Science, and the Society for Industrial and Applied Mathematics (SIAM) with the aim of developing a universal, robust, and easy-to-use solution to display mathematics on the web. MathJax’s open source JavaScript library provides high-quality display on all browsers and platforms without the need for readers to install plugins or fonts. Using MathJax also enables copy&paste of equations and is compatible with accessibility tools for vision and learning disabilities. The MathJax Consortium is supported by numerous sponsors.

So this seemingly implies the following: > [...] it probably means that we won’t see MathML supported on Blink in the short-term [...] Too bad… (I do know that using MathJAX can work around this in the meantime, but still...) Olaf - - - CONFIDENTIALITY UN-DISCLAIMER: Nothing in my email contains confidential material. Even if you are not the intended recipient, please feel free to read it, or simply delete it whenever you feel like it. Please understand that my email may contain incorrect or useless information, so please use it with a grain of salt. > On 22.06.2016, at 01:07, Cramer, Dave <Dave.Cramer@hbgusa.com> wrote: > > This article discusses what Blink is doing with Houdini and MathML: > > https://blogs.igalia.com/mrego/2016/06/21/my-blinkon6-summary-grid-layout-h > oudini-and-mathml/ > > This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network. >

Both of these mails had the URL cut, because your respective clients wrapped the lines… Here is a short URL that can help:-) http://bit.ly/28US66t Ivan > On 22 Jun 2016, at 03:58, George Kerscher <kerscher@montana.com> wrote: > > Hi, > Here is a link that should work: > https://blogs.igalia.com/mrego/2016/06/21/my-blinkon6-summary-grid-layout-ho > udini-and-mathml/ > > Best > George > > -----Original Message----- > From: Cramer, Dave [mailto:Dave.Cramer@hbgusa.com] > Sent: Tuesday, June 21, 2016 5:07 PM > To: W3C Digital Publishing IG > Subject: Houdini and MathML in Blink > > This article discusses what Blink is doing with Houdini and MathML: > > https://blogs.igalia.com/mrego/2016/06/21/my-blinkon6-summary-grid-layout-h > oudini-and-mathml/ > > This may contain confidential material. If you are not an intended > recipient, please notify the sender, delete immediately, and understand that > no disclosure or reliance on the information herein is permitted. Hachette > Book Group may monitor email to and from our network. > > > > ---- Ivan Herman, W3C Digital Publishing Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 ORCID ID: http://orcid.org/0000-0003-0782-2704

Planet MathML features:

- Ask.com News Search for "mathml"
- David Carlisle
- Design Science News
- FMath
- MathJax
- Murray Sargent: Math in Office
- Planetary Developer Forum: {9} Planetary News
- SF.net - ASCIIMathML
- SF.net - DocBook to LaTeX Publishing
- SF.net - MathCast Equation Editor
- SF.net - MathStudio
- SF.net - Open Math Edit
- SF.net - PyMathML
- SF.net - SVGMath
- SF.net - UniWakka
- SF.net - jsMath
- SF.net - jscl-meditor
- SF.net - pMML2SVG
- W3C Blog
- W3C Math Home
- W3C News
- Web Platform Blog
- public-digipub-ig@w3.org Mail Archives
- public-html-a11y@w3.org Mail Archives
- public-html@w3.org Mail Archives
- public-webapps@w3.org Mail Archives
- www-math@w3.org Mail Archives
- www-style@w3.org Mail Archives

If you own a blog with a focus on MathML, and want to be added or removed from this aggregator, please get in touch with Bert Bos at bert@w3.org.