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.
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 |
(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
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.
Programmers' Heaven - Found Feb. 2,
2016 • MathML equations rendering inside shapes implemented • MathML equations vertical positioning improved when rendering • Improved... |
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 |
PR.com - Found Jan. 30,
2016 • MathML equations rendering inside shapes implemented • MathML equations vertical positioning improved when rendering • Improved... |
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
W3C - Found Jan. 18, 2016 Other features include support for HTML5 (including the element), MathML, SVG, XSLT, JavaScript, and accessible PDF. (Java. |
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 |
W3C - Found Jan. 14, 2016 Other features include support for HTML5 (including the element), MathML, SVG, XSLT, JavaScript, and accessible PDF. (Java. |
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 >
W3C - Found Jan. 12, 2016 Other features include support for HTML5 (including the element), MathML, SVG, XSLT, JavaScript, and accessible PDF. (Java. |
After a smooth beta run, we’re happy to officially release MathJax v2.6. This release focused on two main features:
Completing the CommonHTML output, a faster HTML output that can be generated on both client and server.
Accessibility improvements in the form of
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
and starting today the files at the
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.
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.
If you are using a combined configuration, please note the following:
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
.
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.
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.
Accessibility improvements. We thank the AT community for their guidance, support, and feedback in our efforts towards making MathJax completely accessible to all users.
AssistiveMML
extension enables
compatibility with most MathML-capable screenreaders by inserting
visually-hidden MathML alongside MathJax’s visual output. See
screenreader support <screenreader-support> for details on
the expected behavior as well as background on the limitations due
to lack of web standards and browser/OS technology.* Accesssible UI. We have improved the accessibility of the MathJax menu to enable assistive technology users to easily access its features, cf. MathJax UI <mathjax-ui-a11y>.
<annotation-xml>
elements. This
helps with accessibility and copy&paste of document
fragments.bower install
components/MathJax
to install a fork of MathJax without PNG
fonts. Many thanks to @minrk from the IPython/Jupyter team
and to the team at components!npm install mathjax
to install a copy of
MathJax without PNG fonts.MMLorHTML
extension. For
a detailed guide on configuring MathJax to choose different outputs
on different browsers, please see Automatic Selection of the Output
Processor <automatic-output-switch> for more
information.Numerous bugs and issues have also been resolved; for a detailed listing please check the release milestone.
MathZoom.js
: global
border-box support. Special thanks to @CalebKesterblacker
setting to 1.useFontCache=false
.mtext
elements.overparen
and
underparen
to provide
stretchy arcs above/belowmhchem
extension to use
multiscripts, cf. #1072.\alignedat
.\binom
and friends.\operatorname
not ignoring
\limits
that follow
immediately after.\eqnarray
environment.scriptlevel
set on arrays
via an mstyle
node (affects
\smallmatrix
).overparen
,
underparen
to produce
mover
and munder
constructs.bowtie
,
ltimes
and rtimes
.mmultiscript
elements (after
clarification in MathML 3 editors’ draft); cf. #956.toMathML
from changing
<maligngroup>
to
<malign>
mmultiscripts
with odd
number of post-scripts not rendering correctly.<math>
element not
being treated as an <mrow>
for embellished operator
spacing.<maligngroup>
and
<malignmark>
be
self-closing in MathML input.mml3.js
: better RTL support
in HTML-CSS; improved IE/Edge compatibility.U+2322 (FROWN)
,
U+2323 (SMILE)
, and also
U+2312 (ARC)
to be aliases
for the top and bottom parentheses. This enables stretchy
constructions; cf. also #567.bower install components/MathJax
for a
copy without PNG fonts. Special thanks to @minrk from the IPython/Jupyter team
and to the team at components!/test
: add
viewport meta tags, improve dynamic examples.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
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 > > > >
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.
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!
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 :-)
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:
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:
computePreferredLogicalWidths
which sets the
preferred width of the fraction during the first layout pass, by
considering the widest between numerator and denominator.layoutBlock
and firstLineBaseline
which calculate the final width/height/ascent of the fraction
element and position the numerator and denominator.paint
which draws the fraction bar.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.
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.
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...
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!
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. > > ________________________________ > >
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. ________________________________
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. ________________________________
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.