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

## XML entities draft on github

Source: www-math@w3.org Mail Archives • David Carlisle (davidc@nag.co.uk) • October 02, 2015 • Permalink

The editor's draft of the entities spec has been moved to github

https://w3c.github.io/xml-entities/

(The old URL at http://www.w3.org/2003/entities/2007doc/ redirects to
the same thing)

In particular this now means that the unicode.xml and other source files
are more easily tracked by other projects. (I know several browser
and latex-to-xxx projects are using that in one way or another.)

The sources are at

https://github.com/w3c/xml-entities

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: [css-writing-modes] Behavior of <iframe> in vertical writing mode

Source: www-style@w3.org Mail Archives • fantasai (fantasai.lists@inkedblade.net) • September 30, 2015 • Permalink

On 08/07/2015 05:41 AM, Jonathan Kew wrote:
> On 7/8/15 03:46, fantasai wrote:
>> On 08/06/2015 05:45 AM, Jonathan Kew wrote:
>>> I'm wondering how <iframe>s should be handled when writing-mode is
>>> vertical.
>>> ...
>>> which could easily be read as being applicable to <iframe> content,
>>> unless that content explicitly resets writing-mode to its
>>> initial value. Clarification?
>>
>> Yeah, that needs a clarification. I think it only should apply to
>> inlined replaced content like the examples mentioned, not to content
>> pulled in from another document.
>
> Sounds reasonable; given that other styles don't inherit into
> <iframe>s, it would seem odd for writing-mode to magically do
> so. I expect you can figure out some suitable wording here to
> eliminate the potential confusion.

Proposed wording:

# The content of replaced elements do not rotate due to the
# writing mode: images and external content such as from
# iframes, for example, remain upright, and the default
# object size of 300px×150px does not re-orient. However
# embedded replaced content involving text (such as MathML
# content or form elements) should match the replaced
# element’s writing mode and line orientation if the UA
# supports such a vertical writing mode for the replaced
# content.

Please let me know if that's sufficiently clear, or if you have
any suggestions for improvement.

Thanks~
~fantasai


## Re: Vote for math fonts in Windows

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

Neil: a manager from Microsoft seems to say that using the app feature
feedback is wrong:

On 09/13/2015 11:24 PM, Neil Soiffer wrote:
> The dev.modern.ie <http://dev.modern.ie> one is for web developers and
> designers (wpdev.uservoice.com/forums/257854-microsoft-edge-developer
> <http://wpdev.uservoice.com/forums/257854-microsoft-edge-developer>),
> whereas as the windows.uservoice.com <http://windows.uservoice.com>
> one is for users. It doesn't hurt to vote on both lists.
>
> Neil Soiffer



## Introduction to MathML – The Markup Language for Math - Hongkiat

Source: mathml - Google Blog Search • Preethi Ranjit • September 24, 2015 • Permalink

MathML is a markup language that can be used to display mathematical notations. You can use MathML tags directly from HTML5. It is useful for when you wish to show more than simple notations of Math in your web pages, and it's quite easy ...

## Re: Important information about the MathML fonts in Gecko 41

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

Thank you for the suggestion and reference Murray.

Actually, the "check whether there is a MATH table" workaround has
already been used since Gecko 31, because many OpenType fonts with a
MATH table didn't set the OS/2 USE_TYPO_METRICS flag properly. However,
it's not really good to keep such "hacks" so this will be removed
starting with Gecko 43 (to be released at the end of the year):
https://bugzilla.mozilla.org/show_bug.cgi?id=1170782

From my testing of free math fonts and from what I heard (for non-free
math fonts), all the fonts with a MATH table but STIX sets the OS/2
USE_TYPO_METRICS flag. That's not much a problem for STIX since the
current release has bugs that prevent it to be usable for math layout
anyway and it's best to use the XITS fork. The STI Pub is aware of the
bugs and I'm confident that at least the  OS/2 USE_TYPO_METRICS bug will
be fixed in version 2.

On 09/23/2015 10:58 PM, Murray Sargent wrote:
> Frédéric noted that the STIX font doesn't support the OS/2 USE_TYPO_METRICS flag.
>
> For math fonts, a workaround is to check if there's a MATH table and use the typo metrics if so. Another work around is to compare the type ascent/descent to the TEXTMETRIC ascent/descent and assume a high font is involved if the latter is significantly bigger (1.5 × or more). Here's a post (http://blogs.msdn.com/b/murrays/archive/2009/12/01/high-fonts-and-math-fonts.aspx#10023606) on high fonts which explains a little more.
>
> Murray

--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic



## RE: Important information about the MathML fonts in Gecko 41

Source: www-math@w3.org Mail Archives • Murray Sargent (murrays@exchange.microsoft.com) • September 23, 2015 • Permalink

Frédéric noted that the STIX font doesn't support the OS/2 USE_TYPO_METRICS flag.

For math fonts, a workaround is to check if there's a MATH table and use the typo metrics if so. Another work around is to compare the type ascent/descent to the TEXTMETRIC ascent/descent and assume a high font is involved if the latter is significantly bigger (1.5 × or more). Here's a post (http://blogs.msdn.com/b/murrays/archive/2009/12/01/high-fonts-and-math-fonts.aspx#10023606) on high fonts which explains a little more.

Murray


## Important information about the MathML fonts in Gecko 41

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

Dear all,

As previously announced for Gecko 31, we are moving our math font
support towards OpenType fonts with a MATH table. Firefox 41 has been
released this week and I'd like to give important information for our
users. Of course this applies to other products based on Gecko such that
Thunderbird or SeaMonkey.

1) The first good news is that the the OS/2 USE_TYPO_METRICS is now
implemented in the Gecko versions relying on the GDI API, that is old
versions of Windows [1]. AFAIK, Firefox is thus the first browser to
fully support this OpenType feature after Internet Explorer. Also all
OpenType fonts but STIX have now enabled this bit which means that they
can be used without being affected by an "excessive line spacing bug" [2].

2) We have dropped support for "Standard Symbols L" and "MathJax fonts"
[3]. Support for "STIX General" (installed on Mac OSX) and the "Symbol"
font on Windows (XP does not have Cambria Math) has been kept for now.
Of course, we recommend to install OpenType fonts with a MATH table

3) Users willing to use LaTeX's default "Computer Modern" style should
install the latest Latin Modern Math fonts by the GUST e-foundry group [5].

4) Users willing to use the "STIX" style should install Khaled Hosny's
XITS fork [6]. Any version of STIX will provide very good Unicode
coverage for math & tech symbols but the current release has too many
bugs to be usable for math layout. Hopefully these will be fixed in
version 2, currently in development [7].

5) The enhancement request for math fonts on windows.uservoice.com has

6) Last but not least, the old "font.mathfont-family" property from the
"about:config" menu has finally been removed. This used to provide a way
to configure your preferred fonts for MathML when one is not specified
by the page author. In Gecko 41, it has been replaced with new
properties that I won't mention here, since "about:config" not really
to set the "Serif" font for "Mathematics". See the attached screenshot.

Frédéric Wang (for the Mozilla MathML Project)

[1] http://www.microsoft.com/typography/otspec/os2.htm#fss
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=947650
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1174143
[4] https://developer.mozilla.org/en-US/docs/Mozilla/MathML_Project/Fonts
[5] http://www.gust.org.pl/projects/e-foundry/lm-math
[6] https://github.com/khaledhosny/xits-math
[7] http://www.stixfonts.org/
[8]



## Re: Best citation format for accessibility

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

+1

On 22 Sep 2015, at 18:43, Bill Kasdorf <bkasdorf@apexcovantage.com> wrote:

> But frankly, if the purpose is just getting to the cited resource, then rather than a link to the JATS info, it seems more straightforward to just implement the link to the cited resource that is usually already in that citation (having been put there based on the JATS markup in the citation and in the metadata of the cited article).

And this makes me think about what I tend to call 'complex document substructures'… There is excellent support for some complex document substructures in HTML, for example for lists, tables and with the advent of MathML on HTML, for mathematical expression/equations/formulae. There are no mechanisms for complex document substructures in other cases [no, SVG doesn't count because it might be complex but is not well prepared to express semantic structure], and unfortunately HTML5 cannot be extended by 'custom tags' or tags from some other tag language (whereas that is possible for SVG…).

Now, if we take citations as a worthwhile example of a complex document substructure, and also look at other examples of complex document substructures, like diagram, bar charts, maps, musical notation, etc. - can we think of an approach that not only serves citations but also (some of) the other types/classes of complex document substructure? My main interest here is not to run the risk of fragmenting the landscape even further such that each individual problem gets its own specialist solution… (despite the fact that one could argue they all belong to the same class of problems)

Olaf


## [Meeting Summary] Meeting Summary 2015-09-21

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

The meeting summary is here:

https://www.w3.org/blog/dpub/2015/09/22/dpub-ig-telco-2015-09-21-publication-object-model-mathml/ <https://www.w3.org/blog/dpub/2015/09/22/dpub-ig-telco-2015-09-21-publication-object-model-mathml/>

----
Ivan Herman, W3C
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704



## Meeting Minutes 2015-09-21

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

The meeting minutes of yesterday's meeting are here:

http://www.w3.org/2015/09/21-dpub-minutes.html <http://www.w3.org/2015/09/21-dpub-minutes.html>

Text version below

Ivan

----
Ivan Herman, W3C
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704

[1]W3C

[1] http://www.w3.org/

Digital Publishing Interest Group Teleconference

21 Sep 2015

[2]Agenda

[2] http://www.w3.org/mid/60044b021c654e5f98268070bc5c796a@CAR-WNMBP-006.wiley.com

[3] http://www.w3.org/2015/09/21-dpub-irc

Attendees

Present
Charles LaPierre, Ben De Meester, Ivan Herman, Karen
Myers, Daniel Glazman (glazou), Ralph Swick, Tzviya
Siegman, Dave Cramer (dauwhe), Leonard Rosenthol
(lrosenth), Deborah Kaplan, Markus Gylling, Peter
Krautzberger, Alan Stearns, John Pedersen, Vladimir
Levantovski, Brady Duga, Paul Belfanti, Bill Kasdorf,
Bert Bos

Regrets
Julie Morris, Mike Miller, Nick Ruffilo, Laura Fowler,
Tim Cole, Zheng Xu

Chair
Tzviya

Scribe
Dave Cramer

Contents

* [4]Topics
1. [5]DPUB API-s
2. [6]MathML discussions II
* [7]Summary of Action Items
__________________________________________________________

<trackbot> Date: 21 September 2015
<tzviya> agenda:
[8]https://lists.w3.org/Archives/Public/public-digipub-ig/2015S
ep/0138.html

[8] https://lists.w3.org/Archives/Public/public-digipub-ig/2015Sep/0138.html

<tzviya> chair: tzviya
<scribe> scribenick: dauwhe

<tzviya> [9]http://www.w3.org/2015/09/14-dpub-minutes.html

[9] http://www.w3.org/2015/09/14-dpub-minutes.html

tzviya: first item: approving minutes

<Ralph> agenda:
[10]https://lists.w3.org/Archives/Public/public-digipub-ig/2015
Sep/0138.html

[10] https://lists.w3.org/Archives/Public/public-digipub-ig/2015Sep/0138.html

... minutes approved
... we've invited Daniel Glazman to talk about...

DPUB API-s

glazou: I am the implentor of a WYSIWYG editor
... only native epub2/3 editor
... which led me to discover some complications in spec
... the very low-level code you have to write to access the
package

<astearns> [11]http://bluegriffon.org/

[11] http://bluegriffon.org/

... you have to follow a chain of IDs and IDREFs
... so I want to hide that complexity behind some APIs

<tzviya> [12]http://www.bluegriffon-epubedition.com/

[12] http://www.bluegriffon-epubedition.com/

glazou: to open, validate, add files to package
... the code you have to write now to do this is huge
... and I think this has hindered the adoption of EPUB3
... if we had an EPUB object model with an open-source object
model
... and a polyfill
... right now everyone has to implement everything from scratch
... so an object model for EPUB, or more generally electronic
books
... would be a good thing
... I can elaborate, but this is the summary

tzviya: I have a question
... this group has been talking about shifting the digital
publication model towards models available on the open web
... are you thinking about EPUB package?

glazou: I want something more general
... that would work for HTML in ZIP, for example
... I want to hide the complexity of the package, of epub
... hide the complexity of whatever is implemented
... the object model could be mapped to whatever the
implementation is

tzviya: I like that idea

<Bill_Kasdorf> +1

clapierre: I was wondering about a11y features of bluegriffon
... can you add aria-roles and accessibility features

glazou: yes I can

lrosenth: I think the idea is very good
... especially if it's not package-format-specific
... the question is where's the boundary?
... is this an API or an object model for any type of
publication?
... or just OWP publications?
... I'm trying to understand the boundaries

glazou: think of that object model in two layers
... the first level is the visible API layer
... the second layer underneath is the system layer where you
call the guts of the package
... my primary goal now is EPUB3

<Bill_Kasdorf> +1 to the two layered strategy

glazou: but that second layer could be different for different
implementations epub2, mobi, whatever
... it's doable

lrosenth: all the examples you gave are variants of the same
thing, for example PDF
... do you envision that same object model could apply to
something completely different
... or does it only apply to OWP resources bundled together

glazou: I think it could be open to absolutely everything
... it's just a question of writing a layer that's between the
PDF and the API
... in theory, yes.
... the lower level would have to be rewritten for every format
you want to reach
... think of it as a "publication object model"

ivan: coming back to EPUB
... how does this API deal with other object models, like HTML
... how are these combined?

glazou: I don't understand the Q

ivan: I understand that from your API I reach a specific
resource in the package, for example HTML5
... do you try to parse the HTML with your stuff?

glazou: I've not completely written this
... imagine you open a package and get list of resources and
fetch one
... if it's HTML, what you retrieve is the HTML DOM
... if you want reach it as a file, you just need another set
of API
... it's not really a file system
... the idea is to as soon as you can fall back to existing DOM
APIs you do so

mgylling: just to be clear
... I thought I heard you say an API for reading and writing
... this is for reading systems as well as authoring tools?

glazou: absolutely
... add stuff, delete stuff, change stuff...
... thing of all the things you do to a DOM tree
... you should be able to do all those things to a publication
package

<Bill_Kasdorf> Also +1 to always referring to what we are
talking about as "a publication package."

foundation
... they have a read-only API
... would be interesting to compare your proposal to what

lrosenth: focused on a JS-based API model
... do you think this could extend to a REST model or other
languages

glazou: I mentioned JS because this is obvious and immediate
usage
... clearly JS is not my sole focus
... should be buildable in C++
... a REST API should be possible in an ideal world

lrosenth: are you designing it around JS or a generic object
model?

glazou: the latter. I'm writing Web IDLs, not JS
... it's a lot of work but wanted to talk to people before
investing lots of time

tzviya: this is very much in line with what we've been working
on lately
... like our requirements for packaging web apps
... the concepts work very well together
... what the next step is is a good question

glazou: I started writing Web IDLs
... it's a lot of effort
... having a place to discuss this with people would be good
... I'm a newcomer to world of dpub
... I could miss things, make bad design choice
... having discussion would be good

tzviya: are you on EPUB31 mailing list?

glazou: I am

<Ralph> [I wonder to what extent Markus and other EPUB
architects have been thinking of an object model in the
background]

tzviya: we're having this kind of discussion there, too

glazou: my problem is that we should go quite fast
... an OM to be designed should take 18 months max
... it will pass quite quickly

<Bill_Kasdorf> Fast is good for this, because it's foundational
for other specs and implementations

glazou: the more I look at the market the more we're limited by
the lack of such a framework on a stable OM
... I think it's a market enabler

lrosenth: I think it's a good idea
... my biggest comment would be that this object model needs to
align with work on identification
... whatever work we do in this area is done by same group or
in close collaboration

glazou: my only goal is to make that happen and I'll work with
anyone, W3C, IDPF, wherever

ivan: putting on w3c hat
... what's next step?
... having discussion based on more specific document would be
great
... I think this group is the right forum
... don't want to argue whether the final development it's here
or IDPF

glazou: I have a question
... this group is not tailored to published specs

ivan: initial discussion stays informal
... with new charter we can do proof-of-concept spec
... but won't be REC
... if it should be REC then we must go down WG route
... my suggestion would be to write a note published by DPUB
... explaining why an OM would be good
... and suggesting ways to reach a REC
... I think it's a joint effort between IDPF and W3C
... higher-level objects are IDPF
... but objects to be retrieved are DOM nodes
... let's not get into "cuisine" of where/how it gets done
... tzviya and mgylling are the chairs, they can decide if this
is the place to publish a note
... I'd go further, and publish a skeleton of the interface
... whatever it is, we'll have to convince people to devote
time and energy to a WG

glazou: I can start that

<lrosenth> POM works for me...

glazou: I can start that document, but what would be the title?
Publications Object Model?

ivan: we've had a hundred-email discussion on terminology

<Ralph> "curated document object model" - cdom ;)

tzviya: we haven't talked about portable object model :)

mgylling: it's apple not potato

<glazou> ;-)

mgylling: I almost forgot
... Ivan covered it
... we need to get IPDF implementors a way to be involved
... maybe it's a CG

glazou: I have no religion about that
... whatever works

ivan: let's not worry
... let's get a document and then see where it goes

tzviya: OK
... we are at the half-hour
... we'll try to get something started
... we can tie in some loose ends... packaging, glossary, etc

ivan: each word is a hundred emails ;)

tzviya: as soon as glazou said publication object model it
sounded good

<lrosenth> +1 on POM

<pbelfanti> +1 on POM

<Bill_Kasdorf> +1 but I prefer "Publication" to "Publishing"

<pbelfanti> As long as we don't get sued by Apple:-)

<Bill_Kasdorf> It is also promoted as a healthy thing a la "POM
Wonderful"

everyone: silence

tzviya: thanks glazou!

<Bill_Kasdorf> Seriously I like the pomegranate metaphor
because it

<Bill_Kasdorf> 'because it's a package with lots of little
things in it

tzviya: I forgot to introduce my collage John Pedersen

John_Pedersen: I've been involved in developing our schemas in
Wiley
... we're getting involved in all things digital

tzviya: OK
... John is particularly interested in Math

John_Pedersen: it is my background, I was a math professor

tzviya: Peter, we'll turn it over to you

pkra: I hope I figured them out :)
... where should we start?
... should I recap?

MathML discussions II

pkra: the most obv. question is where is this coming from
... most critical one is that browser dev for MathML support
has stalled in the past years
... has never been driven by browser vendors but by unpaid
volunteers
... this is the base problem
... we have MathML but not implementation
... 2nd problem is MathML is in maintenance mode
... Math WG is up for rechartering
... maintenance mode would have some consequence
... the 3rd issue is new tools for Math on web

<pkra> ... new features in MathJAX, ability to convert MathML
into something that looks good

<Ralph> [13]14-Sep MathML discussion (part 1)

[13] http://www.w3.org/2015/09/14-dpub-minutes.html#item01

pkra: pre-render into HTML or SVG
... so you have good rendering but not actual MathML in the
page
... other tools like KaTeX that don't even use MathML and go to
LaTex ways
... or tools like PDF.js that just convert something into HTML
... my personal perspective:
... browser development is not working out
... we see no interest
... this is a huge issue
... 2nd assumption is how MathML should be realized in browsers
... for me that means HTML+CSS
... in the aughts it was a black box for rendering
... some people think it should be in a separate renderer
... at end of call last week, Ivan asked what I would do if I
could do anything
... the key problem is that browser vendors don't care
... which has tech and personal connotation
... they're not involved in Math WG
... haven't given input to spec
... fundamentally there's no interest
... so we have to make them interested
... there are areas that we can make them interested
... typographic detail and reliability
... if math layout was implemented you'd get better typography
... odd way to get there
... large areas are shared
... multiscript, sub/superscript and pre/post
... fancy borders
... lots of math is just fancy borders
... there's layout and semantics
... on layout end, there's interest from Houdini that we might
pursue
... on the semantic side, there's the big glaring hole of the
ARIA spec
... which has just one "Math" role
... and there seems to be some interest from ARIA
... since renderers can't rely on MathML
... you want to expose underlying semantics
... one more thing
... ivan asked why browsers don't care
... MathML is a top-down solution
... it assumes you want to solve fundamental problems before

lrosenth: are you suggesting that ARIA would be the direction
to apply semantics to math rather than many other directions?
... why ARIA?

pkra: I'm not sure if ARIA is the right direction
... with the tools I use for math on the web
... you can't use the mroot element and use clever CSS, you
must use DOM injection to build layout around it
... feels similar where you want to build button but you can't
use button element, but must use ARIA role="button"
... I"m not talking about detailed semantics
... but I think there's low-hanging fruit to help a11y
... like presentation MathML-level semantics

ivan: I'd come back to presentation side
... I'm not really clear on the direction you want to propose
... current approach is that I put in my HTML5 some MathML
markup
... the script just catch this stuff then does complex JS
rendering
... is that correct?

pkra: yes
... I see a strong move towards doing the JS on the server
rather than the client

ivan: there's a move to do all that on the server
... take that element and turn it into clever html and CSS, and
that's all my client sees
... is that what you're proposing?

pkra: it's what we're facing
... developers are eager to not do MathML rendering on client

ivan: that means if I am a random user who writes HTML with
math then I have to run it through a special server

pkra: it's not like the client side is going away but you can
do both
... professionals can use the complex solution
... there are people that throw markdown on their web page and
have JS convert it on the fly
... but we'll see more and more people doing it on server
... but then you disconnect the MathML from the output

ivan: that's where ARIA would come in

pkra: yes
... right now you could just put MathML beside rendering and
hide it
... you want to expose MathML to AT
... now you have AT content not connected to visual

ivan: still concerned about client side
... they use the term "polyfill" as the tool that solves every
misery of the world
... last time you remarked that MathJax? is not good at
polyfilling

pkra: MathJax is not a pollyfill in the modern sense
... a polyfill should be as similar to a native implementaiton
as possible
... and lay the basis for the native implementation
... for example, picturefill
... you develop spec alongside polyfill
... with MathML you could imagine this
... you could write a polyfill that creates custom elements etc
... make complicated custom element structure
... we don't work that way
... it seems like a difficult process for performance
... you don't want to expose any APIs but the DOM
... you would expect development to manipulate DOM as if it was
a normal MathML implementation
... but no one is doing that

ivan: You don't think there would be interest?

pkra: I don't think it will solve the core problems

pkra: it wouldn't solve layout, just shove it into shadow DOM
... it wouldn't show us a way towards native
... make it easier for browsers to ignore
... third, it doesn't solve any of the non-JS problems
... since web components require JS

tzviya: is there a solution?

<Ayla_Stein> need to run to a meeting, thanks!

tzviya: it sounds like we're saying there are a lot of

pkra: we're not a polyfill because web components aren't yet
available
... we've decided to ignore this
... because the real problem is to render in HTML and CSS
... let's bridge the gap and get the rendering to be easier
... have more of it done by native
... make this usable to AT
... have a way of exposing semantics
... it's like grid before grid layout, or flex before flexbox
... we need new stuff to make this possible
... just a personal opinion

lrosenth: that makes perfect sense
... my concern is that I don't want us to lose the semantics
... or redo the syntax for different people
... AT knows how to deal with MathML
... but layout doesn't know how to deal with MathML
... so let's not throw away the existing work in order to make
browser vendors happy

tzviya: to flip that
... it's used on back end now
... it's used in processing
... how a11y is it in real world?
... if the browsers aren't using it, how used is it, really?
... maybe not scrapping MathML but building on it

<Bill_Kasdorf> the company I work for creates thousands of
MathML expressions daily. It is used a LOT, just not in
browsers.

lrosenth: you need all groups in the room--AT, renderers,
semantics

ivan: this has been tried and failed for the last twenty years

<pkra> I could go on ...

tzviya: at least ARIA has browsers and AT vendors in the same
room
... we're not talking about scrapping MathML

ivan: the question for me
... do we have to modify MathML to make this server-side
processing more streamlined?

<pkra> +1 to dauwhe

Summary of Action Items

[End of minutes]
__________________________________________________________

Minutes formatted by David Booth's [14]scribe.perl version
1.140 ([15]CVS log)
$Date: 2015/10/04 19:31:47$

[14] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
[15] http://dev.w3.org/cvsweb/2002/scribe/



## Re: DOM5 and MathML4

Murray,

Thank you for the information.  Mathematical notations, scientific notations, diagrams and other educational contents for 3D graphics and video production scenarios, in particular with API or abstraction layers for computer-automated design and layout, are topics interesting to me (https://www.linkedin.com/pulse/artificial-mental-simulation-adam-sobieski).

From: Murray Sargent
Sent: ‎Monday‎, ‎September‎ ‎21‎, ‎2015 ‎3‎:‎14‎ ‎PM

I’d like to share a link: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3848348-enhance-directx-directwrite-with-the-layout-and-re.  DirectWrite and DirectX Graphics mathematical layout and rendering would entail mathematical notations for apps, including document authoring software, the Edge browser as well as 3D graphics rendered with DirectX 12.

The Microsoft Office apps and RichEdit already have elegant math rendering on Direct2D/DWrite. Edge uses Direct2D/DWrite and LineServices, which has the TeX-quality math handler. Adding native MathML support to Edge is mostly a matter of hooking up the math callbacks that LineServices makes for math zones. It’s a little tricky since LineServices expects object prefix notation and Presentation MathML is often infix, e.g., <mrow>.

The major problem with this approach though is that LineServices isn’t documented publically. It would be good to expose math interfaces that people can use. The RichEdit math facilities are documented in MSDN, but they are disabled in the Windows RichEdit msftedit.dll. Hopefully we can change that.

Murray


## MathJax v2.6 beta now available

Source: MathJax • September 22, 2015 • Permalink

Today we are entering the public beta phase of MathJax v2.6. This release focused on two main features:

1. Completing the CommonHTML output, a faster HTML output that can be generated on both client and server.

2. Accessibility improvements in the form of

• an extension to expose MathJax’s internal MathML to screenreaders
• making the MathJax Menu accessible.

The v2.6 release also includes over 30 bug fixes to increase the quality and stability of MathJax (see below for details).

The beta is available via our CDN at beta.mathjax.org/mathjax/latest/MathJax.js which you can load it in place of the version you are currently using. Alternatively, you can get a ZIP archive or access the branch on GitHub.

### Changes to the default MathJax “TeX” fonts

We have updated our default MathJax “TeX” fonts to improve the CommonHTML output and simplify its layout process. If you have previously installed a copy of the MathJax TeX fonts to your local system, please update that copy to ensure correct rendering in the CommonHTML output.

You can check this using the embedded page below (external link) which will detect whether you need to update installed MathJax “TeX” fonts installed.

See the Pen MathJax Font Check by MathJax (@mathjax) on CodePen.

Note: Other applications may have installed the MathJax “TeX” fonts for you.

Note: The changes to the MathJax “TeX” fonts are backward compatible to previous versions of MathJax so you can install them without worrying about sites using older MathJax versions. Of course you do not need to install the fonts as MathJax can automatically load webfonts instead.

### Changes to the combined configuration files

If you are using a combined configuration, please note the following:

1. We have added several new combined configuration files. In particular, you can use the new CommonHTML output by chosing a combined configuration ending on _CHTML.

2. The new AssitiveMML.js extension is included in these configurations. If you want to de-activate it, add, e.g., the following to your page before MathJax.js is loaded.

Remember that this is still beta software, so if you are not an experienced user, you may want to wait for the official 2.6 release. We do not recommend that you use the 2.6-beta version for production environments, but do encourage you to test your content with it.

If you are linking to http://cdn.mathjax.org/mathjax/latest/MathJax.js, note that at the point of the official release of v2.6, the address will begin to serve MathJax v2.6. You can also continue to use v2.5 by linking to http://cdn.mathjax.org/mathjax/2.5-latest/MathJax.js instead — and you can change to that version at any point (it is available now). Once the official v2.6 release is made, the v2.6-beta address will be removed from the CDN.

The official release of v2.6 should occur within the next three weeks, but we want you to be able to start to test out the v2.6 features now. Please report any bugs you find to the issue tracker at https://github.com/mathjax/MathJax/issues.

Thanks for your continuing interest in MathJax. We hope that this release makes your MathJax experience even better.

The MathJax Team.

## New in MathJax v2.6

MathJax v2.6 includes a number of new features, as well a more than 30 important bug fixes. The following are some of the highlights.

## Features

• Improved CommonHTML output. The CommonHTML output now provides the same layout quality and MathML support as the HTML-CSS and SVG output. It is on average 40% faster than the other outputs and the markup it produces are identical on all browsers and thus can also be pre-generated on the server via MathJax-node. The fast preview mechanism introduced in v2.5 continues to develop as a separate output as PreviewHTML and the fast-preview extension.
• Accessibility improvements. We thank the AT community for their guidance, support, and feedback in our efforts towards making MathJax completely accessible to all users.
• Screenreader compatibility. The new AssistiveMML extension enables compatibility with most MathML-capable screenreaders by inserting visually-hidden MathML alongside MathJax’s visual output. See screenreader support for details on the expected behavior as well as background on the limitations due to lack of web standards and browser/OS technology.
• Accesssible UI. We have improved the accessibility of the MathJax menu to enable assistive technology users to easily access its features, cf. MathJax UI.
• Semi-slim MathJax repository for bower. You can now use bower install components/MathJax for a fork of MathJax without PNG fonts. Many thanks to @minrk from the IPython/Jupyter team and to the team at components!
• Deprecated: MMLorHTML extension. We have deprecated the MMLorHTML extension. For a detailed guide on configuring MathJax to choose different outputs on different browsers, please see Automatic Selection of the Output Processor for more information.

Numerous bugs and issues have also been resolved; for a detailed listing please check the release milestone.

## Interface

• #938 Expose MathML for accessibility; cf. screenreader support.
• #939 Make MathJax contextual menu properly accessible.
• #1210 Update MathZoom.js: global border-box support. Special thanks to @CalebKester

## HTML/SVG/nativeMML display

• #1095 HTML-CSS output: prevent collapse of table borders.
• #596 SVG Output: Fix overlapping equation labels in SVG output
• #994 SVG Output: Change default blacker setting to 1.
• #995 SVG output: fix baseline alignment issues.
• #995 SVG output: fix failure to scale all but the first glyph in a fraction when useFontCache=false.
• #1233 SVG output: make maligngroup and malignmark produce no output.
• #1035 PreviewHTML output: fix fractions formatting in WebKit and IE.

## TeX emulation

• #567 Add macro for overparen and underparen to provide stretchy arcs above/below
• #956 Simplify the mhchem extension to use multiscripts, cf. #1072.
• #1028 Fix spacing in \alignedat.
• #1194 Fix problem where automatic numbering affects \binom and friends.
• #1199 Fix problem with dot delimiter not being recognized as a delimiter.
• #1224 Handle braces properly in text mode when looking for matching math delimiters.
• #1225 Fix \operatorname not ignoring \limits that follow immediately after.
• #1229 Fix wrong spacing of trailing binary operators.

## Asciimath

• asciimath/#31 Add support for overparen, underparen to produce mover and munder constructs.

## MathML

• #1072 Right-justify prescripts in mmultiscript elements (after clarification in MathML 3 editors’ draft); cf. #956.
• #1089 Fix toMathML from changing <maligngroup> to <malign>
• #1188 Fix mmultiscripts with odd number of post-scripts not rendering correctly.
• #1231 Fix  element not being treated as an <mrow> for embellished operator spacing. • #1233 Make <maligngroup> and <malignmark> be self-closing in MathML input. • #1238 Fix Content MathML extension not handling namespace prefixes. • #1257 Improve mml3.js: better RTL support in HTML-CSS; improved IE/Edge compatibility. ## Fonts • #928 Add data for stretchy U+2322 (FROWN), U+2323 (SMILE), and also U+2312 (ARC) to be aliases for the top and bottom parentheses. This enables stretchy constructions; cf. also #567. • #1211 Fix web font detection for Gyre-Pagella etc. in IE10+. • #1251 Fix primes in STIX-web font being too small in SVG output. ## Localization • #1248 Updated locales thanks to the contributors at Translatewiki.net; activate locales for Bulgarian, Sicilian, and Lithuanian. ## APIs • #1216 Add debugging tips to console output. ## Misc. • #1074 Fix regression in v2.5 regarding MathPlayer on IE9. • #1036 Improve CDN rollover behavior. • #1085 Fix detection of Windows Phone mobile IE. • #1155 Work around websites using user agent filtering • #1173 Avoid warning message in debug mode. • #1208 Fix CHTML preview from setting chunking parameters even when disabled. • #1214 semi-slim official MathJax repository for bower; use bower install components/MathJax for a copy without PNG fonts. Special thanks to @minrk from the IPython/Jupyter team and to the team at components! • #1254 Improve examples in /test: add viewport meta tags, improve dynamic examples. ## Re: Are web components *seriously* not namespaced? Source: public-webapps@w3.org Mail Archives • Henri Manson (hfmanson@gmail.com) • September 21, 2015 • Permalink I created a prototype of this idea on github: https://github.com/hfmanson/webcomponentsjs/blob/xml-namespace/README.md by forking the original webcomponents.js project. It contains a working example of this concept. Below the content of the README.md file: This fork of webcomponents.js enhances Document.registerElement so that the options argument can contain a 'namespace' property which contains an XHTML namespaceURI e.g. http://mansoft.nl/big-blue-button so you can put a custom element in another namespace than http://www.w3.org/1999/xhtml, which is the default when no namespace is specified. The custom element registry is now a 2 dimensional lookup table. First the namespaceURI is looked up and then the localname of the custom Element. An example usage can be found at https://github.com/hfmanson/webcomponentsjs/blob/xml-namespace/xmltests/brb-test-polyfill-ce.xhtml Here two custom elements are defined with the same name 'bigbutton' (without dashes) but with different namespaces " http://mansoft.nl/big-red-button" and "http://mansoft.nl/big-blue-button". When webcomponents.js is build you can test this file on a browser not natively implementing Document.registerElement e.g. Firefox An important change is to no longer use the HTML-specific onclick functions etc. but the generic DOM AddEventListener pattern. The registration of the components using the extra 'namespace' property is done in https://github.com/hfmanson/webcomponentsjs/blob/xml-namespace/xmltests/bbb-component.js and https://github.com/hfmanson/webcomponentsjs/blob/xml-namespace/xmltests/brb-component.js The example component 'Big Red Button' is based on a webcomponent sample from Robin Berjon's presentation 'Distributed Extensibility: Finally Done Right?' on XML Prague 2014. When this will be implemented in the official Custom Element specification it will be possible to polyfill XHTML with for example XForms by implementing each XForm component using custom components. Or MathML. I'll be happy to hear your comments and suggestions.  ## RE: DOM5 and MathML4 Source: www-math@w3.org Mail Archives • Murray Sargent (murrays@exchange.microsoft.com) • September 21, 2015 • Permalink Adam wrote: I’d like to share a link: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3848348-enhance-directx-directwrite-with-the-layout-and-re. DirectWrite and DirectX Graphics mathematical layout and rendering would entail mathematical notations for apps, including document authoring software, the Edge browser as well as 3D graphics rendered with DirectX 12. The Microsoft Office apps and RichEdit already have elegant math rendering on Direct2D/DWrite. Edge uses Direct2D/DWrite and LineServices<http://blogs.msdn.com/b/murrays/archive/2006/11/15/lineservices.aspx>, which has the TeX-quality math handler. Adding native MathML support to Edge is mostly a matter of hooking up the math callbacks that LineServices makes for math zones. It’s a little tricky since LineServices expects object prefix notation and Presentation MathML is often infix, e.g., <mrow>. The major problem with this approach though is that LineServices isn’t documented publically. It would be good to expose math interfaces that people can use. The RichEdit math facilities are documented in MSDN, but they are disabled in the Windows RichEdit msftedit.dll. Hopefully we can change that. Murray  ## Re: DOM5 and MathML4 Source: www-math@w3.org Mail Archives • Adam Sobieski (adamsobieski@hotmail.com) • September 21, 2015 • Permalink Math Working Group, MathML4, as envisioned, is a highly-extensible semantics-based markup. Presentational markup can be obtained from the semantics content, utilizing transcribe() or transcribeXML(). <math xmlns:arith="http://www.w3.org/math/arithmetic/"> <arith:multiply arith:presentationalattr="..."> <... /> <... /> </arith:multiply>

<math xmlns:arith="http://www.w3.org/math/arithmetic/">

<presentation type="application/xhtml+xml">

<!-- automatically generated from MathElement’s transcribeXML, e.g. XHTML+CSS -->

</presentation>
<arith:multiply arith:presentationalattr="...">
<... />
<... />
</arith:multiply>
[/itex]

The extensibility adds complexity to schema processing; for example <arith:multiply> might be valid if and only if it has two operands that are elements of certain sets.  We could put isValid() onto the MathElement interface.

interface MathElement : Element
{

bool isValid();

float? /* [0, 1] */ canTranscribe(DOMString format, Container? container = null);

DOMString? transcribe(DOMString format, Container? container = null);
Element? transcribeXML(DOMString format, Container? xmlns = null, Document? document = null);

void semantics(Graph graph, Container? ontology = null);
...
};

We can also specify sets with the MathML4, resembling abstract expression trees.

interface MathSet

{

…

};

interface MathElement : Element
{

bool isValid();

MathSet getSet();

float? /* [0, 1] */ canTranscribe(DOMString format, Container? container = null);

DOMString? transcribe(DOMString format, Container? container = null);
Element? transcribeXML(DOMString format, Container? xmlns = null, Document? document = null);

void semantics(Graph graph, Container? ontology = null);
...
};

Kind regards,

http://www.phoster.com

Sent: ‎Monday‎, ‎September‎ ‎21‎, ‎2015 ‎1‎:‎10‎ ‎PM
To: www-math@w3.org

Math Working Group,

I’d like to share a link: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3848348-enhance-directx-directwrite-with-the-layout-and-re.  DirectWrite and DirectX Graphics mathematical layout and rendering would entail mathematical notations for apps, including document authoring software, the Edge browser as well as 3D graphics rendered with DirectX 12.

Also, exciting news; recent ideas about DOM5 (https://www.w3.org/community/argumentation/2015/09/21/document-object-model-5/) present new opportunities for MathML4.

Here is a tentative sketch of a MathElement interface:

interface MathElement : Element
{
float? /* [0, 1] */ canTranscribe(DOMString format, Container? container = null);

DOMString? transcribe(DOMString format, Container? container = null);
Element? transcribeXML(DOMString format, Container? xmlns = null, Document? document = null);

void semantics(Graph graph, Container? ontology = null);
...
};

Kind regards,

http://www.phoster.com


## DOM5 and MathML4

Math Working Group,

I’d like to share a link: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3848348-enhance-directx-directwrite-with-the-layout-and-re.  DirectWrite and DirectX Graphics mathematical layout and rendering would entail mathematical notations for apps, including document authoring software, the Edge browser as well as 3D graphics rendered with DirectX 12.

Also, exciting news; recent ideas about DOM5 (https://www.w3.org/community/argumentation/2015/09/21/document-object-model-5/) present new opportunities for MathML4.

Here is a tentative sketch of a MathElement interface:

interface MathElement : Element
{
float? /* [0, 1] */ canTranscribe(DOMString format, Container? container = null);

DOMString? transcribe(DOMString format, Container? container = null);
Element? transcribeXML(DOMString format, Container? xmlns = null, Document? document = null);

void semantics(Graph graph, Container? ontology = null);
...
};

Kind regards,

http://www.phoster.com


## Re: "MathML Association"

Source: www-math@w3.org Mail Archives • Bert Bos (bert@w3.org) • September 18, 2015 • Permalink

On Wednesday 16 September 2015 23:46:45 Frédéric WANG wrote:

> *The official address is mathml-association.org *

I've made it a (temporary) highlight on http://www.w3.org/Math/

Nice to see this initiative!

Bert
--
Bert Bos                                ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos                               W3C/ERCIM
bert@w3.org                             2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France



## The MathML Association promotes & funds MathML im­ple­men­ta­tions

Source: W3C Math Home • September 17, 2015 • Permalink

The MathML Association promotes & funds MathML im­ple­men­ta­tions

## Re: "MathML Association"

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

On 09/16/2015 09:22 PM, Deyan Ginev wrote:
> On 09/16/2015 03:10 PM, Paul Libbrecht wrote:
>> Maybe it can make a difference into advertising the need and encouraging
>> implementations?
>> Somehow, an association may be more friendly or appear more open,
>> similarly to the way the WhatWG has appeared.
> Let's hope so, that's the goal.
>
>
> directors@mathml-association.org
>
> And some of us are also lurking on this list.
>
> It's a great time to be excited about MathML!
>
> Greetings,
> Deyan
Dear all,

I would like to add a precision:

*The official address is mathml-association.org *

The "dev" link mentioned in a previous message was used during the
development phase and should never have been posted on a public forum...

I'm also really surprised how one who carefully reads the content of the
website can arrive to the conclusion that it is a "competitor" to the
Math WG. As others say and as stated on the website, the main goal is to
support native MathML implementations in browsers, so it is obviously
complementary to the Math WG effort...

Please tell us if there are still instances of the "dev." URL appearing
somewhere on our public pages, twitter acount etc or if there are
statements on our website that would wrongly suggest a competition with
the Math WG, so that we can fix that as soon as possible. Thanks for

Frédéric



## RE: "MathML Association"

Source: www-math@w3.org Mail Archives • Paul Topping (pault@dessci.com) • September 16, 2015 • Permalink

Sounds good to me. Do you have any specific activities in mind?

Paul Topping

Design Science, Inc.
"How Science Communicates"
Makers of MathType, MathFlow, MathPlayer, Equation Editor
http://www.dessci.com

From: Michael Kohlhase [mailto:m.kohlhase@jacobs-university.de]
Sent: Wednesday, September 16, 2015 12:56 PM
To: Peter Krautzberger <peter.krautzberger@mathjax.org>; www-math@w3.org
Subject: Re: "MathML Association"

Dear Peter, dear all,

the MathML association is not at all a competitor to the WG, which is about setting standards.

The MathML association is trying to drum up support for native MathML and support its implementation in browser. That can only be good for the WG.

Michael
On 16/09/15 20:23, Peter Krautzberger wrote:
Hi,

It seems the WG has a "competitor".

* http://dev.mathml-association.org/

* https://github.com/MathML

Peter.

--

----------------------------------------------------------------------

Prof. Dr. Michael Kohlhase,        Office: Research 1, Room 168

Professor of Computer Science  Campus Ring 1,

Jacobs University Bremen           D-28759 Bremen, Germany

tel/fax: +49 421 200-3140/-493140  skype: m.kohlhase

m.kohlhase@jacobs-university.de<mailto:m.kohlhase@jacobs-university.de> http://kwarc.info/kohlhase

----------------------------------------------------------------------


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