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.

Latest articles

SimpleTeX4ht

Source: Ask.com News Search for "mathml" • February 04, 2016 • Permalink

ZDNet - Found Feb. 4, 2016
LaTeX files to HTML, XHTML, OpenDocument (.odt which is the native format of OpenOffice.org), MathML, DocBook or Text Encoding Initiative (TEI).
Tech Tip: Moving Files to a Mac From a PC - New York Times
FastFox Text Expander - ZDNet
Moving Files to a Mac From a PC - New York Times
Sequel Pro - ZDNet
Explore All

Huffington Post

Re: Clipboard API: remove dangerous formats from mandatory data types

Source: public-webapps@w3.org Mail Archives • Hallvord Reiar Michaelsen Steen (hsteen@mozilla.com) • February 04, 2016 • Permalink

(Finally found some time to resume this old discussion - if you've all
forgotten the details by now the thread started here:
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0819.html
)

On Sat, Aug 29, 2015 at 3:16 PM, Paul Libbrecht <paul@hoplahup.net> wrote:

> But copying a fragment of HTML in the wild without reformulating it will
> lead to privacy breach: it would copy references to external content. I
> believe all browsers have an "inlining" method to solve that problem when
> pasting from a web-page (I believe "save as web page complete" also does a
> part of that).

I think the proposed solution may be worse for privacy than the
original problem: images you would "inline" might have sensitive data
in them.. AFAIK it's not common to do any image inlining or URL
mangling when pasting HTML copied from another site, is it?

>> Why should JSON be unsafe? Parsing JSON should be pretty easy, so hopefully
>> most parsers would be safe.
>
> I think the danger lies beyond parsers.
> In XML, you would have XInclude which can be used in many tools to include
> content from outside.
> I believe I have seen JSON syntaxes that had external references as part of
> their specs but I can't remember which now.
> As long these formats are copied as is and parsed blindly the risk of
> external inclusion remains.

XML: good point.
JSON: nope, there's no such thing as "external inclusion" in JSON, and
there never will be.

>> For the unsafe formats, the warning could say that the UA-implementors
>> should only support the flavour if they have a method to make this content
>> safe so that local applications (which do not expect untrusted content)
>> receive content they can trust when pasting. Methods to make the content
>> safe include the following: transcoding a picture, inlining all external
>> entities for html, xml, mathml, or rtf).
>
>
> On Windows I believe images are transcoded to and from DIB - device
> independent bitmap format anyway. Is there any equivalent graphics
> interchange format on other platforms? Does mandating such transcoding help
> guarantee against payloads that might trigger vulnerabilities in target
> software?
>
> All platforms I know of have some sort of transcoding of pictures (in Macs
> it is PDF as the central format).
> I think this is a very safe mechanism to rely on.

I've just done a small test in Safari on Mac. It allows writing a
random string to the clipboard and labelling it image/tiff (and
helpfully adds a "public.tiff" clipboard entry with the same random
data). There's no transcoding or similar.

> I expect it adds a significant hurdle against exploits, but I'd like input
> from Daniel Cheng and perhaps from people who have worked on image
> decoders..

I'd still like Daniel Cheng to chime in again if he has time :)
So, the question (for recap) is: would it be OK to let JS write binary
data labelled as an image type if the browser was required to
transcode it to TIFF or DIB and only update the clipboard if such
transcoding succeeded?

(Obviously we also need the reverse mechanism - on paste, if there's
TIFF or DIB on the clipboard offer JPEG and/or PNG to JS).
-Hallvord

HighWire continues as MathJax Supporter

Source: MathJax • February 03, 2016 • Permalink

The HighWire Open Platform provides innovative technology solutions to influential societies, university presses, and independent publishing organizations, assisting in the digital dissemination and readability of some of the most high-impact journals, books, and other scholarly materials on the net.

“Celebrating 20 years of service, HighWire Press, Inc. is excited to once again be a supporter of the initiatives behind the development of MathJax’s open source platform for display of mathematics,” said Christopher Abbott, Director, Content Service, HighWire Press. “The HighWire Open Platform is designed to work well with standards such as MathML. We’re proud to be part of the solution.”

“HighWire has been providing both support and important feedback for our development at MathJax”, comments Peter Krautzberger, MathJax manager. “Dedicated sponsors such as HighWire enable us at MathJax to deliver the most reliable, high-quality solution for math and science on the web.”

We look forward to continuing the collaboration with HighWire and welcome their ongoing support for the MathJax project.

MS SharePoint Server 2016 Support & Enhanced Footnote Handling & ...

Source: Ask.com News Search for "mathml" • February 02, 2016 • Permalink

Programmers' Heaven - Found Feb. 2, 2016
• MathML equations rendering inside shapes implemented • MathML equations vertical positioning improved when rendering • Improved...

OASIS DITA 1.3 Standard Approved for Authoring and Publishing

Source: Ask.com News Search for "mathml" • February 01, 2016 • Permalink

Channel 8 Eyewitness News - Found Feb. 1, 2016
... new features, introduced in DITA 1.3, such as troubleshooting topic type, keyscopes, branch filtering, MathML domain, XML mention domain and...
OASIS DITA 1.3 Standard Approved for Authoring and Publishing - WVNS
OASIS DITA 1.3 Standard Approved for Authoring and Publishing - KHQ Right Now
OASIS DITA 1.3 Standard Approved for Authoring and Publishing - IT Business Net
OASIS DITA 1.3 Standard Approved for Authoring and Publishing - Minyanville
Explore All

MS SharePoint Server 2016 Support & Enhanced Footnote Handling & ...

Source: Ask.com News Search for "mathml" • January 30, 2016 • Permalink

PR.com - Found Jan. 30, 2016
• MathML equations rendering inside shapes implemented • MathML equations vertical positioning improved when rendering • Improved...

Re: Apple's feedback for custom elements

Source: public-webapps@w3.org Mail Archives • Olli Pettay (olli@pettay.fi) • January 24, 2016 • Permalink

Random comments inline (other people from Mozilla may have different opinions)

On 01/24/2016 10:01 AM, Ryosuke Niwa wrote:
>
>
> Hi all,
>
> Here's WebKit team's feedback for custom elements.
>
>
> == Constructor vs createdCallback ==
> We would like to use constructor instead of created callback.
no comments

>
> == Symbol-named properties for lifecycle hooks ==
> After thorough consideration, we no longer think using symbols for callback names is a good idea.  The problem of name conflicts with an existing
> library seems theoretical at best, and library and framework authors shouldn't be using names such as "attributeChanged" for other purposes than as
> for the designated purpose of custom elements API.
>
> In addition, forcing authors write `[Element.attributeChanged]()` instead of `attributeChanged()` in this one API is inconsistent with the rest of Web
> API.
>
Personally I agree.

>
> == Calling attributeChanged for all attributes on creation ==
> We think invoking `attributeChanged` for each attribute during creation will help mitigating the difference between the upgrade case and a direct
> creation inside author script.
>
> https://github.com/w3c/webcomponents/issues/364
>
Fine to me. This is also close to what XTF had. (It had also a pre-callback, willSet/RemoveAttribute [1], but we can live without those at least in v1)


>
> == Lifecycle callback timing ==
> We're fine with end-of-nano-task timing due to the implementation difficulty of going fully sync and async model doesn’t meet author’s expectation.
>
nano-task scheduling sounds good.


>
> == Consistency problem ==
> This is a problem but we think calling constructor before attributes and children are added during parsing is a good enough mitigation strategy.
It is possible that we'll need beginAddingChildren()/doneAddingChildren() for the parsing case later, but not for v1.
I wonder if all the engines can easily have end-of-nanotask right after main-thread part of parser has created the DOM element and before any 
attributes/children are set.
IIRC Gecko should be fine these days.


> == Attached/detached vs. inserted/removed hooks ==
> Elements that define things or get used by other elements should probably do their work when they’re inserted into a document.  e.g. HTMLBaseElement
> needs to modify the base URL of a document when it gets inserted. To support this use case, we need callbacks when an element is inserted into a
> document/shadow-tree and removed from a document/shadow-tree.
>
> Once we have added such insertedIntoDocument/removedFromDocument callbacks, attached/detached seems rather arbitrary and unnecessary as the author can
> easily check the existence of the browsing context via `document.defaultView`.
>
> We would not like to add generic callbacks (inserted/removed) for every insertion and removal due to performance reasons.
>
> https://github.com/w3c/webcomponents/issues/362
I'd prefer getting more consistent parentChainChanged(oldSubtreeRoot, newSubtreeRoot) callback or some such. That wouldn't depend on is-in-document
state. Adding parentChainChanged later if there is already insertedIntoDocument/removedFromDocument would just duplicate some of the behavior.


Something to consider, borrowed from XTF, should custom element implementation tell to browser engine which notifications it is interested in?
That way performance considerations are partially moved from browser engine to the custom element author.


> == Style attribute spamming ==
> Since keeping the old value is inherently expensive, we think we should mitigate this issue by adding an attribute filtering.  We think having this
> callback is important because responding to attribute change was the primary motivation for keeping the end-of-a-nano-task timing for lifecycle callbacks.
>
> https://github.com/w3c/webcomponents/issues/350
attribute filter sounds good. Especially if it is consistent with MutationObserver.


> == childrenChanged callback ==
> Given the consistency problem, it might be good idea to add `childrenChanged` callback to encourage authors to respond to this event instead of
> relying on children being present if we decided to go with non-synchronous construction/upgrading model.
>
> On the other hand, many built-in elements that rely on children such as `textarea` tends to respond to all children at once.  So attaching mutation
> observer and doing the work lazily might be an acceptable workflow.
So would childrenChanged be called after parser has added all the child nodes? Or just at random time, or for each child nodes separately?

This is a case where beginAddingChildren()/doneAddingChildren() would be needed, but for now, childrenChanged is probably ok.


>
>
> == Upgrading order ==
> We should do top-down in both parsing and upgrading since parser needs to do it top-down.
no comments


>
>
>
> == What happens when a custom element is adopted to another document? ==
> Since a given custom element may not exist in a new document, retaining the prototype, etc... from the original document makes sense.  In addition,
> WebKit and Blink already exhibit this behavior so we don’t think it poses a major combat issue.
(can't recall all the details. Would need to re-read the relevant spec bugs.)


>
>
> == Inheritance from subclasses of HTMLElement such as HTMLInputElement ==
> We strongly oppose to adding this feature at least in v1.
>
> https://github.com/w3c/webcomponents/issues/363
Sounds good


>
>
> == Inheritance from SVGElement/MathMLElement ==
> We don't want to allow custom SVG and MathML elements at least in v1.
>
> https://github.com/w3c/webcomponents/issues/363
ditto


>
>
> - R. Niwa
>


-Olli

[1] http://mxr.mozilla.org/seamonkey/source/content/xtf/public/nsIXTFElement.idl#127

The CSS WG published Candidate Recommendations of CSS Fragme…

Source: Ask.com News Search for "mathml" • January 18, 2016 • Permalink

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

EditiX

Source: Ask.com News Search for "mathml" • January 15, 2016 • Permalink

ZDNet - Found Jan. 15, 2016
EditiX includes default templates with XML, DTD, XHTML, XSLT, XSD, XML RelaxNG, SVG, MathML and XML FO.
Jaksta Media Recorder - ZDNet
MixPad Multitrack Recorder - ZDNet
Balsamiq Mockups - ZDNet
Mail Archiver X - ZDNet
Explore All

The CSS WG published a Candidate Recommendation of CSS Fragm…

Source: Ask.com News Search for "mathml" • January 14, 2016 • Permalink

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

Re: CSS Priorities / character alignment (Was: Meeting Minutes, 2016-01-11)

Source: public-digipub-ig@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • January 13, 2016 • Permalink

I'm not sure if it's interesting or already known but
https://www.w3.org/Math/draft-spec/mathml.html#chapter3_id.3.5.5.10
describes the algorithm specified by the MathML spec for its in-table
alignment markup. Though, as far as I know, no web-based MathML renderer
implements malign groups.

Speaking of that link
https://drafts.csswg.org/css-text-4/#character-alignment; the example's
pseudo-rendering does not correspond to the table markup; it confused
people I had sent it to.

Peter.

On Wed, Jan 13, 2016 at 8:13 AM, Florian Rivoal <florian@rivoal.net> wrote:

>
> > On Jan 13, 2016, at 15:01, Ivan Herman <ivan@w3.org> wrote:
> >
> > Minutes are available here:
> >
> > http://www.w3.org/2016/01/11-dpub-minutes.html
>
> Hi all,
>
> Sorry for missing the meeting, it was a holiday in Japan (but I should
> have sent regrets nonetheless).
>
> I just wanted to briefly react to the discussion about the CSS Priorities
> Document,
> and confirm that there is a meeting of the CSSWG from February 1 to 3,
> that I am going to it, and that I am happy to push for discussions on
> DPUB-IG topics such as character alignment in tables, but also that
> it will be difficult for me to do so if I don't have a corpus of examples,
> especially examples that could inform the discussion about the issues
> raised by Dbaron in the spec (
> https://drafts.csswg.org/css-text-4/#character-alignment).
>
> Please help me help you :)
>
>  - Florian
>

The CSS Working Group, in cooperation with John Allsopp (Web…

Source: Ask.com News Search for "mathml" • January 12, 2016 • Permalink

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

MathJax v2.6 now available

Source: MathJax • December 30, 2015 • Permalink

After a smooth beta run, we’re happy to officially release MathJax v2.6. This release focused on two main features:

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

  2. Accessibility improvements in the form of

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

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

MathJax v2.6 is available on the CDN, and for download from GitHub; see the documentation for details.

Version 2.6 is available on the CDN at

http://cdn.mathjax.org/mathjax/2.6-latest/MathJax.js

and starting today the files at the

http://cdn.mathjax.org/mathjax/latest/MathJax.js

address will be switched over the v2.6. If you are using the mathjax/latest address you might get a mixture of files in your browser cache, and so may need to clear your browser cache and for some browsers (e.g., Chrome) restart your browser in order to get a consistent version of all files.

If you are a page author and concerned about this, you can change (temporarily) to the mathjax/2.6-latest URL instead of mathjax/latest since that is a new address that will not have any cached older versions to worry about. You can switch back to mathjax/latest in a few days when the new version has migrated to all the locations in the cloud. If you want to keep using Mathjax v2.5 you can switch to mathjax/2.5-latest.

See http://docs.mathjax.org/en/v2.6-latest/whats-new-2.6.html for details about the changes in v2.6. We anticipate a smooth upgrade from v2.5 to v2.6, but as always, let us know on the bug tracker if you experience problems with this new version of MathJax.

Changes to the default MathJax “TeX” fonts

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

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

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

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

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

Changes to the combined configuration files

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

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

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


Thank you for your continued support.

The MathJax Team.


New in MathJax v2.6

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

Features

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

Interface

HTML/SVG/nativeMML display

TeX emulation

Asciimath

MathML

Fonts

Localization

APIs

Misc.

Fwd: MathML in HTML5 - Implementation Note

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

FYI

> Begin forwarded message:
> 
> 
> Ivan,
> 
> looks like you might see some progress on MathML implementations next year:
> 
> MathML at the Web Engines Hackfest 2015
> http://www.maths-informatique-jeux.com/blog/frederic/?post/2015/12/20/MathML-at-the-Web-Engines-Hackfest-2015
> 
> MathML in HTML5 - Implementation Note:
> http://www.mathml-association.org/MathMLinHTML5/
> 
> [webkit-dev] MathML layout refactor proposal
> https://lists.webkit.org/pipermail/webkit-dev/2015-December/027840.html
> 


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






Re: Fwd announcement "Towards MathJax 3.0"

Source: www-math@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • December 21, 2015 • Permalink

Hi www-math,

Thanks for cross-posting here, Bill! It was on our to-do list but fell
through the cracks.

> However, as I understand it, their html/css and svg renderings will
continue to be derived from MathML

That's correct though improving MathJax's internal format (which is
essentially MathML) is on the table.

> and the (MathJax versions of) Tex and ascii-math inputs will continue to
be available as author-friendly inputs for math.

That's correct.

Best regards,
Peter.

On Thu, Dec 17, 2015 at 10:44 PM William F Hammond <hammond@csc.albany.edu>
wrote:

> Dear Friends --
>
> Several days ago the MathJax team announced plans for
> version 3 of MathJax.  It appears that the MathJax team no
> longer wants their development path to be focused on
> promoting native browser rendering of MathML.
>
> However, as I understand it, their html/css and svg
> renderings will continue to be derived from MathML and the
> (MathJax versions of) Tex and ascii-math inputs will
> continue to be available as author-friendly inputs for math.
>
> I'm surprised that they seem not to have announced it here.
> Someone else shared the announcement in "texhax", and I
> think it to be of even more relevance here.  The team's
> thoughts about diagrams are certainly relevant here.
>
> https://www.mathjax.org/whitepaper-towards-mathjax-v3/
>
>                           -- Bill
>
>
>
>

On “Towards MathJax 3.0” | On music, computing and math

Source: mathml - Google Blog Search • pbelmans • December 21, 2015 • Permalink

One should be aware that there is something called MathML which is a web standard for producing mathematical formulas on the web, just like HTML is a standard for producing what are basically hyperlinked text documents.

MathML at the Web Engines Hackfest 2015

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

Hackfest

Two weeks ago, I travelled to Spain to participate to the second Web Engines Hackfest which was sponsored by Igalia and Collabora. Such an event has been organized by Igalia since 2009 and used to be focused on WebkitGTK+. It is great to see that it has now been extended to any Web engines & platforms and that a large percentage of non-igalian developers has been involved this year. If you did not get the opportunity to attend this event or if you are curious about what happened there, take a look at the wiki page or flickr album.

Last day of the hackfest
Photo from @webengineshackfest licensed under Creative Commons Attribution-ShareAlike

I really like this kind of hacking-oriented and participant-driven event where developers can meet face to face, organize themselves in small collaboration groups to efficiently make progress on a task or give passionate talk about what they have recently been working on. The only small bemol I have is that it is still mainly focused on WebKit/Blink developments. Probably, the lack of Mozilla/Microsoft participants is probably due to Mozilla Coincidental Work Weeks happening at the same period and to the proprietary nature of EdgeHTML (although this is changing?). However, I am confident that Igalia will try and address this issue and I am looking forward to coming back next year!

MathML developments

This year, Igalia developer Alejandro G. Castro wanted to work with me on WebKit's MathML layout code and more specifically on his MathML refactoring branch. Indeed, as many people (including Google developers) who have tried to work on WebKit's code in the past, he arrived to the conclusion that the WebKit's MathML layout code has many design issues that make it a burden for the rest of the layout team and too complex to allow future improvements. I was quite excited about the work he has done with Javier Fernández to try and move to a simple box model closer to what exists in Gecko and thus I actually extended my stay to work one whole week with them. We already submitted our proposal to the webkit-dev mailing list and received positive feedback, so we will now start merging what is ready. At the end of the week, we were quite satisfied about the new approach and confident it will facilitate future maintenance and developements :-)

Main room
Photo from @webengineshackfest licensed under Creative Commons Attribution-ShareAlike

While reading a recent thread on the Math WG mailing list, I realized that many MathML people have only vague understanding of why Google (or to be more accurate, the 3 or 4 engineers who really spent some time reviewing and testing the WebKit code) considered the implementation to be unsafe and not ready for release. Even worse, Michael Kholhase pointed out that for someone totally ignorant of the technical implementation details, the communication made some years ago around the "flexbox-based approach" gave the impression that it was "the right way" (indeed, it somewhat did improve the initial implementation) and the rationale to change that approach was not obvious. So let's just try and give a quick overview of the main problems, even if I doubt someone can have good understanding of the situation without diving into the C++ code:

  1. WebKit's code to stretch operator was not efficient at all and was limited to some basic fences buildable via Unicode characters.
  2. WebKit's MathML code violated many layout invariants, making the code unreliable.
  3. WebKit's MathML code relied heavily on the C++ renderer classes for flexboxes and has to manage too many anonymous renderers.

The main security concerns were addressed a long time ago by Martin Robinson and me. Glyph assembly for stretchy operators are now drawn using low-level font painting primitive instead of creating one renderer object for each piece and the preferred width for them no longer depends on vertical metrics (although we still need some work to obtain Gecko's good operator spacing). Also, during my crowdfunding project, I implemented partial support for the OpenType MATH table in WebKit and more specifically the MathVariant subtable, which allows to directly use construction of stretchy operators specified by the font designer and not only the few Unicode constructions.

However, the MathML layout code still modifies the renderer tree to force the presence of anonymous renderers and still applies specific CSS rules to them. It is also spending too much time trying to adapt the parent flexbox renderer class which has at the same time too much features for what is needed for MathML (essentially automatic box alignment) and not enough to get exact placement and measuring needed for high-quality rendering (the TeXBook rules are more complex, taking into account various parameters for box shifts, drops, gaps etc).

During the hackfest, we started to rewrite a clean implementation of some MathML renderer classes similar to Gecko's one and based on the MathML in HTML5 implementation note. The code now becomes very simple and understandable. It can be summarized into four main functions. For instance, to draw a fraction we need:

Perhaps, the best example to illustrate how the complexity has been reduced is the case of the renderer of mmultiscripts/msub/msup/msubsup elements (attaching an arbitrary number of subscripts and superscripts before or after a base). In the current WebKit implementation, we have to create three anonymous wrappers (a first one for the base, a second one for prescripts and a third one for postscripts) and an anonymous wrapper for each subscript/superscript pair, add alignment styles for these wrappers and spend a lot of time maintaining the integrity of the renderer tree when dynamic changes happen. With the new code, we just need to do arithmetic calculations to position the base and script boxes. This is somewhat more complex than the fraction example above but still, it remains arithmetic calculations and we can not reduce any further if we wish quality comparable to TeXBook / MATH rules. We actually take into account many parameters from the OpenType MATH table to get much better placement of scripts. We were able to fix bug 130325 in about twenty minutes instead of fighting with a CSS "negative margin" hack on anonymous renderers.

MathML dicussions

The first day of the hackfest we also had an interesting "breakout session" to define the tasks to work on during the hackfest. Alejandro briefly presented the status of his refactoring branch and his plan for the hackfest. As said in the previous section, we have been quite successful in following this plan: Although it is not fully complete yet, we expect to merge the current changes soon. Dominik Röttsches who works on Blink's font and layout modules was present at the MathML session and it was a good opportunity to discuss the future of MathML in Chrome. I gave him some references regarding the OpenType MATH table, math fonts and the MathML in HTML5 implementation note. Dominik said he will forward the references to his colleagues working on layout so that we can have deeper technical dicussion about MathML in Blink in the long term. Also, I mentioned noto-fonts issue 330, which will be important for math rendering in Android and actually does not depend on the MathML issue, so that's certainly something we could focus on in the short term.

Álex and Fred during the MathML breakout session
Photo from @webengineshackfest licensed under Creative Commons Attribution-ShareAlike

Alejandro also proposed to me to prepare a talk about MathML in Web Engines and exciting stuff happening with the MathML Association. I thus gave a brief overview of MathML and presented some demos of native support in Gecko. I also explained how we are trying to start a constructive approach to solve miscommunication between users, spec authors and implementers ; and gather technical and financial resources to obtain a proper solution. In a slightly more technical part, I presented Microsoft's OpenType MATH table and how it can be used for math rendering (and MathML in particular). Finally, I proposed my personal roadmap for MathML in Web engines. Although I do not believe I am a really great speaker, I received positive feedback from attendees. One of the thing I realized is that I do not know anything about the status and plan in EdgeHTML and so overlooked to mention it in my presentation. Its proprietary nature makes hard for external people to contribute to a MathML implementation and the fact that Microsoft is moving away from ActiveX de facto excludes third-party plugin for good and fast math rendering in the future. After I went back to Paris, I thus wrote to Microsoft employee Christian Heilmann (previously working for Mozilla), mentioning at least the MathML in HTML5 Implementation Note and its test suite as a starting point. MathML is currently on the first page of the most voted feature requested for Microsoft Edge and given the new direction taken with Microsoft Edge, I hope we could start a discussion on MathML in EdgeHTML...

Conclusion

This was a great hackfest and I'd like to thank again all the participants and sponsors for making it possible! As Alejandro wrote to me, "I think we have started a very interesting work regarding MathML and web engines in the future.". The short term plan is now to land the WebKit MathML refactoring started during the hackfest and to finish the work. I hope people now understand the importance of fonts with an OpenType MATH table for good mathematical rendering and we will continue to encourage browser vendors and font designers to make such fonts wide spread.

The new approach for WebKit MathML support gives good reason to be optmimistic in the long term and we hope we will be able to get high-quality rendering. The fact that the new approach addresses all the issues formulated by Google and that we started a dialogue on math rendering, gives several options for MathML in Blink. It remains to get Microsoft involved in implementing its own OpenType table in EdgeHTML. Overall, I believe that we can now have a very constructive discussion with the individuals/companies who really want native math support, with the Math WG members willing to have their specification implemented in browsers and with the browser vendors who want a math implementation which is good, clean and compatible with the rest of their code base. Hopefully, the MathML Association will be instrumental in achieving that. If everybody get involved, 2016 will definitely be an exciting year for native MathML in Web engines!

Re: Formula alignment

Source: www-math@w3.org Mail Archives • Neil Soiffer (NeilS@dessci.com) • December 19, 2015 • Permalink

David's solution is widely used and is what people do in TeX. You do need
add some spacing around the '=' though (probably by overriding
columnspacing).

Another option that is widely supported in renderers is to use <mphantom>
to get alignment. That's pretty hacky though.

There are also options to use with indenttarget, although that still isn't
well implemented even though it isn't that hard to implement. It works well
if the first equation is the left of the second. I.e., if you had
x+1=y
    y=x+1

because you can put the target on the '1'.

Perhaps in MathML 4 we could add a variant of indenting so that all marked
characters align (only the first on a line -- that would handle the common
cases and avoid the complications with maligngroup/malignmark that have
caused others to put off implementing maligngroup/malignmark.

Neil Soiffer
Senior Scientist
Design Science, Inc.
www.dessci.com
~ Makers of MathType, MathFlow, MathPlayer, MathDaisy, Equation Editor ~


On Fri, Dec 18, 2015 at 9:20 AM, David Carlisle <davidc@nag.co.uk> wrote:

> On 18/12/2015 16:56, Daniel Marques wrote:
>
>> Dear MathML group,
>>
>> I’m just wandering how to align formulas given a symbol. For example,
>>
>> __y=x+1
>>
>> x+1=y
>>
>> (where the _ are spaces)
>>
>> Reading the MathML specification, I came up with
>>
>> <mtable>
>>
>>    <mtd>
>>
>>      <mi>y</mi>
>>
>>      <malignmark/>
>>
>>      <mo> = </mo>
>>
>>     <mi>x</mi>
>>
>>      <mo>+</mo>
>>
>>      <mn>1</mn>
>>
>>    </mtd>
>>
>>   <mtd>
>>
>>      <mi>x</mi>
>>
>>      <mo>+</mo>
>>
>>      <mn>1</mn>
>>
>>      <malignmark/>
>>
>>      <mo> = </mo>
>>
>>      <mi>y</mi>
>>
>>    </mtd>
>>
>> </mtable>
>>
>> Do you think that this is the best way to express that?
>>
>
> Apart from a missing mtr (was optional in mathml 1 but not since)
> yes but.....
>
>
> malignmark is one of the trickier areas of mathml and not supported
> in all mathml renderers so if you are targetting a specific system and
> it works then fine, otherwise I'd split it as two columns right aligned
> for the left hand side and left aligned for the rest. Of course that
> suffers from the problem that malignmark was trying to address of
> breaking up the expression structure.
>
>
>
>> Another question is whether the malignmark must appear always inside a
>> table (mtable)
>>
> as specified yes.
>
>  or can be used also combined with <mspace
>
>> linebreak="newline"/>. For example, is the following a valid alternative?
>>
>>    <mrow>
>>
>>      <mi>y</mi>
>>
>>      <malignmark/>
>>
>>      <mo> = </mo>
>>
>>     <mi>x</mi>
>>
>>      <mo>+</mo>
>>
>>      <mn>1</mn>
>>
>>      <mspace linebreak="newline"/>
>>
>>      <mi>x</mi>
>>
>>      <mo>+</mo>
>>
>>      <mn>1</mn>
>>
>>      <malignmark/>
>>
>>      <mo> = </mo>
>>
>>      <mi>y</mi>
>>
>>    </mrow>
>>
>> Dani
>>
>>
> I was going to show that that was invalid but it turns out that
> it is invalid according to the prose but the constraint that malignmark
> only appears in tables isn't checked by the schema. (In principle it
> could do but it would greatly complicate the relax schema as you'd have
> to carry the fact that you were inside a table through arbitrary pattern
> rules.  I suppose the XSD schema could have had an xpath assertion
> saying explicitly that all malignmark are within a table.
>
>
> David
>
> ________________________________
>
>
> The Numerical Algorithms Group Ltd is a company registered in England and
> Wales with company number 1249803. The registered office is:
>
> Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
>
>
>
> This e-mail has been scanned for all viruses by Microsoft Office 365.
>
> ________________________________
>
>

RE: Formula alignment

Source: www-math@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • December 18, 2015 • Permalink

Thank you very much David for the response and very fast in answering.  As
always you do!!!

-----Original Message-----
From: David Carlisle [mailto:davidc@nag.co.uk]
Sent: viernes, 18 de diciembre de 2015 18:21
To: www-math@w3.org
Subject: Re: Formula alignment

On 18/12/2015 16:56, Daniel Marques wrote:
> Dear MathML group,
>
> I’m just wandering how to align formulas given a symbol. For example,
>
> __y=x+1
>
> x+1=y
>
> (where the _ are spaces)
>
> Reading the MathML specification, I came up with
>
> <mtable>
>
>    <mtd>
>
>      <mi>y</mi>
>
>      <malignmark/>
>
>      <mo> = </mo>
>
>     <mi>x</mi>
>
>      <mo>+</mo>
>
>      <mn>1</mn>
>
>    </mtd>
>
>   <mtd>
>
>      <mi>x</mi>
>
>      <mo>+</mo>
>
>      <mn>1</mn>
>
>      <malignmark/>
>
>      <mo> = </mo>
>
>      <mi>y</mi>
>
>    </mtd>
>
> </mtable>
>
> Do you think that this is the best way to express that?

Apart from a missing mtr (was optional in mathml 1 but not since) yes
but.....


malignmark is one of the trickier areas of mathml and not supported in all
mathml renderers so if you are targetting a specific system and it works
then fine, otherwise I'd split it as two columns right aligned for the left
hand side and left aligned for the rest. Of course that suffers from the
problem that malignmark was trying to address of breaking up the expression
structure.


>
> Another question is whether the malignmark must appear always inside a
> table (mtable)
as specified yes.

  or can be used also combined with <mspace
> linebreak="newline"/>. For example, is the following a valid alternative?
>
>    <mrow>
>
>      <mi>y</mi>
>
>      <malignmark/>
>
>      <mo> = </mo>
>
>     <mi>x</mi>
>
>      <mo>+</mo>
>
>      <mn>1</mn>
>
>      <mspace linebreak="newline"/>
>
>      <mi>x</mi>
>
>      <mo>+</mo>
>
>      <mn>1</mn>
>
>      <malignmark/>
>
>      <mo> = </mo>
>
>      <mi>y</mi>
>
>    </mrow>
>
> Dani
>

I was going to show that that was invalid but it turns out that it is
invalid according to the prose but the constraint that malignmark only
appears in tables isn't checked by the schema. (In principle it could do but
it would greatly complicate the relax schema as you'd have to carry the fact
that you were inside a table through arbitrary pattern rules.  I suppose the
XSD schema could have had an xpath assertion saying explicitly that all
malignmark are within a table.


David

________________________________


The Numerical Algorithms Group Ltd is a company registered in England and
Wales with company number 1249803. The registered office is:

Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.



This e-mail has been scanned for all viruses by Microsoft Office 365.

________________________________

Re: Formula alignment

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

On 18/12/2015 16:56, Daniel Marques wrote:
> Dear MathML group,
>
> I’m just wandering how to align formulas given a symbol. For example,
>
> __y=x+1
>
> x+1=y
>
> (where the _ are spaces)
>
> Reading the MathML specification, I came up with
>
> <mtable>
>
>    <mtd>
>
>      <mi>y</mi>
>
>      <malignmark/>
>
>      <mo> = </mo>
>
>     <mi>x</mi>
>
>      <mo>+</mo>
>
>      <mn>1</mn>
>
>    </mtd>
>
>   <mtd>
>
>      <mi>x</mi>
>
>      <mo>+</mo>
>
>      <mn>1</mn>
>
>      <malignmark/>
>
>      <mo> = </mo>
>
>      <mi>y</mi>
>
>    </mtd>
>
> </mtable>
>
> Do you think that this is the best way to express that?

Apart from a missing mtr (was optional in mathml 1 but not since)
yes but.....


malignmark is one of the trickier areas of mathml and not supported
in all mathml renderers so if you are targetting a specific system and
it works then fine, otherwise I'd split it as two columns right aligned
for the left hand side and left aligned for the rest. Of course that
suffers from the problem that malignmark was trying to address of
breaking up the expression structure.


>
> Another question is whether the malignmark must appear always inside a
> table (mtable)
as specified yes.

  or can be used also combined with <mspace
> linebreak="newline"/>. For example, is the following a valid alternative?
>
>    <mrow>
>
>      <mi>y</mi>
>
>      <malignmark/>
>
>      <mo> = </mo>
>
>     <mi>x</mi>
>
>      <mo>+</mo>
>
>      <mn>1</mn>
>
>      <mspace linebreak="newline"/>
>
>      <mi>x</mi>
>
>      <mo>+</mo>
>
>      <mn>1</mn>
>
>      <malignmark/>
>
>      <mo> = </mo>
>
>      <mi>y</mi>
>
>    </mrow>
>
> Dani
>

I was going to show that that was invalid but it turns out that
it is invalid according to the prose but the constraint that malignmark
only appears in tables isn't checked by the schema. (In principle it
could do but it would greatly complicate the relax schema as you'd have
to carry the fact that you were inside a table through arbitrary pattern
rules.  I suppose the XSD schema could have had an xpath assertion
saying explicitly that all malignmark are within a table.


David

________________________________


The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:

Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.



This e-mail has been scanned for all viruses by Microsoft Office 365.

________________________________

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.

(feed)This page as an Atom feed

A mechanical calculation machine (with an added W3C logo)

Bert Bos, math activity lead
Copyright © 2008–2015 W3C®

Powered by Planet