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

Re: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Robin Berjon (robin@berjon.com) • September 26, 2016 • Permalink

On 23/09/2016 17:54 , Liam R. E. Quin wrote:
> On Fri, 2016-09-23 at 11:03 -0400, Robin Berjon wrote:
> [...]
>>  
>>   function listPeople (people = [], listType) {
>>     return (
>>       <ul className={listType}>
>>         {
>>           people.map(p => <li>{p.name}</li>)
>>         }
>>       </ul>
>>     );
>>   }
> 
> This isn't far removed from JSONiq (or even XQuery).

Yes, that's why I like it. I have long been thinking of doing some kind
of XQuery-like using JSX.

But _sshhhhh_, don't tell the millions of JS developers now using this!

-- 
• Robin Berjon - http://berjon.com/ - @robinberjon
• http://science.ai/ — intelligent science publishing
•

Re: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Jean Kaplansky (jeankap@gmail.com) • September 23, 2016 • Permalink

But it is _very_ much "you got chocolate in my peanut butter" code. Good
thing I like chocolate AND peanut butter. :)

Jean Kaplansky
jeankap@earthlink.net

On Fri, Sep 23, 2016 at 5:54 PM, Liam R. E. Quin <liam@w3.org> wrote:

> On Fri, 2016-09-23 at 11:03 -0400, Robin Berjon wrote:
> [...]
> >
> >   function listPeople (people = [], listType) {
> >     return (
> >       <ul className={listType}>
> >         {
> >           people.map(p => <li>{p.name}</li>)
> >         }
> >       </ul>
> >     );
> >   }
>
> This isn't far removed from JSONiq (or even XQuery).
>
>
>
>

Re: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Liam R. E. Quin (liam@w3.org) • September 23, 2016 • Permalink

On Fri, 2016-09-23 at 11:03 -0400, Robin Berjon wrote:
[...]
> 
>   function listPeople (people = [], listType) {
>     return (
>       <ul className={listType}>
>         {
>           people.map(p => <li>{p.name}</li>)
>         }
>       </ul>
>     );
>   }

This isn't far removed from JSONiq (or even XQuery).

Re: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Robin Berjon (robin@berjon.com) • September 23, 2016 • Permalink

On 22/09/2016 14:51 , Jos de Jong wrote:
> @Robin can you elaborate a bit on your idea? Do you mean that it would
> be trivial to translate a math formula into plain JavaScript which then
> can be evaluated, or to SVG for rendering? Or both?... Do you have
> concrete use cases in mind?

The way JSX works is that you can use markup in your code, like this:

  let foo = <button>ohai!</button>;

That's pretty simple to type out, but obviously to make it useful what
you get out of it is not a string but a data structure. You can then
proceed to manipulating that data structure, injecting it into a DOM,
rendering it to string, etc. You can also embed code, variable, etc,
inside of it, say:

  function listPeople (people = [], listType) {
    return (
      <ul className={listType}>
        {
          people.map(p => <li>{p.name}</li>)
        }
      </ul>
    );
  }

To be clear, I am not suggesting that this should be a major constraint
on the design. But I think it's worth keeping in mind the ability to
have the syntax as something that could be used as a plugin in a
JavaScript transpiler (this is not a very strong constraint, basically
it mostly needs to be disambiguatable from the surrounding context).

What gets returned could be manipulated (eg. you could feed it into a
library to execute it) or it could be rendered.

It's just a thought :)

-- 
• Robin Berjon - http://berjon.com/ - @robinberjon
• http://science.ai/ — intelligent science publishing
•

TPAC 2016 F2F Minutes

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • September 23, 2016 • Permalink

Hi math-on-web CG,

Below are the minutes to the F2F at TPAC.

Given the late notice, the group was very small and we ended up focusing
entirely on accessibility related problems.

@Dani I noticed I didn't represent your example from the whiteboard. Can
you reconstruct it?

Best regards,
Peter.


# 2016-09-20 math-on-webpages CG, TPAC 2016

* Introductions / Present
  * Manuel (Igalia): browser implementations, CSSWG
  * Volker (ProgressiveAccess, U of Birmingham): accessibility interest,
math specifically, also working on MathJax
  * Dani (WIRIS): known for web-based math editor, also handwriting
recognition, putting formulas (any which way), also a11y (but more
rendering).
  * Peter (krautzource): works on MathJax, works on publishing workflow
chainend
* Peter: summarized the activity of the Group
  * still getting to know each other, working on who can contribute on
which areas
  * not about anything like MathML but interests so far are: practical
accessibility, procedural/computational, and incremental layout
improvemenets

## topic: accessibility

* Dani: starting point: we want to go beyond image+alttext
  * exploration, alternative renderings etc
  * if you have MathML you have a tree you can attach to; if you have HTML
or SVG, you also have a tree.
* Volker: our solution applies an "orthogonal" tree to the visual rendering
tree
  * abstracting away the visual layout
* Dani: can we assume a static version of the equation?
  * Volker: we do that to some degree (embed the data structure that
enhances)
    * have done initial exploration for ARIA structure to expose such
information
  * Dani: do you respect the visual output tree hierarchy?
    * Volker: try to but sometimes not possible
    * Dani: do you think it's possible?
      * Peter: not sure it can be. Human understanding is too complicated;
cf. how you visually explore an image/SVG structure. but limitation of the
platform is: tree.
    * Volker: demonstrated some examples from MathJax's accessibility
extensions
      * the data structure is added to the MathML and is preserved in HTML
and SVG rendering
      * while the semantic tree structure is ad-hoc, it seems this wheel
has been invented several times  (conversations with Murray Sargent, Neil
Soiffer etc)
* Dani: I like the idea of a tree that is both semantic and visual
  * can we find something simpler/less powerful but where semantic = visual?
  * [Peter made unhelpful comment until he realized he misunderstood]
* Dani: example: 2+xy
  * <span role="math"> x+2y</span>?
  * but AT might read "ecks too whee", so slap on some aria-labels to fix
that
  * maybe you can add "role=variable" etc.?
    * Peter: cf our DEIMS paper
* Volker: should we have a structure that is independent of the actual DOM
representation
  * e.g., commutative diagrams, chemistry etc have circular semantics that
cannot be mapped to a tree structure
  * Dani: the descendants should be the default descendants
* Peter: there probably is (should be) a connection to SVG a11y
  * e.g., an SVG for a clockface should need some circular component
* Volker: have not followed SVG a11y TF well enough
  * asked Chaals, who said you can't do ProgressiveAccess's style chemistry
exploration with current SVG a11y TF work
* Dani: can we use hmtl trees and references
  * [Dani's example, needs to be reconstructed]
  * Peter: like aria-describedby?
* Peter: what if the visual tree does not match the semantic tree.
  * e.g., \overbrace{a+...+a}{n-times}
  * need to indicate to start at "a"
  * Dani: pointers handle this
  * Volker: so like aria-labledby/describedby
* Peter: what is in the elements in the second tree?
  * Dani if referenced, nothing, but more than that
  * Volker: why do labels and describeby not suffice?
* Peter: I suspect ARIA people will not accept a secondary tree.
  * aria attributes are on the unique tree and, via accessible name
calculation, modify the accessible trees (potentially changing /
overwriting the original content)
  * Dani: how much can you modify this way? E.g., order of the tree
  * Peter: I think you can (vague memory from building menus, specifying
children and, I think their order)
  * Volker: and obviously hacks (Google knowledge cards, taborder, flexbox
direction)
* Volker: have done test implementations to do both two trees and one.
  * with a second tree, you might open up using any other formar (chemml)
  * Peter: this comes very close to custom elements and shadowDOM
* ACTIONS: try to schedule meeting with aria folks

Re: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • September 23, 2016 • Permalink

Hi Kevin,

> With CAS, since the goal is to compute, you have no choice but to type
what you mean. Is the goal to come up with a universal CAS language?

The goal of this group is to bring practitioners together. While the group
itself cannot develop any kind of standard on its own, if enough people
want to work on such a thing, the group can provide the breeding ground and
help propose a standards effort. Of course, the group can also make
practical collaborative agreements among practitioners, especially when
things do not fall into the web standards world (cf. common-mark),

Best wishes,
Peter.


On Fri, Sep 23, 2016 at 12:25 AM, Paul Topping <pault@dessci.com> wrote:

> All good issues and ones that should be solved before worrying about the
> language syntax.
>
>
>
> I believe that the math structure should be bound to an interpretation
> that may be declared in the structure or held separately. Two mathematical
> structures may both contain an alpha but one binds it to some concept,
> variable, constant, or value and the other binds it some different one.
> When it is desired to calculate with the notation structure, it must be
> transformed into some other, computational structure based on the
> interpretation to which it is bound.
>
>
>
> Of course, problems may occur when it is necessary to map the
> computational structure back to a notational structure. These mappings are
> not generally one-to-one. This can be a good thing as it is possible to
> change a given expression from one notational scheme to another, or one
> computational structure to another. But it is a bad thing because there are
> multiple representations that have non-trivial mappings between them.
>
>
>
> Paul
>
>
>
>
>
> *From:* Kevin Cheung [mailto:KEVINCHEUNG@CUNET.CARLETON.CA]
> *Sent:* Thursday, September 22, 2016 3:02 PM
> *To:* Paul Topping <pault@dessci.com>; Jos de Jong <wjosdejong@gmail.com>;
> Robin Berjon <robin@berjon.com>
>
> *Cc:* Peter Krautzberger <peter.krautzberger@mathjax.org>;
> public-mathonw. <public-mathonwebpages@w3.org>
> *Subject:* Re: plain text math notation
>
>
>
> It will be nice if there is a math notation language that forces math
> writers to mean exactly what they write.  (Contrasting to what
> mathematicians sometimes do; they use the same LaTex symbols to mean
> different things in different contexts.)  With CAS, since the goal is to
> compute, you have no choice but to type what you mean.  Is the goal to come
> up with a universal CAS language?  If so, how would one go about dealing
> with really abstract math?
> ------------------------------
>
> *From:* Paul Topping <pault@dessci.com>
> *Sent:* Thursday, September 22, 2016 3:17:56 PM
> *To:* Jos de Jong; Robin Berjon
> *Cc:* Peter Krautzberger; public-mathonw.
> *Subject:* RE: plain text math notation
>
>
>
> The goal of a single math language that describes standard math notation
> AND works well for computation and manipulation is a worthwhile and, IMHO,
> achievable goal. However, starting at the syntax is not going to work.
> Sure, it is fine to express preferences for one language or another but the
> place to start is the model that the language expresses. By model, I mean
> abstract data structure and its dynamic semantics.
>
>
>
> MathML suffered from the too-many-cooks problem as well as not having a
> clear set of goals, IMHO. It also suffered from its association with XML
> but that’s a whole other story.
>
>
>
> I believe starting with the model is the only road to success but it is
> perhaps hard to convince people of that. Another advantage that might be
> more compelling is that, with well-designed model in hand, it should be
> possible to develop multiple syntaxes for expressing it, each useful in a
> different scenario: an XML syntax for the XML document world and, perhaps,
> for embedding in HTML, a JSON syntax for programmatic generation,
> manipulation, and consumption, a “plain-text math notation” for authors to
> type directly, etc.
>
>
>
> BTW, I am not sure “plain text math notation” is well-defined. In a sense,
> all computer languages are plain text and, at the same time, all have a
> syntax. I’m guessing what is meant by this is a notation that humans feel
> comfortable typing. Computers like regular syntaxes and are not bothered by
> extra characters such as angle brackets. Humans like something that doesn’t
> require too many keystrokes, hard to reach keys on the keyboard, doesn’t
> get scrambled in email, and is easy for humans to read. If this is what is
> meant, perhaps “human math language” might work. Just a thought.
>
>
>
> Paul Topping
>
>
>
> Design Science, Inc.
>
> "How Science Communicates"
>
> Makers of MathType, MathFlow, MathPlayer, Equation Editor
>
> http://www.dessci.com
>
>
>
> *From:* Jos de Jong [mailto:wjosdejong@gmail.com <wjosdejong@gmail.com>]
> *Sent:* Thursday, September 22, 2016 11:52 AM
> *To:* Robin Berjon <robin@berjon.com>
> *Cc:* Peter Krautzberger <peter.krautzberger@mathjax.org>;
> public-mathonw. <public-mathonwebpages@w3.org>
> *Subject:* Re: plain text math notation
>
>
>
> @Robin can you elaborate a bit on your idea? Do you mean that it would be
> trivial to translate a math formula into plain JavaScript which then can be
> evaluated, or to SVG for rendering? Or both?... Do you have concrete use
> cases in mind?
>
>
>
> Jos
>
>
>
> On Thu, Sep 22, 2016 at 3:53 PM, Robin Berjon <robin@berjon.com> wrote:
>
> On 22/09/2016 02:54 , Peter Krautzberger wrote:
> > Jos has written up some notes on plain text math notations at [1].
>
> This is IMHO a very promising area. I wonder if it may be interesting to
> consider making it not too distant from the syntax of (modern) JS so
> that it could easily be implemented as a BabelJS[0] plugin (like JSX[1]).
>
> [0] http://babeljs.io/
> [1] https://facebook.github.io/react/docs/jsx-in-depth.html
>
> --
> • Robin Berjon - http://berjon.com/ - @robinberjon
> • http://science.ai/ — intelligent science publishing
> •
>
>
>

RE: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Paul Topping (pault@dessci.com) • September 22, 2016 • Permalink

All good issues and ones that should be solved before worrying about the language syntax.

I believe that the math structure should be bound to an interpretation that may be declared in the structure or held separately. Two mathematical structures may both contain an alpha but one binds it to some concept, variable, constant, or value and the other binds it some different one. When it is desired to calculate with the notation structure, it must be transformed into some other, computational structure based on the interpretation to which it is bound.

Of course, problems may occur when it is necessary to map the computational structure back to a notational structure. These mappings are not generally one-to-one. This can be a good thing as it is possible to change a given expression from one notational scheme to another, or one computational structure to another. But it is a bad thing because there are multiple representations that have non-trivial mappings between them.

Paul


From: Kevin Cheung [mailto:KEVINCHEUNG@CUNET.CARLETON.CA]
Sent: Thursday, September 22, 2016 3:02 PM
To: Paul Topping <pault@dessci.com>; Jos de Jong <wjosdejong@gmail.com>; Robin Berjon <robin@berjon.com>
Cc: Peter Krautzberger <peter.krautzberger@mathjax.org>; public-mathonw. <public-mathonwebpages@w3.org>
Subject: Re: plain text math notation


It will be nice if there is a math notation language that forces math writers to mean exactly what they write.  (Contrasting to what mathematicians sometimes do; they use the same LaTex symbols to mean different things in different contexts.)  With CAS, since the goal is to compute, you have no choice but to type what you mean.  Is the goal to come up with a universal CAS language?  If so, how would one go about dealing with really abstract math?

________________________________
From: Paul Topping <pault@dessci.com<mailto:pault@dessci.com>>
Sent: Thursday, September 22, 2016 3:17:56 PM
To: Jos de Jong; Robin Berjon
Cc: Peter Krautzberger; public-mathonw.
Subject: RE: plain text math notation

The goal of a single math language that describes standard math notation AND works well for computation and manipulation is a worthwhile and, IMHO, achievable goal. However, starting at the syntax is not going to work. Sure, it is fine to express preferences for one language or another but the place to start is the model that the language expresses. By model, I mean abstract data structure and its dynamic semantics.

MathML suffered from the too-many-cooks problem as well as not having a clear set of goals, IMHO. It also suffered from its association with XML but that's a whole other story.

I believe starting with the model is the only road to success but it is perhaps hard to convince people of that. Another advantage that might be more compelling is that, with well-designed model in hand, it should be possible to develop multiple syntaxes for expressing it, each useful in a different scenario: an XML syntax for the XML document world and, perhaps, for embedding in HTML, a JSON syntax for programmatic generation, manipulation, and consumption, a "plain-text math notation" for authors to type directly, etc.

BTW, I am not sure "plain text math notation" is well-defined. In a sense, all computer languages are plain text and, at the same time, all have a syntax. I'm guessing what is meant by this is a notation that humans feel comfortable typing. Computers like regular syntaxes and are not bothered by extra characters such as angle brackets. Humans like something that doesn't require too many keystrokes, hard to reach keys on the keyboard, doesn't get scrambled in email, and is easy for humans to read. If this is what is meant, perhaps "human math language" might work. Just a thought.

Paul Topping

Design Science, Inc.
"How Science Communicates"
Makers of MathType, MathFlow, MathPlayer, Equation Editor
http://www.dessci.com

From: Jos de Jong [mailto:wjosdejong@gmail.com]
Sent: Thursday, September 22, 2016 11:52 AM
To: Robin Berjon <robin@berjon.com<mailto:robin@berjon.com>>
Cc: Peter Krautzberger <peter.krautzberger@mathjax.org<mailto:peter.krautzberger@mathjax.org>>; public-mathonw. <public-mathonwebpages@w3.org<mailto:public-mathonwebpages@w3.org>>
Subject: Re: plain text math notation

@Robin can you elaborate a bit on your idea? Do you mean that it would be trivial to translate a math formula into plain JavaScript which then can be evaluated, or to SVG for rendering? Or both?... Do you have concrete use cases in mind?

Jos

On Thu, Sep 22, 2016 at 3:53 PM, Robin Berjon <robin@berjon.com<mailto:robin@berjon.com>> wrote:
On 22/09/2016 02:54 , Peter Krautzberger wrote:
> Jos has written up some notes on plain text math notations at [1].

This is IMHO a very promising area. I wonder if it may be interesting to
consider making it not too distant from the syntax of (modern) JS so
that it could easily be implemented as a BabelJS[0] plugin (like JSX[1]).

[0] http://babeljs.io/
[1] https://facebook.github.io/react/docs/jsx-in-depth.html

--
* Robin Berjon - http://berjon.com/ - @robinberjon
* http://science.ai/ - intelligent science publishing
*

Re: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Kevin Cheung (KEVINCHEUNG@CUNET.CARLETON.CA) • September 22, 2016 • Permalink

It will be nice if there is a math notation language that forces math writers to mean exactly what they write.  (Contrasting to what mathematicians sometimes do; they use the same LaTex symbols to mean different things in different contexts.)  With CAS, since the goal is to compute, you have no choice but to type what you mean.  Is the goal to come up with a universal CAS language?  If so, how would one go about dealing with really abstract math?

________________________________
From: Paul Topping <pault@dessci.com>
Sent: Thursday, September 22, 2016 3:17:56 PM
To: Jos de Jong; Robin Berjon
Cc: Peter Krautzberger; public-mathonw.
Subject: RE: plain text math notation

The goal of a single math language that describes standard math notation AND works well for computation and manipulation is a worthwhile and, IMHO, achievable goal. However, starting at the syntax is not going to work. Sure, it is fine to express preferences for one language or another but the place to start is the model that the language expresses. By model, I mean abstract data structure and its dynamic semantics.

MathML suffered from the too-many-cooks problem as well as not having a clear set of goals, IMHO. It also suffered from its association with XML but that's a whole other story.

I believe starting with the model is the only road to success but it is perhaps hard to convince people of that. Another advantage that might be more compelling is that, with well-designed model in hand, it should be possible to develop multiple syntaxes for expressing it, each useful in a different scenario: an XML syntax for the XML document world and, perhaps, for embedding in HTML, a JSON syntax for programmatic generation, manipulation, and consumption, a "plain-text math notation" for authors to type directly, etc..

BTW, I am not sure "plain text math notation" is well-defined. In a sense, all computer languages are plain text and, at the same time, all have a syntax. I'm guessing what is meant by this is a notation that humans feel comfortable typing. Computers like regular syntaxes and are not bothered by extra characters such as angle brackets. Humans like something that doesn't require too many keystrokes, hard to reach keys on the keyboard, doesn't get scrambled in email, and is easy for humans to read. If this is what is meant, perhaps "human math language" might work. Just a thought.

Paul Topping

Design Science, Inc.
"How Science Communicates"
Makers of MathType, MathFlow, MathPlayer, Equation Editor
http://www.dessci.com

From: Jos de Jong [mailto:wjosdejong@gmail.com]
Sent: Thursday, September 22, 2016 11:52 AM
To: Robin Berjon <robin@berjon.com>
Cc: Peter Krautzberger <peter.krautzberger@mathjax.org>; public-mathonw. <public-mathonwebpages@w3.org>
Subject: Re: plain text math notation

@Robin can you elaborate a bit on your idea? Do you mean that it would be trivial to translate a math formula into plain JavaScript which then can be evaluated, or to SVG for rendering? Or both?... Do you have concrete use cases in mind?

Jos

On Thu, Sep 22, 2016 at 3:53 PM, Robin Berjon <robin@berjon.com<mailto:robin@berjon.com>> wrote:
On 22/09/2016 02:54 , Peter Krautzberger wrote:
> Jos has written up some notes on plain text math notations at [1].

This is IMHO a very promising area. I wonder if it may be interesting to
consider making it not too distant from the syntax of (modern) JS so
that it could easily be implemented as a BabelJS[0] plugin (like JSX[1]).

[0] http://babeljs.io/
[1] https://facebook.github.io/react/docs/jsx-in-depth.html

--
* Robin Berjon - http://berjon.com/ - @robinberjon
* http://science.ai/ - intelligent science publishing
*

RE: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Paul Topping (pault@dessci.com) • September 22, 2016 • Permalink

The goal of a single math language that describes standard math notation AND works well for computation and manipulation is a worthwhile and, IMHO, achievable goal. However, starting at the syntax is not going to work. Sure, it is fine to express preferences for one language or another but the place to start is the model that the language expresses. By model, I mean abstract data structure and its dynamic semantics.

MathML suffered from the too-many-cooks problem as well as not having a clear set of goals, IMHO. It also suffered from its association with XML but that’s a whole other story.

I believe starting with the model is the only road to success but it is perhaps hard to convince people of that. Another advantage that might be more compelling is that, with well-designed model in hand, it should be possible to develop multiple syntaxes for expressing it, each useful in a different scenario: an XML syntax for the XML document world and, perhaps, for embedding in HTML, a JSON syntax for programmatic generation, manipulation, and consumption, a “plain-text math notation” for authors to type directly, etc.

BTW, I am not sure “plain text math notation” is well-defined. In a sense, all computer languages are plain text and, at the same time, all have a syntax. I’m guessing what is meant by this is a notation that humans feel comfortable typing. Computers like regular syntaxes and are not bothered by extra characters such as angle brackets. Humans like something that doesn’t require too many keystrokes, hard to reach keys on the keyboard, doesn’t get scrambled in email, and is easy for humans to read. If this is what is meant, perhaps “human math language” might work. Just a thought.

Paul Topping

Design Science, Inc.
"How Science Communicates"
Makers of MathType, MathFlow, MathPlayer, Equation Editor
http://www.dessci.com


From: Jos de Jong [mailto:wjosdejong@gmail.com]
Sent: Thursday, September 22, 2016 11:52 AM
To: Robin Berjon <robin@berjon.com>
Cc: Peter Krautzberger <peter.krautzberger@mathjax.org>; public-mathonw. <public-mathonwebpages@w3.org>
Subject: Re: plain text math notation

@Robin can you elaborate a bit on your idea? Do you mean that it would be trivial to translate a math formula into plain JavaScript which then can be evaluated, or to SVG for rendering? Or both?... Do you have concrete use cases in mind?

Jos

On Thu, Sep 22, 2016 at 3:53 PM, Robin Berjon <robin@berjon.com<mailto:robin@berjon.com>> wrote:
On 22/09/2016 02:54 , Peter Krautzberger wrote:
> Jos has written up some notes on plain text math notations at [1].

This is IMHO a very promising area. I wonder if it may be interesting to
consider making it not too distant from the syntax of (modern) JS so
that it could easily be implemented as a BabelJS[0] plugin (like JSX[1]).

[0] http://babeljs.io/

[1] https://facebook.github.io/react/docs/jsx-in-depth.html


--
• Robin Berjon - http://berjon.com/ - @robinberjon
• http://science.ai/ — intelligent science publishing
•

Re: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Jos de Jong (wjosdejong@gmail.com) • September 22, 2016 • Permalink

@Robin can you elaborate a bit on your idea? Do you mean that it would be
trivial to translate a math formula into plain JavaScript which then can be
evaluated, or to SVG for rendering? Or both?... Do you have concrete use
cases in mind?

Jos

On Thu, Sep 22, 2016 at 3:53 PM, Robin Berjon <robin@berjon.com> wrote:

> On 22/09/2016 02:54 , Peter Krautzberger wrote:
> > Jos has written up some notes on plain text math notations at [1].
>
> This is IMHO a very promising area. I wonder if it may be interesting to
> consider making it not too distant from the syntax of (modern) JS so
> that it could easily be implemented as a BabelJS[0] plugin (like JSX[1]).
>
> [0] http://babeljs.io/
> [1] https://facebook.github.io/react/docs/jsx-in-depth.html
>
> --
> • Robin Berjon - http://berjon.com/ - @robinberjon
> • http://science.ai/ — intelligent science publishing
> •
>
>

Re: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Robin Berjon (robin@berjon.com) • September 22, 2016 • Permalink

On 22/09/2016 02:54 , Peter Krautzberger wrote:
> Jos has written up some notes on plain text math notations at [1]. 

This is IMHO a very promising area. I wonder if it may be interesting to
consider making it not too distant from the syntax of (modern) JS so
that it could easily be implemented as a BabelJS[0] plugin (like JSX[1]).

[0] http://babeljs.io/
[1] https://facebook.github.io/react/docs/jsx-in-depth.html

-- 
• Robin Berjon - http://berjon.com/ - @robinberjon
• http://science.ai/ — intelligent science publishing
•

plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • September 22, 2016 • Permalink

Hi math-on-web CG,

Jos has written up some notes on plain text math notations at [1].

Please check it out ahead of next week's meeting.

Best regards,
Peter.

[1] https://w3c.github.io/mathonwebpages/research/text_based_standards.html

Re: TPAC hangout Inbox x

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • September 20, 2016 • Permalink

PS We continue to have connection issues. If you want to join and encounter
problems, please write a short message.

On Tue, Sep 20, 2016 at 3:27 PM, Peter Krautzberger <
peter.krautzberger@mathjax.org> wrote:

> Hi folks,
>
> In case anyone has time to join us at TPAC remotely, here is a hangout
> you are invited to:
>
> https://hangouts.google.com/call/5h7rwp7cnbe2fideopwzjfpvmif
>
> (Sorry for the delay due to network problems).
>
> There will also be minutes.
>
> Best regards,
> Peter.
>

TPAC hangout Inbox x

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • September 20, 2016 • Permalink

Hi folks,

In case anyone has time to join us at TPAC remotely, here is a hangout
you are invited to:

https://hangouts.google.com/call/5h7rwp7cnbe2fideopwzjfpvmif

(Sorry for the delay due to network problems).

There will also be minutes.

Best regards,
Peter.

Release Notes for Safari Technology Preview Release 13

Source: WebKit • Jon Davis • September 15, 2016 • Permalink

Safari Technology Preview Release 13 is now available for download for both macOS Sierra betas and OS X El Capitan 10.11.6. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 204876–205519.

Fetch API

Custom Elements

JavaScript

Web APIs

Web Inspector

CSS

Rendering

Security

Plugins

UnicodeMath

Source: Murray Sargent: Math in Office • MurrayS3 • September 07, 2016 • Permalink

In writing the post Nemeth Braille—the first math linear format, I became increasingly aware that the Unicode Nearly Plain Text Encoding of Mathematics needed a better name than “linear format”. In addition to the Nemeth braille linear format, there are other math linear formats some of which are described in the post Linear Format Notations for Mathematics. One of these, AsciiMath, inspired the name UnicodeMath, which is much more specific than “linear format”. UnicodeMath uses the Unicode math symbol set (see Math property in DerivedCoreProperties.txt), resembles real mathematical notation the most closely of all math linear formats, and handles almost every mathematical notation. Since Unicode characters are global by nature, UnicodeMath doesn’t need localization. [La]TeX and AsciiMath define characters using ASCII control words that are Western-centric, and perhaps need to be localized in nonLatin-based locales.

Advantages

In addition to being the most readable linear format, UnicodeMath is the most concise. It represents the simple fraction, one half, by the 3 characters “1/2”, whereas typical MathML takes 62 characters (consisting of the <mml:mfrac> entity). This conciseness makes UnicodeMath an attractive format for storing mathematical expressions and equations, as well as for ease of keyboard entry. Another comparison is in the math structures for the Equation Tools tab in the Office ribbon. In Word, the structures are defined in OMML (Office MathML) and built up by Word, while for the other apps, the structures are defined in UnicodeMath and built up by RichEdit. The latter are much faster and the equation data much smaller. A dramatic example is the stacked fraction template (empty numerator over empty denominator). In UnicodeMath, this is given by the single character ‘/’. In OMML, it’s 109 characters! LaTeX is considerably shorter at 9 characters “\frac{}{}”, but is still 9 times longer than UnicodeMath. AsciiMath represents fractions the same way as UnicodeMath, so simple cases are identical. If Greek letters or other characters that require names in AsciiMath are used, UnicodeMath is shorter and more readable.

Another advantage of UnicodeMath over MathML and OMML is that UnicodeMath can be stored anywhere Unicode text is stored. When adding math capabilities to a program, XML formats require redefining the program’s file format and potentially destabilizing backward compatibility, while UnicodeMath does not. If a program is aware of UnicodeMath math zones (see Section 3.20 of UnicodeMath), it can recover the built-up mathematics by passing those zones through the RichEdit UnicodeMath MathBuildUp function. In fact, you can roundtrip RichEdit documents containing math zones through the plain-text editor Notepad: the math zones are preserved!

AsciiMath

As its name implies, AsciiMath uses only ASCII characters, although it converts to MathML with access to a much larger character set. AsciiMath is relatively simple to parse and can handle many mathematical constructs. AsciiMath shares some methodology with UnicodeMath, such as eliminating the outer parentheses in fractions like (a+b)/c when converting to built-up format. AsciiMath is designed to work with a MathML renderer, such as MathJax. In Microsoft Office apps, UnicodeMath builds up to the LineServices math internal format, which represented by OMML.

Math autocorrect

By default, the Office math autocorrect facility contains most [La]TeX math symbol control word definitions such as \beta for β. AsciiMath has a subset of such control words but omits the leading backslash. The user can modify such control words in the Office math autocorrect list or add them explicitly, but it’d probably be worth adding an option to make the leading backslash optional. That would speed up keyboard entry of UnicodeMath via math autocorrect. The RichEdit dll includes the UnicodeMath build up/down facility as well as converters for other math formats, such as MathML and OMML. It would be straightforward to add an option to the RichEdit UnicodeMath facility to accept AsciiMath input in general. Such an option would be handy for people that know AsciiMath.

One C++ oriented autocorrect choice in AsciiMath is that typing != enters ≠. Although I program in C++ almost every day, I think /= is a better choice for entering ≠. For one thing, using != for ≠ complicates typing in an equation like n! = n(n-1)(n-2)…1, which is the main reason we didn’t implement it. But in Office apps this equation can also be entered by typing ! = instead of !=, since math spacing rules insert space between ! and = and the RichEdit UnicodeMath facility automatically deletes a user’s space if typed there (see User Spaces in Math Zones). So, that’s an easy work around for entering an n! equation if one wants to support != for ≠. The RichEdit UnicodeMath facility supports most Unicode negated operators by sequences of / followed by the corresponding unnegated operator as described in the post Negated Operators.

<gripe> Meanwhile the C++ language should recognize ≠, ≤, ≥, and ≡ as aliases for !=, <=, >=, and ==. It seems primitive that C++ doesn’t do so in this Unicode age of computing. At least the C++ editing/debugging environments should have an option to display !=, <=, >=, and == as ≠, ≤, ≥, and ≡. </gripe>

Comparison

Here’s a table with various formats for the integral

integral

Format Representation
UnicodeMath 1/2𝜋 ∫_0^2𝜋▒ⅆ𝜃/(𝑎+𝑏 sin⁡𝜃 )=1/√(𝑎^2−𝑏^2 )
AsciiMath 1/(2pi) int_0^(2pi) dx/(a+bsin theta)=1/sqrt(a^2-b^2)
LaTeX \frac{1}{2\pi}\int_{0}^{2\pi}\frac{d\theta}{a+b\sin {\theta}}=\frac{1}{\sqrt{a^2-b^2}}

 

Note that UnicodeMath binds the integrand to the integral, whereas AsciiMath and LaTeX don’t define the limits of the integrand. The Presentation MathML and OMML for this integral are too long to put into this post.

Observations

There is a unicode-math conversion package for Unicode enabled XeTeX and LuaLaTeX. The name UnicodeMath seems sufficiently different from unicode-math that there shouldn’t be any confusion between the two. The unicode-math package supports a variety of math fonts including Cambria Math, Minion Math, Latin Modern Math, TeX Gyre Pagella Math, Asana-Math, Neo-Euler, STIX, and XTIS Math. Did you know there are so many math fonts?

Enjoy the new name UnicodeMath. I am and it already appears near the end of my previous blog post, Nemeth Braille Alphanumerics and Unicode Math Alphanumerics. If you’re interested in the origin of UnicodeMath, read the post How I got into technical WP. The forerunner of UnicodeMath originated back in the early microcomputer days and had only 512 characters consisting of upright ASCII, italics, script, Greek and various mathematical symbols used in theoretical physics. Unicode 1.0 didn’t arrive until 10 years later.

 

The HTML5 Spec: What's In and What's Out?

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

HTML Goodies - Found Sep. 1, 2016
... and announced to start developing tools using HTML5. Options to support scalable vector graphics (SVL) and MathML were added to support...

MathJax v2.7 beta now available

Source: MathJax • September 01, 2016 • Permalink

Today we are entering the public beta phase of MathJax v2.7. MathJax v2.7 is primarily a bug-fix release with over 60 important bug fixes. In addition, this release adds several new features as an opt-in. The following are some of the highlights:

  1. CommonHTML output improvements Several important bugs in the layout model have been fixed, in particular tabular layout is now much more robust.
  2. Accessibility extensions. After the completion of the MathJax Accessibility Extensions, we are integrating the lightweight opt-in into the MathJax core. This allows readers to opt into the following features via the MathJax Menu:
    • Responsive Equations. An innovative responsive rendering of mathematical content through collapsing and exploration of subexpressions.
    • Universal aural Rendering. An aural rendering tool providing on-the-fly speech-text for mathematical content and its subexpressions using various rule sets.
    • Full Exploration. A fully accessible exploration tool, allowing for meaningful exploration of mathematical content including multiple highlighting features and synchronized aural rendering.
    • For detailed information check the accessibility extensions’ release announcement.
  3. Opt-in for mhchem v3 The mhchem extension in the core now provides a configuration option to switch to mchhem v3. This new version was (re-)written by Martin Hensel, author of the original $\rm \LaTeX$ package, and greatly revises and extends it. This new extension is also available directly through the MathJax Third Party Extension repository
  4. Simplified opt-in for third party extensions MathJax v2.7 configures the [Contrib] path variable to the URL of the third party extension repository on the MathJax CDN. This simplifies loading contributed extensions.
  5. Third Party Extension Updates Our Third Party Extension repository as seen some great additions recently. The MathJax team is grateful for these contributions from the community!

For details on all bug fixes, please see below.

The beta is available via our CDN at beta.mathjax.org/mathjax/latest/MathJax.js which you can load it in place of the version you are currently using. Alternatively, you can get a ZIP archive or access the branch on GitHub.

Please note the following.

Changes to the combined configuration files

If you are using a combined configuration, please note that we added the the accessibility menu extension to all combined configuration files. This extension will always load from cdn.mathjax.org/mathjax/contrib. If you are hosting your own copy of MathJax and if your users will not be able to access cdn.mathjax.org, then you should disable the [Contrib] path by adding noContrib to the query string, e.g., MathJax.js?config=...&noContrib to avoid unnecessary failed requests.


Remember that this is still beta software, so if you are not an experienced user, you may want to wait for the official 2.7 release. We do not recommend that you use the 2.7-beta version for production environments, but do encourage you to test your content with it.

If you are linking to http://cdn.mathjax.org/mathjax/latest/MathJax.js, note that at the point of the official release of v2.7, the address will begin to serve MathJax v2.7. You can also continue to use v2.6 by linking to http://cdn.mathjax.org/mathjax/2.6-latest/MathJax.js instead — and you can change to that version at any point (it is available now).

The official release of v2.7 should occur within the next few weeks, but we want you to be able to start to test out the v2.7 features now. Please report any bugs you find to the issue tracker at https://github.com/mathjax/MathJax/issues.

Thanks for your continuing interest in MathJax. We hope that this release makes your MathJax experience even better.

The MathJax Team.


New in MathJax v2.7

MathJax v2.7 is primarily a bug-fix release with over 60 important bug fixes, in particular to the CommonHTML output. In addition, this release adds several new features as an opt-in. The following are some of the highlights.

Features

For a detailed listing please check the release milestone.

Accessibility

Interface

HTML/SVG/nativeMML display

TeX emulation

Asciimath

MathML

Fonts

Localization

APIs

Misc.

Re: TPAC meeting DPUB IG & math-on-webpages

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter.krautzberger@mathjax.org) • August 31, 2016 • Permalink

Dear math-on-webpages CG,

The last-minute nature of this thread makes it difficult to plan beyond our
own slot.

>From the call, I remember that a few people besides myself are planning or
considering to attend TPAC so there's no reason to let our slot go to waste
:-)

If you are thinking about attending TPAC and would like to attend the CG
meeting (Tuesday, 13:30--15:30), could you please send an email to Dani or
myself?

Best regards,
Peter.

On Mon, Aug 29, 2016 at 5:55 PM, Peter Krautzberger <
peter.krautzberger@mathjax.org> wrote:

> Dea DPUB IG and Math-on-Webpages CG,
>
> The math-on-webpages CG got a meeting slot for TPAC (Tue, 13:30–15:30).
> Unfortunately, we didn't know about this until rather recently.
>
> So in the last CG F2F, people present decided to it would be best to
> concentrate on a meeting with the DPUB IG.
>
> The DPUB IG schedule [1] already lists something for the time but I'm
> wondering if we could fit something in anyway?
>
> Best wishes,
> Peter.
>
> [1] https://www.w3.org/dpub/IG/wiki/Sep_2016_F2F_Logistics_
> and_Details#Tuesday.2C_20_September
>

Release Notes for Safari Technology Preview Release 12

Source: WebKit • Jon Davis • August 30, 2016 • Permalink

Safari Technology Preview Release 12 is now available for download for both macOS Sierra betas and OS X El Capitan. If you already have Safari Technology Preview installed, you can update from the Mac App Store’s Updates tab. This release covers WebKit revisions 204289–204876.

This release of Safari Technology Preview will be the last that will install and run on OS X El Capitan 10.11.4 and 10.11.5. To continue testing or living on the latest enhancements to WebKit, please upgrade to OS X El Capitan 10.11.6 or the macOS Sierra betas.

JavaScript

Web APIs

Web Inspector

MathML

CSS

Rendering

Accessibility

Security

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