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.

en-US December 15, 2014 Project Euclid continues as a MathJax Supporter

Author: Peter Krautzberger | Channel: MathJax

Project Euclid continues to support the MathJax project as a MathJax Supporter.

Project Euclid is a not-for-profit online publishing service designed to address the unique needs of the fields of theoretical and applied mathematics and statistics by providing access to independent and society journals, monographs, and conference proceeding. Through a collaborative partnership arrangement, publishers join forces and participate in an online presence with advanced functionality, allowing them to better serve scholars without sacrificing their intellectual or economic independence or commitment to low subscription prices. Project Euclid is jointly managed by Cornell University Library and Duke University Press.

“We initially implemented MathJax on twenty titles, since then we have significantly expanded its use on Project Euclid” says Mira Waller, Director of Publishing Services. “MathJax has become an important part of Project Euclid’s display of math on the web and we are proud to continue our support of this valuable service.”

“The continued support of Project Euclid demonstrates its commitment to being a partner to the science community on the web”, comments Peter Krautzberger, MathJax Manager. “The feedback of sponsors such as Project Euclid is invaluable to ensure that MathJax remains the reliable, high-quality rendering solution it is today.”

The MathJax team looks forward to the continued collaboration with Project Euclid, and welcomes their ongoing support for the MathJax project.

UND December 09, 2014 Re: Fwd: FW: Problem with MathML3 schema

Author: David Carlisle (davidc@nag.co.uk) | Channel: www-math@w3.org Mail Archives

On 08/12/2014 20:42, Autumn Cuellar wrote:
> Hi,
>
> Tom Magliery at JustSystems seems to have spotted an issue in the MathML
> 3 Schema. I believe he's correct but wouldn't claim to be an XML Schema
> expert. What say you?
>
> Thanks,
> Autumn
>
> *From:* Tom Magliery [mailto:tom.magliery@justsystems.com
> <mailto:tom.magliery@justsystems.com>]
> *Sent:* Friday, December 05, 2014 4:16 PM
> *To:* Autumn Cuellar
> *Subject:* Problem with MathML3 schema____
>
> __ __
>
> Hi Autumn,____
>
> __
>
> __
>
> We think there's an invalid definition in the XSD for MathML 3. The
> issue occurs within mathml3-strict-content.xsd.____
>
> http://www.w3.org/Math/XMLSchema/mathml3/____
>
> On line 65, they define a group, “semantics-ci” and that group includes
> itself on line 72; according to our understanding of XSD this is not
> allowed:____
>
> __ __
>
> ---------------------------------------------------------------------------------____
>
> http://www.w3.org/TR/xmlschema-1/#coss-modelGroup____
>
> __ __
>
> 2 Circular groups are disallowed. That is, within the {particles} of a
> group there must not be at any depth a particle whose {term} is the
> group itself.____
>
> ---------------------------------------------------------------------------------____
>
> __ __
>
> I guess I'll start with: are we misunderstanding something?____
>
> __ __
>
> The XSDs are not normative for MathML, but this sure seems like an error
> that someone would have discovered before. (Then again, I have been on
> the DITA TC long enough to understand/believe that something like this
> could happen.)____
>
> __ __
>
> mag____
>

Hmm reading the XSD spec (always a delight:-) it seems you are right.
I'd be interested to know how you spotted that? Thanks.

The construct is generated by trang as a translation from a recursive
pattern in the Relax NG. Trang can not translate everything and already
the conversion pipeline has some transformations that simplify the Relax
NG before doing the translation. So we could add another....

It seems it got missed because XSV and xmllint -schema (xerces) both
not only accept the schema without warning, they validate using this
construct as intended. So before changing the MathML schema I may make
some enquiries to check the XSD spec does mean to say what it appears to
say. (I am certainly no expert in XSD schema).


The intention was to make <semantics> have a context sensitive content
model so that the first child is only allowed to be semantics again,
or an element that would have been allowed at that point without the
semantics (ci here).

The simplest fix is to drop that and make the same rule as in the DTD
that the first child of semantics can be any MathML (and leave further
requirements to the text of the spec and the relax NG).

Specifically you can change the definition to

    <xs:group name="semantics-ci">
     <xs:choice>
     <xs:element ref="m:ci"/>
     <xs:group ref="m:semantics"/>
     </xs:choice>
    </xs:group>





  That successfully validates

<math xmlns="http://www.w3.org/1998/Math/MathML">
  <bind>
   <csymbol>forall</csymbol>
   <bvar>
   <semantics>
    <ci>x</ci>
    <annotation></annotation>
   </semantics>
   </bvar>
  </bind>
</math>

but it no longer enforces that the content of bvar is a ci, possibly 
annotated, and this would be valid to the XSD (as it is to the DTD)

<math xmlns="http://www.w3.org/1998/Math/MathML">
  <bind>
   <csymbol>forall</csymbol>
   <bvar>
   <semantics>
    <cn>2</cn>               <!-- cn here -->
    <annotation></annotation>
   </semantics>
   </bvar>
  </bind>
</math>

But with the schema as it currently both XSV and xerces declare the 
first one valid and the second invalid.


David

UND December 08, 2014 Fwd: FW: Problem with MathML3 schema

Author: Autumn Cuellar (autumn.cuellar@gmail.com) | Channel: www-math@w3.org Mail Archives

Hi,

Tom Magliery at JustSystems seems to have spotted an issue in the MathML 3
Schema. I believe he's correct but wouldn't claim to be an XML Schema
expert. What say you?

Thanks,
Autumn

*From:* Tom Magliery [mailto:tom.magliery@justsystems.com]
*Sent:* Friday, December 05, 2014 4:16 PM
*To:* Autumn Cuellar
*Subject:* Problem with MathML3 schema



Hi Autumn,



 We think there's an invalid definition in the XSD for MathML 3. The issue
occurs within mathml3-strict-content.xsd.

http://www.w3.org/Math/XMLSchema/mathml3/

On line 65, they define a group, “semantics-ci” and that group includes
itself on line 72; according to our understanding of XSD this is not
allowed:



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

http://www.w3.org/TR/xmlschema-1/#coss-modelGroup



2 Circular groups are disallowed. That is, within the {particles} of a
group there must not be at any depth a particle whose {term} is the group
itself.

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



I guess I'll start with: are we misunderstanding something?



The XSDs are not normative for MathML, but this sure seems like an error
that someone would have discovered before. (Then again, I have been on the
DITA TC long enough to understand/believe that something like this could
happen.)



mag

UND December 05, 2014 Re: Ideas for future improvements

Author: Frédéric WANG (fred.wang@free.fr) | Channel: www-math@w3.org Mail Archives

Le 05/12/2014 09:05, William F Hammond a écrit :
> Not if the fences wind up being constructed with CSS as enhanced
> border decorations (somewhat beyond what is presently available in
> CSS) with precise effortless stretching as a bonus. Having the fence
> specs in <mo>'s would be awkward for that.
This won't work for the "separator" attribute or for general Unicode
characters that don't have a CSS border definition. And we still need to
implement stretchy rules anyway, so using CSS is only helpful for the
simplest cases like those of Opera's stylesheet.
> Moreover, the fence operators are not semantically the same as other
> operators, and there is no definitive way to tell whether operators
> that are fence-like first and last children in <mrow> are really there
> as fences. For example, in [f(x)]_{x=a}^{x=b} (which resolves as math
> to f(b)-f(a)) the brackets are non-fence operators. Of course,
> presentation mathml is semantically poor from the outset, but this
> doesn't mean that whatever semantics are there should be trashed. 
Then I believe you are doing something wrong. The spec says that "any
|mfenced| element is completely equivalent to an expanded form described
below" and "In particular, authors cannot be guaranteed that MathML
preprocessors won't replace occurrences of mfenced with equivalent
expanded forms. ". So if you want to preserve any kind of semantics you
should use a "class" attribute or a <semantics> element with parallel
markup and not rely on a presentation element name.
> Don't forget that there are many implementations other than browser
> rendering, both for generating mathml and for consuming it. If people
> believe that MathML documents are not durable at least for the extent
> of their lifetimes, they will run from MathML. [...] It would also
> break the paradigm of XML. A document spec-ed as XHTML 1 + MathML 2
> should be durable forever. [...]  BTW, I believe there has been this
> debate about <mfenced> virtually from the beginning of mathml.
What you say makes sense, but it's probably this kind of reasoning that
makes MathML not attractive to Web browser companies.

-- 
Frédéric Wang
maths-informatique-jeux.com/blog/frederic



UND December 05, 2014 Re: Ideas for future improvements

Author: William F Hammond (hammond@csc.albany.edu) | Channel: www-math@w3.org Mail Archives

Frédéric WANG <fred.wang@free.fr> writes:

> - The structure is quite different because the operators in <mfenced>
> are in attribute values rather than in elements. As a consequence,
> native implementations need to create anonymous frames to represent
> these operators.

Not if the fences wind up being constructed with CSS as enhanced border
decorations (somewhat beyond what is presently available in CSS) with
precise effortless stretching as a bonus.  Having the fence specs
in <mo>'s would be awkward for that.

Moreover, the fence operators are not semantically the same
as other operators, and there is no definitive way to tell
whether operators that are fence-like first and last
children in <mrow> are really there as fences.  For example,
in [f(x)]_{x=a}^{x=b} (which resolves as math to f(b)-f(a))
the brackets are non-fence operators.  Of course,
presentation mathml is semantically poor from the outset,
but this doesn't mean that whatever semantics are there
should be trashed.

> - Deprecating will not break conforming implementations (they implement
> the two versions, as currently required by the spec) but only poor
> implementations like the one that used to be in Opera. As said by
> William, the only risk is breaking old documents.

Don't forget that there are many implementations other than browser
rendering, both for generating mathml and for consuming it.

If people believe that MathML documents are not durable at least for
the extent of their lifetimes, they will run from MathML.

Don't we remember the breakage in Firefox when <mlabeledtr>
was pulled from Firefox?  It had consequences.  Yes, that
element was of limited use, but it had some use, some were
using it, and they were annoyed.

> What I'm proposing is that browsers display a deprecation
> warning and encourage people to move to the equivalent
> version, to prepare future removal in a (very) long term.

It would also break the paradigm of XML.  A document spec-ed as
XHTML 1 + MathML 2 should be durable forever.

BTW, I believe there has been this debate about <mfenced>
virtually from the beginning of mathml.

                                    -- Bill

UND December 04, 2014 Re: Ideas for future improvements

Author: Frédéric WANG (fred.wang@free.fr) | Channel: www-math@w3.org Mail Archives

Le 03/12/2014 23:29, Murray Sargent a écrit :
> <nary> has three arguments: two limits and a n_aryand, whereas the pot pourri tags don't identify the n-aryand.
In MathML this is <munderover>A B C</munderover>

where A is an <mo> with property "largeop" (explicitly or from the
operator dictionary). The "movablelimits" of the <mo> property indicates
whether they should become subsup in inline mode.

(I agree having <mover></mover> and <munder></munder> seems a bit
duplicate, but in Gecko we end up merging the implementations, which
does not seem trivial with <mfenced>)

> A delimiter object is handy since you measure its contents and then display the result with brackets that fit (according to special rules)
<mfenced> is equivalent to <mrow> as specified by the MathML spec.
Again, you need to use the operator dictionary to determine whether the
first and last child are stretchy / fences. This just need some
additional verifications on the first and last child, but that won't
make layout or a11y algorithms harder.

> For the same reason, I prefer <mfract> to <mrow>...<mo>/</mo>...</mrow>. We use nontrivial code to convert the inline versions to the prefix versions.
This is <mfrac bevelled="true"> in MathML.
> In any event, this is all water over the dam. Deprecating any Presentation MathML tags would break too many implementations.
<mfenced> is different to what you mention above:

- The spec explicitly indicates the equivalent markup and requires the
implementation to render the two versions exactly the same. You can not
choose the one version you prefer, so implementers have double work.

- The structure is quite different because the operators in <mfenced>
are in attribute values rather than in elements. As a consequence,
native implementations need to create anonymous frames to represent
these operators.

- Deprecating will not break conforming implementations (they implement
the two versions, as currently required by the spec) but only poor
implementations like the one that used to be in Opera. As said by
William, the only risk is breaking old documents. What I'm proposing is
that browsers display a deprecation warning and encourage people to move
to the equivalent version, to prepare future removal in a (very) long term.

-- 
Frédéric Wang
maths-informatique-jeux.com/blog/frederic



UND December 04, 2014 Re: Ideas for future improvements

Author: Peter Krautzberger (peter.krautzberger@mathjax.org) | Channel: www-math@w3.org Mail Archives

> In any event, this is all water over the dam. Deprecating any
Presentation MathML tags would break too many implementations.

In the context of browser implementations, there are not many
implementations to "break", especially if such ideas end up helping browser
vendors to actually implement MathML. Converting to such a "restricted"
profile seems trivial.

Peter.


On Wed, Dec 3, 2014 at 11:29 PM, Murray Sargent <
murrays@exchange.microsoft.com> wrote:

> Re <mfenced> I think it should be kept and I'd prefer if <mnary> were used
> instead of the pot pourri <msup>, <msub>, <msubsup>, <mover>, <munder>,
> <munderover> for n-ary expressions. In OMML, there's <d> (essentially
> <mfenced>) for delimited objects (parenthetical/bracketed expressions) and
> there's <nary> for n-ary expressions. <nary> has three arguments: two
> limits and a n_aryand, whereas the pot pourri tags don't identify the
> n-aryand. OMML is an XML where you know from the opening tag what the
> object is, whereas Presentation MathML needs sophisticated parsing much
> along the lines needed for the Unicode plain text encoding of mathematics (
> http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf). In fact,
> the Microsoft Office MathML parser uses the rich-text string stack
> originally developed for building up plain-text math content.
>
> The main math layout ideas are documented in The TeXbook in Appendix G. In
> particular, you have objects with arguments and you measure the arguments
> (recursively) and place them along with lines, etc. as needed for the
> objects. A delimiter object is handy since you measure its contents and
> then display the result with brackets that fit (according to special
> rules). The inline approach seems more complicated to me. At least it
> requires a different approach from objects such as <menclose>. For the same
> reason, I prefer <mfract> to <mrow>...<mo>/</mo>...</mrow>. We use
> nontrivial code to convert the inline versions to the prefix versions.
>
> In any event, this is all water over the dam. Deprecating any Presentation
> MathML tags would break too many implementations.
>
> Murray
>

UND December 03, 2014 RE: Ideas for future improvements

Author: Murray Sargent (murrays@exchange.microsoft.com) | Channel: www-math@w3.org Mail Archives

Re <mfenced> I think it should be kept and I'd prefer if <mnary> were used instead of the pot pourri <msup>, <msub>, <msubsup>, <mover>, <munder>, <munderover> for n-ary expressions. In OMML, there's <d> (essentially <mfenced>) for delimited objects (parenthetical/bracketed expressions) and there's <nary> for n-ary expressions. <nary> has three arguments: two limits and a n_aryand, whereas the pot pourri tags don't identify the n-aryand. OMML is an XML where you know from the opening tag what the object is, whereas Presentation MathML needs sophisticated parsing much along the lines needed for the Unicode plain text encoding of mathematics (http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf). In fact, the Microsoft Office MathML parser uses the rich-text string stack originally developed for building up plain-text math content.

The main math layout ideas are documented in The TeXbook in Appendix G. In particular, you have objects with arguments and you measure the arguments (recursively) and place them along with lines, etc. as needed for the objects. A delimiter object is handy since you measure its contents and then display the result with brackets that fit (according to special rules). The inline approach seems more complicated to me. At least it requires a different approach from objects such as <menclose>. For the same reason, I prefer <mfract> to <mrow>...<mo>/</mo>...</mrow>. We use nontrivial code to convert the inline versions to the prefix versions.

In any event, this is all water over the dam. Deprecating any Presentation MathML tags would break too many implementations.

Murray

en-US December 03, 2014 The London Mathematical Society continues as MathJax supporter

Author: Peter Krautzberger | Channel: MathJax

The London Mathematical Society continues to support MathJax as a MathJax Supporter.

The London Mathematical Society (LMS) is the major UK learned society for mathematics with a nationwide and international membership. The LMS offers a rich publishing program, provides a diverse grant program, and organizes scientific meetings and lectures. Beyond that, the LMS contributes to public debate on matters affecting mathematics and mathematics education.

“LMS offers MathJax full-text HTML as an alternative to PDF on five of its journals and is preparing to implement it on further journals.” comments Dr. Ola Tornkvist,
Managing Editor, LMS, “Feedback from readers has been positive, focusing on improved navigation and ease of access when looking something up in a paper. The LMS is pleased to continue to support the MathJax project.“

“Thanks to our dedicated sponsors like the LMS, we are able to develop MathJax continuously,” comments Peter Krautzberger, MathJax manager. “We are grateful for the continued support which allows us to keep MathJax the high-quality and universal rendering solution it is today”.

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

UND December 03, 2014 Re: Ideas for future improvements

Author: Frédéric WANG (fred.wang@free.fr) | Channel: www-math@w3.org Mail Archives

Le 03/12/2014 08:07, William F Hammond a écrit :
>  But (1) the markup is actually richer with it,
What do you mean by richer? It duplicates an existing feature and so
does not bring anything more from my point of view. Do you also want to
introduce <combination>...</combination> as a shorthand for <mfrac
linethickness="0px">?
> (2) it is convenient in the way that you observe [consistent with the
> what-wg sense of convenience], and
I said it was convenient for bad implementation of MathML ; I don't
think this should be a motivation to keep it.
> (3) it's an additional hook for CSS, that is helpful.
<mfenced> uses attributes, which make it bad for CSS styling of
individual separators / fences compared to the expanded form (or even
bad to apply MathML attributes to these elements). So I'm not sure what
you mean here.
> Also deprecation usually precedes removal, and removal would break old
> documents. -- Bill 
That's the point, although I'm sure the MathML WG will be willing to
keep it for this kind of reason. The removal is for the long term
(several years). In my opinion it should have been deprecated long ago.

Anyway, I expect that <mfenced> can be implemented using shadow tree and
Web components so that it could be dropped from native MathML
implementations, without breaking existing old documents.

-- 
Frédéric Wang
maths-informatique-jeux.com/blog/frederic



UND December 03, 2014 Re: Ideas for future improvements

Author: William F Hammond (hammond@csc.albany.edu) | Channel: www-math@w3.org Mail Archives

Frédéric WANG <fred.wang@free.fr> writes:

> * <mfenced> should be deprecated as it duplicates its equivalent
> <mrow>+<mo> expansion and thus adds more code to implementation. For
> native implementation like WebKit/Gecko this typically means creating
> many anonymous frames (for separators and open/close). This is a mess to
> make the mfenced rendering 100% equivalent to the <mrow>+<mo> expansion,
> to handle edge cases when parsing the attributes or to manage memory
> allocation/desallocation after dynamic changes. It seems that the only
> reason for this element is that it is a convenient shorthand for
> rudimentary implementations that don't know about the operator
> dictionary or have bad mo support in general (in some a11y tools or in
> Opera Presto).

I think <mfenced> should be kept without deprecation.  I
know that the spec makes it no different from
<mrow>+<mo> for native rendering.  But (1) the markup is
actually richer with it, (2) it is convenient in the way
that you observe [consistent with the what-wg sense of
convenience], and (3) it's an additional hook for CSS, that
is helpful.  Also deprecation usually precedes removal, and
removal would break old documents.

                                    -- Bill

UND December 02, 2014 HTML5 Standard Brings Many Useful Features

Channel: Ask.com News Search for "mathml"

TMC Net - Found Dec. 2, 2014
... minimize plugins, including functionality for displaying vector graphics (SVG files) and mathematical notations (MathML), the new element for...

UND December 02, 2014 CICM 2015: Call for Workshops

Author: Serge Autexier (serge.autexier@dfki.de) | Channel: www-math@w3.org Mail Archives

                     Call for Workshop Proposals
                                                                                 
     CICM 2015 - Conference on Intelligent Computer Mathematics
                           July 13-17, 2015
       The George Washington University, Washington, D.C , USA
                 http://www.cicm-conference.org/2015

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

As   computers   and   communications  technology   advance,   greater
opportunities arise  for intelligent mathematical  computation.  While
computer  algebra, automated  deduction,  mathematical publishing  and
novel user interfaces individually have long and successful histories,
we are  now seeing  increasing opportunities  for synergy  among these
areas.  The Conference  on  Intelligent  Computer Mathematics  (CICM)
offer a venue for discussing these areas and their synergy.

CICM has been held annually as  a joint meeting since 2008, colocating
related conferences and  workshops to advance work  in these subjects.
Previous meetings have been held in Birmingham (U.K. 2008), Grand Bend
(Canada  2009), Paris  (France 2010),  Bertinoro (Italy  2011), Bremen
(Germany 2012), Bath (U.K. 2013) and Coimbra (Portugal, 2014).

This is a  call for proposals for  workshops to be held  at CICM 2015,
which will be held in Washington D.C. (USA), July 13-17 next year.

The principal tracks of the 2015 meeting will be

  Calculemus (Symbolic Computation and Mechanised Reasoning)
  DML (Towards a Digital Mathematics Library)
  MKM (Mathematical Knowledge Management)
  Systems and Data

Some of the workshops that have been held at past CICM meetings are:

  Automated Reasoning: Bridging the Gap between Theory and Practice
  Compact Computer Algebra
  Empirically Successful Automated Reasoning for Mathematics
  Intelligent Proof Search
  Mathematical user Interfaces
  OpenMath
  Pen-Based Mathematical Computation
  Programming languages for Mechanized Mathematics Systems
  SCIEnce
  The Notion of Proof

Proposals for workshops  to be held at CICM  2015 are solicited.  Both
well-established workshops and newer or brand new ones are encouraged.

Please provide the following information:
 
 + Workshop title.
 + Names and affiliations of organizers.
 + Brief description of workshop goals and/or topics.
 + Proposed workshop duration (half a day up to two days is possible).
 + If the workshop has met previously, please include the conference 
   affiliation for the previous meeting. If the workshop is new, 
   please indicate so.

CICM  will take  care  of copying  and  distributing informal  printed
proceedings for  workshops that  would like this  service, as  well as
permanently archived open access online proceedings with CEUR-WS.org.

All proposals should be sent via email to

             cicm-organizers@cs.bham.ac.uk

for consideration by the CICM 2015 organizers:

 Local Organization Chairs:    Bruce Miller    (NIST)
                               Abdou Youssef   (GWU, USA)
 General Program Chair:        Manfred Kerber  (U. Birmingham, UK)
 Calculemus Track Chair:       Jacques Carette (McMaster U., Canada)
 DML Track Chair:              Volker Sorge    (U. Birmingham, UK)
 MKM Track Chair:              Cezary Kaliszyk (U. Innsbruck, Austria)
 System & Data Chair:          Florian Rabe    (JUB, Germany)
 Workshop Chair:               Serge Autexier  (DFKI, Germany)

Important dates:

 Deadline for proposal submissions:                   January 23, 2015
 Acceptance/rejection notification:                   February 4, 2015
 Workshop dates:                                      July 13-17, 2015

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

UND December 02, 2014 Seeking: Canonicalizer for presentation MathML

Author: Deyan Ginev (d.ginev@jacobs-university.de) | Channel: www-math@w3.org Mail Archives

Dear Math working group,
   dear MathML enthusiasts,

I am seeking a tool for canonicalization of presentation MathML, that is
as true as possible to the MathML specification, as well as the "intent"
behind the specification.

In other words, I am wondering if there is a piece of software (e.g. an
XSLT stylesheet) that is endorsed either by the W3C MathML group itself,
or at least "looks reasonable" to individual members.
I have seen a number of open source projects online that tackle the
problem, but I lack an overview of their maturity and compliance to the
spec. Hence, I am asking for advice.

To state the obvious, the ideal tool would map any two presentation
trees that (are intended to) render the same, to the same canonical
expression.

Thanks for any leads,
Deyan

UND November 28, 2014 Things you can do with MathML | Joseph Rex

Author: Joseph Rex | Channel: mathml - Google Blog Search

For a while, I've been enjoying the awesomeness of mathML. I've not had specific use cases but just playing around with it gives me fun. Sometimes I idly just write equations that should be on a paper in my local web pages.

UND November 24, 2014 Open Source Insider: Berners-Lee: new HTML5 'open web' milestones

Channel: Ask.com News Search for "mathml"

Computer Weekly - Found Nov. 24, 2014
• programmatic access to a resolution-dependent bitmap canvas • native support for scalable vector graphics (SVG) and math (MathML);

en-US November 20, 2014 HTML5 is a W3C Recommendation

Author: Ian Jacobs | Channel: W3C News

HTML5 The HTML Working Group today published HTML5 as W3C Recommendation. This specification defines the fifth major revision of the Hypertext Markup Language (HTML), the format used to build Web pages and applications, and the cornerstone of the Open Web Platform.

Today we think nothing of watching video and audio natively in the browser, and nothing of running a browser on a phone,” said Tim Berners-Lee, W3C Director. “We expect to be able to share photos, shop, read the news, and look up information anywhere, on any device. Though they remain invisible to most users, HTML5 and the Open Web Platform are driving these growing user expectations.

HTML5 brings to the Web video and audio tracks without needing plugins; programmatic access to a resolution-dependent bitmap canvas, which is useful for rendering graphs, game graphics, or other visual images on the fly; native support for scalable vector graphics (SVG) and math (MathML); annotations important for East Asian typography (Ruby); features to enable accessibility of rich applications; and much more.

The HTML5 test suite, which includes over 100,000 tests and continues to grow, is strengthening browser interoperability. Learn more about the Test the Web Forward community effort.

With today’s publication of the Recommendation, software implementers benefit from Royalty-Free licensing commitments from over sixty companies under W3C’s Patent Policy. Enabling implementers to use Web technology without payment of royalties is critical to making the Web a platform for innovation.

Read the Press Release, testimonials from W3C Members, and acknowledgments. For news on what’s next after HTML5, see W3C CEO Jeff Jaffe’s blog post: Application Foundations for the Open Web Platform. We also invite you to check out our video Web standards for the future.

UND November 06, 2014 Display MathML with Html5-Javascript solution

Author: Ionel Alexandru (noreply@blogger.com) | Channel: FMath

Hi,

    A new solution to display MathML on web using only HTML 5  / Javascript technologies is available for download: http://www.fmath.info/java/download.jsp

A page with examples for all tags and how to use:
http://www.fmath.info/formula/js/how_to_use.jsp

The list of tags implemented from MathML is here:
http://www.fmath.info/whatIsImplemented.jsp

An example for mroot and msqrt tags (ltr and rtl implementation):



regards
Ionel Alexandru

en November 06, 2014 MathFlow in Action @ tekom Stuttgart

Author: Bruce Virga | Channel: Design Science News

We will be showing our MathML editing tools at the Tekom conference in Stuttgart, Germany November 11-13, 2014. If you're a technical writer, documentation manager, content strategist, consultant or systems integrator you should know about MathFlow, especially if you're involved in structured XML content. We have tools that work with Oxygen, FrameMaker, Flare, XMetaL, Arbortext and Codex, to name a few. If you or any of your colleagues back at the office are working with any math content at all, visit us in Hall 1, stand 1/C02 to find out about MathFlow.

Don't miss Autumn Cuellar's presentation: What you need to know about the Maths Stack: MathML, MathJax, HTML5, and EPUB 3, on Thursday Nov 13, 08:45 - 09:30, room C7.3 OG.

We hope to see you there!

If you're not going to be able to make it, check out our event schedule to see the other shows we will be attending. We'll also be posting Autumn's slides on the events page after the conference.

Topics in this post: 

en-US November 03, 2014 The MathWorks continues as MathJax Supporter

Author: Peter Krautzberger | Channel: MathJax

The MathWorks continues to support MathJax as a MathJax Supporter.

The MathWorks provides the fundamental tools for research and development in academia and industry. Its leading computing software products, MATLAB and Simulink, help engineers and scientists worldwide to accelerate the pace of discovery, innovation, and development. From industries, such as aerospace and industrial automation, to technical fields, such as financial services and computational biology, to more than 5000 colleges and universities around the world, the tools support teaching and research in a broad range of technical disciplines.

“Through its innovative display engine, MathJax is providing a valuable service to academia and industry,” said Mary Ann Freeman, director of engineering, MATLAB Products, MathWorks. “We are pleased to continue our support of this important initiative, which is focused on bringing the power of mathematics to the web.”

“The continued support of the MathWorks demonstrates its commitment to being a partner to the math science community on the web”, comments Peter Krautzberger, MathJax manager. “The feedback from sponsors like MathWorks is invaluable to ensure that MathJax remains the reliable, high-quality rendering solution it is today.”

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