# Planet MathML

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

Source: www-math@w3.org Mail Archives • David Carlisle (davidc@nag.co.uk) • July 26, 2016 • Permalink

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.

________________________________


## Re: [MathML4] Deprecation/Removal of the mfenced element

Source: www-math@w3.org Mail Archives • Miller, Bruce R (Fed) (bruce.miller@nist.gov) • July 26, 2016 • Permalink

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


## [MathML4] Removal of the menclose notation "radical"

Source: www-math@w3.org Mail Archives • Frédéric WANG (fred.wang@free.fr) • July 26, 2016 • Permalink

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



## Re: [MathML4] Deprecation/Removal of the mfenced element

Source: www-math@w3.org Mail Archives • Frédéric WANG (fred.wang@free.fr) • July 26, 2016 • Permalink

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.



## Re: [MathML4] Deprecation/Removal of the mfenced element

Source: www-math@w3.org Mail Archives • Frédéric WANG (fred.wang@free.fr) • July 26, 2016 • Permalink

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



## Re: [MathML4] Deprecation/Removal of the mfenced element

Source: www-math@w3.org Mail Archives • Stephen Watt (smwatt@gmail.com) • July 25, 2016 • Permalink

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
>
>
>


## RE: [MathML4] Deprecation/Removal of the mfenced element

Source: www-math@w3.org Mail Archives • Murray Sargent (murrays@exchange.microsoft.com) • July 25, 2016 • Permalink

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



## [MathML4] Deprecation/Removal of the mfenced element

Source: www-math@w3.org Mail Archives • Frédéric WANG (fred.wang@free.fr) • July 25, 2016 • Permalink

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



## Re: Recent MathML Improvements in WebKit

Source: www-math@w3.org Mail Archives • David Carlisle (davidc@nag.co.uk) • July 21, 2016 • Permalink

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
> 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]
> [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,
>
>

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.

________________________________


## Recent MathML Improvements in WebKit

Source: www-math@w3.org Mail Archives • Frédéric WANG (fred.wang@free.fr) • July 21, 2016 • Permalink

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
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]
[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,



## Recent MathML Improvements in WebKit

Source: www-math@w3.org Mail Archives • Frédéric Wang (fwang@igalia.com) • July 21, 2016 • Permalink

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
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]
[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,


## Recent MathML Improvements in WebKit

Source: www-math@w3.org Mail Archives • Frédéric Wang (fwang@igalia.com) • July 20, 2016 • Permalink

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
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]
[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,


## RE: [DPUB][A11Y] Agenda 07082016

Source: public-digipub-ig@w3.org Mail Archives • George Kerscher (kerscher@montana.com) • July 08, 2016 • Permalink

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.
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
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

[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

[4] DPUB IRC Channel
irc.w3.org
Group: #dpub


## [DPUB][A11Y] Agenda 07082016

Source: public-digipub-ig@w3.org Mail Archives • Charles LaPierre (charlesl@benetech.org) • July 07, 2016 • Permalink

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.
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
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

[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

[4] DPUB IRC Channel
irc.w3.org
Group: #dpub



## Speaking of math…

Source: Murray Sargent: Math in Office • MurrayS3 • June 30, 2016 • Permalink

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”.

## Speech granularity

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.

## Parentheses

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.

## Built-up format

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.

## Variables and ordinary text

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”.

## Tweaks

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.

## RealObjects released PDFreactor version 8.1, an XML-to-PDF f…

Source: Ask.com News Search for "mathml" • June 27, 2016 • Permalink

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

## American Physical Society continues as MathJax Supporter

Source: MathJax • June 27, 2016 • Permalink

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 becomes a MathJax Supporter

Source: MathJax • June 23, 2016 • Permalink

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.

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.

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.

## Re: Houdini and MathML in Blink

Source: public-digipub-ig@w3.org Mail Archives • Olaf Drümmer (olaf@druemmer.com) • June 22, 2016 • Permalink

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:
>
>
> 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.
>


## Re: Houdini and MathML in Blink

Source: public-digipub-ig@w3.org Mail Archives • Ivan Herman (ivan@w3.org) • June 22, 2016 • Permalink

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:
> 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
>
>
> 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
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704



## Feeds

Planet MathML features:

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.