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.

UND September 19, 2014 Re: Displaystyle and mtable

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

> But not all that strange, afterall.

Agreed. But I was referring to the corresponding MathML (and the
combination of all three cases).

Best,
Peter.

On Fri, Sep 19, 2014 at 12:16 AM, Ross Moore <ross.moore@mq.edu.au> wrote:

> Hi David and Peter,
>
> On 19/09/2014, at 7:33, David Carlisle <davidc@nag.co.uk> wrote:
>
> > On 18/09/2014 22:09, Peter Krautzberger wrote:
> >> Thanks, David, for confirming the reading of the spec.
> >
>
>
> >> <mfrac>
> >> <mtable displaystyle="true">
> >> ...
> >> </mtable>
> >> <mrow>
> >> ...
> >> </mrow>
> >> </mfrac>
> >>
> >> would get us a table with displaystyle formatting, but in scriptstyle
> >> size (when used in an inline formula). (I admit I find that somewhat
> >> strange; oh well.)
> >
> > again, if tex did this you probably wouldn't find it strange:-)
>
> I can well imagine this being used in Statistics, or Statistical
> Mechanics, and related fields,
> where the fraction is the ratio of integrals or summations or products
> — especially for presentation slides, where the ratio of text width to
> line height is typically much less than in printed publications.
>
> Of course you need to manipulate the TeX by declaring \displaystyle within
> the numerator and denominator, as David suggests. But not all that strange,
> afterall.
>
>
> >>
> >> Thanks again for your quick response!
> >> Peter.
> >
> >
> > From the speed you may note that it was a personal response, but I think
> I only cited what the spec is saying:-)
> >
> > David
>
> Cheers,
>
>    Ross

UND September 18, 2014 Re: Displaystyle and mtable

Author: Ross Moore (ross.moore@mq.edu.au) | Channel: www-math@w3.org Mail Archives

Hi David and Peter,

On 19/09/2014, at 7:33, David Carlisle <davidc@nag.co.uk> wrote:

> On 18/09/2014 22:09, Peter Krautzberger wrote:
>> Thanks, David, for confirming the reading of the spec.
> 


>> <mfrac>
>> <mtable displaystyle="true">
>> ...
>> </mtable>
>> <mrow>
>> ...
>> </mrow>
>> </mfrac>
>> 
>> would get us a table with displaystyle formatting, but in scriptstyle
>> size (when used in an inline formula). (I admit I find that somewhat
>> strange; oh well.)
> 
> again, if tex did this you probably wouldn't find it strange:-)

I can well imagine this being used in Statistics, or Statistical Mechanics, and related fields,
where the fraction is the ratio of integrals or summations or products
— especially for presentation slides, where the ratio of text width to line height is typically much less than in printed publications.

Of course you need to manipulate the TeX by declaring \displaystyle within the numerator and denominator, as David suggests. But not all that strange, afterall.


>> 
>> Thanks again for your quick response!
>> Peter.
> 
> 
> From the speed you may note that it was a personal response, but I think I only cited what the spec is saying:-)
> 
> David

Cheers,

   Ross

UND September 18, 2014 Re: Displaystyle and mtable

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

Fair enough :-)

Peter.
Am 18.09.2014 23:33 schrieb "David Carlisle" <davidc@nag.co.uk>:

> On 18/09/2014 22:09, Peter Krautzberger wrote:
>
>> Thanks, David, for confirming the reading of the spec.
>>
>> So to guarantee \displaystyle we're supposed to do something like
>>
>> <mstyle scriptlevel="0">
>> <mtable displaystyle="true">
>> ...
>> </mtable>
>> </mstyle>
>> To guarantee \textstyle something like
>>
>> <mstyle displaystyle="true" scriptlevel="0">
>> <mtable>
>> ...
>> </mtable>
>> </mstyle>
>>
>
> well if an author is coding directly in mathml probably wouldn't have the
> mstyle.
> If you're converting from TeX code (that is not using \mathchoice) then
> you would need that for absolute fidelity, although to be honest often
> if tex alignments end up being used in a subscript the author _doesn't
> want the table to stay using large fonts, and ammends the code to use
> mathchoice so it gets smaller.
>
>
>
>
>> And
>>
>> <mfrac>
>> <mtable displaystyle="true">
>> ...
>> </mtable>
>> <mrow>
>> ...
>> </mrow>
>> </mfrac>
>>
>> would get us a table with displaystyle formatting, but in scriptstyle
>> size (when used in an inline formula). (I admit I find that somewhat
>> strange; oh well.)
>>
>
> again, if tex did this you probably wouldn't find it strange:-)
>
>>
>> Thanks again for your quick response!
>> Peter.
>>
>
>
> From the speed you may note that it was a personal response, but I think I
> only cited what the spec is saying:-)
>
> David
>
>

UND September 18, 2014 Re: Displaystyle and mtable

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

On 18/09/2014 22:09, Peter Krautzberger wrote:
> Thanks, David, for confirming the reading of the spec.
>
> So to guarantee \displaystyle we're supposed to do something like
>
> <mstyle scriptlevel="0">
> <mtable displaystyle="true">
> ...
> </mtable>
> </mstyle>
> To guarantee \textstyle something like
>
> <mstyle displaystyle="true" scriptlevel="0">
> <mtable>
> ...
> </mtable>
> </mstyle>

well if an author is coding directly in mathml probably wouldn't have 
the mstyle.
If you're converting from TeX code (that is not using \mathchoice) then
you would need that for absolute fidelity, although to be honest often
if tex alignments end up being used in a subscript the author _doesn't
want the table to stay using large fonts, and ammends the code to use 
mathchoice so it gets smaller.



>
> And
>
> <mfrac>
> <mtable displaystyle="true">
> ...
> </mtable>
> <mrow>
> ...
> </mrow>
> </mfrac>
>
> would get us a table with displaystyle formatting, but in scriptstyle
> size (when used in an inline formula). (I admit I find that somewhat
> strange; oh well.)

again, if tex did this you probably wouldn't find it strange:-)
>
> Thanks again for your quick response!
> Peter.


 From the speed you may note that it was a personal response, but I 
think I only cited what the spec is saying:-)

David

UND September 18, 2014 Re: Displaystyle and mtable

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

Thanks, David, for confirming the reading of the spec.

So to guarantee \displaystyle we're supposed to do something like

<mstyle scriptlevel="0">
<mtable displaystyle="true">
...
</mtable>
</mstyle>

To guarantee \textstyle something like

<mstyle displaystyle="true" scriptlevel="0">
<mtable>
...
</mtable>
</mstyle>

And

<mfrac>
<mtable displaystyle="true">
...
</mtable>
<mrow>
...
</mrow>
</mfrac>

would get us a table with displaystyle formatting, but in scriptstyle size
(when used in an inline formula). (I admit I find that somewhat strange; oh
well.)

Thanks again for your quick response!
Peter.

On Thu, Sep 18, 2014 at 5:07 PM, David Carlisle <davidc@nag.co.uk> wrote:

> On 17/09/2014 20:37, Peter Krautzberger wrote:
>
>> Hi everyone,
>>
>> A follow-up question after Fred commented
>> <https://github.com/dpvc/MathJax/commit/98e3f098bd519dabe9bf558736c5bf
>> 6438fbc217>
>> on our changes to MathJax (following the results of this discussion);
>> these changes include resetting the scriptlevel to 0. To us, this
>> seemed to make the most sense after the discussion: if display style
>> wasn't supposed to be inherited, then scriptlevel seemed strange to
>> inherit (also, there were some "matching TeX behavior" comments on
>> this thread).
>>
>> To put it differently, we couldn't imagine how an author setting
>> displaystyle to "true" would expect to stay at scriptlevel=1 (for
>> example). The only use-case we could think of would be an array in a
>>  superscript or fraction, but this doesn't seem very likely.
>>
>> However, as Fred pointed out, the spec seems to read differently.
>> Since displaystyle needed to be clarified, we thought it's best to
>> ask for clarification on this as well.
>>
>> Thanks in advance, Peter.
>>
>>
> I think the spec is clear, and the splitting of tex's \xxxstyle concept
> into two separately settable parameters was certainly intentional:
>
> 3.1.6 says
>
>  TEX's \displaystyle, \textstyle, \scriptstyle, and \scriptscriptstyle
>> correspond to displaystyle and scriptlevel as "true" and "0", "false"
>> and "0", "false" and "1", and "false" and "2", respectively.
>>
>
>
>
> That choice inevitably means that there are combinations not reachable
> in TeX (and thus uncommon to most authors and probably unlikely
> to be used except in exceptional circumstances) but I think it's clear
> that the spec intends that they are reachable.
>
>
>
> David
>
>
>
>
>
>

UND September 18, 2014 Re: Displaystyle and mtable

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

On 17/09/2014 20:37, Peter Krautzberger wrote:
> Hi everyone,
>
> A follow-up question after Fred commented
> <https://github.com/dpvc/MathJax/commit/98e3f098bd519dabe9bf558736c5bf6438fbc217>
> on our changes to MathJax (following the results of this discussion);
> these changes include resetting the scriptlevel to 0. To us, this
> seemed to make the most sense after the discussion: if display style
> wasn't supposed to be inherited, then scriptlevel seemed strange to
> inherit (also, there were some "matching TeX behavior" comments on
> this thread).
>
> To put it differently, we couldn't imagine how an author setting
> displaystyle to "true" would expect to stay at scriptlevel=1 (for
> example). The only use-case we could think of would be an array in a
>  superscript or fraction, but this doesn't seem very likely.
>
> However, as Fred pointed out, the spec seems to read differently.
> Since displaystyle needed to be clarified, we thought it's best to
> ask for clarification on this as well.
>
> Thanks in advance, Peter.
>

I think the spec is clear, and the splitting of tex's \xxxstyle concept
into two separately settable parameters was certainly intentional:

3.1.6 says

> TEX's \displaystyle, \textstyle, \scriptstyle, and \scriptscriptstyle
> correspond to displaystyle and scriptlevel as "true" and "0", "false"
> and "0", "false" and "1", and "false" and "2", respectively.



That choice inevitably means that there are combinations not reachable
in TeX (and thus uncommon to most authors and probably unlikely
to be used except in exceptional circumstances) but I think it's clear 
that the spec intends that they are reachable.



David

UND September 17, 2014 Re: Displaystyle and mtable

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

Hi everyone,

A follow-up question after Fred commented
<https://github.com/dpvc/MathJax/commit/98e3f098bd519dabe9bf558736c5bf6438fbc217>
on
our changes to MathJax (following the results of this discussion); these
changes include resetting the scriptlevel to 0. To us, this seemed to make
the most sense after the discussion: if display style wasn't supposed to be
inherited, then scriptlevel seemed strange to inherit  (also, there were
some "matching TeX behavior" comments on this thread).

To put it differently, we couldn't imagine how an author setting
displaystyle to "true" would expect to stay at scriptlevel=1 (for example).
The only use-case we could think of would be an array in a superscript or
fraction, but this doesn't seem very likely.

However, as Fred pointed out, the spec seems to read differently. Since
displaystyle needed to be clarified, we thought it's best to ask for
clarification on this as well.

Thanks in advance,
Peter.



On Fri, Jun 13, 2014 at 10:28 AM, David Carlisle <davidc@nag.co.uk> wrote:

>  On 13/06/2014 07:13, Frédéric WANG wrote:
>
> Le 13/06/2014 01:29, David Carlisle a écrit :
>
> Unlike array, aligned sets its cells in displaystyle so should map to
> <mtable displaystyle="true"> which is no harder to generate than <mtable>
> You don't need to generate many (or any) mstyle elements.
>
> It's unfortunate if some convertors get that wrong but it shouldn't be
> hard for the maintainers to fix them (Davide's already entered a bug
> for MathJax.)
>
> Thank you David. Are there any table-like environments that inherit the
> displaystyle (and could be nested)? If they all automatically force either
> displaystyle="true" or displaystyle="false", then I'm no longer concerned
> (except that we're likely to get report like
> https://bugzilla.mozilla.org/show_bug.cgi?id=1011237 until everybody
> align on the MathML spec).
>
> -
>
>
>
> In TeX?
>
> No not really: the underlying \halign alignment structure always takes you
> out of math mode
> and there is no sane way of "inheriting" the current math style through to
> the cells.
> So macros tend to use textstyle (like array) or displaystyle (like
> aligned).
>
>
> The only way in TeX to fake inheriting the current style is to set the
> entire alignment in all four styles
> (display, text, script and scriptscript) and have the primitive
> \mathchoice pick one as it lays out the
> final math list after the macro layer hands over control.  That's slow and
> painful and so typically
> only used for things that have "hidden alignments" eg the use of \ooalign
> to make up constructed symbols
> such as plain TeX's \rightleftharpoons. I don't know of any common macro
> definitions in the usual TeX
> packages that make alignments with author supplied content in cells that
> inherit the display style.
>
> David
>
>

en-US September 15, 2014 InfoLogic Releases MathMagic Lite for Windows - Math Equation ...

Channel: Ask.com News Search for "mathml"

PRWeb - Found Sep. 15, 2014
... and symbols via palettes and custom keyboard layout, MathMagic Lite also reads various Math formats including MathML, LaTeX, Plain TeX, Wiki...

en-US September 15, 2014 InfoLogic Releases MathMagic Lite for Windows - Math Equation Editor ...

Channel: Ask.com News Search for "mathml"

PRWeb - Found 21 minutes ago
... and symbols via palettes and custom keyboard layout, MathMagic Lite also reads various Math formats including MathML, LaTeX, Plain TeX, Wiki...

UND September 13, 2014 Re: Update to unicode.xml

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

I verified  the latex set this morning and I think you are right that we 
can not probably do better for the Unicode-to-LaTeX mapping. I attach 
the updated LaTeX-commands.diff. Since I need the LaTeX-to-Unicode 
mapping for my math converter, I now only take the "AMS" set as a 
reference (+ some commands from itex2MML). The remaining issues for the 
AMS set are the duplicate in 
http://lists.w3.org/Archives/Public/www-math/2013Dec/att-0001/AMS-commands.diff 
as well as the question mark for <AMS>\doublebarwedge ?</AMS> (should it 
be \doublebarwedge or, to match unicode-math \vardoublebarwedge?).

Later, I'll try to analyze more carefully the difference between what I 
get from unicode.xml and itex2MML (mathclass etc) and see if there is 
anything relevant to say.

More comments below.

>> - Some Arabic Letters (U+0627-U+063A and Arabic mathematical alphabetic
>> symbol) should probably have mathclass="A" since they are used as
>> mathematical variables.
>
> ftp://ftp.unicode.org/Public/math/
> unicode still at revison 13, so this hasn't changed (unless I decide 
> to break from exact matching of mathclass data with the Unicode data) 
Do you know when the Unicode group will consider this change?  (and 
whether they have approved that?)

> On 03/07/2014 13:49, Patrick Ion wrote:
>> I would urge you to change the "nameless" <latex> entries to a
>> 'set="latex-historical">' at least so as not to lose the record of
>> where people may have got their authoritative info
So it seems that this request to add set="latex-historical" has been 
ignored. In my opinion, keeping these "latex-historical" entries is not 
really useful since the changes are already recorded in the CVS history, 
and actually I believe using revision control system is the proper way 
to record this kind of info. The only potential problem I see is that 
this CVS repository does not seem public... or is there at least a 
public web page for that?

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



UND September 12, 2014 Re: Update to unicode.xml

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

Le 12/09/2014 18:54, Frédéric WANG a écrit :
> but the 3 issues of the <mathlatex> 
> (http://lists.w3.org/Archives/Public/www-math/2013Dec/att-0001/MathLaTeX-commands.diff) 
> seems to be fixed.
> Al the entries in your MathLaTeX-commands.diff file are of this form 
> as far as I can see
OK, actually I executed the wrong command for MathLaTeX-commands.diff. 
Indeed, the three duplicates are still here but as you say that's 
expected per classical tex limitation.

I now see new duplicates from the unicode-math set for

U03014 \lbrbrak
U03018 \Lbrbrak
U03015 \rbrbrak
U03019 \Rbrbrak

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

UND September 12, 2014 Re: Update to unicode.xml

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

Le 08/09/2014 00:35, David Carlisle a écrit :
> Frédéric,
>
> Thanks again for your comments,
>
> a somewhat belated reply...

Thanks David. I haven't had time to look into the details of the <latex> 
set, but the 3 issues of the <mathlatex> 
(http://lists.w3.org/Archives/Public/www-math/2013Dec/att-0001/MathLaTeX-commands.diff) 
seems to be fixed. The issue in the <AMS> set 
(http://lists.w3.org/Archives/Public/www-math/2013Dec/att-0001/AMS-commands.diff) 
does not seem to be fixed though. "LEFT RIGHT DOUBLE ARROW WITH STROKE" 
should probably map to \nLeftrightarrow (with an uppercase L) just like 
it is done for the <latex> and <mathlatex> sets.

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

UND September 09, 2014 Prevent stripping MathML tags on post save - WordPress ...

Author: Najmul Hosain | Channel: mathml - Google Blog Search

I am trying to add MathML markups in wordpress custom post. But, it is stripping all MathML tags when I hit the publish button :(. I have disabled "wpautop" and "Visual Editor". These are not helping at all. Can you please ...

UND September 07, 2014 Re: Update to unicode.xml

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

Frédéric,

Thanks again for your comments,

a somewhat belated reply...

>
> - Some characters have mathclass="R?" (with a question mark)... I guess
> that's because the mathclass is not clear, but it is unexpected for
> someone who wants to process the file automatically...
>

fixed at the time, updating from version 11 to 13 of the unicode data.

> - Some Arabic Letters (U+0627-U+063A and Arabic mathematical alphabetic
> symbol) should probably have mathclass="A" since they are used as
> mathematical variables.

ftp://ftp.unicode.org/Public/math/
unicode still at revison 13, so this hasn't changed (unless I decide to 
break from exact matching of mathclass data with the Unicode data)


>
> - Some LaTeX commands map to different Unicode code points. For example
> \mathsfbf{\Alpha} maps to both the capital and small (bold sans-serif)
> alpha, which is clearly wrong (one should be \mathsfbf{\alpha}). See the
> attached diff files for details. They were generated using the attached
> XSLT stylesheet and the Unix command  "xsltproc extract.xsl unicode.xml
> | sort --key=2,2 > commands1.txt; cat commands1.txt | uniq
> --skip-chars=7 > commands2.txt ; diff -U8 commands1.txt commands2.txt >
> commands.diff".


That one is clearly wrong but it isn't necessarily wrong that you get 
duplicate mappings in the latex to unicode direction. Classic Tex fonts 
do not for example have a full Greek alphabet  so  both U+006F and 
U+03BF  ( latin o and Greek omicron) map to o.  Al the entries in your
MathLaTeX-commands.diff file are of this form as far as I can see, Greek 
letters with tonos being overloaded with latin letters with acute
which is not exactly a brilliant mapping but agrees with classical tex 
usage.


By far the biggest set of incorrect mappings wer essentially all the
lowercase greek mathematical alphabet blocks having uppercase names.
I fixed those thanks.

Comments on some others in your LaTeX-commands-diff file below.


  the first group is

  U0002D -
-U02010 -
-U02212 -


that is ascii - and the explicit hyphen and minus characters all mapping 
to - in latex, that again is the best you can do really if mapping to
classic 7bit fonts

-U0201A ,similar mapping the low quotation to a comma matches classical 
TeX usage

-U02024 .  One DOT leader, I suppose this could be \ldotp rather than . 
(although that's the same character in the default setup)

-U02019 ' again using the ascii ' for the right quotation mark is normal 
tex usage

-U00386 \'{A}  as for the mathlatex usage this is the best approximation 
you can do in classic tex font distribution

-U0212B \AA   angstrom and A ring being same character, this seems correct


-U0219D \arrowwaveright
oops thanks, that's the left arrow....


-U025EF \bigcirc
size mapping to classical fonts is a bit strained, this is
"WHITE CIRCLE" and "LARGE CIRCLE" not sure I can do better but 
suggestions welcome

-U022C5 \cdot  "DOT OPERATOR" and "MIDDLE DOT" the latter is a bit of 
abuse of the math font but again accords with 7bit cm font usage.

-U02662 \diamond  diamond/lozenge

-U02729 \ding{73} two different white stars

-U02A63 \ElsevierGlyph{225A} This macro name is not actually usable to 
anyone other than Sebastian I guess

-U00192 f f and script f.
-U00261 g same for g

-U1D716 \in
-U1D750 \in
-U1D78A \in
-U1D7C4 \in
Yes I guess I could wrap some of those in a math alphabet
(although classic tex mathalphabet commands do not affect the standard 
definition of \in)


-U0039C M
Mu=M.
-U1D6B3 M
-U1D6CD M
-U1D6ED M
-U1D707 M
-U1D727 M
-U1D741 M
-U1D761 M
-U1D77B M
-U1D79B M
-U1D7B5 M
Mu=M but I added the math alphabets \mathbf{M} etc


U02306 \perspcorrespond
-U02A5E \perspcorrespond
  Not sure either of these are really defined in classic tex setups,
I made one var... (to match unicode-math)


$ cvs commit -m "lowercase latex greek and other fixes (FW)" unicode.xml
/w3ccvs/WWW/2003/entities/2007xml/unicode.xml,v  <--  unicode.xml
new revision: 1.78; previous revision: 1.77



David

UND September 05, 2014 Re: Update to unicode.xml

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

On 05/09/2014 15:33, Frédéric WANG wrote:
> Le 03/07/2014 15:53, David Carlisle a écrit :
>> Oh Ok that's simpler: don't fix the names in the file just mark then
>> as set="historical"
>> OK good plan!
> Is there any update on this or a plan to lead to reliable set of LaTeX
> mappings (in the last version of unicode.xml I still see some of the
> errors I initially reported and no set="historical") ? As I see, the
> unicode-math names are not really "standard" (whatever it means for
> LaTeX), for example "GREEK SMALL LETTER ALPHA" is mapped by "\upalpha"
> instead of the more traditional "\alpha". Just marking the legacy
> mappings "historical" without fixing the errors, will not be very
> helpful for someone willing to rely on this set.
>

ah I'll see what I can do....

Although it really isn't so clear in a unicode setting that saying
U+03B1 is traditionally mapped as \alpha really helps.
U+03B1 is (as you know) textual Greek, and mapping it to \alpha
with the traditional definition of \alpha will just lead to tex errors.
Perhaps I can document that if the character element has mode="math" 
then the <latex> mapping is only assumed to work in math mode.

But in anycase the errors you reported initially were just errors
I think not relying on such details, I'll try to get that done.....


David

UND September 05, 2014 Re: Update to unicode.xml

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

Le 03/07/2014 15:53, David Carlisle a écrit :
> Oh Ok that's simpler: don't fix the names in the file just mark then 
> as set="historical"
> OK good plan!
Is there any update on this or a plan to lead to reliable set of LaTeX 
mappings (in the last version of unicode.xml I still see some of the 
errors I initially reported and no set="historical") ? As I see, the 
unicode-math names are not really "standard" (whatever it means for 
LaTeX), for example "GREEK SMALL LETTER ALPHA" is mapped by "\upalpha" 
instead of the more traditional "\alpha". Just marking the legacy 
mappings "historical" without fixing the errors, will not be very 
helpful for someone willing to rely on this set.

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

UND September 01, 2014 Firefox 32 MathML Release Notes

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

Dear all,

Firefox 32 will be released this week, please find some release notes 
below. As usual, you can check 
https://wiki.mozilla.org/MathML:Home_Page#Last_bugs_fixed and 
https://developer.mozilla.org/en-US/Firefox/Releases/32#MathML for details.

* Gecko 32:
   - Implement menclose notation "phasorangle"
   - Improvements to the MathML stretchy code

* Gecko 33:
   - Add support for mtable@rowspacing/columnspacing/framespacing attributes
   - Use Open Type MATH constants for fractions, stacks, radicals and 
scripts

* Gecko 34:
   - Fix a performance regression due to the mathvariant improvements in 
Gecko 28

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

en-US August 26, 2014 Springer Science+Business Media continues as a MathJax Supporter

Author: Peter Krautzberger | Channel: MathJax

Springer Science+Business Media continues to support MathJax project as a MathJax Supporter.

A leading global scientific publisher, Springer publishes 2,200 journals and over 8,000 new books each year. Over 240 open access journals on Springer’s open access platforms Springer Open and BioMed Central provide accessible, high-quality display of mathematical and scientific content using MathJax.

“The quality of our online publications are reliant on the accurate and readable display of mathematical equations.”, says Rob Lloyd, Head of Front End, Springer London. “The work of the Mathjax team is vital to achieving this. We are proud to sponsor and engage with a team and a community that is dedicated to the advancement of the display of mathematics in the browser.”

“Thanks to dedicated sponsors like Springer, we are able to develop MathJax continuously, keeping it the high-quality and universal rendering solution it is today,” comments Peter Krautzberger, MathJax manager. “In addition to its financial support, Springer provides the MathJax team with productive feedback that helps our development.”

The MathJax team looks forward to continuing the collaboration with Springer and welcomes their ongoing support for the MathJax project.

en-US August 13, 2014 AIP Publishing continues as MathJax Supporter

Author: Peter Krautzberger | Channel: MathJax

Mathjax is pleased to announce that AIP Publishing and the American Institute of Physics have reaffirmed their commitment to MathJax in the form of a renewed financial contribution for 2014. AIP Publishing provides the global physical science community with a comprehensive collection of highly cited peer reviewed scientific information. Accessed by researchers at nearly 4,000 institutions worldwide, AIP Publishing’s portfolio of 17 journals includes prestigious titles such as Applied Physics Letters, Journal of Applied Physics, and The Journal of Chemical Physics, and the AIP Conference Proceedings series. AIP Publishing also publishes on behalf of several of AIP’s Member Societies and other publishing partners.

As a federation of 10 physical science societies, The American Institute of Physics (AIP) pursues a mission to advance and distribute the knowledge of the physical sciences and its applications. AIP Member Societies collectively represent more than 120,000 scientists, engineers, educators and students in the global physical sciences community.

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

“We believe MathJax provides a valuable service to researchers in the physical sciences by taking the worry out of accurately displaying and easily sharing the mathematical equations that are so important to the research they do,” said John Haynes, CEO of AIP Publishing.

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

UND August 02, 2014 MathML panel at Balisage 2014

Author: Lauren Wood | Channel: Design Science News

Next week at the Balisage conference I'm going to be part of a panel on MathML that includes Scott Dineen (Optical Society of America), Alexander Miłowski (University of Edinburgh), and Kennett Rawson (IEEE). We'll be discussing MathML in some depth, covering topics including authoring, web browsing, ebooks, accessibility, conversion, and proofreading. The panel is Wednesday Aug 6, from 11 AM to 12:30 PM.

Balisage is a technical conference about markup and all those related technologies that are used for structuring information. The conference is August 5 - 8, 2014 in Washington, DC, USA.  Balisage attendees include many of the people who write and maintain the specifications on which XML depends, design the commonly-used schemas, and implement the tools XML systems depend on. Together with the XML power users and consultants who also attend Balisage regularly, they exchange ideas and fuel the next wave of XML-related innovations.

Autumn Cuellar will also be at Balisage this year, so if you're attending, let's talk about MathML! If you're not attending, but want to know more about how MathFlow can make it easier to get MathML into your content, let us know.