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

## Last Call for Papers: Workshop on User Interfaces for Theorem Provers (UITP 2016 @ IJCAR), Coimbra, Portugal, Deadline May 17th *NEW* (was May 9th, 2016)

Source: www-math@w3.org Mail Archives • Serge Autexier (serge.autexier@dfki.de) • May 04, 2016 • Permalink

                         Last Call for Papers

UITP 2016
12th International Workshop on User Interfaces for Theorem Provers
in connection with IJCAR 2016
July 2nd, 2016, Coimbra, Portugal
http://www.informatik.uni-bremen.de/uitp/current/

* NEW Submission deadline: May 17th, 2016 *

----------------------------------------------------------------------
NEWS:
- Invited Speaker: Sylvain Conchon (LRI, France) giving a talk about
"AltGr-Ergo, a graphical user interface for the SMT solver Alt-Ergo"
- Submission deadline postponed by one week to May, 17th, 2016
----------------------------------------------------------------------

The  User  Interfaces  for  Theorem  Provers  workshop  series  brings
together   researchers  interested   in   designing,  developing   and
evaluating interfaces  for interactive proof systems,  such as theorem
provers,  formal  method  tools,  and  other  tools  manipulating  and
presenting mathematical formulas.

While  the reasoning  capabilities of  interactive proof  systems have
increased dramatically over the last years, the system interfaces have
often  not   enjoyed  the   same  attention   as  the   proof  engines
themselves.  In many  cases,  interfaces remain  relatively basic  and
under-designed.

The User  Interfaces for  Theorem Provers  workshop series  provides a
forum for  researchers interested in improving  human interaction with
proof  systems. We  welcome participation  and contributions  from the
theorem proving, formal  methods and tools, and  HCI communities, both
to  report on  experience with  existing systems,  and to  discuss new
directions. Topics covered include, but are not limited to:

- Application-specific  interaction mechanisms  or designs  for prover
interfaces Experiments and evaluation of prover interfaces
- Languages and tools for authoring, exchanging and presenting proof
- Implementation  techniques (e.g.  web  services, custom  middleware,
DSLs)
- Integration of interfaces and tools to explore and construct proof
- Representation and manipulation of mathematical knowledge or objects
- Visualisation of mathematical objects and proof
- System descriptions

UITP 2016 is a one-day workshop to be held on Saturday, July 2nd, 2016
in Coimbra, Portugal, as a IJCAR 2016 workshop.

** Submissions **

Submitted   papers  should   describe   previously  unpublished   work
(completed or  in progress), and  be at least 4  pages and at  most 12
pages. We encourage concise and relevant papers. Submissions should be
in PDF format, and typeset with  the EPTCS LaTeX document class (which
done via EasyChair at

https://www.easychair.org/conferences/?conf=uitp16

All papers will be peer reviewed by members of the programme committee
and selected by the organizers in accordance with the referee
reports.

At  least one  author/presenter  of accepted  papers  must attend  the
workshop and present their work.

** Proceedings **

Authors will have the opportunity to incorporate feedback and insights
gathered during the  workshop to improve their  accepted papers before
publication  in the  Electronic  Proceedings  in Theoretical  Computer
Science (EPTCS - http://www.eptcs.org/).

** Important dates **

Workshop: July 2nd, 2016

** Programme Committee **

Serge Autexier, DFKI Bremen, Germany (Co-Chair)
Pedro Quaresma, U Coimbra, Portugal (Co-Chair)
David Aspinall, University of Edinburgh, Scotland
Chris Benzmüller, FU Berlin, Germany & Stanford, USA
Yves Bertot, INRIA Sophia-Antipolis, France
Gudmund Grov, Heriott-Watt University, Scotland
Zoltán Kovács, RISC, Austria
Christoph Lüth, University of Bremen and DFKI Bremen, Germany
Alexander Lyaletski, Kiev National Taras Shevchenko Univ., Ukraine
Michael Norrish, NICTA, Australia
Christian Sternagel, University Innsbruck, Austria
Enrico Tassi, INRIA Sophia-Antipolis, France
Laurent Théry, INRIA Sophia-Antipolis, France
Makarius Wenzel, Sketis, Germany
Wolfgang Windsteiger, RISC Linz, Austria
Bruno Woltzenlogel Paleo, TU Vienna, Austria


## FMath "HTML + MathML" for Chrome Solution

Source: FMath • Ionel Alexandru (noreply@blogger.com) • April 29, 2016 • Permalink

Hi,

I have created an extension for Google Chrome to display MathML inside HTML.

The solution is ONLY javascript.

Search for "MathML" keyword.

After you install the extension you can test by going on this page
http://www.fmath.info/plugins/chrome/test.html

The page is built using HTML and MathML. No other tricks.

enjoy
ionel alexandru

P.S. Let me know on www.fmath.info if you find bugs or you need more features.

## Math Accessibility Trees

Source: Murray Sargent: Math in Office • MurrayS3 • April 28, 2016 • Permalink

This post discusses some aspects of making mathematical equations accessible to blind people. Presumably equations that are simple typographically, such as E = mc², are accessible with the use of standard left and right arrow key navigation and with each variable and two-dimensional construct being spoken when the insertion point is moved to them. At any particular insertion point, the user can edit the equation using the regular input methods, perhaps based on the linear format and Nemeth Braille or Unified English Braille keyboards. But it can be hard to follow a more typographically complex equation, let alone edit it. Instead, the user needs to be able to navigate such an equation using a mathematical tree of the equation.

More than one kind of tree is possible and this post compares two possible kinds using the equation

We label each tree node with its math text in the linear format along with the type of node. The linear format lends itself to being spoken especially if processed a bit to say things like “a^2” as “a squared” in the current natural language. The first kind of tree corresponds to the traditional math layout used in documents, while the second kind corresponds to the mathematical semantics. Accordingly we call the first kind a display tree and the second a semantic tree.

More specifically, the first kind of tree represents the way TeX and Microsoft Office applications display mathematical text. Mathematical layout entities such as fractions, integrals, roots, subscripts and superscripts are represented by nodes in trees. But binary and relational operators that don’t require special typography other than appropriate spacing are included in text nodes. The display tree for the equation above is

Note that the invisible times between the leading fraction and the integral isn’t displayed and the expression a+b sinθ is displayed as a text node a+b followed by a function-apply node sinθ, without explicit nodes for the + and the invisible times.

To navigate through the a+b and into the fractions and integral, one can use the usual text left and right arrows or their braille equivalents. One can navigate through the whole equation with these arrow keys, but it’s helpful also to have tree navigation keys to go between sibling nodes and up to parent nodes. For the sake of discussion, let’s suppose the tree navigation hot keys are those defined in the table

 Ctrl+→ Go to next sibling Ctrl+← Go to previous sibling Home Go to parent position ahead of current child End Go to parent position after current child

For example starting at the beginning of the equation, Ctrl+→ moves past the leading fraction to the integral, whereas → moves into the numerator of the leading fraction. Starting at the beginning of the upper limit, Home goes to the insertion point between the leading fraction and the integral, while End goes to the insertion point in front of the equal sign. Ctrl+→ and Ctrl+← allow a user to scan an equation rapidly at any level in the hierarchy. After one of these hot keys is pressed, the linear format for the object at the new position can be spoken in a fashion quite similar to ClearSpeak. When the user finds a position of interest, s/he can use the usual input methods to delete and/or insert new math text.

Now consider the semantic tree, which allocates nodes to all binary and relational operators as well as to fractions, integrals, etc.

The semantic tree has two drawbacks: 1) it’s bigger and requires more key strokes to navigate and 2) it requires a Polish-prefix mentality. Some people have such a mentality, perhaps having used HP calculators, and prefer it. But it’s definitely an acquired taste and it doesn’t correspond to the way that mathematics is conventionally displayed and edited. Accordingly the display tree seems significantly better for blind reading and editing, as well as for sighted editing.

Both kinds of trees include nodes defined by the OMML entities listed in the following table along with the corresponding MathML entities

 Built-up Office Math Object OMML tag MathMl Accent acc mover/munder Bar bar mover/munder Box box menclose (approx) BoxedFormula borderBox menclose Delimiters d mfenced EquationArray eqArr mtable (with alignment groups) Fraction f mfrac FunctionApply func &FunctionApply; (binary operator) LeftSubSup sPre mmultiscripts (special case of) LowerLimit limLow munder Matrix m mtable Nary nary mrow followed by n-ary mo Phantom phant mphantom and/or mpadded Radical rad msqrt/mroot GroupChar groupChr mover/munder Subscript sSub msub SubSup sSubSup msubsup Superscript sSup msup UpperLimit limUpp mover Ordinary text r mrow

MathML has additional nodes, some of which involve infix parsing to recognize, e.g., integrals. The OMML entities were defined for typographic reasons since they require special display handling. Interestingly the OMML entities also include useful semantics, such as identifying integrals and trigonometric functions without special parsing.

In summary, math zones can be made accessible using display trees for which the node contents are spoken using in the localized linear format and navigation is accomplished using simple arrow keys, Ctrl arrow keys, and the Home and End keys, or their Braille equivalents. Arriving at any particular insertion point, the user can hear or feel the math text and can edit the text in standard ways.

I’m indebted to many colleagues who helped me understand various accessibility issues and I benefitted a lot from attending the Benetech Math Code Sprint.

## call for abstracts: Using sets of mathematical tools @ CADGME 2016

Source: www-math@w3.org Mail Archives • Paul Libbrecht (paul@hoplahup.net) • April 25, 2016 • Permalink


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

Using Sets of Mathematical Tools

7--10 September 2016, Targu Mures, Romania

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

Mathematical softwares are diverse and rich. Each software can perform
some tasks very well and others only with big efforts.

This session aims at exploring the possibility to teach mathematics and
mathematical tools when using them /together/: How can one use the
systems productively, keeping the best of each software's functionality
when teaching and using?

We invite contributions about the exchange between computing systems
such as the following:

* user reports (expectations, obtained results)
* teaching directions when working with several systems
* scenarios of teaching of exchanges that can be effective for the
education
* standards and their applicability in the exchanges
* technical tools that can facilitate the exchanges

There is just a week left till the end of the submission period for the
abstracts and posters at the CADGME conference (May 2nd).

* abstracts of a presentation are max 300 words big sketch the
intended presentation to be done at the conference
* posters will be presented in an expo environment so as to introduce
discussion



## Re: Change URL of sume translations about MathML

Source: www-math@w3.org Mail Archives • Xueyuan Jia (xueyuan@w3.org) • April 21, 2016 • Permalink



On 2016/4/16 20:38, 高村 吉一 wrote:
> Dear Translators
> And Dear W3C Math mailing list Members
>
> I change URL of sume translations  about MathML into Japanese of the following document:
>
> (1) MathML for CSS Profile(http://www.w3.org/TR/2011/REC-mathml-for-css-20110607/)
>  CSSに対応するMathMLの概要書(http://takamu.sakura.ne.jp/mathml-for-css-ja.html)
>  Previous URL http://www3.fctv.ne.jp/~takamu/mathml-for-css-ja.html
>
> (2) XML Entity Definitions for Characters(http://www.w3.org/TR/2010/REC-xml-entity-names-20100401/)
>  文字に対するXML実体の定義(http://takamu.sakura.ne.jp/xml-entity-names-ja/index.html)
>  Previous URL http://www3.fctv.ne.jp/~takamu/xml-entity-names-ja/index.html
Dear Yoshikazu,

Thanks for your information and now they are updated in the translation
database:

Cf.
<https://www.w3.org/2005/11/Translations/Query?rec=any&lang=ja&translator=Yoshikazu_Takamura&date=any&sorting=byTechnology&output=FullHTML&submit=Submit>

> (3) Units in MathML(https://www.w3.org/TR/2003/NOTE-mathml-units-20031110/)
>  MathMLにおける単位(http://takamu.sakura.ne.jp/mathml-units-ja.htm)
>  Previous URL http://www3.fctv.ne.jp/~takamu/mathml-units-ja.htm

Please note that, as of 2012, only translations of W3C Recommendations
will be added to the Translations Database. So the Group Note
translation will not be included in the DB according to the announcement:

https://lists.w3.org/Archives/Public/w3c-translators/2012JulSep/0038.html

Many thanks and all of your translations are much appreciated.

Best,
Xueyuan
> Sincerely
>
> 16.Apr.2016
>
> 高村 吉一(Yoshikazu Takamura)
>


## The Community Group ‘Getting math on Web pages’ launched

Source: W3C Math Home • April 19, 2016 • Permalink

The Community Group ‘Getting math on Web pages’ launched

## OpenType MATH in HarfBuzz

Source: Blog de Frédéric - Tag - mathml • fredw • April 16, 2016 • Permalink

TL;DR:

• Work is in progress to add OpenType MATH support in HarfBuzz and will be instrumental for many math rendering engines relying on that library, including browsers.

• For stretchy operators, an efficient way to determine the required number of glyphs and their overlaps has been implemented and is described here.

In the context of Igalia browser team effort to implement MathML support using TeX rules and OpenType features, I have started implementation of OpenType MATH support in HarfBuzz. This table from the OpenType standard is made of three subtables:

• The MathConstants table, which contains layout constants. For example, the thickness of the fraction bar of ab\frac{a}{b}.

• The MathGlyphInfo table, which contains glyph properties. For instance, the italic correction indicating how slanted an integral is e.g. to properly place the subscript in ∫D\displaystyle\displaystyle\int_{D}.

• The MathVariants table, which provides larger size variants for a base glyph or data to build a glyph assembly. For example, either a larger parenthesis or a assembly of U+239B, U+239C, U+239D to write something like:

 (abcdefgh\left(\frac{\frac{\frac{a}{b}}{\frac{c}{d}}}{\frac{\frac{e}{f}}{\frac{g}{h}}}\right.

Code to parse this table was added to Gecko and WebKit two years ago. The existing code to build glyph assembly in these Web engines was adapted to use the MathVariants data instead of only private tables. However, as we will see below the MathVariants data to build glyph assembly is more general, with arbitrary number of glyphs or with additional constraints on glyph overlaps. Also there are various fallback mechanisms for old fonts and other bugs that I think we could get rid of when we move to OpenType MATH fonts only.

In order to add MathML support in Blink, it is very easy to import the OpenType MATH parsing code from WebKit. However, after discussions with some Google developers, it seems that the best option is to directly add support for this table in HarfBuzz. Since this library is used by Gecko, by WebKit (at least the GTK port) and by many other applications such as Servo, XeTeX or LibreOffice it make senses to share the implementation to improve math rendering everywhere.

The idea for HarfBuzz is to add an API to

1. 1.

Expose data from the MathConstants and MathGlyphInfo.

2. 2.

Shape stretchy operators to some target size with the help of the MathVariants.

It is then up to a higher-level math rendering engine (e.g. TeX or MathML rendering engines) to beautifully display mathematical formulas using this API. The design choice for exposing MathConstants and MathGlyphInfo is almost obvious from the reading of the MATH table specification. The choice for the shaping API is a bit more complex and discussions is still in progress. For example because we want to accept stretching after glyph-level mirroring (e.g. to draw RTL clockwise integrals) we should accept any glyph and not just an input Unicode strings as it is the case for other HarfBuzz shaping functions. This shaping also depends on a stretching direction (horizontal/vertical) or on a target size (and Gecko even currently has various ways to approximate that target size). Finally, we should also have a way to expose italic correction for a glyph assembly or to approximate preferred width for Web rendering engines.

As I mentioned at the beginning, the data and algorithm to build glyph assembly is the most complex part of the OpenType MATH and deserves a special interest. The idea is that you have a list of n≥1n\geq 1 glyphs available to build the assembly. For each 0≤i≤n-10\leq i\leq n-1, the glyph gig_{i} has advance aia_{i} in the stretch direction. Each gig_{i} has straight connector part at its start (of length sis_{i}) and at its end (of length eie_{i}) so that we can align the glyphs on the stretch axis and glue them together. Also, some of the glyphs are “extenders” which means that they can be repeated 0, 1 or more times to make the assembly as large as possible. Finally, the end/start connectors of consecutive glyphs must overlap by at least a fixed value omino_{\mathrm{min}} to avoid gaps at some resolutions but of course without exceeding the length of the corresponding connectors. This gives some flexibility to adjust the size of the assembly and get closer to the target size tt.

gig_{i}

sis_{i}

eie_{i}

aia_{i}

gi+1g_{i+1}

si+1s_{i+1}

ei+1e_{i+1}

ai+1a_{i+1}

oi,i+1o_{i,i+1}

Figure 0.1: Two adjacent glyphs in an assembly

To ensure that the width/height is distributed equally and the symmetry of the shape is preserved, the MATH table specification suggests the following iterative algorithm to determine the number of extenders and the connector overlaps to reach a minimal target size tt:

1. 1.

Assemble all parts by overlapping connectors by maximum amount, and removing all extenders. This gives the smallest possible result.

2. 2.

Determine how much extra width/height can be distributed into all connections between neighboring parts. If that is enough to achieve the size goal, extend each connection equally by changing overlaps of connectors to finish the job.

3. 3.

If all connections have been extended to minimum overlap and further growth is needed, add one of each extender, and repeat the process from the first step.

We note that at each step, each extender is repeated the same number of times r≥0r\geq 0. So if IExtI_{\mathrm{Ext}} (respectively INonExtI_{\mathrm{NonExt}}) is the set of indices 0≤i≤n-10\leq i\leq n-1 such that gig_{i} is an extender (respectively is not an extender) we have ri=rr_{i}=r (respectively ri=1r_{i}=1). The size we can reach at step rr is at most the one obtained with the minimal connector overlap omino_{\mathrm{min}} that is

 ∑i=0N-1(∑j=1riai-omin)+omin=(∑i∈INonExtai-omin)+(∑i∈IExtr⁢(ai-omin))+omin\sum_{i=0}^{N-1}\left(\sum_{j=1}^{r_{i}}{a_{i}-o_{\mathrm{min}}}\right)+o_{% \mathrm{min}}=\left(\sum_{i\in I_{\mathrm{NonExt}}}{a_{i}-o_{\mathrm{min}}}% \right)+\left(\sum_{i\in I_{\mathrm{Ext}}}r{(a_{i}-o_{\mathrm{min}})}\right)+o% _{\mathrm{min}}

We let NExt=|IExt|N_{\mathrm{Ext}}={|I_{\mathrm{Ext}}|} and NNonExt=|INonExt|N_{\mathrm{NonExt}}={|I_{\mathrm{NonExt}}|} be the number of extenders and non-extenders. We also let SExt=∑i∈IExtaiS_{\mathrm{Ext}}=\sum_{i\in I_{\mathrm{Ext}}}a_{i} and SNonExt=∑i∈INonExtaiS_{\mathrm{NonExt}}=\sum_{i\in I_{\mathrm{NonExt}}}a_{i} be the sum of advances for extenders and non-extenders. If we want the advance of the glyph assembly to reach the minimal size tt then

 SNonExt-omin⁢(NNonExt-1)+r⁢(SExt-omin⁢NExt)≥t{S_{\mathrm{NonExt}}-o_{\mathrm{min}}\left(N_{\mathrm{NonExt}}-1\right)}+{r% \left(S_{\mathrm{Ext}}-o_{\mathrm{min}}N_{\mathrm{Ext}}\right)}\geq t

We can assume 0" class="ltx_Math" display="inline" id="p12.m1">SExt-omin⁢NExt>0S_{\mathrm{Ext}}-o_{\mathrm{min}}N_{\mathrm{Ext}}>0 or otherwise we would have the extreme case where the overlap takes at least the full advance of each extender. Then we obtain

 r≥rmin=max⁡(0,⌈t-SNonExt+omin⁢(NNonExt-1)SExt-omin⁢NExt⌉)r\geq r_{\mathrm{min}}=\max\left(0,\left\lceil\frac{t-{S_{\mathrm{NonExt}}+o_{% \mathrm{min}}\left(N_{\mathrm{NonExt}}-1\right)}}{S_{\mathrm{Ext}}-o_{\mathrm{% min}}N_{\mathrm{Ext}}}\right\rceil\right)

This provides a first simplification of the algorithm sketched in the MATH table specification: Directly start iteration at step rminr_{\mathrm{min}}. Note that at each step we start at possibly different maximum overlaps and decrease all of them by a same value. It is not clear what to do when one of the overlap reaches omino_{\mathrm{min}} while others can still be decreased. However, the sketched algorithm says all the connectors should reach minimum overlap before the next increment of rr, which means the target size will indeed be reached at step rminr_{\mathrm{min}}.

One possible interpretation is to stop overlap decreasing for the adjacent connectors that reached minimum overlap and to continue uniform decreasing for the others until all the connectors reach minimum overlap. In that case we may lose equal distribution or symmetry. In practice, this should probably not matter much. So we propose instead the dual option which should behave more or less the same in most cases: Start with all overlaps set to omino_{\mathrm{min}} and increase them evenly to reach a same value oo. By the same reasoning as above we want the inequality

 SNonExt-o⁢(NNonExt-1)+rmin⁢(SExt-o⁢NExt)≥t{S_{\mathrm{NonExt}}-o\left(N_{\mathrm{NonExt}}-1\right)}+{r_{\mathrm{min}}% \left(S_{\mathrm{Ext}}-oN_{\mathrm{Ext}}\right)}\geq t

which can be rewritten

 SNonExt+rmin⁢SExt-o⁢(NNonExt+rmin⁢NExt-1)≥tS_{\mathrm{NonExt}}+r_{\mathrm{min}}S_{\mathrm{Ext}}-{o\left(N_{\mathrm{NonExt% }}+{r_{\mathrm{min}}N_{\mathrm{Ext}}}-1\right)}\geq t

We note that N=NNonExt+rmin⁢NExtN=N_{\mathrm{NonExt}}+{r_{\mathrm{min}}N_{\mathrm{Ext}}} is just the exact number of glyphs used in the assembly. If there is only a single glyph, then the overlap value is irrelevant so we can assume NNonExt+r⁢NExt-1=N-1≥1N_{\mathrm{NonExt}}+{rN_{\mathrm{Ext}}}-1=N-1\geq 1. This provides the greatest theorical value for the overlap oo:

 omin≤o≤omaxtheorical=SNonExt+rmin⁢SExt-tNNonExt+rmin⁢NExt-1o_{\mathrm{min}}\leq o\leq o_{\mathrm{max}}^{\mathrm{theorical}}=\frac{S_{% \mathrm{NonExt}}+r_{\mathrm{min}}S_{\mathrm{Ext}}-t}{N_{\mathrm{NonExt}}+{r_{% \mathrm{min}}N_{\mathrm{Ext}}}-1}

Of course, we also have to take into account the limit imposed by the start and end connector lengths. So omaxo_{\mathrm{max}} must also be at most min⁡(ei,si+1)\min{(e_{i},s_{i+1})} for 0≤i≤n-20\leq i\leq n-2. But if rmin≥2r_{\mathrm{min}}\geq 2 then extender copies are connected and so omaxo_{\mathrm{max}} must also be at most min⁡(ei,si)\min{(e_{i},s_{i})} for i∈IExti\in I_{\mathrm{Ext}}. To summarize, omaxo_{\mathrm{max}} is the minimum of omaxtheoricalo_{\mathrm{max}}^{\mathrm{theorical}}, of eie_{i} for 0≤i≤n-20\leq i\leq n-2, of sis_{i} 1≤i≤n-11\leq i\leq n-1 and possibly of e0e_{0} (if 0∈IExt0\in I_{\mathrm{Ext}}) and of of sn-1s_{n-1} (if n-1∈IExt{n-1}\in I_{\mathrm{Ext}}).

With the algorithm described above NExtN_{\mathrm{Ext}}, NNonExtN_{\mathrm{NonExt}}, SExtS_{\mathrm{Ext}}, SNonExtS_{\mathrm{NonExt}} and rminr_{\mathrm{min}} and omaxo_{\mathrm{max}} can all be obtained using simple loops on the glyphs gig_{i} and so the complexity is O⁢(n)O(n). In practice nn is small: For existing fonts, assemblies are made of at most three non-extenders and two extenders that is n≤5n\leq 5 (incidentally, Gecko and WebKit do not currently support larger values of nn). This means that all the operations described above can be considered to have constant complexity. This is much better than a naive implementation of the iterative algorithm sketched in the OpenType MATH table specification which seems to require at worst

 ∑r=0rmin-1NNonExt+r⁢NExt=NNonExt⁢rmin+rmin⁢(rmin-1)2⁢NExt=O⁢(n×rmin2)\sum_{r=0}^{r_{\mathrm{min}}-1}{N_{\mathrm{NonExt}}+rN_{\mathrm{Ext}}}=N_{% \mathrm{NonExt}}r_{\mathrm{min}}+\frac{r_{\mathrm{min}}\left(r_{\mathrm{min}}-% 1\right)}{2}N_{\mathrm{Ext}}={O(n\times r_{\mathrm{min}}^{2})}

and at least Ω⁢(rmin)\Omega(r_{\mathrm{min}}).

One of issue is that the number of extender repetitions rminr_{\mathrm{min}} and the number of glyphs in the assembly NN can become arbitrary large since the target size tt can take large values e.g. if one writes \underbrace{\hspace{65535em}} in LaTeX. The improvement proposed here does not solve that issue since setting the coordinates of each glyph in the assembly and painting them require Θ⁢(N)\Theta(N) operations as well as (in the case of HarfBuzz) a glyph buffer of size NN. However, such large stretchy operators do not happen in real-life mathematical formulas. Hence to avoid possible hangs in Web engines a solution is to impose a maximum limit NmaxN_{\mathrm{max}} for the number of glyph in the assembly so that the complexity is limited by the size of the DOM tree. Currently, the proposal for HarfBuzz is Nmax=128N_{\mathrm{max}}=128. This means that if each assembly glyph is 1em large you won’t be able to draw stretchy operators of size more than 128em, which sounds a quite reasonable bound. With the above proposal, rminr_{\mathrm{min}} and so NN can be determined very quickly and the cases N≥NmaxN\geq N_{\mathrm{max}} rejected, so that we avoid losing time with such edge cases…

Finally, because in our proposal we use the same overlap oo everywhere an alternative for HarfBuzz would be to set the output buffer size to nn (i.e. ignore r-1r-1 copies of each extender and only keep the first one). This will leave gaps that the client can fix by repeating extenders as long as oo is also provided. Then HarfBuzz math shaping can be done with a complexity in time and space of just O⁢(n)O(n) and it will be up to the client to optimize or limit the painting of extenders for large values of NN…

## Change URL of sume translations about MathML

Source: www-math@w3.org Mail Archives • 高村 吉一 (soco__kankyo@hotmail.com) • April 16, 2016 • Permalink

Dear Translators
And Dear W3C Math mailing list Members

I change URL of sume translations  about MathML into Japanese of the following document:

(1) MathML for CSS Profile(http://www.w3.org/TR/2011/REC-mathml-for-css-20110607/)
CSSに対応するMathMLの概要書(http://takamu.sakura.ne.jp/mathml-for-css-ja.html)
Previous URL http://www3.fctv.ne.jp/~takamu/mathml-for-css-ja.html

(2) XML Entity Definitions for Characters(http://www.w3.org/TR/2010/REC-xml-entity-names-20100401/)
文字に対するXML実体の定義(http://takamu.sakura.ne.jp/xml-entity-names-ja/index.html)
Previous URL http://www3.fctv.ne.jp/~takamu/xml-entity-names-ja/index.html

(3) Units in MathML(https://www.w3.org/TR/2003/NOTE-mathml-units-20031110/)
MathMLにおける単位(http://takamu.sakura.ne.jp/mathml-units-ja.htm)
Previous URL http://www3.fctv.ne.jp/~takamu/mathml-units-ja.htm

Sincerely

16.Apr.2016



## Announcing MathUI 2016 - the Mathematical User Interfaces Workshop

Source: www-math@w3.org Mail Archives • Paul Libbrecht (paul@hoplahup.net) • April 12, 2016 • Permalink


Call for Papers: MathUI'16

http://www.cicm-conference.org/2016/cicm.php?event=mathui

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

10^th Mathematical User Interfaces Workshop 2016

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

at the Conference on Intelligent Computer Mathematics

Bialystok, Poland

on Monday 25^th of July 2016

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

SCOPE

MathUI is an international workshop to discuss how users can be best
supported when doing/learning/searching for/interacting with mathematics
using a computer.

* Is mathematical user interface design a design for representing
mathematics, embedding mathematical context, or a specific design
for mathematicians?
* How is mathematics for which purpose best represented?
* What specifically math-oriented support is needed?
* Does learning of math require a platform different than other
learning platforms?
* Which mathematical services can be offered?
* Which services can be meaningfully combined?
* What best practices wrt. mathematics can be found and how can they
be best communicated?

We invite all questions, that care for the use of mathematics on
computers and how the user experience can be improved, to be discussed
in the workshop.

TOPICS include

* user-requirements for math interfaces
* presentation formats for mathematical content
* mobile-devices powered mathematics
* cultural differences in practices of mathematical languages
* didactically sensible mathematical scenarios of use
* manipulations of mathematical expressions

This workshop follows a successful series of workshops held at the
Conferences on Intelligent Computer Mathematics since 11 years;
it features presentations of brand new ideas in papers selected by a
thorough review process, wide space for discussions,as well as a
software demonstration session.

SUBMISSIONS

The organizers invite authors to submit contributions of 6 to 12 pages
on the workshop-related topics in PDF format optionally illustrated by

DEADLINE for submissions: May 30^th 2015.

https://easychair.org/conferences/?conf=mathui16.

The submissions will be reviewed by the international programme
committee whose comments and recommendations will be
sent back by June 19^th requesting a final version no later than July 2^nd .

Moreover, MathUI will be concluded by an exhibit-like demonstration
session. Proposed demonstrations should be sent by email until June
20th, containing a URL to a software description, a title, a short
abstract of the demonstrated features, and the indication of hardware
expectations (own/lent laptop/tablet, internet access (speed?), power,
...). After a short elevator pitch, the demonstration session will run
for 1-3h, each demonstrating to interested parties.

REVIEW COMMITTEE

(to be confirmed)

* Finland
o Olga Caprotti, University of Helsinki
* France
o Jana Trgalova, Universite Claude Bernard Lyon 1
* Germany
o Andrea Kohlhase (organizer), Neu-Ulm University of Applied Sciences
o Peter Krautzberger, krautzource UG, Bonn
o Paul Libbrecht (organizer), University of Education of Weingarten
* Great Britain
o Chris Rowley
* Netherlands
o Jan Willem Knopper, Technische Universiteit Eindhoven
* Spain
o Daniel Marquès, wiris, Barcelona
* USA
o Deyan Ginev, Authorea, New York
o Elena Smirnova, Texas Instruments Inc. Education Technology

* Paul Libbrecht, paul@cermat.org or
* Andrea Kohlhase, Andrea.Kohlhase@hs-neu-ulm.de


## Re: MathML is a failed web standard (or not?)

Source: www-math@w3.org Mail Archives • William F Hammond (hammond@csc.albany.edu) • April 11, 2016 • Permalink

Going back to April 1, Andrew Robbins writes in part:

> In my humble opinion, the reason why MathML has failed
> isn't because of Content MathML, it's because of
> Presentation MathML, and it's not because it isn't
> accurate, or because it doesn't look good, it's because
> people prefer TeX over angle brackets. MathJax provides
> people the ability to show the same beautiful math
> expressions on web pages, that Presentation MathML
> promised but with many fewer keystrokes.

I believe that almost all extant MathML content that I've
seen originates, one way or another, with LaTeX or
LaTeX-like markup.

> superscripts. The only thing that interests me with
> regards to Content MathML, is the fact that it is, at a
> fundamental level, a LISP where symbols are selected from
> URI/RDF/XML/MathML namespaces.  . . .

I think it's rather difficult to generate reliably useful
content MathML from LaTeX markup as commonly seen, for
example, at arXiv.  On the other hand, I believe that adding
a LaTeX package for type declaration of mathematical symbols
would go a long way toward improving this.  Even better
would be the use of a suitable LaTeX profile (such as I
spoke about at TUG 2010 and TUG 2014) with provision for
symbol type declarations.

> . . .  As I said earlier, I agree that Presentation MathML
> has failed, but that's because it's a failed viewpoint.
> Math isn't symbols, it's semantics. From the beginning,
> MathML should have been about Content, not Presentation. I
> think if we had focused on Content all along, then we
> probably wouldn't be having this conversation now.

>From the beginning the development of MathML has had two
tracks with content MathML focused on content interchange
and presentation MathML designed for minimizing the amount
of work required for a web browser to provide a TeX-quality
rendering of mathematical content from an extension of HTML
markup.

I disagree with the assertion that presentation MathML has
failed as a web standard.  It works quite well in Firefox
and other Gecko browsers, and one should not forget W3C's
Amaya.  It is, of course, disappointing that, for the moment
and for most of the time since the beginning of MathML in
the late 1990s, three of the "big four" browsers have not

It's a failing in the market based on crass market thinking.

It was also disappointing that for the period from 2001 (if
not 1995 with the dropping of HTML v 3.0) to 2011 the W3C
banned any form of math content from the media type
"text/html".

Of course, there would be breakage of existing content if
web browsers that now render MathML ceased to do so.

It continues to be disappointing that search engines do not
cover mathematical content well.

The disappointments are not failures, but rather the
result of a world where a relatively small number of
individuals have any interest in mathematics.

Still, native browser rendering of MathML could happen.
Didn't Murray Sargent just say so?  There is no reason
to stop wishing for it.

-- Bill


## Re: should MathML dictate a specific graphical rendering

Source: www-math@w3.org Mail Archives • Bruce Miller (bruce.miller@nist.gov) • April 09, 2016 • Permalink

On 04/09/2016 02:42 PM, William F Hammond wrote:
> Murray Sargent writes in part:
>
>> It's good to have this discussion. Clearly Presentation
>> MathML is used a lot for interchanging math zones between
>> programs. Also I haven't given up on the idea of the
>> browsers rendering MathML well natively. If IE ever
>> succeeds, it'll likely look like TeX, since both IE and
>> Edge use LineServices. And it should be way faster than
>> Java script code.
>
> This would be good to see.

Oh, this would more than "good", it would be...
Well, let's go with the ever popular Sports Analogies:

It would be a game changer.  Moreover, knowing Murray,
I have no doubt that it'd reset the bar for math rendering
on the web.

Sigh. It's all the more frustrating in that MS has already done
the hard part (not to trivialize the integration & testing).

bruce


## Re: should MathML dictate a specific graphical rendering

Source: www-math@w3.org Mail Archives • William F Hammond (hammond@csc.albany.edu) • April 09, 2016 • Permalink

Murray Sargent writes in part:

> It's good to have this discussion. Clearly Presentation
> MathML is used a lot for interchanging math zones between
> programs. Also I haven't given up on the idea of the
> browsers rendering MathML well natively. If IE ever
> succeeds, it'll likely look like TeX, since both IE and
> Edge use LineServices. And it should be way faster than
> Java script code.

This would be good to see.

-- Bill


## RE: should MathML dictate a specific graphical rendering

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

The LineServices post<https://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/> includes a description of an incredible afternoon several of us spent with Donald Knuth back in 2004. Among many things, he demonstrated how he tweaks<https://blogs.msdn.microsoft.com/murrays/2011/04/30/two-math-typography-niceties/> his TeX documents. We did automate some of these tweaks, notably creating “cut-ins” for subscript/superscript positioning. These cut-ins are part of the OpenType math spec<https://blogs.msdn.microsoft.com/murrays/2014/04/27/opentype-math-tables/>. Knuth explained that he didn’t want to go back and change TeX due to its archival usage. Naturally non-math concepts such as revision tracking and embedded objects along with international text had to be accommodated in our implementation. This was another reason for using OMML instead of MathML as the preferred math XML; you can embed other XMLs into OMML. In principle you can do that using the MathML <semantics> element, but it’d be somewhat cumbersome. The Office layout is essentially the same as TeX’s. It’ll be interesting to see how the two compare when the STIX font is finally released with full OpenType math table support. Tyro Typeworks<http://www.tiro.com/> is handling this and it also did Cambria Math.

Murray

From: Paul Topping [mailto:pault@dessci.com]
Sent: Friday, April 8, 2016 3:03 PM
To: Murray Sargent <murrays@exchange.microsoft.com>; Daniel Kinzler <daniel@brightbyte.de>; Moritz Schubotz <schubotz@tu-berlin.de>; www-math@w3.org; Peter Krautzberger <peter.krautzberger@mathjax.org>
Cc: Wikimedia developers <wikitech-l@lists.wikimedia.org>; wikidata-tech <wikidata-tech@lists.wikimedia.org>
Subject: RE: should MathML dictate a specific graphical rendering

Murray,

I guess I forgot about Appendix G of the TeXbook. Thanks for the correction. Did you find that it defined the rendering accurately enough for your line services implementation? Since it has OpenType ‘math’ table support, does it really render exactly as TeX? I guess one could say that the two implementations render the same modulo the fonts used. Did your line services improve on TeX math rendering at all or fill in any gaps in Appendix G. Were there any concessions made to compatibility with layout of non-math text?

I am not asking these questions to argue against your point. I’m just suggesting that while a reader may regard two renderings as being equal, there may still be unavoidable, or by-design, differences due to variations in rendering technology, software environment, and other considerations.

Paul

From: Murray Sargent [mailto:murrays@exchange.microsoft.com]
Sent: Friday, April 8, 2016 2:34 PM
To: Paul Topping <pault@dessci.com<mailto:pault@dessci.com>>; Daniel Kinzler <daniel@brightbyte.de<mailto:daniel@brightbyte.de>>; Moritz Schubotz <schubotz@tu-berlin.de<mailto:schubotz@tu-berlin.de>>; www-math@w3.org<mailto:www-math@w3.org>; Peter Krautzberger <peter.krautzberger@mathjax.org<mailto:peter.krautzberger@mathjax.org>>
Cc: Wikimedia developers <wikitech-l@lists.wikimedia.org<mailto:wikitech-l@lists.wikimedia.org>>; wikidata-tech <wikidata-tech@lists.wikimedia.org<mailto:wikidata-tech@lists.wikimedia.org>>
Subject: RE: should MathML dictate a specific graphical rendering

Paul commented "TeX doesn't specify its rendering in detail either except via the code itself. In other words, the only proper rendering of TeX is that done by TeX itself."

Actually Appendix G of The TeXbook describes how TeX lays out math. The Office math layout program<https://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/> uses the algorithms therein, which is why the results look so much like TeX. The actual code is completely different from TeX’s, but the layout principles are generally the same.

It’s good to have this discussion. Clearly Presentation MathML is used a lot for interchanging math zones between programs. Also I haven’t given up on the idea of the browsers rendering MathML well natively. If IE ever succeeds, it’ll likely look like TeX, since both IE and Edge use LineServices<https://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/>. And it should be way faster than Java script code.

My main complaints about Presentation MathML are 1) lack of an explicit n-ary element (for integrals, summations, products, etc.) and 2) lack of document level math properties<https://blogs.msdn.microsoft.com/murrays/2008/10/27/default-document-math-properties/>, like default math font. Also Presentation MathML depends too much on proper use of <mrow>, which wouldn’t even be needed if the elements were all “prefix” elements like <mfrac> and <mfenced>. But infix notation can be translated to prefix notation, a good example being conversion of the linear format<http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf> to the OMML<https://blogs.msdn.microsoft.com/murrays/2006/10/06/mathml-and-ecma-math-omml/>-like internal format for LineServices. Similarly RichEdit’s MathML reader converts using the rich-text string stack<https://msdn.microsoft.com/en-us/library/windows/desktop/hh768736(v=vs.85).aspx> originally developed for the linear format.

The bottom line is that MathML isn’t perfect, but it’s a widely used standard and gets the job done. As such, it’s hardly a failure. And it’s nicely supported on the web thanks to MathJax.

Murray



## RE: should MathML dictate a specific graphical rendering

Source: www-math@w3.org Mail Archives • Paul Topping (pault@dessci.com) • April 08, 2016 • Permalink

Murray,

I guess I forgot about Appendix G of the TeXbook. Thanks for the correction. Did you find that it defined the rendering accurately enough for your line services implementation? Since it has OpenType ‘math’ table support, does it really render exactly as TeX? I guess one could say that the two implementations render the same modulo the fonts used. Did your line services improve on TeX math rendering at all or fill in any gaps in Appendix G. Were there any concessions made to compatibility with layout of non-math text?

I am not asking these questions to argue against your point. I’m just suggesting that while a reader may regard two renderings as being equal, there may still be unavoidable, or by-design, differences due to variations in rendering technology, software environment, and other considerations.

Paul

From: Murray Sargent [mailto:murrays@exchange.microsoft.com]
Sent: Friday, April 8, 2016 2:34 PM
To: Paul Topping <pault@dessci.com>; Daniel Kinzler <daniel@brightbyte.de>; Moritz Schubotz <schubotz@tu-berlin.de>; www-math@w3.org; Peter Krautzberger <peter.krautzberger@mathjax.org>
Cc: Wikimedia developers <wikitech-l@lists.wikimedia.org>; wikidata-tech <wikidata-tech@lists.wikimedia.org>
Subject: RE: should MathML dictate a specific graphical rendering

Paul commented "TeX doesn't specify its rendering in detail either except via the code itself. In other words, the only proper rendering of TeX is that done by TeX itself."

Actually Appendix G of The TeXbook describes how TeX lays out math. The Office math layout program<https://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/> uses the algorithms therein, which is why the results look so much like TeX. The actual code is completely different from TeX’s, but the layout principles are generally the same.

It’s good to have this discussion. Clearly Presentation MathML is used a lot for interchanging math zones between programs. Also I haven’t given up on the idea of the browsers rendering MathML well natively. If IE ever succeeds, it’ll likely look like TeX, since both IE and Edge use LineServices<https://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/>. And it should be way faster than Java script code.

My main complaints about Presentation MathML are 1) lack of an explicit n-ary element (for integrals, summations, products, etc.) and 2) lack of document level math properties<https://blogs.msdn.microsoft.com/murrays/2008/10/27/default-document-math-properties/>, like default math font. Also Presentation MathML depends too much on proper use of <mrow>, which wouldn’t even be needed if the elements were all “prefix” elements like <mfrac> and <mfenced>. But infix notation can be translated to prefix notation, a good example being conversion of the linear format<http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf> to the OMML<https://blogs.msdn.microsoft.com/murrays/2006/10/06/mathml-and-ecma-math-omml/>-like internal format for LineServices. Similarly RichEdit’s MathML reader converts using the rich-text string stack<https://msdn.microsoft.com/en-us/library/windows/desktop/hh768736(v=vs.85).aspx> originally developed for the linear format.

The bottom line is that MathML isn’t perfect, but it’s a widely used standard and gets the job done. As such, it’s hardly a failure. And it’s nicely supported on the web thanks to MathJax.

Murray



## RE: should MathML dictate a specific graphical rendering

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

Paul commented "TeX doesn't specify its rendering in detail either except via the code itself. In other words, the only proper rendering of TeX is that done by TeX itself."

Actually Appendix G of The TeXbook describes how TeX lays out math. The Office math layout program<https://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/> uses the algorithms therein, which is why the results look so much like TeX. The actual code is completely different from TeX’s, but the layout principles are generally the same.

It’s good to have this discussion. Clearly Presentation MathML is used a lot for interchanging math zones between programs. Also I haven’t given up on the idea of the browsers rendering MathML well natively. If IE ever succeeds, it’ll likely look like TeX, since both IE and Edge use LineServices<https://blogs.msdn.microsoft.com/murrays/2006/11/14/lineservices/>. And it should be way faster than Java script code.

My main complaints about Presentation MathML are 1) lack of an explicit n-ary element (for integrals, summations, products, etc.) and 2) lack of document level math properties<https://blogs.msdn.microsoft.com/murrays/2008/10/27/default-document-math-properties/>, like default math font. Also Presentation MathML depends too much on proper use of <mrow>, which wouldn’t even be needed if the elements were all “prefix” elements like <mfrac> and <mfenced>. But infix notation can be translated to prefix notation, a good example being conversion of the linear format<http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf> to the OMML<https://blogs.msdn.microsoft.com/murrays/2006/10/06/mathml-and-ecma-math-omml/>-like internal format for LineServices. Similarly RichEdit’s MathML reader converts using the rich-text string stack<https://msdn.microsoft.com/en-us/library/windows/desktop/hh768736(v=vs.85).aspx> originally developed for the linear format.

The bottom line is that MathML isn’t perfect, but it’s a widely used standard and gets the job done. As such, it’s hardly a failure. And it’s nicely supported on the web thanks to MathJax.

Murray



## Re: MathML is dead, long live MathML

Source: www-math@w3.org Mail Archives • Roger Martin (mathmldashx@yahoo.com) • April 08, 2016 • Permalink

Hello,  how many of us have github accounts?

On Friday, April 8, 2016 6:10 AM, Daniel Kinzler <daniel@brightbyte.de> wrote:

Am 07.04.2016 um 23:01 schrieb Paul Topping:
> I have no problem with that but are some of these lists members-only? I was
> told when I replied that my message would be reviewed by the moderator as I
> wasn't a member. Perhaps that was the W3C list.

Oh... both the Wikimedia lists are members only, I'm afraid. The W3C list
requires a 1-click agreement to their terms. That's easier, but less likely to
involve Wikimedia people.



## Re: MathML is dead, long live MathML

Source: www-math@w3.org Mail Archives • Daniel Kinzler (daniel@brightbyte.de) • April 08, 2016 • Permalink

Am 07.04.2016 um 23:01 schrieb Paul Topping:
> I have no problem with that but are some of these lists members-only? I was
> told when I replied that my message would be reviewed by the moderator as I
> wasn't a member. Perhaps that was the W3C list.

Oh... both the Wikimedia lists are members only, I'm afraid. The W3C list
requires a 1-click agreement to their terms. That's easier, but less likely to
involve Wikimedia people.


## Re: MathML is a failed web standard (or not?)

Source: www-math@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • April 08, 2016 • Permalink

Hi Peter and Andrew,

Thanks for those interesting statements. I'm not sure how they relate to
what I wrote (please let me know if I missed something) but I appreciate
having the opportunity to read them.

Regards,
Peter.

On Sat, Apr 2, 2016 at 3:42 AM, Andrew Robbins <andjrob@gmail.com> wrote:

> Dear MathML Subscribers,
>
> I must admit that I have not read every word of both posts, but I already
> know what this is about, because I have already encountered similar issues,
> with both Presentation and Content. I'm not too concerned with
> Presentation, because MathJax does an excellent job at that. What I am
> concerned with is Content (i.e. Semantics), and to quote the original
> article:
>
>     "Content MathML is just not relevant." -- Peter Krautzberger
>
> I have been writing a set of tools for trans-language compilation for
> about 5 years now, (freely available at
> https://github.com/andydude/droxtools), and the only system I've found
> that is is open, non-commercial, and easily extensible for representing
> arbitrary concepts from every programming language ever invented, is
> Content MathML. This is the opposite of "not relevant", and Paul Topping
>
> In my humble opinion, the reason why MathML has failed isn't because of
> Content MathML, it's because of Presentation MathML, and it's not because
> it isn't accurate, or because it doesn't look good, it's because people
> prefer TeX over angle brackets. MathJax provides people the ability to show
> the same beautiful math expressions on web pages, that Presentation MathML
> promised but with many fewer keystrokes.
>
> I don't care about angle brackets. I don't care about superscripts. The
> only thing that interests me with regards to Content MathML, is the fact
> that it is, at a fundamental level, a LISP where symbols are selected from
> URI/RDF/XML/MathML namespaces. Granted, OpenMath/MathML namespaces are
> naturally defined to be equivalent, but to apply to XML/QNames as well,
> then you need a QName to URI mapping. I've seen two of these, the
> "{NS}NAME" method (think Java/Ruby/Python) and the "NS::NAME" method (think
> JavaScript/E4X), the first one fails to produce a valid URI, but the second
> method does produce a valid URI, so that's what I've been using in my
> tools. The point is that URIs are already a carefully controlled resource,
> and so they are much more open than LISP's traditional filesystem based
> package system, or any other system I've seen.
>
> Just in the interest of full disclosure, there are closed, commercial
> systems out there that do trans-language compilation, like the kind I'm
> currently developing. https://www.semanticdesigns.com/ is an example of a
> corporation involved in such a business. But I whole-heartedly believe that
> the future of open-source software depends on having such tools available
> as open source tools. This is starting to sound like a rant, so I will stop
> it here.
>
> Actually, I changed my mind. I still have to have a Content vs.
> Presentation debate. As I said earlier, I agree that Presentation MathML
> has failed, but that's because it's a failed viewpoint. Math isn't symbols,
> it's semantics. From the beginning, MathML should have been about Content,
> not Presentation. I think if we had focused on Content all along, then we
> probably wouldn't be having this conversation now.
>
> Regards,
> Andrew Robbins
>
>
> On Fri, Apr 1, 2016 at 7:21 PM, Peter Murray-Rust <pm286@cam.ac.uk> wrote:
>
>> I write as a chemist who has tried to do the same thing with Chemistry
>> (CML, Chemical Markup Language). I have been inspired by what I see as the
>> success of MathML and do not regard it as a failure. I am particularly
>> interested in Content MathML as computable maths.
>>
>> The reality seems to be that it takes a generation for many of these
>> ideas to be implemented. in 1998 SVG seemed to be the obvious way of doing
>> graphics, but after 5 years it looked close to death. After 15 years it's
>> become universal.
>>
>> CML is used by a small number of enthusiasts. The chemical software
>> manufacturers don't care because they only care about the pharma industry
>> and instruments. So we strugle on with a number of ad hoc broken
>> representations of chemistry, which are still primarily graphical. There is
>> almost no chemistry for blind people.
>>
>> The real problem is semantics. At the moment the world doesn't care. They
>> will have to in the future. IoT demands semantics. You cannot compute
>> pictures. Binding semantics to maths and chemistry is hard but it will have
>> to come. I'd guess that people will need semantic math in 5 years and
>> chemistry in 15.
>>
>> If you let the world be driven by browser manufacturers and publishers
>> you will get a sighted-human vision of maths and science. The IoT won't
>> need browsers.
>>
>> It WILL need semantic maths.
>>
>>
>> On Fri, Apr 1, 2016 at 11:10 PM, Paul Topping <pault@dessci.com> wrote:
>>
>>> Hi,
>>>
>>> Peter Krautzberger of MathJax fame, recently posted this on his own blog:
>>>
>>> MathML is a failed web standard
>>> https://www.peterkrautzberger.org/0186/
>>>
>>> Obviously, he presents some challenges to the MathML standard and its
>>> community. I felt that I had to respond:
>>>
>>> Response to Peter Krautzberger's "MathML is a failed web standard"
>>> http://bit.ly/1ZLfCF8
>>>
>>> I hope this exchange prompts some serious dialog.
>>>
>>> Paul Topping
>>>
>>> Design Science, Inc.
>>> "How Science Communicates"
>>> Makers of MathType, MathFlow, MathPlayer, Equation Editor
>>> http://www.dessci.com
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Peter Murray-Rust
>> Unilever Centre, Dep. Of Chemistry
>> University of Cambridge
>> CB2 1EW, UK
>> +44-1223-763069
>>
>
>


## Re: MathML is dead, long live MathML

Source: www-math@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • April 08, 2016 • Permalink

Hi Daniel,

Could you let me know once you've decided on a venue for discussion? I'd be
happy to join in.

Peter.

On Thu, Apr 7, 2016 at 8:05 PM, Daniel Kinzler <daniel@brightbyte.de> wrote:

> Am 07.04.2016 um 20:00 schrieb Moritz Schubotz:
> > Hi Daniel,
> >
> > Ok. Let's discuss!
>
> Great! But let's keep the discussion in one place. I made a mess by
> cross-posting this to two lists, now it's three, it seems. Can we agree on
> <wikitech-l@lists.wikimedia.org> as the venue of discussion? At least for
> the
> discussion of MathML in the context of Wikimedia, that would be the best
> place,
> I think.
>
> -- daniel
>
>


## Improved FMath MathML Formula and FMath Editor - Release 2.1.2

Source: FMath • Ionel Alexandru (noreply@blogger.com) • April 08, 2016 • Permalink

Hi,

I have a new free to use version for "FMath MathML Formula" components and for "FMath MathML Editor":
• Now it is possible to tweak the way the root is dislayed for "msqrt" and "mroot" elements. I added the attribute "thickness". Also I added the attribute "sqrtthickness" in "mstyle" element.
•  30% 50% 80% 100% 120%

• For java version I have migrate the xml reader to jdom2.0 library.

• If you need help to use or if you find bugs which you want to be solved, let me know.

regards
Ionel Alexandru

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