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

- Re: [MathML4] CSS properties for MathML elements and default math font • February 22, 2019
- Re: [MathML4] Whitespace and attributes canonicalization in MathML VS HTML5/CSS • February 22, 2019
- Re: [MathML4] Removing some deprecated attributes • February 22, 2019
- Re: [MathML4] New entries in the operator dictionary for U+1EEF0 and U+1EEF1 • February 22, 2019
- Re: [MathML 4] Add rules to map from non-combining to combining accents • February 22, 2019
- Re: [MathML4] thin, medium and thick values for mfrac@linethickness • February 22, 2019
- Re: [MathML4] Simplification of the mstyle element • February 22, 2019
- Re: [MathML4] Deprecation/Removal of the mfenced element • February 22, 2019
- Re: [MathML4] Removal of the menclose notation "radical" • February 22, 2019
- Re: [www-math] <none> • February 13, 2019
- [www-math] <none> • February 12, 2019
- Re: Meeting today • February 11, 2019
- Re: Meeting today • February 11, 2019
- Re: Meeting today • February 11, 2019
- Meeting today • February 11, 2019
- Re: meeting Jan 28 • January 28, 2019
- meeting Jan 28 • January 28, 2019
- MathML Refresh Community Group • January 27, 2019
- RichEdit 9 Additions • January 18, 2019
- variable fonts and stretchy characters • January 17, 2019
**[List of feeds]**

On 27/07/2016 11:31, Frédéric Wang wrote: > Hi readers of the Math WG mailing list, > > In a previous message, Murray Sargent indicated that his two main > complaints about Presentation MathML were "1) lack of an explicit n-ary > element (for integrals, summations, products, etc.) and 2) lack of > document level math properties, like default math font". However, MathML > already has a mechanism to describe such n-ary constructions based on > the mo/munderover/msubsup elements and the largeop property ; Gecko & > WebKit rely on them to use the appropriate layout constants. The second > point is more interesting (especially fonts) so let's open a discussion > here. > > As you know, stylistic properties in web engines are described using > CSS. All Web authors are familiar with this mechanism and it is a very > important feature for them. Users of web browsers can also use custom > user stylesheets to specify their preferred default style, possibly > overriding the one of page authors. However, the MathML specification > does not say much about CSS and so web engines developers have to do > their own interpretation, leading to incompatibilities between > implementations. Some parts of the discussion below may be out of the > scope of the Math WG but I think some hints should be provided in the > MathML specification anyway. > > First, CSS is much more powerful than the <mstyle> inheritance > mechanism. That latter element should probably be made compatible with > CSS or at least should reuse it as much as possible. This is discussed > in the other thread: > https://lists.w3.org/Archives/Public/www-math/2016Jul/0024.html > > The specification should probably also explain how many CSS properties > (e.g. margin, padding, border etc) should be handled for MathML. At the > moment, Gecko and WebKit essentially ignore these properties in most > cases. Anyway, the MathML specification is too vague about the exact > rendering of math elements to open this discussion so I'll postpone it > for a later thread. > > The default visibility for the mphantom element should be "hidden". > Although it can be hidden by other mechanisms, using CSS is the most > natural way to do it and this also has implications in other parts > outside the rendering module (e.g. the a11y module). > Many properties should be reset on the <math> element to avoid > unexpected things. Here is a non-exhaustive list extracted from bug reports: > > * Inheriting the following properties can cause excessive spacing of > mathematical formulas: text-indent, line-height, word-spacing, > letter-spacing. > > * In some countries and languages, text is written from right-to-left > while mathematical formulas are written from left-to-write. Hence it is > wrong to inherit the direction and we reset that property to > left-to-write on the <math> tag. Per the MathML specification, authors > should explicitly use the "dir" attribute on the <math> element if they > want to force the overall direction of the mathematical formulas. > Similarly, the writing-mode should probably be set to "horizontal-tb" by > default. > > * Some properties give poor rendering in math formulas or are confusing > with the mathvariant style. They should be reset too. This includes at > least font-style or font-weight. > > Finally, one of the most important issue is the choice of the math font. > Note that most stylistic math properties are actually included in the > font itself so it's great that authors can just use the CSS font-family > to select their preferred fonts (possibly provided as Web fonts), and > make it consistent with the rest of the page. However, to determine the > default math fonts, some mechanisms should probably be formalized and > implemented in web engines: > > 1) Text fonts are not appropriate for math layout. Hence making the > <math> element inherit the text font is a very bad idea. Ideally, web > engines should have a mechanism to try and find math fonts in the > specified CSS font-family lists and to fallback to known math fonts on > the system. > > 2) One consequence is that we are likely to get different text and math > fonts and so inconsistent font-size. Instead of making the <math> > element inherit the font-size, Web engines should probably have a > mechanism to automatically adjust the font-size. > > 3) Even with this adjustment, the style of the font faces of the text > and math fonts may be inconsistent. Many text fonts have a math > companion e.g. STIX / STIX Math, Latin Modern Roman / Latin Modern Math, > DejaVu Serif / DejaVu Math TeX Gyre etc It would be good to have a > mechanism to map a font to its math companion (probably this should be > discussed on the Open Font Format mailing list). Then the font-family > can be determined using this mapping and this solves all the issues of > inconsistent style and font-size. > > So to summarize, the idea to determine the default font-family / > font-size on the <math> element would be: a) find a math font that fits > best (font-size and fontface style) with the inherited font-family and > b) adjust the font-size if necessary to match the parent font-size. > > Finally, for the record the user agent stylesheets of WebKit and Gecko > are available here: > https://trac.webkit.org/browser/trunk/Source/WebCore/css/mathml.css > https://dxr.mozilla.org/mozilla-central/source/layout/mathml/mathml.css > > Frédéric > > > Moved to https://github.com/mathml-refresh/mathml/issues/37 https://github.com/mathml-refresh/mathml/issues/36 https://github.com/mathml-refresh/mathml/issues/35 https://github.com/mathml-refresh/mathml/issues/34 -- Frédéric Wang

On 01/08/2016 17:31, Frédéric Wang wrote: > Hi Math WG, > > Continuing on feedback for a future MathML specification, here is a > (probably non-exhaustive) list of inconsistencies between MathML and > HTML5/CSS regarding whitespace and attributes canonicalization. As a > rule of thumb, it would be better for web engines if MathML can align on > HTML5 so that we can reuse as much code as possible and avoid extra code > to handle MathML special cases. Also people familiar with HTML5 will be > less surprised when handling MathML. > > 1) Whitespace collapsing/trimming > https://www.w3.org/TR/MathML/chapter2.html#fund.collapse > > Whitespace collapsing is consistent with the default CSS property > "white-space" and people are familiar with it. > > Removing "whitespace at the beginning and end of the content" is less > expected. Gecko has some code to handle this but it would be very > helpful to avoid this additional complexity. WebKit does not handle it > at the moment and it's not clear it's worth doing it... Except in the > MathML spec/test, everybody seems to just write <mo>(</mo> and not <mo> > ( </mo>. Can we deprecate this behavior in MathML4? Or maybe you should > work with the HTML5 WG to define such collapsing rules during document > parsing, so that the MathML rendering code no longer need to handle it? > > 2) In MathML, white spaces are understood as XML spaces (U+0020), tabs > (U+0009), line feeds (U+000A), and carriage returns (U+000D) while HTML5 > also includes "form feed" (U+000C). > > https://www.w3.org/TR/html5/infrastructure.html#space-character > > 3) MathML attributes are case-sensitive while HTML5 attributes are > case-insensitive. case-sensitiveness is probably not a problem for users > and it's easier for the parsing. However, WebKit developers writing or > reviewing patches have often considered doing case-insensitive > comparisons as that's consistent with the rest of the code base. > > 4) MathML boolean attributes take value "true" and "false". In HTML5, > the boolean value is given by the presence/absence of the attribute and > the only allowed value is the name of the attribute. This allows to get > more compact syntax like <mo largeop stretchy> instead of <mo > largeop="true" stretchy="true">. However, Web engines and authoring > tools will continue to support the true/false syntax anyway, so it's > probably not worth adding complexity here... > > https://www.w3.org/TR/html5/infrastructure.html#boolean-attributes > > 5) As I said in a previous message, the values "small", "normal", "big" > of mathsize do not exist for CSS font-size. Removing them will simplify > a bit the parsing code. > > 6) The definition of numbers is also not very accurate in the MathML > recommendation compared to HTML5. One has to check the RelaxNG schemas > and the predefined RelaxNG types to know the exact syntax. Again, it > think it would be best to rely on the HTML5 definitions. For example, > <math><mspace width="1E1em" height="10em" mathbackground="red"/></math> > draws a red square in WebKit but Gecko says "1E1em" is invalid. > > https://www.w3.org/TR/html5/infrastructure.html#numbers > > Frédéric > > > Moved to individual github issues: https://github.com/mathml-refresh/mathml/issues/28 https://github.com/mathml-refresh/mathml/issues/21 https://github.com/mathml-refresh/mathml/issues/22 https://github.com/mathml-refresh/mathml/issues/33 https://github.com/mathml-refresh/mathml/issues/7 https://github.com/mathml-refresh/mathml/issues/23 -- Frédéric Wang

On 03/08/2016 10:07, Frédéric Wang wrote: > Hi, > > The following attributes are deprecated in MathML3. Some of them are > still implemented in Gecko and WebKit. If they are no longer used, it > would be good to do some clean up by removing the support. Also they > should probably be removed from a specification focusing on core features. > > About deprecated features, the recommendation says that "However, all > (MathML-input-conformant) tools are encouraged to support the old forms > as much as possible.". This is bad because supported features encourages > authors to use them. > > 1) general attribute: other. > > 2) math attributes: macros, mode. mode is supported in Gecko. > > 3) mglyph attributes: fontfamily, index. > > 4) token elements attributes: fontfamily, fontweight, fontstyle, > fontsize, color, background. These are supported in Gecko and WebKit > (although the latter does not make them of lower priority than thei > non-deprecated replacements). > > 5) deprecated namedspace attributes: veryverythinmathspace, > verythinmathspace, thinmathspace, mediummathspace, thickmathspace, > verythickmathspace, veryverythickmathspace. This used to be implemented > in Gecko but is now removed. > > Frédéric > > > Moved to https://github.com/mathml-refresh/mathml/issues/5 -- Frédéric Wang

On 23/08/2016 15:57, Frédéric Wang wrote: > Hi Math WG, > > A small follow-up of > https://lists.w3.org/Archives/Public/www-math/2016Feb/0000.html > > Unicode 6.1 mentions that U+1EEF0 and U+1EEF1 are used for Arabic sum > and Persian limit. Additionally, Azzeddine Lazrek indicated to me that > U+1EEF1 is also used for Arabic product. > https://www.w3.org/TR/arabic-math/ also mentions a special stretched > character for Arabic limit, but it does not seem to have been included > in Unicode at the end. > > Regarding the default value, I think the "prefix" and "stretchy" > properties added by David are correct. I don't know about the spacing, > but the default thickmathspace value is probably too big. So in the > doubt, I'd recommend setting the default lspace/rspace to 0 or 1. > > Frédéric > > > Moved to https://github.com/mathml-refresh/mathml/issues/6 -- Frédéric Wang

Moved to https://github.com/mathml-refresh/mathml/issues/11 On 09/03/2018 18:31, Frédéric Wang wrote: > > Hello, > > Another idea for a future MathML spec. > > MathML suggests to use non-combining characters for operators and most > of the operators in its dictionary are non-combining. However, TeX > seems to rely on combining characters for accents and hence in > practice OpenType fonts with a MATH table only provide size variants > or glyph assemblies for these combining characters ; and nothing for > the non-combining equivalents. That means non-combining characters are > not stretchable with these fonts and users may be tempted to use the > combining versions instead. > > I think it would be good if MathML specifies how web engines can > fallback from non-combining to combining accents in order to stretch > accents. Ideally, we should have a list of such mappings (maybe data > in the XML Entity Definitions for Characters). For example to stretch > U+00AFMACRON, WebKit will also try and find size variants or glyph > assemblies associated to that character inthe OpenType MATH table and > otherwise fallback to data associated to U+0304 (COMBINING MACRON) or > U+0305 (COMBINING OVERLINE). > > Having such a list will allow to improve consistencies between web > engines and to write WPT tests for that feature (currently it's > non-standard so only tested in WebKit repo). > > WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=159513 > > Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1285277 > > -- > Frédéric Wang - frederic-wang.fr -- Frédéric Wang

On 01/08/2016 18:02, Frédéric Wang wrote: > > Hi, > > The mfrac elements has values "thin", "medium" and "thick" which are > "left up to the rendering agent". This is prone to inconsistencies > between implementations. During Igalia's MathML refactoring, we > aligned WebKit on Gecko's behavior. This is essentially what is > suggested in the MathML in HTML5 implementation note and that should > probably be included in an official MathML recommendation too: > > * The default linethickness "medium" is given by the > FractionRuleThickness constant of the MATH table of the font used for > the MathML rendering (see > https://lists.w3.org/Archives/Public/www-math/2016Jul/0025.html for > discussion about how to determine that font). > > * "thin" is 50% and "thick" is 200% of the default linethickness > (these values are arbitrary and based on how it has been implemented > in Gecko probably for more than 15 years). > > But are these keywords really used in practice? If not maybe you may > be inclined to deprecate them too. > > Frédéric > Moved to https://github.com/mathml-refresh/mathml/issues/4 -- Frédéric Wang

Discussion has been moved to https://github.com/mathml-refresh/mathml/issues/1 On 27/07/2016 10:10, Frédéric WANG wrote: > > Hi, > > Continuing with suggestions for future Math WG work, let's come back > again to the idea of simplifying the mstyle element. It duplicates the > CSS inheritance mechanism in a CSS-incompatible way and has many > exceptions that make it hard to understand: there are three different > types of inheritance described in the specification, mathbackground > applies more naturally to the element that bears the attribute than to > each token descendants, mpadded/mspace share attributes names that > have different syntax etc For example, in previous discussions the > case of displaystyle seemed really clear in the mind of spec authors > but less in the one of the various implementers. > > In practice, many of the mstyle attributes are not useful and never > used. It is a burden for implementers since they essentially have to > reimplement a specific "attribute" inheritance mechanism to support > the general case even if the most prominent attributes have obvious > mapping to CSS. It is also a performance issue to perform the > rendering and keep it up-to-date since the rendering on any node may > depend on its mstyle ancestors. > > Support for mstyle has been simplified in Gecko several years ago. > When this was reported to this mailing list, there have not been > strong complaints against the idea (only a few extra attributes were > reported to be used in the MathML3 test suite). There has not been any > bug reports regarding removal of attributes, confirming they were not > used (this contrasts with the case of displaystyle for which aligning > on the specification caused some trouble). Support for some important > mstyle attributes have been implemented in WebKit but there are no > plans to handle the general cases. > > Given this, the proposal is as follows: restrict mstyle to attributes > used in practice listed below. Also the inheritance can in most cases > be more easily described with CSS rules or attribute mapping. > > 1) dir: mapped to the CSS direction property. > > 2) mathsize: mapped to font-size. Note that MathML has the keywords > "small", "normal", "big" that adds some parsing code before the > mapping. It's not clear whether these keywords are very important > (small is 100%, small/big are unspecified...) so they could be > deprecated too to simplify the mapping code. > > 3) mathbackground: mapped to CSS background property. > > 4) color: mapped to CSS color property. > > 5) displaystyle: this one will be preserved but inheritance can be > more clearly described to people familiar with CSS as equivalent to > having a CSS property with values false/true, which is inherited, has > computed value "as specified" and with the following rules in the user > agent stylesheet. > > math { > displaystyle: false; > } > math[display="block"] { > displaystyle: true; > } > math[display="false"] { > displaystyle: false; > } > math[displaystyle="false"] { > displaystyle: false; > } > math[displaystyle="true"] { > displaystyle: true; > } > mtable { > displaystyle: false; > } > mtable[displaystyle="true"] { > displaystyle: true; > } > mstyle[displaystyle="false"] { > displaystyle: false; > } > mstyle[displaystyle="true"] { > displaystyle: true; > } > mfrac > * { > displaystyle: false; > } > mroot > :not(:first-child) { > displaystyle: false; > } > msub > :not(:first-child), > msup > :not(:first-child), > msubsup > :not(:first-child), > mmultiscripts > :not(:first-child) { > displaystyle: false; > } > munder > :not(:first-child), > mover > :not(:first-child), > munderover > :not(:first-child) { > displaystyle: false; > } > > 6) mathvariant: this one will be preserved but inheritance can be more > clearly described to people familiar with CSS as mapped to a CSS > property with all the mathvariant values + an "auto" value (to handle > automatic italic), initial value "auto", which is inherited and has > computed value "as specified". > > 7) scriptsizemultiplier: can be described as a CSS property with > <number> values, initial value 0.71, computed value "as specified" and > which is inherited. It's not clear whether the attribute is really > useful as in practice it is left to its default value. Also this is in > conflicts with ScriptPercentScaleDown and ScriptScriptPercentScaleDown > properties of the MATH table. > > 8) scriptminsize: can be described as a CSS property with <length> > values, initial value 8pt, computed value "as specified" and which is > inherited. Again, it's not really clear whether the attribute is > useful as in practice it is left to its default value. > > 9) scriptlevel: This one must be preserved but it is not clear whether > it can be described as a pure CSS property without adding too much > complexities. There is a proposal on > http://www.mathml-association.org/MathMLinHTML5/S2.html#SS3 but the > increment in munderover/munder/mover should really depend on the > accent/accentunder property which itself depends on specified > attributes or implicit/explicit operator properties in the > overscript/underscript subtrees. > > A rule to determine the computed value for font-size must also be > provided, for example: > > FontSize_Child = > max of ScriptMinSize_Parent and > [FontSize_Parent times > ScriptSizeMultiplier_Parent^(FontSize_Child - FontSize_Parent)] > > with possible additional edge cases to handle. > > Unless something has been forgotten above, all the other mstyle > attributes could be safely deprecated and removed. > > -- > Frédéric Wang -- Frédéric Wang

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

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

On 12/02/2019 17:36, Maria Byrne wrote: > > Dear developers of MathML, > > How can I find web content that is written in MathML? I am an instructor > with a blind student, and I will like to send him the information that > he can't currently access from his textbook, such as integration tables > and such. These can be found on lots of web pages, but I don't know how > to tell if they are in MathML or not. A Calculus textbook in MathMl > would be really perfect. > > It's funny, when I search for "Calculus textbook in MathMl", I just get > lots and lots of resources on how to write a Calculus textbook in MathMl.. > > Thank you for your help! > > Audi Byrne > It's not so easy to search for specific markup as mostly search engines are set up to search the visible text. Also with the current state of play the MathML may be hidden in various ways while still being available to screen readers. wikipedia for example serves its mathematics (by default) as svg or png but with MathML hidden in a form that should be usable by screen readers and other assistive technology, see https://en.wikipedia.org/wiki/Help:Displaying_a_formula#Native_MathML The details depend on your browser and settings but for example if I view the source of https://en.wikipedia.org/wiki/Integration_by_parts I see all the mathml hidden via style="display: none;" as for example <span class="mwe-math-mathml-inline mwe-math-mathml-a11y" style="display: none;"><math xmlns="http://www.w3.org/1998/Math/MathML" alttext="{\displaystyle \int _{\Omega }\nabla u\cdot \nabla v\,d\Omega =\int _{\Gamma }u\,\nabla v\cdot {\hat {\nu }}\,d\Gamma -\int _{\Omega }u\,\nabla ^{2}v\,d\Omega ,}"> <semantics> <mrow class="MJX-TeXAtom-ORD"> <mstyle displaystyle="true" scriptlevel="0"> <msub> <mo>∫<!-- ∫ --></mo> ......... David Disclaimer 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 and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.

Dear developers of MathML, How can I find web content that is written in MathML? I am an instructor with a blind student, and I will like to send him the information that he can't currently access from his textbook, such as integration tables and such. These can be found on lots of web pages, but I don't know how to tell if they are in MathML or not. A Calculus textbook in MathMl would be really perfect. It's funny, when I search for "Calculus textbook in MathMl", I just get lots and lots of resources on how to write a Calculus textbook in MathMl.. Thank you for your help! Audi Byrne

Oh sorry about that I pressed the wrong button when I left. I started it back up if anyone would still like to join. Here is the information Join from PC, Mac, Linux, iOS or Android: https://benetech.zoom.us/j/872934179 Or iPhone one-tap : US: +16699006833,,872934179# or +16468769923,,872934179# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 669 900 6833 or +1 646 876 9923 or +1 877 853 5257 (Toll Free) or +1 855 880 1246 (Toll Free) Meeting ID: 872 934 179 International numbers available: https://zoom.us/u/i2LL0KGb Or an H.323/SIP room system: H.323: 162.255.37.11 (US West) 162.255.36.11 (US East) 221.122.88.195 (China) 115.114.131.7 (India) 213.19.144.110 (EMEA) 202.177.207.158 (Australia) 209.9.211.110 (Hong Kong) 64.211.144.160 (Brazil) 69.174.57.160 (Canada) Meeting ID: 872 934 179 SIP: 872934179@zoomcrc.com<mailto:872934179@zoomcrc.com> Thanks EOM Charles LaPierre Technical Lead, DIAGRAM and Born Accessible Twitter: @CLaPierreA11Y Skype: charles_lapierre Phone: 650-600-3301 On Feb 11, 2019, at 8:17 AM, Peter Krautzberger <peter@krautzource.com<mailto:peter@krautzource.com>> wrote: David, sorry to hear that. Unfortunately, Charles just shut down the call since few people showed up, so we can't re-start it for now. I'll see if we can provide some more permanent alternatives. Best, Peter. Am Mo., 11. Feb. 2019 um 17:12 Uhr schrieb David Farmer <farmer@aimath.org<mailto:farmer@aimath.org>>: And I wanted to join, but I have not done that before and cannot seem to figure out what to do! Apologies, David On Mon, 11 Feb 2019, Daniel Marques wrote: > Hi, > I'm in a train with delay and not sure I'll be on time for the meeting. > > Regards > > Dani > > ___________________________________________________________________________________________________________________________________ > MathType 7 is out! Check the new version at wiris.com/mathtype<http://wiris.com/mathtype> > >

David, sorry to hear that. Unfortunately, Charles just shut down the call since few people showed up, so we can't re-start it for now. I'll see if we can provide some more permanent alternatives. Best, Peter. Am Mo., 11. Feb. 2019 um 17:12 Uhr schrieb David Farmer <farmer@aimath.org>: > And I wanted to join, but I have not done that before and cannot > seem to figure out what to do! > > Apologies, > > David > > > On Mon, 11 Feb 2019, Daniel Marques wrote: > > > Hi, > > I'm in a train with delay and not sure I'll be on time for the meeting. > > > > Regards > > > > Dani > > > > > ___________________________________________________________________________________________________________________________________ > > MathType 7 is out! Check the new version at wiris.com/mathtype > > > > > > >

And I wanted to join, but I have not done that before and cannot seem to figure out what to do! Apologies, David On Mon, 11 Feb 2019, Daniel Marques wrote: > Hi, > I'm in a train with delay and not sure I'll be on time for the meeting. > > Regards > > Dani > > ___________________________________________________________________________________________________________________________________ > MathType 7 is out! Check the new version at wiris.com/mathtype > >

Hi, I'm in a train with delay and not sure I'll be on time for the meeting. Regards Dani -- MathType 7 is out! Check the new version at wiris.com/mathtype <http://www.wiris.com/mathtype?utm_source=emailfooter>

It was just me on the call. I agreed with most of what I said :-) On Mon, Jan 28, 2019, 8:47 AM Peter Krautzberger <peter@krautzource.com wrote: > Hi everybody, > > I had a last minute conflict and I believe Dani did also. > > For those who were on the call, if you had a conversation worth sharing, > it'd be great if you can share post some notes to the list. > > Otherwise, see you in two weeks. > > Best, > Peter. >

I am pleased to announce the formation of the MathML Refresh Community Group <https://www.w3.org/community/mathml4/>. The charter of this group is to focus on changes to the MathML 3 recommendation so that it better aligns with the current web environment, eases the burden on browser implementations, and increases support for assistive technology. Initially the group will meet via Zoom every other week with the day and time to be determined via a doodle poll of the members. I encourage everyone who is interested in improving math support on the web to join and contribute to this effort. More information about the group and how you can join can be found on the community group's web page <https://www.w3.org/community/mathml4/>.

Six years have past since the post RichEdit 8 Feature Additions and a lot has happened in between. Along the way, several versions have shipped, but we might as well call the current one RichEdit 9, This covers RichEdit up through Office 2019 and includes some features of more recent Office 365 versions. The latter versions are shipped almost every month with fixes and improvements and, hopefully, no regressions! Much of the new functionality is described in posts, so I point to them as well as mention other improvements.

Excel has switched to RichEdit 9 both for in-cell editing and formula-bar editing. This switch required numerous Excel-specific additions to RichEdit in order to maintain Excel’s existing behavior. Most notably, a lot of effort was spent on the ruby text feature. Many changes were small enough to be named bug fixes, although some added functionality. Substantial effort has been devoted to keeping up with Unicode, particularly with emoji, but also with new scripts.

Perhaps the most impressive change is that RichEdit 9 ships in many forms: Win32, Universal, Mac, iOS, Android, and server! To support all these versions, we write unit tests for all new features. The extensive test infrastructure for older features runs on Windows, and some of those tests have been converted to unit tests that run on other platforms. Fortunately, the implementations of most features are platform independent and can be tested adequately on Windows alone. Part of porting RichEdit to other platforms depended on porting LineServices and DirectWrite to those platforms as well.

The remainder of this post has links to features that have shipped. Please click on the links that you’re interested in.

RichEdit has many character-format properties, most of which are documented for ITextFont2 and CHARFORMAT2. Nevertheless, the OpenType specification defines many more character-format properties called OpenType features consisting of a 32-bit identifier (id) and a 32-bit value. For example, the Gabriola font has stylistic set 6, which displays “Gabriola is graceful” as

Variable fonts are the latest addition to the OpenType specification. RichEdit 9 supports both OpenType features and variable fonts. December 22, 2018

Microsoft products expose their contents for accessibility purposes via a set of interfaces known as UI Automation (UIA). Currently UIA has no special support for math text. Either the assistive technology program (AT) has to figure out if math is involved or the application has to return math-specific speech text as done with Office math. RichEdit 9 supports two ways for an AT to retrieve math zones in a specific format, e.g., MathML. November 16, 2018

As discussed in the post Editing equations created using the Microsoft Equation Editor, the Microsoft Equation Editor 3.0 (MEE) was removed from Office installations because it has security problems and no maintenance. Microsoft doesn’t have access to the MEE source code and MEE’s author, Design Science, doesn’t maintain it, instead offering the more powerful, upward-compatible MathType. Users can invoke the converter built into RichEdit 9 in Word and PowerPoint to convert MEE and MathType math objects to OfficeMath. August 31, 2018

The post RichEdit 8.0 Image Support describes how RichEdit supports popular image formats, such as jpeg’s, png’s and GIF’s. RichEdit 8.1 added direct support for jpeg’s and png’s in the Rich Text Format (RTF) instead of using RichEdit’s proprietary blob format. Even so, GIFs were treated as second-class images in two ways. First, they were converted to png’s when persisted in RTF. Since png’s are limited to a single frame, only the initial frame of a multiframe GIF was saved. Second, only the initial frame was displayed, so the animated GIFs that are seen frequently on the web and in texting programs weren’t animated. This post describes how RichEdit 9 fixes both problems. February 21, 2018

For a while now it’s been possible to switch Word’s math input mode from UnicodeMath to LaTeX. We didn’t advertise this highly requested feature since it needed more work. We fixed most of the problems and this post describes how you can use [La]TeX as a math input method in Word, PowerPoint, OneNote, and Outlook. The LaTeX converters are shared code built into RichEdit 9. July 30, 2017

Microsoft Office math-aware applications can now speak math in over 18 different languages! Try it out with native math zones in Word by enabling Narrator (type Windows+Ctrl+Enter) and navigate a math zone as described in the post Speaking of math… There are two math-speech granularities: coarse-grained (navigate by words), which speaks math expressions fluently in a natural language, and fine-grained (navigate by characters), which explains the content at the insertion point (IP) in enough detail to enable editing. The math speech engine is shared code built into RichEdit 9. February 27, 2017

The 6-dot Nemeth braille encoding was created by Abraham Nemeth for mathematical and scientific notation and is general enough to encode almost all Microsoft Office math notation. RichEdit 9 supports Nemeth math braille input and output. This capability hasn’t yet been integrated into Office apps. July 31, 2016

For years, many applications have used the locale ID (LCID) to identify the language and locale for text and other data. For example since 1997 (RichEdit 2.0), RichEdit’s character formatting has included CHARFORMAT2::lcid. The LCID can, in fact, describe most language/locale combinations in use as far as text is concerned. However, the more general BCP-47 language tag is based on international standards and it can describe virtually any language/locale combination and it can include additional subtags such as for script and private-use. Since myriad existing documents use LCIDs, text engines still need to support LCIDs. This post describes how RichEdit 9 supports both properties gracefully in a way that doesn’t require tearing existing programs apart. October 19, 2015

The popularity of emoji symbols has encouraged a variety of technological innovations, notably fonts with multicolor characters. This is different from just having text color, which is described in RichEdit Colors. While some colored glyphs were part of the original Japanese emoji standards, colored glyphs got much more elegant when Apple introduced its proprietary color emoji font. This post describes how RichEdit 9 displays text formatted with Microsoft color fonts. September 24, 2015

Here are some posts that describe older RichEdit versions and history.

The time has come to summarize the features added in RichEdit 8, which shipped with Windows 8 and Office 2013. Since so much was added, I wrote a number of blog posts over the last twelve months about the larger RichEdit 8 features. The present post lists those features and then describes some smaller features… September 7, 2013

A couple of comments have raised the question of people outside Microsoft using the various versions of RichEdit. Specifically, Teis Johansen asks, “Just to be sure. Can I redistribute RichEdit 6.0 with my application?” and Kyle Alons asks, “So what’s the point of listing these features without documenting how to use them? Just to make… October 19, 2006

The original RichEdit Versions post covered RichEdit versions 1.0 through 6.0, since 6.0 was the latest version at the time. RichEdit 7.0 will ship with Office 2010, so here’s an update describing what that version adds. Most additions involve math editing/display and play a central role in the math features of OneNote 2010, PowerPoint 2010,… September 5, 2009

Starting with Windows 7, Windows includes a cool applet called the Math Input Panel. This applet lets you enter mathematical text using a pen or a mouse. It recognizes what you enter and displays the result using a special private version of RichEdit 6. It also lets you copy the results to Word, Mathematica, or any… May 6, 2009

Digging through old doc files, I ran across the following summary of RichEdit up through Version 3.0. It’s more detailed than my post on RichEdit Versions, so it might be of interest to history buffs, anyhow. And it does describe the riched20.dll that still ships with Windows, mostly for purposes of backward compatibility. I wrote… January 12, 2010

Recurring questions are what RichEdit’s are available, where they are installed and what features they have. A relatively new question is which RichEdit’s support the new Office math editing and display. So this post attempts to answer these questions. To answer the last question first, only RichEdit 6.0 has the Office math facility, although RichEdit… October 13, 2006

Hi everyone, Below is a video of a talk by John Hudson (of Tiro) pondering variable fonts for stretchy constructions (the part starts around 43 min into the talk though the link should take you there). I've reached to John to get more input on this ideas. Best, Peter. https://www.youtube.com/watch?v=MuuAmG_qer8&feature=youtu.be&t=2559

Planet MathML features:

- David Carlisle
- Design Science News
- FMath
- Getting Math onto Web Pages Community Group
- MathJax
- Murray Sargent: Math in Office
- SF.net - ASCIIMathML
- SF.net - DocBook to LaTeX Publishing
- SF.net - MathCast Equation Editor
- SF.net - MathStudio
- SF.net - Open Math Edit
- SF.net - PyMathML
- SF.net - SVGMath
- SF.net - UniWakka
- SF.net - jsMath
- SF.net - jscl-meditor
- SF.net - pMML2SVG
- Updates | Frédéric Wang
- W3C Blog
- W3C Math Home
- W3C News
- WebKit
- public-digipub-ig@w3.org Mail Archives
- public-html-a11y@w3.org Mail Archives
- public-html@w3.org Mail Archives
- public-mathonwebpages@w3.org Mail Archives
- public-webapps@w3.org Mail Archives
- www-math@w3.org Mail Archives
- www-style@w3.org Mail Archives

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