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

## Inserting and Getting Math Text in RichEdit

Source: Murray Sargent: Math in Office • MurrayS3 • November 22, 2015 • Permalink

Starting with the Office 2007 RichEdit, it has been possible to enter math using the keyboard and to read and write RTF files that contain math zones. The RichEdit Text Object Model (TOM) ITextRange2 interface has methods to handle math programmatically, such as ITextRange2::BuildUpMath() and ITextRange2::SetInlineObject() and GetInlineObject(). But the methods don’t offer convenient ways to enter and retrieve math in other formats, such as MathML and OMML (Office MathML). This post describes some recent additions to handle math in various formats easily using ITextRange2::SetText2(options, bstr) and GetText2(options, pbstr).

These methods offer a variety of options including the tomConvertRTF (0x2000) option to insert and get RTF strings. This capability is exposed in the XAML text object model of the RichEditBox via the Windows.UI.Text.ITextRange::SetText() and GetText() methods with the FormatRtf option. Officially RTF is a byte format, that is, the character codes are 8-bits or multiples thereof and the TOM methods support BYTE strings, even though housed in BSTRs. In addition, the methods support UTF-16 strings that can contain any Unicode characters, so you don’t need to use the hard-to-read RTF Unicode \uN control word. On input (SetText2), UTF-16 RTF is recognized automagically. To retrieve UTF-16 RTF, bitwise OR in the tomGetUtf16 flag (0x00020000), that is, call ITextRange2::GetText2(tomConvertRTF | tomGetUtf16, &bstr). International and math UTF-16 RTF is so much easier to read than the standard 8-bit RTF! Internally, RichEdit reads UTF-16 RTF by converting it to UTF-8 RTF, a format introduced by RichEdit 4.1 in 2002, and reading in the resulting UTF-8 RTF.

Since the tomConvertRTF option made handling RTF easier, we decided to add some more options for the SetText2 and GetText2 methods. Specifically the latest Microsoft Office RichEdit supports the tomConvertMathML (0x00010000), tomConvertOMML (0x00080000), and tomConvertLinearFormat (0x00040000) options for converting MathML, OMML (Office MathML), and the math linear format, respectively. These options let you use RichEdit as a math-zone conversion machine: input math in one format and retrieve it in another.

Note that while RTF is a general rich-text format that can include math zones, MathML and OMML only represent math zones. In a fashion similar to RTF, plain text can include math zones in the linear format delimited by square brackets with quills ⁅ (U+2045) and ⁆ (U+2046). In fact, you can copy RichEdit text with math zones to a plain-text editor such as NotePad, copy that plain text back into RichEdit, Select All and use the ctrl-alt-shift-= hot key to build up all the math zones! Although most rich-text formatting is lost in plain-text copies, the math zones come through with little or no loss.

The new RichEdit can also copy and paste MathML and OMML using the usual copy/paste hot keys and commands. Older RichEdit versions contain the MathML and OMML converters used by PowerPoint and OneNote, but ironically RichEdit itself didn’t expose MathML/OMML copy/paste functionality, so that’s been remedied.

In a nonmath context, there’s a new SetText2 option, tomConvertRuby (0x00100000), to convert strings like “{…|…}” to ruby inline objects, where the first ellipsis represents the ruby text and the second ellipsis the base text. The ASCII curly braces and vertical bar are translated to the internal ruby-object structure characters U+FDD1, U+FDEF, and U+FDEE, respectively. Alternatively the string can contain those structure characters directly. If a digit follows the start delimiter (‘{‘ or U+FDD1}, the digit defines the ruby options

 rubyAlign val Meaning center (0) Center with respect to distributeLetter (1) Distribute difference in space between longer and shorter text in the latter, evenly between each character distributeSpace (2) Distribute difference in space between longer and shorter text in the latter using a ratio of 1:2:1 which corresponds to lead : inter-character : end left (3) Align with the left of right (4) Align with the right of

If you add 5 to these values, the ruby object will display the ruby text below the base text instead of above it. For example, calling ITextRange2::SetText2(tomConvertRuby, bstr) with bstr containing the string “{1にほんご|日本語}” inserts

The string can contain text in addition to ruby objects and the ruby objects can be nested to create compound ruby objects such as

We see that the ITextRange2::SetText2() and GetText2() methods provide helpful conversion facilities. You may have noticed that the very important LaTeX/TeX math format doesn’t have such an option yet: no tomConvertTeX. That’s a serious shortcoming that needs to be addressed.

## shakespeare is a Haskell library that provides a template sy…

Source: Ask.com News Search for "mathml" • November 16, 2015 • Permalink

 W3C - Found Nov. 16, 2015 Other features include support for HTML5 (including the element), MathML, SVG, XSLT, JavaScript, and accessible PDF. (Java.

## Re: Removal of the link to w3centities-f.ent....

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

On 14/11/2015 03:14, Raghav V Karnam wrote:
> Hi,
>
> We have the reference to this file w3centities-f.ent on w3.org url in
> our code heavily…
>         Public identifier: -//W3C//ENTITIES Combined Set//EN//XML
>         System identifier:
> http://www.w3.org/2003/entities/2007/w3centities-f.ent
> Since this morning this link to the file seems to be invalid. I am
> looking at changing the code to use this file locally…
> Is it possible to send a copy of this file? Or enable the link back on
> the authenticity of the file.
> Thanks
> --
> W3C Enthusiast....
> "The happiest of people don't necessarily have the best of everything;
> they just make the best of everything that comes along their way." efax
> : (208) 361-9687
>
Oh thanks for that report.

The master has been at github for a couple of months

https://github.com/w3c/xml-entities/tree/gh-pages/2007

However there are supposed to be redirects in place so the

http://www.w3.org/2003/entities/2007

I'm travelling today but I'll report it to the W3C webmasters and
hopefully the old link will work again soon.

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.

________________________________


## Removal of the link to w3centities-f.ent....

Source: www-math@w3.org Mail Archives • Raghav V Karnam (raghav_vk@yahoo.com) • November 14, 2015 • Permalink

Hi,
We have the reference to this file w3centities-f.ent on w3.org url in our code heavily…         Public identifier: -//W3C//ENTITIES Combined Set//EN//XML       System identifier: http://www.w3.org/2003/entities/2007/w3centities-f.entSince this morning this link to the file seems to be invalid. I am looking at changing the code to use this file locally…Is it possible to send a copy of this file? Or enable the link back on the server so I can download. I found couple of links but not sure of the authenticity of the file.Thanks-- W3C Enthusiast.... "The happiest of people don't necessarily have the best of everything; they just make the best of everything that comes along their way." efax : (208) 361-9687


## Open Font Format 3 released: Are browser vendors good at math?

Source: Blog de Frédéric - Tag - mathml • fredw • October 17, 2015 • Permalink

Version 3 of the Open Font Format was officially published as ISO standard early this month. One of the interesting new feature is that Microsoft's MATH table has been integrated into this official specification. Hopefully, this will encourage type designers to create more math fonts and OS vendors to integrate them into their systems. But are browser vendors ready to use Open Font Format for native MathML rendering? Here is a table of important Open Font Format features for math rendering and (to my knowledge) the current status in Apple, Google, Microsoft and Mozilla products.

.green { background: #7f7; } .yellow { background: #ff7; } .red { background: #f77; } table { border-collapse: collapse; } th, td { font-size: 80%; border: 1px solid black; text-align: center; padding: .5em; }
Feature Rationale Apple Google Microsoft Mozilla
Pre-installed math fonts Make mathematical rendering possible with the default system fonts. OSX: Obsolete STIX
iOS: no
Android: no
Chrome OS: no
Windows: Cambria Math
Windows phone: no?
Firefox OS: no
MATH table allowed in Web fonts Workaround the lack of pre-installed math fonts or let authors provide custom math style. WebKit: yes (no font sanitizer?) Blink: yes (OTS) Trident: yes (no font sanitizer?) Gecko: yes (OTS)
USE_TYPO_METRICS OS/2 fsSelection flag taken into account Math fonts contain tall glyphs (e.g. integrals in display style) and so using the "typo" metrics avoids excessive line spacing for the math text. WebKit: no Blink: yes Trident: yes Gecko: yes (gfx/)
Open Font Format Features Good mathematical rendering requires some glyph substitutions (e.g. ssty, flac and dtls). WebKit: yes Blink: yes Trident: yes Gecko: yes
Ability to parse the MATH table Good mathematical rendering requires many font data. WebKit: yes (WebCore/platform/graphics/) Blink: no Trident: yes (LineServices) Gecko (gfx/)
Using the MATH table for native MathML rendering The MathML specification does not provide detailed rules for mathematical rendering. WebKit: for operator stretching (WebCore/rendering/mathml/) Blink: no Trident: no Gecko: yes (layout/mathml/)
Total Score: 4/6 3/6 4.5/6 5/6

update: Daniel Cater provided a list of pre-installed fonts on Chrome OS stable, confirming that no fonts with a MATH table are available.

## Learn about MathML at Lavacon

Source: Design Science News • Lary Stucker • October 15, 2015 • Permalink

Design Science will be exhibiting and presenting at the LavaCon Conference in New Orleans October 18-21. If you want to learn the proper way to implement math with your content, this is a great opportunity to meet with the experts.

Plan to see Design Science's Aaron Guigar present the session Making the Most of the New Math Domains in DITA 1.3, on October 20th at 9:15am. In this session we will talk about what MathML is and the advantages of using it, its role in DITA 1.3, and the available tools for authoring, display and accessibility of MathML. If you cannot make the conference, there will be video of the presentation on the LavaCon website after the conference.

If you or any of your colleagues back at the office are working with any math content at all, stop by the exhibit area to find out about MathFlow. We would be happy to answer your specific questions and try to help with your project.

We hope to see you in New Orleans!

Topics in this post:

## Learn about MathML at Lavacon | Design Science News

Source: mathml - Google Blog Search • Lary Stucker • October 15, 2015 • Permalink

Learn about MathML at Lavacon. Design Science will be exhibiting and presenting at the LavaCon Conference in New Orleans October 18-21. If you want to learn the proper way to implement math with your content, this is a ...

## 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: 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/11/26 00:31:51$

[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 [itex] 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:
forking the original webcomponents.js project.
It contains a working example of this concept. Below the content of the

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.



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


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