# 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

Source: www-math@w3.org Mail Archives • Paul Libbrecht (paul@hoplahup.net) • May 22, 2015 • Permalink


the new deadlines for submission to MathUI are set as follows:
- abstracts: 26th of May
- full submissions: 29th of May
https://easychair.org/conferences/?conf=mathui15

Call for Papers: MathUI'15
http://cermat.org/events/MathUI/15/
9th Mathematical User Interfaces Workshop 2015

At the Conference on Intelligent Computer Mathematics
Washington DC, USA, 1-day Workshop
between 13th -- 17th of July 2015



## MathMagic 6.4 for Mac OS X Released

Source: Ask.com News Search for "mathml" • May 18, 2015 • Permalink

 CreativePro.com - Found May. 18, 2015 Save path and user defined file naming with Macros for faster multiple equation creation * Improved MathML and LaTeX support Categories: News...

## MathJax Community Update #8

Source: MathJax • May 18, 2015 • Permalink

It’s been far too long since we shared all the great new stuff from around the MathJax community!

## News

MathJax 2.5.3 is out. This patch releases should wrap up 2.5.x and we’re making good progress on the upcoming 2.6 release.

We have also started the MathJax semantic enrichment project – watch out for a longer post on this coming soon!

Peter had a guest post over at Wiley’s Exchanges Blog.

Oh, and we also released MathJax-node v0.3.0 so go grab it via npm.

## Plugins and tools

Check out mathjax-server for a small nodejs server built on MathJax-node.

You’re using GitHub’s Atom editor? There’s a Markdown+MathJax previewer for that.

The markdown editor Remarkable comes with out-of-the-box MathJax support.

The Chrome extension / markdown editor Markdown Preview Plus added MathJax support.

The slide-show tool Gistdeck now comes with a MathJax extension.

The web annotation platform Hypothes.is added math input support.

mathjs, the extensive math library for JS shared a nifty “pretty printing” example using MathJax.

Sina Baharm created the nifty MathInjector bookmarklet to extract MathML from various elements on a page and insert it as raw MathML for assistive technologies to access.

Mathgram is web-based editor using LaTeX internally.

The code documentation generator PAX comes with MathJax support.

## Content and Demos

@alexan0308 added two demos to MathJax/MathJax-examples for interacting with subexpressions.

João Palhoto Matos, Instituto Superior Técnico, shared his multivariable calculus resources (in Portuguese).

Ron Knott, Surrey University, has some great math resources such as this page on exact values of trignometric function.

Jeremy Elson pointed us to his small but excellent summary on calculating the expected value of a lottery jackpot.

Over on CSS-Tricks, a guest post by Rajoshi Ghosh and Tanmai Gopal needs a bit of math to explain how to get a parallax effect in pure CSS.

## Design Science Partners with BNStar

Source: Design Science News • Aaron Guigar • May 14, 2015 • Permalink

Design Science has partnered with BNStar Information Technology, a Chinese company built around technical publishing. BNStar has a great deal of experience with Arbortext XML publishing tools in the airline, manufacturing, automobile, and military industries. BNStar assesses each client's unique needs to create a publishing platform that best fits their business. These unique platforms are used to distribute technical documents that solve training, maintenance, and other information sharing challenges.

The consultants at BNStar recommend Arbortext as their XML editing platform of choice, and has partnered with Design Science because of our MathFlow integration with Arbortext. This integration allows BNStar's clients to use MathFlow to create and publish MathML equations within their XML workflows. It also adds equation conversion to Arbortext's Import/Export feature, which converts legacy documents from Microsoft Word to XML and MathML.

To find out more about BNStar visit their website at http://www.bnstarinfo.com.cn

Topics in this post:

## Improved Iso29500 Support for MS Word for Mac 2011 documents ...

Improved Iso29500 Support for MS Word for Mac 2011 documents, MathML Equations, EMF, WMF rendering and many other Improvements in Aspose.Words 15.4.0. Posted May 14 2015 by admin in ASP.Net with 0 Comments ...

## Design Science Partners with eGloo Technologies P/L, developers of tekReader

Source: Design Science News • Aaron Guigar • May 08, 2015 • Permalink

eGloo, a software and consulting company based in Australia, focuses on helping their clients move old data formats to structured XML content.

eGloo's tekReader product is an HTML5 eReader, a device agnostic platform that delivers content to the cloud. Businesses can use existing XML tools to publish content directly to tekReader, or eGloo’s tekAuthor and tekPublish can be combined with tekReader to provide an easy-to-use, end-to-end publishing solution. eGloo has provided these benefits to businesses in industries like education, aerospace, government, legal, and sports/recreation.

eGloo uses MathFlow with tekAuthor, an HTML5 authoring tool. tekAuthor is a FrameMaker 12 application that has been developed using the tekreader.dtd.

eGloo pointed out that MathFlow was the missing piece of the puzzle for their tekAuthor environment and it now allows MathML to be rendered and displayed in tekReader using MathJax.

Topics in this post:

## MathML Accessibility

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

## Overview

In a previous blog post about MathML in Wikipedia, I mentioned that, despite ongoing efforts there was still no accessibility support for MathML in Gecko. The situation changed two months ago: Design Science and NV Access released new versions of MathPlayer and NVDA, which in particular add MathML accessibility support on Windows, as shown in the demos below. This is exciting news and I am really willing to see this support extended to other platforms...

Last December, I also met Joanmarie Diggs at the Web Engines Hackfest and we have been able to start some preliminary work for Linux (WebKit/Gecko/Orca). I had the opportunity to refresh some of the patches written by Jonathan Wei during a Mozilla internship and to get part of his work landed into trunk. I have also made basic improvements to how we expose the accessible tree for ATK in order to prepare future support in Orca. It is certainly too early to announce anything. Just as a comparison, I also provide how Orca currently (badly) reads the MathML formulas below.

MathML accessibility support is also available in the latest versions of Safari+VoiceOver. So in theory, we "only" need to make Gecko expose the same accessible tree as WebKit in order to support the Mac platform. Jonathan Wei had a work-in-progress patch for that, see bug 1001641. Since it is far from being ready, I will cheat a bit and just show how VoiceOver reads the MathML examples in Safari.

Finally, the mobile platforms (Firefox OS and Android) are also very important. So far, I have only submitted some patches to make the GeckoView accessible and to fix some other small accessibility bugs. So I am interested in hearing more from Mozilla developers about the AccessFu stuff and how we could make MathML accessible on these platforms.

## Audio Demos

The table below contains some concrete examples taken from Wikipedia (in MathML mode), Mozilla Developer Network, KaTeX and MathJax. Note that at the moment, MathJax MathML formulas are not exposed to all assistive technologies. I recommend to force native MathML using an add-on for Gecko browsers or Safari ; or to use this GreaseMonkey script.

For the record, the detailed software versions used are:

• NVDA: Windows 7, Firefox 37, NVDA try-t4673-10720,5202e97, MathPlayer 4.0 beta 1
• VoiceOver: OS X Yosemite, Safari 8, VoiceOver 4
• Orca: Debian GNU/Linux 8 (jessie), Gnome 3.14.1, Firefox 31, Orca 3.14.0

## June Schedule

All of these developments are still in progress and there are certainly many bugs to fix and improvements to do. Next month, I expect to have several opportunities to meet people and make progress on MathML. For people interested to help, here is my schedule:

• On the 8th, I'll attend the 9th European e-Accessibility Forum in Paris where Neil Soiffer (Design Science) will present "The State of Accessible Math".
• From the 11th to 22th, I'll stay in the Montréal area. I hope I'll have the chance to meet Joanmarie and the accessibility team from Mozilla Toronto during that time frame (to be confirmed).
• Last but not least, I'm one of the lucky Mozilla volunteer invited to Whistler's work week from the 22th to 26th!

## Re: [css-writing-modes][svg] Embedded SVG and inheritance

Source: www-style@w3.org Mail Archives • Amelia Bellamy-Royds (amelia.bellamy.royds@gmail.com) • May 07, 2015 • Permalink

>From an SVG author's perspective, a  svg { all: unset; }  rule in the
default stylesheet would be very problematic; it would break current
content that uses SVG to style text within HTML (e.g., decorative headings)
with the expectation that the text styles are inherited.  It would also
throw off any sizing of the SVG using font-relative units.

On the specific issue of writing modes and layout, the desired behavior is
*either* to rotate the SVG to match the writing mode, or to inherit the
writing mode, but never both, since this would rotate the SVG text twice.

A case of when you would want to rotate the SVG would be a small inline
icon within latin rotated vertical text.  The same small icon within
upright vertical text would not be rotated.  A larger block SVG, such as a
chart, would also not be rotated.

I would therefore suggest the default should be *not* to rotate the SVG
contents.  However, there should be the *option* of rotating the graphic to
match the text, for both SVG and image inline icons or other small graphics.

I therefore propose there should be a new property that applies to block,
inline-block, and inline replaced content elements, to define how that
element's layout properties should be computed relative to the page layout:
possible names would be layout-orientation or content-orientation.

The main options would be the same as text-orientation: upright |
sideways-right | sideways-left | sideways .  However, there would be a new
option, context or use-text or something equivalent, which would say to
use the parent element's writing mode and text orientation to determine how
this element will be laid out.

The current prose statement in CSS Writing Modes about which content should
rotate by default would be redefined in terms of this new property.  So,
[itex] would have layout-orientation: context in the default stylesheet,
but <img> and <svg> would have layout-orientation: upright.  But the author
could over-ride either as required.

This still leaves the question of what to do with writing-mode.  I would
lean towards letting it inherit as normal, and requiring authors to
over-ride as they wish.

Best,
Amelia BR

On 7 May 2015 at 13:19, fantasai <fantasai.lists@inkedblade.net> wrote:

> On 05/07/2015 01:14 AM, Jonathan Kew wrote:
>
>> On 7/5/15 05:22, Koji Ishii wrote:
>>
>>> Not sure where to post cross-WG thing, IIUC cross-posting is not
>>> recommended, so let me start here.
>>>
>>
> Cross-posting is totally fine, when it's a legit thing that should
> be discussed in both groups. :)
>
>  An issue was brought up asking whether SVG viewBox is logical or
>>> physical when containing HTML has writing-mode: vertical-*. I think
>>> this is easy -- physical -- and should be confirmed at www-svg if
>>> needed.
>>>
>>> But then checking CSS Writing Modes brought up a couple of CSS questions.
>>>
>>> 1. Is SVG "images" or "content involving text"?
>>>
>>> CSS Writing Modes defines[1]:
>>>
>>> * The content of replaced elements do not rotate due to the writing
>>> mode: images, for example, remain upright.
>>>
>>> but then defines:
>>>
>>> * However replaced content involving text (such as MathML content or
>>> form elements) should match the replaced element’s writing mode and
>>> line orientation
>>>
>>> I suppose SVG belongs to images rather than "involving text" here even
>>> if SVG contains text.
>>>
>>
> Yes, I think it should probably be treated as an image. We'll
> want to clarify that in the spec.
>
>  2. Does writing-mode: vertical-rl in HTML inherits to SVG?
>>> [...]
>>>
>>
>> ... I agree it might be better to avoid this, as the svg image as a
>> whole does not rotate. While there may be some cases where an author
>> would want the text within an svg image to respond to the document's
>> writing mode, this seems unlikely to be widely useful.
>>
>> Perhaps we should simply add
>>
>>    svg { writing-mode: initial; }
>>
>> to the UA stylesheet? Then an author who *does* want the outside
>> writing-mode to apply to text within the svg can still use
>> "writing-mode: inherit" to achieve this.
>>
>
> It seems to me that this is a broader problem than just writing-mode.
> Should 'font-variant: small-caps' inherit into an SVG? What about
> 'text-emphasis'?
>
> It might just make sense for the UA style sheet to include
>
>   svg { all: unset; }
>
> and then make a per-property exception if necessary for some very
> specific reason, e.g.
>
>   svg { all: unset; color: inherit; }
>
> if we want 'color' to inherit by default.
>
> The place to make this change would be
>   * informatively in CSS Cascade Level 3 (as an example appendix)
>   * normatively in the appropriate SVG specs
>
> ~fantasai
>
>


## Re: [css-writing-modes][svg] Embedded SVG and inheritance

Source: www-style@w3.org Mail Archives • fantasai (fantasai.lists@inkedblade.net) • May 07, 2015 • Permalink

On 05/07/2015 01:14 AM, Jonathan Kew wrote:
> On 7/5/15 05:22, Koji Ishii wrote:
>> Not sure where to post cross-WG thing, IIUC cross-posting is not
>> recommended, so let me start here.

Cross-posting is totally fine, when it's a legit thing that should
be discussed in both groups. :)

>> An issue was brought up asking whether SVG viewBox is logical or
>> physical when containing HTML has writing-mode: vertical-*. I think
>> this is easy -- physical -- and should be confirmed at www-svg if
>> needed.
>>
>> But then checking CSS Writing Modes brought up a couple of CSS questions.
>>
>> 1. Is SVG "images" or "content involving text"?
>>
>> CSS Writing Modes defines[1]:
>>
>> * The content of replaced elements do not rotate due to the writing
>> mode: images, for example, remain upright.
>>
>> but then defines:
>>
>> * However replaced content involving text (such as MathML content or
>> form elements) should match the replaced element’s writing mode and
>> line orientation
>>
>> I suppose SVG belongs to images rather than "involving text" here even
>> if SVG contains text.

Yes, I think it should probably be treated as an image. We'll
want to clarify that in the spec.

>> 2. Does writing-mode: vertical-rl in HTML inherits to SVG?
>> [...]
>
> ... I agree it might be better to avoid this, as the svg image as a
> whole does not rotate. While there may be some cases where an author
> would want the text within an svg image to respond to the document's
> writing mode, this seems unlikely to be widely useful.
>
> Perhaps we should simply add
>
>    svg { writing-mode: initial; }
>
> to the UA stylesheet? Then an author who *does* want the outside
> writing-mode to apply to text within the svg can still use
> "writing-mode: inherit" to achieve this.

It seems to me that this is a broader problem than just writing-mode.
Should 'font-variant: small-caps' inherit into an SVG? What about
'text-emphasis'?

It might just make sense for the UA style sheet to include

svg { all: unset; }

and then make a per-property exception if necessary for some very
specific reason, e.g.

svg { all: unset; color: inherit; }

if we want 'color' to inherit by default.

The place to make this change would be
* informatively in CSS Cascade Level 3 (as an example appendix)
* normatively in the appropriate SVG specs

~fantasai


## Re: [css-writing-modes][svg] SVG and writing-mode

Source: www-style@w3.org Mail Archives • Jonathan Kew (jfkthame@gmail.com) • May 07, 2015 • Permalink

On 7/5/15 05:22, Koji Ishii wrote:
> Not sure where to post cross-WG thing, IIUC cross-posting is not
> recommended, so let me start here.
>
> An issue was brought up asking whether SVG viewBox is logical or
> physical when containing HTML has writing-mode: vertical-*. I think
> this is easy -- physical -- and should be confirmed at www-svg if
> needed.
>
> But then checking CSS Writing Modes brought up a couple of CSS questions.
>
> 1. Is SVG "images" or "content involving text"?
>
> CSS Writing Modes defines[1]:
>
> * The content of replaced elements do not rotate due to the writing
> mode: images, for example, remain upright.
>
> but then defines:
>
> * However replaced content involving text (such as MathML content or
> form elements) should match the replaced element’s writing mode and
> line orientation
>
> I suppose SVG belongs to images rather than "involving text" here even
> if SVG contains text.
>
> 2. Does writing-mode: vertical-rl in HTML inherits to SVG?
>
> The other one is how CSS writing-mode applies to text in SVG; i.e., if
> there were <text> in SVG, and the containing HTML is vertical-rl,
> should the <text> be vertical or not?
>
> Current implementation is a bit complicated. WebKit/Blink applies
> -webkit-writing-mode to HTML, and writing-mode to SVG, so if author
> specifies -webkit-writing-mode: vertical-rl, it does not affect SVG.
> But this behavior may change when unprefixed, depends on how we
> unprefix.
>
> Trident supports writing-mode in 2003 CR syntax for HTML, which is the
> same as the current SVG syntax. Applying writing-mode: tb applies both
> to HTML and SVG text.
>
> I couldn't test Gecko; when I applied vertical-rl to <body> and put
> SVG in it, it does not render as of today's nightly.

Not sure why this failed for you; could you file a bug with testcase?

Gecko does apply the writing-mode from HTML to the text within the SVG
as well, as shown by an example like:

data:text/html,<html style="writing-mode:vertical-rl">
<body>Hello world
<div>
<svg width="100" height="100">
<circle cx="50" cy="50" r="20" fill="green" />
<text x="50" y="50" font-family="sans-serif" font-size="20px"
fill="red">Hello!</text>
</svg>

However, I agree it might be better to avoid this, as the svg image as a
whole does not rotate. While there may be some cases where an author
would want the text within an svg image to respond to the document's
writing mode, this seems unlikely to be widely useful.

svg { writing-mode: initial; }

to the UA stylesheet? Then an author who *does* want the outside
writing-mode to apply to text within the svg can still use
"writing-mode: inherit" to achieve this.

JK


## [css-writing-modes][svg] SVG and writing-mode

Source: www-style@w3.org Mail Archives • Koji Ishii (kojiishi@gmail.com) • May 07, 2015 • Permalink

Not sure where to post cross-WG thing, IIUC cross-posting is not
recommended, so let me start here.

An issue was brought up asking whether SVG viewBox is logical or
physical when containing HTML has writing-mode: vertical-*. I think
this is easy -- physical -- and should be confirmed at www-svg if
needed.

But then checking CSS Writing Modes brought up a couple of CSS questions.

1. Is SVG "images" or "content involving text"?

CSS Writing Modes defines[1]:

* The content of replaced elements do not rotate due to the writing
mode: images, for example, remain upright.

but then defines:

* However replaced content involving text (such as MathML content or
form elements) should match the replaced element’s writing mode and
line orientation

I suppose SVG belongs to images rather than "involving text" here even
if SVG contains text.

2. Does writing-mode: vertical-rl in HTML inherits to SVG?

The other one is how CSS writing-mode applies to text in SVG; i.e., if
there were <text> in SVG, and the containing HTML is vertical-rl,
should the <text> be vertical or not?

Current implementation is a bit complicated. WebKit/Blink applies
-webkit-writing-mode to HTML, and writing-mode to SVG, so if author
specifies -webkit-writing-mode: vertical-rl, it does not affect SVG.
But this behavior may change when unprefixed, depends on how we
unprefix.

Trident supports writing-mode in 2003 CR syntax for HTML, which is the
same as the current SVG syntax. Applying writing-mode: tb applies both
to HTML and SVG text.

I couldn't test Gecko; when I applied vertical-rl to <body> and put
SVG in it, it does not render as of today's nightly.

# Proposal

While SVG might need some clarification in their spec if needed, I
think part of the problem come from the CSS definition where it
renders SVG upright (assuming my understanding above is correct) but
still writing-mode value is vertical and is inherited into SVG.

My proposal hence is CSS defines:
1. Clarify SVG should render upright
2. Upright-rendered replaced elements have default writing-mode to horizontal-tb

Stopping writing-mode inheritance at SVG boundary not only prevents
issues today, but also future issues when SVG changes its syntax, and
helps authors to not to surprise by all text in SVG images being
vertical when document's writing-mode was changed.

Thoughts?

[1] http://dev.w3.org/csswg/css-writing-modes-3/#block-flow
[2] http://dev.w3.org/csswg/css-writing-modes-3/#svg-writing-mode

/koji


## MathML Accessibility - Blog de Frédéric - Maths, Informatique, Jeux

Source: mathml - Google Blog Search • fredw • May 06, 2015 • Permalink

Overview In a previous blog post about MathML in Wikipedia, I mentioned that, despite ongoing efforts there was still no accessibility support for MathML in Gecko. The situation.

## jquery - How to convert MathML to image - Stack Overflow

Source: mathml - Google Blog Search • Farook • May 01, 2015 • Permalink

You can use latex code to generate those type of equations. URL for that - http://latex.codecogs.com. For your case, it will be http://latex.codecogs.com/gif.latex?%5Cinline%20%5Csqrt%5B1/2%5D%7B25%7D. Here, you need to ...

## Meeting minutes, 2014-04-27

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

The meetings are on the Web:

http://www.w3.org/2015/04/27-dpub-minutes.html

Text version below.

Thanks to Dave for scribing

Ivan

[1]W3C

[1] http://www.w3.org/

Digital Publishing Interest Group Teleconference

27 Apr 2015

[2]Agenda

[2] https://lists.w3.org/Archives/Public/public-digipub-ig/2015Apr/0098.html

[3] http://www.w3.org/2015/04/27-dpub-irc

Attendees

Present
Charles LaPierre (clapierre), Tzviya Siegman (Tzviya),
Rob Sanderson (azaroth), Ivan Herman (Ivan), Phil Madans
(philm), Markus Gylling (Markus), Bill Kasdorf
(Bill_Kasdorf), Laura Dawson (LDawson), Dave Cramer
(dauwhe), Deborah Kaplan (deborahGU), Laura Fowler
(lfowler), Patrick Keating (pkeating), Mike Miller
(astearns, Nick Ruffilo (NickRuffilo), Karen Myers
(Karen_Myers), Tim Cole (TimCole), Peter Krautzberger
(pkra), Paul Belfanti (pbelfanti), Ben De Meester
(bjdmeest), Bert Bos (Bert), Jeff Xu (zhengxu)

Regrets
Brady Duga, Ayla Stein, David Stroup, Julie Morris,
Heather Flanagan

Chair
Tzviya Siegman

Scribe
Dave Cramer

Contents

* [4]Topics
1. [5]STEM Survey
2. [6]Fragment ID-s
3. [7]HTML5 + Footnote
* [8]Summary of Action Items
__________________________________________________________

<trackbot> Date: 27 April 2015

<tzviya> agenda
[9]https://lists.w3.org/Archives/Public/public-digipub-ig/2015A
pr/0098.html

[9] https://lists.w3.org/Archives/Public/public-digipub-ig/2015Apr/0098.html

<tzviya> [10]http://www.w3.org/2015/04/20-dpub-minutes.html

[10] http://www.w3.org/2015/04/20-dpub-minutes.html

tzviya: let's look at last week's minutes
... motion to accept?
... minutes approved.
... today's agenda

<tzviya>
[11]https://lists.w3.org/Archives/Public/public-digipub-ig/2015
Apr/0098.html

[11] https://lists.w3.org/Archives/Public/public-digipub-ig/2015Apr/0098.html

STEM Survey

pkra: first look at survey
... 34 responses
... sent to 93 people
... ok result, but not too exciting
... people don't feel qualified to answer
... good coverage on all questions
... 37 questions total
... there's an unsurprising bias towards math
... partly due to me leading the survey
... lots of people talked about mathml
... it wasn't a random sample
... run through a few of the questions
... first section was about background
... bias towards CS and math
... 2nd was professional background
... didn't have a lot of aggregators
... most people were researchers
... researchers were primary audience
... which platforms people serve
... a few comments pointed to "the web is our platform"
... most people were focusing on desktop
... on the low end was print and ebooks
... next section was about content
... subject domains
... the question about reusing content was unclear
... "were people actively reusing content"
... prev. q was about making content resuable
... so people just repeated answer
... there was q about standardization
... there will be fun quotes from that

<pkra>
[12]https://www.w3.org/2002/09/wbs/64149/DPUB-STEM-2014-12/resu
lts

[12] https://www.w3.org/2002/09/wbs/64149/DPUB-STEM-2014-12/results

... there were a couple of problems
... first question didn't get responses we wanted
... want to know why people lose information when converting
... but questions were too vague
... people talked about transformation of text formats
... surprised to hear people do version control, did mention
things like git
... "we see more and more JSON in scholarly publishing"
... that was unexpected answer to STEM fragment storage
question
... and very positive

ivan: are some formats other than MathML that are widely used?

... not at this point
... alas, I don't have all the data in my head :)

tzviya: question 21, maybe?

pkra: yes, 21
... CML
... there isn't that much
... someone from Wolfram had CDS
... not as much as I'd hoped
... in the authoring section
... that was a good result
... people are used to using XML
... next section on delivery
... how is content delivered
... HTML was ahead of PDF
... 32% to 26%
... most produce both
... there was an open question about desired methods
... Q about migrating away from PDF
... people said Yes
... not enthusiastic about PDF but said they have to
... Q about exposing data on web
... answers were all over the place
... Q about embedding scientific data via attributes,
microdata, etc.
... quite a bit of stuff there

tzviya: more summary would be good

... the workflow section was tricky to write
... similarly solid in results, no surprises but good data
... PDF comes up because we have to
... a11y section I haven't looked at much
... that was a challenging section

tzviya: I have a few questions
... first
... everyone should read through this even if STEM isn't your
bag
... thanks PKRA!
... so what do we do next? There's a lot of information here,
and it's all over the place
... might be helpful to focus on a few points and go from there

pkra: one challenge is to extract data in efficient way to
... yes, it's a lot, and it's not clear what to focus on
... a meeting of task force will help
... to get an in-depth summary
... original idea was to publish a note by the IG
... but the input in some sections is not viable
... for example, a11y is not balanced enough to provide good
feedback

tzviya: if we try to write a note summarizing everything, it
would be huge

pkra: would be good to make data available in anonymized
fashion

... so I can just remove a column

pkra: yes, but maybe that's a different conversation
... Ivan, is it legally possible to publish data?

ivan: if it's anonymous, then it's not a problem

<astearns> not just names, but any identifying details in
free-form responses

pkra: then the note can be much more focused
... it's all anecdotal

Bill_Kasdorf: while the anon. data are useful, what's most
important are the messages
... sometimes they're clear and sometimes they're contradictory
... don't need to cover all issues equally
... what did we hear that was notable?

pkra: I agree

ivan: You also need people around you?

pkra: I will rely on the task force, but more people will be
great.

ivan: if anyone in the group has some experience in managing
survey results, volunteer!

pkra: I'm also not experienced

NickRuffilo: I've done this
questions or analyzing results, please let me know

tzviya: NickRuffilo is our new favorite

Bill_Kasdorf: too much reliance on statistical analysis would
be suspect due to the small and biased sample

<NickRuffilo> Excel TIPS:
[13]http://publishingperspectives.com/2013/01/tips-for-technolo
gists-7-excel-with-excel/

[13] http://publishingperspectives.com/2013/01/tips-for-technologists-7-excel-with-excel/

Karen: do I have confidence this is not public, just
members-only? I don't think raw results should be public

ivan: we can check

ivan: it's not public

Karen: OK. If there's a quote, it will not be attributed?
... more a qualitative report

ivan: it should never be quoted or attributed

pkra: most people would be OK with that

tzviya: we've never asked permission to quote people
... we have our existing STEM task force, and Nick has been
drafted.

<pkra> or otherwise shanghai you ;-)

Karen: we have a replacement AC rep for Copyright Clearance
center, who may be interested in STEM

tzviya: thanks Karen.
... moving on...

Fragment ID-s

tzviya: a few weeks ago there was a discussion about fragment
identifiers

[14]https://lists.w3.org/Archives/Public/public-annotation/2015
Apr/0051.html

[14] https://lists.w3.org/Archives/Public/public-annotation/2015Apr/0051.html

tzviya: which ended up on the annotations list
... Ivan will lead us through this

tzviya: lots of discussion on what makes a legal identifier

ivan: is rob around?
... we discussed that three weeks ago that the model for
selectors in open annotations document
... is in fact a very rich and powerful collection of terms

<tzviya> ivan: perhaps starting with position of the selection
model in open annotation is a good

<tzviya> ...not bound to one media type

<tzviya> ...the model is an abstract model, not described in
terms of URI

<tzviya> ...perhaps it's possible to turn it into fragment ID

<tzviya> ...then there was further discussion of when a frag ID
is legal, etc

<tzviya> Rob's position:
[15]https://lists.w3.org/Archives/Public/public-annotation/2015
Apr/0054.html

[15] https://lists.w3.org/Archives/Public/public-annotation/2015Apr/0054.html

ivan: the fundamental issue is the following
... a fragment identifier is bound to a specific media type
... you must register for each and every media type
... so you can't just declare the OA model for the entire world
... if we go down that route and use the selector model
... the correct way is we define them as part of a URI
... and then we register them for some of the media types for
which they are useful
... html, svg, etc.
... we can do that
... then it can be combined with other mechanisms as it's done
with web packaging
... it's not clear to me who should work on this
... I have the impression that there's some sort of agreement
that if we restrict by media types we can do this
... azaroth, is this a fair summary?

azaroth: yes, that's it

Bill_Kasdorf: keeping in mind the mission of the various groups
... DPUB is expressing needs, not writing standards
... I have a strong interest in what Anno WG comes up with
... as far as DPUB, our job is to surface the issue and work
with the appropriate WG
... the OA model you recommended came out of a CG
... I'm not trying to wash my hands of it

ivan: I understand and agree
... we already do this approach with structural semantics where
we're involved with PF
... the other thing is that we need to recharter this group
... maybe we can then go beyond what we have here
... we'll see where it goes after September

<TimCole>
[16]http://www.w3.org/2015/04/22-annotation-minutes.html

[16] http://www.w3.org/2015/04/22-annotation-minutes.html

TimCole: it was discussed at Anno F2F a bit
... if this is important to DPUB
... you need to push Anno WG
... talked about in context of rangefinder
... but it's not high on our priority list
... might be good to bring this up as collaborative
... the anno model allows lots of selectors
... not all will work as fragment identifiers
... also, EPUB already has something that kind of works

ivan: I agree

tzviya: we all are talking about epub cfi as if it solves the
issues, but few people use it
... there are too many options
... it's still a multiple choice question
... i can use xpointer, I can use CFI, but what happens with
packaging and building systems and epubweb
... those urls look like multi-part mime
... so maybe we should get used to those semicolons in URI

ivan: for me, the packaged uris don't look that funny
... if you combine with packaging, what is done in the
packaging spec is what should be done

<clapierre1> looks like Readium supports the EPUB CFI

ivan: we are getting into technical discussions
... good topic for f2f
... we should have clear and clean idea of pros and cons of CFI
... it's in the same space as the selectors
... CFI provides you with a fragment ID
... is CFI was completely useful then the package spec approach
combined with CFI and we are done
... so we need to have a clear idea in NY whether CFI works, or
it does not work
... if it does not work, we need to look at alternatives

Bill_Kasdorf: don't want to conflict with anno

HTML5 + Footnote

tzviya: we followed offline with berjon and michael smith
... HTML will not have a formal proposal for an element, so we
should pursue role with aria
... in the past, some roles have been promoted to element in
HTML
... so we're moving forward with ARIA role
... maybe HTML will take it up in the future

TimCole: since most annos are third party
... there might be use cases where people mine footnotes as
they mine annotations
... we should see how footnotes might be transformed into
annotations
... we should keep that in mind

tzviya: we agree
... footnotes are somewhere in the middle of content and
annotations

<azaroth> +1 :)

tzviya: let us know if you're coming to the f2f

<tzviya>
[18]http://www.w3.org/dpub/IG/wiki/May_2015_F2F_Logistics_and_D
etails

[18] http://www.w3.org/dpub/IG/wiki/May_2015_F2F_Logistics_and_Details

tzviya: see you next week

<ivan> trackbot, end telcon

Summary of Action Items

[End of minutes]
__________________________________________________________

Minutes formatted by David Booth's [19]scribe.perl version
1.140 ([20]CVS log)
$Date: 2015/05/30 00:31:47$

[19] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
[20] http://dev.w3.org/cvsweb/2002/scribe/

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



## CICM 2015 - Call for Work-in-Progress Papers

Source: www-math@w3.org Mail Archives • Serge Autexier (serge.autexier@dfki.de) • April 21, 2015 • Permalink

                   Call for Work-in-Progress Papers

Conference on Intelligent Computer Mathematics
CICM 2015

13-17 July 2015
Washington DC, USA

Digital and  computational solutions are becoming  the prevalent means
for the generation, communication, processing, storage and curation of
mathematical  information.  Separate  communities  have  developed  to
investigate  and build  computer based  systems for  computer algebra,
automated deduction, and mathematical publishing as well as novel user
interfaces. While all of these systems excel in their own right, their
value.  The  Conference  on Intelligent  Computer  Mathematics  (CICM)
offers a  venue for discussing  and developing solutions to  the great
challenges posed by the integration of these diverse areas.

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

This is a (short version of  the) call for Work-in-Progress papers for
CICM 2015,  which will be held  in Washington, D.C., 13-17  July 2015.
We  solicit  for  papers  which  describe  work  in  progress,  recent
developments, and other work of interest to our communities which does
not yet have the maturity for archival proceedings.

The full version of the CFP  is available from the conference web page
at http://cicm-conference.org/2015/cicm.php

**********************************************************************
The principal tracks of the conference will be:
**********************************************************************

* Calculemus (Symbolic Computation and Mechanised Reasoning)
Chair: Jacques Carette
* DML (Digital Mathematical Libraries)
Chair: Volker Sorge
* MKM (Mathematical Knowledge Management)
Chair: Cezary Kaliszyk
* Systems and Data
Chair: Florian Rabe

Publicity  chair is  Serge Autexier.  The local  arrangements will  be
coordinated  by  the  Local   Arrangements  Chairs,  Bruce  R.  Miller
(National  Institute  of  Standards  and Technology,  USA)  and  Abdou
Youssef (The George Washington  University, Washington, D.C.), and the
overall programme  will be organized  by the General  Programme Chair,
Manfred Kerber (U. Birmingham, UK).

**********************************************************************
Important Dates
**********************************************************************

Work-in-progress and Doctoral Programme submissions:
Full Work-in-Progress submission*   4 May      2015
Notification of acceptance:        25 May      2015
Camera ready copies due:            1 June     2015
Conference:                     13-17 July     2015

* or for the Doctoral Programme: Abstract+CV

More detailed  information, e.g. on  submission via EasyChair,  can be
found on http://cicm-conference.org/2015/cicm.php


Source: Ask.com News Search for "mathml" • April 20, 2015 • Permalink

 CreativePro.com - Found Apr. 20, 2015 ... for technical writers as MathMagic reads and writes various industry standard equation formats, such as MathML, AMS LaTeX, LaTeX, Plain TeX...

## Learn about MathML in DITA 1.3 at the DITA conference in Chicago

Source: Design Science News • Bruce Virga • April 16, 2015 • Permalink

Design Science will be exhibiting and presenting at the DITA North America Conference in Chicago, April 20-22. If you want to learn the proper way to implement math with your content, this is a great opportunity to meet with the experts.

Plan to see Design Science's Autumn Cuellar and Aaron Guigar present the topic Introducing DITA 1.3's Equation Specialization and Its Star: MathML, on April 21st at 10:20am. In this session they will describe what MathML is and the advantages of using it, its role in DITA 1.3, and the available tools for authoring, display and accessibility of MathML.

Also, stop by our booth in the exhibit hall so we can answer your specific questions and try to help with your project.

If you cannot make the conference, we'll be posting the slides/text on our website after the conference.

We hope to see you in Chicago!

Topics in this post:

## Learn about MathML in DITA 1.3 at the DITA conference in Chicago ...

Source: mathml - Google Blog Search • Bruce Virga • April 16, 2015 • Permalink

Learn about MathML in DITA 1.3 at the DITA conference in Chicago. Design Science will be exhibiting and presenting at the DITA North America Conference in Chicago, April 20-22. If you want to learn the proper way to ...

## MathPlayer 4 – Spoken accessible math in Microsoft Word at POSB Math/Science Institute, April 14-15

Source: Design Science News • Bob Mathews • April 14, 2015 • Permalink

At the Principals of Schools for the Blind (POSB) Math/Science Institute this week in Boston, Neil Soiffer will demonstrate MathPlayer 4 and its ability to read math in Internet Explorer, Firefox, and Microsoft Word. Design Science has been working jointly with Educational Testing Service (ETS) and assisted by some of the country’s leading subject matter experts and developers of assistive technology. With this free tool from Design Science, students with blindness or other visual impairments are able to learn, practice and take math and science tests on a more equal footing with their classroom peers.

If you're able to attend the conference, join us tomorrow at 1:35 PM, when Neil will present MathML to Voiced Math, along with Lois Frankel and Beth Brownstein from ETS. Neil will also be at the Design Science table in the exhibit area today and tomorrow.

Visit the MathPlayer Download page for more information and to download the latest version of MathPlayer, and the test build of NVDA. The initial release works with a test build of the NVDA screen reader to speak and Braille math. We expect to announce MathPlayer support with other assistive technology software products in the coming weeks and months.

Topics in this post:

## Re: data-* attributes

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

Just an afterthought on this. The MathML spec actually enforces one use of
data-* in HTML, namely for custom maction types, see
http://www.w3.org/Math/draft-spec/mathml.html#chapter3_id.3.7.1.1.

Peter.

On Tue, Nov 4, 2014 at 3:33 AM, William F Hammond <hammond@csc.albany.edu>
wrote:

>
> > <mi jats:foo="bar"> is valid to the MathML3 schema (as long
> > as jats: namespace is declared somewhere) it's just that you
> > don't want to let attributes with colons in their name
> > anywhere near an HTML parser, ...
>
> I've never thought that xml-namespaces are of much real
> value for xml document instances (as opposed to xml
> electronic data instances).
>
> In particular, I've understood the banishment of namespaces
> from HTML 5 to represent revulsion toward xml-namespaces of
> those who produce documents.
>
> I think it should be possible to structure the world of HTML
> so that automatic generators (from various profiles of LaTeX
> or DocBook or ...) to HTML5 can switch easily between the
> text/html and the application/xhtml+xml serializations.
> This would mean, in particular, not really using
> xml-namespaces with the latter serialization, but keeping
> within a reasonable framework for validation.  Maybe one
> could introduce for MathML a value something like html's
> "style".  For example, instead of <mi jats:foo="bar">
> something like <mi mmdata='ns: jats; foo1: bar1; foo2:
> "bar2a bar2b"; foo3: bar3;'> which would, with mmdata added
> to the definition of html as an unspecified cdata attribute,
> be able to pass html validation.  As with css a separate,
> less essential, and perhaps not universal, validator could
> check mmdata values.
>
>                                     -- Bill
>
>


## 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.