Planet MathML - W3Chttp://www.w3.org/Math/planet/atom.xml2016-12-01T19:00:20+00:00Planet/2.0 +http://www.planetplanet.orgRe: [math-on-web] reminder: next meeting Thursday, Dec 1mid:CABqxo83_CfskBTrEeJY9-hRiS05JeuGaQKf0gNbHoO7M4WMaCQ@mail.gmail.com2016-12-01T18:56:44+00:00<div>
<pre id="body">
<a shape="rect" name="start3" accesskey="j" id="start3"></a>PS: The hangout is now ready.
Best,
Peter.
On Thu, Dec 1, 2016 at 7:13 PM, Peter Krautzberger <
<a shape="rect" href="mailto:peter.krautzberger@mathjax.org?Subject=Re%3A%20%5Bmath-on-web%5D%20reminder%3A%20next%20meeting%20Thursday%2C%20Dec%201&In-Reply-To=%3CCABqxo83_CfskBTrEeJY9-hRiS05JeuGaQKf0gNbHoO7M4WMaCQ%40mail.gmail.com%3E&References=%3CCABqxo83_CfskBTrEeJY9-hRiS05JeuGaQKf0gNbHoO7M4WMaCQ%40mail.gmail.com%3E">peter.krautzberger@mathjax.org</a>> wrote:
> Yikes!
>
> I made an error.
>
> This was supposed to be
>
> 7pm UTC
>
> since daylight saving time has passed.
>
> Sorry for the confusion!
>
> Hopefully see you in a few minutes.
> Peter.
>
> On Nov 29, 2016 10:19 AM, "Peter Krautzberger" <
> <a shape="rect" href="mailto:peter.krautzberger@mathjax.org?Subject=Re%3A%20%5Bmath-on-web%5D%20reminder%3A%20next%20meeting%20Thursday%2C%20Dec%201&In-Reply-To=%3CCABqxo83_CfskBTrEeJY9-hRiS05JeuGaQKf0gNbHoO7M4WMaCQ%40mail.gmail.com%3E&References=%3CCABqxo83_CfskBTrEeJY9-hRiS05JeuGaQKf0gNbHoO7M4WMaCQ%40mail.gmail.com%3E">peter.krautzberger@mathjax.org</a>> wrote:
>
>> Hi everyone,
>>
>> Just a quick reminder that we skipped meeting last week and meet
>>
>> *December 1, 2016, 6pm UTC*
>>
>> The hangouts link is [1].
>>
>> Best,
>> Peter.
>>
>> [1] <a shape="rect" href="https://hangouts.google.com/hangouts/_/mathjax.org/math-on-web-cg">https://hangouts.google.com/hangouts/_/mathjax.org/math-on-web-cg</a>
>>
>
</pre>
</div>Peter Krautzbergerpeter.krautzberger@mathjax.orghttp://lists.w3.org/Archives/Public/public-mathonwebpages/Re: [math-on-web] reminder: next meeting Thursday, Dec 1mid:CABqxo82EyrR-4zvuFVb31SEYWLj28o5EikgNq=0q=nRF0nO2eg@mail.gmail.com2016-12-01T18:13:54+00:00<div>
<pre id="body">
<a shape="rect" name="start2" accesskey="j" id="start2"></a>Yikes!
I made an error.
This was supposed to be
7pm UTC
since daylight saving time has passed.
Sorry for the confusion!
Hopefully see you in a few minutes.
Peter.
On Nov 29, 2016 10:19 AM, "Peter Krautzberger" <
<a shape="rect" href="mailto:peter.krautzberger@mathjax.org?Subject=Re%3A%20%5Bmath-on-web%5D%20reminder%3A%20next%20meeting%20Thursday%2C%20Dec%201&In-Reply-To=%3CCABqxo82EyrR-4zvuFVb31SEYWLj28o5EikgNq%3D0q%3DnRF0nO2eg%40mail.gmail.com%3E&References=%3CCABqxo82EyrR-4zvuFVb31SEYWLj28o5EikgNq%3D0q%3DnRF0nO2eg%40mail.gmail.com%3E">peter.krautzberger@mathjax.org</a>> wrote:
> Hi everyone,
>
> Just a quick reminder that we skipped meeting last week and meet
>
> *December 1, 2016, 6pm UTC*
>
> The hangouts link is [1].
>
> Best,
> Peter.
>
> [1] <a shape="rect" href="https://hangouts.google.com/hangouts/_/mathjax.org/math-on-web-cg">https://hangouts.google.com/hangouts/_/mathjax.org/math-on-web-cg</a>
>
</pre>
</div>Peter Krautzbergerpeter.krautzberger@mathjax.orghttp://lists.w3.org/Archives/Public/public-mathonwebpages/Re: plain text math notationmid:CACE=nd2pbJcAu2WWWT4D0rQVhaOC8ANm7qnO+o4ByhV6BSwEjg@mail.gmail.com2016-12-01T11:00:18+00:00<div>
<pre id="body">
<a shape="rect" name="start1" accesskey="j" id="start1"></a>>
> 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.
>
Do you consider CAS's to be examples of such languages? What about Content
MathML and OpenMath, or is this a third category, distinct from the Content
vs Presentation MathML categories that (I think) quite cleanly divide all
the notations mentioned so far?
(To me, it's clear that:
Presentation MathML-likes include: LaTeX, troff/eqn
<<a shape="rect" href="https://en.wikipedia.org/wiki/Eqn">https://en.wikipedia.org/wiki/Eqn</a>>, the LibreOffice syntax which looks
very similar, possibly identical to troff/eqn, AsciiMath, UnicodeMath,
MathSON (I'm the one working on MathSON, btw)
Content MathML-likes include: OpenMath (did they merge or something?),
Mathematica, Matlab, Octave, mathjs, Maple, Excel, SymPy, algebra.js
Note that except for OpenMath and Content MathML itself, all the content
formats are directly tied to a CAS and/or evaluation engine; and except for
Presentation MathML itself, all the presentation formats are directly tied
to a rendering engine.
Also note that while all the content formats are meant for machine
evaluation or manipulation and are therefore tree-structured and quite
amenable to machine manipulation, the only presentation format that is
tree-structured and hence amenable to machine manipulation is MathML, if we
ignore MathSON which basically doesn't exist yet (zero implementations);
which is kind of exactly why I'm working on MathSON.)
Han
> ------------------------------
> *From:* Paul Topping <<a shape="rect" href="mailto:pault@dessci.com?Subject=Re%3A%20plain%20text%20math%20notation&In-Reply-To=%3CCACE%3Dnd2pbJcAu2WWWT4D0rQVhaOC8ANm7qnO%2Bo4ByhV6BSwEjg%40mail.gmail.com%3E&References=%3CCACE%3Dnd2pbJcAu2WWWT4D0rQVhaOC8ANm7qnO%2Bo4ByhV6BSwEjg%40mail.gmail.com%3E">pault@dessci.com</a>>
> *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
>
> <a shape="rect" href="http://www.dessci.com">http://www.dessci.com</a>
>
>
>
> *From:* Jos de Jong [mailto:<a shape="rect" href="mailto:wjosdejong@gmail.com?Subject=Re%3A%20plain%20text%20math%20notation&In-Reply-To=%3CCACE%3Dnd2pbJcAu2WWWT4D0rQVhaOC8ANm7qnO%2Bo4ByhV6BSwEjg%40mail.gmail.com%3E&References=%3CCACE%3Dnd2pbJcAu2WWWT4D0rQVhaOC8ANm7qnO%2Bo4ByhV6BSwEjg%40mail.gmail.com%3E">wjosdejong@gmail.com</a>]
> *Sent:* Thursday, September 22, 2016 11:52 AM
> *To:* Robin Berjon <<a shape="rect" href="mailto:robin@berjon.com?Subject=Re%3A%20plain%20text%20math%20notation&In-Reply-To=%3CCACE%3Dnd2pbJcAu2WWWT4D0rQVhaOC8ANm7qnO%2Bo4ByhV6BSwEjg%40mail.gmail.com%3E&References=%3CCACE%3Dnd2pbJcAu2WWWT4D0rQVhaOC8ANm7qnO%2Bo4ByhV6BSwEjg%40mail.gmail.com%3E">robin@berjon.com</a>>
> *Cc:* Peter Krautzberger <<a shape="rect" href="mailto:peter.krautzberger@mathjax.org?Subject=Re%3A%20plain%20text%20math%20notation&In-Reply-To=%3CCACE%3Dnd2pbJcAu2WWWT4D0rQVhaOC8ANm7qnO%2Bo4ByhV6BSwEjg%40mail.gmail.com%3E&References=%3CCACE%3Dnd2pbJcAu2WWWT4D0rQVhaOC8ANm7qnO%2Bo4ByhV6BSwEjg%40mail.gmail.com%3E">peter.krautzberger@mathjax.org</a>>;
> public-mathonw. <<a shape="rect" href="mailto:public-mathonwebpages@w3.org?Subject=Re%3A%20plain%20text%20math%20notation&In-Reply-To=%3CCACE%3Dnd2pbJcAu2WWWT4D0rQVhaOC8ANm7qnO%2Bo4ByhV6BSwEjg%40mail.gmail.com%3E&References=%3CCACE%3Dnd2pbJcAu2WWWT4D0rQVhaOC8ANm7qnO%2Bo4ByhV6BSwEjg%40mail.gmail.com%3E">public-mathonwebpages@w3.org</a>>
> *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 <<a shape="rect" href="mailto:robin@berjon.com?Subject=Re%3A%20plain%20text%20math%20notation&In-Reply-To=%3CCACE%3Dnd2pbJcAu2WWWT4D0rQVhaOC8ANm7qnO%2Bo4ByhV6BSwEjg%40mail.gmail.com%3E&References=%3CCACE%3Dnd2pbJcAu2WWWT4D0rQVhaOC8ANm7qnO%2Bo4ByhV6BSwEjg%40mail.gmail.com%3E">robin@berjon.com</a>> 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] <a shape="rect" href="http://babeljs.io/">http://babeljs.io/</a>
> [1] <a shape="rect" href="https://facebook.github.io/react/docs/jsx-in-depth.html">https://facebook.github.io/react/docs/jsx-in-depth.html</a>
>
> --
> • Robin Berjon - <a shape="rect" href="http://berjon.com/">http://berjon.com/</a> - @robinberjon
> • <a shape="rect" href="http://science.ai/">http://science.ai/</a> — intelligent science publishing
> •
>
>
>
</pre>
</div>Hanlaughinghan@gmail.comhttp://lists.w3.org/Archives/Public/public-mathonwebpages/Re: plain text math notationmid:CABqxo829ZSjE=Bdt9YVyfUd-fvpp_faw_v69QZ94U6ffKQR7Zg@mail.gmail.com2016-12-01T07:54:30+00:00<div>
<pre id="body">
<a shape="rect" name="start0" accesskey="j" id="start0"></a>This might be interesting for those following this thread:
Murray Sargent just published v3.1 of his linear syntax, now dubbed
UnicodeMath [1]
See you in a few hours,
Peter.
[1]
<a shape="rect" href="https://blogs.msdn.microsoft.com/murrays/2016/11/30/unicodemath-version-3-1/">https://blogs.msdn.microsoft.com/murrays/2016/11/30/unicodemath-version-3-1/</a>
On Mon, Sep 26, 2016 at 4:27 PM, Robin Berjon <<a shape="rect" href="mailto:robin@berjon.com?Subject=Re%3A%20plain%20text%20math%20notation&In-Reply-To=%3CCABqxo829ZSjE%3DBdt9YVyfUd-fvpp_faw_v69QZ94U6ffKQR7Zg%40mail.gmail.com%3E&References=%3CCABqxo829ZSjE%3DBdt9YVyfUd-fvpp_faw_v69QZ94U6ffKQR7Zg%40mail.gmail.com%3E">robin@berjon.com</a>> wrote:
> 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 - <a shape="rect" href="http://berjon.com/">http://berjon.com/</a> - @robinberjon
> • <a shape="rect" href="http://science.ai/">http://science.ai/</a> — intelligent science publishing
> •
>
</pre>
</div>Peter Krautzbergerpeter.krautzberger@mathjax.orghttp://lists.w3.org/Archives/Public/public-mathonwebpages/Re: [math-on-web] reminder: next meeting Thursday, Dec 1 JeanKapmid:CAKPaaTqZvp-DPd-CnXa5obf8cORnM2kiLxuN-0mhRyvpK6rqoA@mail.gmail.com2016-11-29T16:35:35+00:00<div>
<pre id="body">
<a shape="rect" name="start2" accesskey="j" id="start2"></a>Please forgive my lameness in not having prepared the list of things I was
supposed to prepare for this meeting.
The good news is that MHE is keeping me on as an official full-time
employee as of December 12. Which means brain bandwidth dedicated to
finding work is opening up and I will be able to start work on this list
after the holidays.
-Jean
On Tue, Nov 29, 2016 at 4:19 AM, Peter Krautzberger <
<a shape="rect" href="mailto:peter.krautzberger@mathjax.org?Subject=Re%3A%20%5Bmath-on-web%5D%20reminder%3A%20next%20meeting%20Thursday%2C%20Dec%201%20JeanKap&In-Reply-To=%3CCAKPaaTqZvp-DPd-CnXa5obf8cORnM2kiLxuN-0mhRyvpK6rqoA%40mail.gmail.com%3E&References=%3CCAKPaaTqZvp-DPd-CnXa5obf8cORnM2kiLxuN-0mhRyvpK6rqoA%40mail.gmail.com%3E">peter.krautzberger@mathjax.org</a>> wrote:
> Hi everyone,
>
> Just a quick reminder that we skipped meeting last week and meet
>
> *December 1, 2016, 6pm UTC*
>
> The hangouts link is [1].
>
> Best,
> Peter.
>
> [1] <a shape="rect" href="https://hangouts.google.com/hangouts/_/mathjax.org/math-on-web-cg">https://hangouts.google.com/hangouts/_/mathjax.org/math-on-web-cg</a>
>
*Jean Kaplansky*
Content Architect/Strategist | Technical Account Manager | UI/UX |
Accessibility Analyst | XML, HTML, and CSS Developer |
Instructional Designer
+1.518.930.1068
<a shape="rect" href="mailto:jeankap@earthlink.net?Subject=Re%3A%20%5Bmath-on-web%5D%20reminder%3A%20next%20meeting%20Thursday%2C%20Dec%201%20JeanKap&In-Reply-To=%3CCAKPaaTqZvp-DPd-CnXa5obf8cORnM2kiLxuN-0mhRyvpK6rqoA%40mail.gmail.com%3E&References=%3CCAKPaaTqZvp-DPd-CnXa5obf8cORnM2kiLxuN-0mhRyvpK6rqoA%40mail.gmail.com%3E">jeankap@earthlink.net</a>
@jeankaplansky <<a shape="rect" href="mailto:jeankap@earthlink.net?Subject=Re%3A%20%5Bmath-on-web%5D%20reminder%3A%20next%20meeting%20Thursday%2C%20Dec%201%20JeanKap&In-Reply-To=%3CCAKPaaTqZvp-DPd-CnXa5obf8cORnM2kiLxuN-0mhRyvpK6rqoA%40mail.gmail.com%3E&References=%3CCAKPaaTqZvp-DPd-CnXa5obf8cORnM2kiLxuN-0mhRyvpK6rqoA%40mail.gmail.com%3E">jeankap@earthlink.net</a>>
On Tue, Nov 29, 2016 at 4:19 AM, Peter Krautzberger <
<a shape="rect" href="mailto:peter.krautzberger@mathjax.org?Subject=Re%3A%20%5Bmath-on-web%5D%20reminder%3A%20next%20meeting%20Thursday%2C%20Dec%201%20JeanKap&In-Reply-To=%3CCAKPaaTqZvp-DPd-CnXa5obf8cORnM2kiLxuN-0mhRyvpK6rqoA%40mail.gmail.com%3E&References=%3CCAKPaaTqZvp-DPd-CnXa5obf8cORnM2kiLxuN-0mhRyvpK6rqoA%40mail.gmail.com%3E">peter.krautzberger@mathjax.org</a>> wrote:
> Hi everyone,
>
> Just a quick reminder that we skipped meeting last week and meet
>
> *December 1, 2016, 6pm UTC*
>
> The hangouts link is [1].
>
> Best,
> Peter.
>
> [1] <a shape="rect" href="https://hangouts.google.com/hangouts/_/mathjax.org/math-on-web-cg">https://hangouts.google.com/hangouts/_/mathjax.org/math-on-web-cg</a>
>
</pre>
</div>Jean Kaplanskyjeankap@earthlink.nethttp://lists.w3.org/Archives/Public/public-mathonwebpages/[math-on-web] a11y TF minutes 2016-11-28mid:CABqxo81mTWMbvP_BtffC8EzoniB=J1NKiRoV4dYQZxHq8n5fHQ@mail.gmail.com2016-11-29T09:36:29+00:00<div>
<pre id="body">
<a shape="rect" name="start1" accesskey="j" id="start1"></a>Hi everyone,
A few notes from the task force meeting this week.
We'll give an update at the next meeting.
Best,
Peter.
# CG a11y TF meeting 2016-11-28
* Peter: working on demos, <a shape="rect" href="https://codepen.io/pkra/pen/VmZLgZ">https://codepen.io/pkra/pen/VmZLgZ</a>
<<a shape="rect" href="https://codepen.io/pkra/pen/VmZLgZ?editors=1010">https://codepen.io/pkra/pen/VmZLgZ?editors=1010</a>>
* works reasonably well in AT
* required reading:
<a shape="rect" href="http://blog.jantrid.net/2015/12/woe-aria-surprisingly-but-ridiculously.html">http://blog.jantrid.net/2015/12/woe-aria-surprisingly-but-ridiculously.html</a>
* Dani's example (replicated at <a shape="rect" href="https://codepen.io/pkra/pen/dOVPVL">https://codepen.io/pkra/pen/dOVPVL</a>)
* ignoring MathML for now, just focus on a11y of output
* two versions: simple and deep labels
* math attribute: idea for keeping source alongside
* title as idea for providing informative
* aria-role="variable" as idea for math-specific roles
* the problem of fraction lines
* should be an element in the DOM
* it's not bad but actually good for AT to have this
* Dani: we should work on a recommendation for doing mathematics in a
static way
* Peter: +1. See the discussion following TPAC re MML media query
* Peter: about role math
* we should suggest new definition (current: "all children are
aria-hidden").
* Could help with Dani's title idea, i.e., help AT announce
"math/formula/equation" if user desires
* AT could use it to change speech prefs, e.g., voicing punctuation.
* Dani: these should still be easily controlled/determined by authoring
(software)
* Peter: also manual (e.g., specialist reported requests to match
teacher's speech pattern)
* Volker: when do you expect to switch between descriptions and content?
* Volker: maybe something like "replace anything non-alphanumeric"?
* Volker: how does navigation work
* Peter: in my example, works already quite well. Just explore the DOM as
usual.
* e.g., MathJax CommonHTML and HTML-CSS output -- expected problems
with MathJax SVG due to optimizations.
* Dani: I like that it's not specific to mathematics. Just as well for
diagrams,
* Peter: me too!
* Volker: back to navigation: is just tapping through?
* Dani: should be just like any other content
* Volker: cf. HighChart examples,
<a shape="rect" href="http://www.highcharts.com/docs/chart-concepts/accessibility">http://www.highcharts.com/docs/chart-concepts/accessibility</a>.
* Just tabbing through.
* Peter: I just used regular screenreader navigation (by line/letter)
* seems natural since that's how regular content is interacted with
* tabbing for display equations might make sense though
* Peter: let's increase our meeting intervals
</pre>
</div>Peter Krautzbergerpeter.krautzberger@mathjax.orghttp://lists.w3.org/Archives/Public/public-mathonwebpages/[math-on-web] reminder: next meeting Thursday, Dec 1mid:CABqxo81daZCBM_270wa_BnYa=ZFs2NWVY76u_LPO10eYDnAWYA@mail.gmail.com2016-11-29T09:19:49+00:00<div>
<pre id="body">
<a shape="rect" name="start0" accesskey="j" id="start0"></a>Hi everyone,
Just a quick reminder that we skipped meeting last week and meet
*December 1, 2016, 6pm UTC*
The hangouts link is [1].
Best,
Peter.
[1] <a shape="rect" href="https://hangouts.google.com/hangouts/_/mathjax.org/math-on-web-cg">https://hangouts.google.com/hangouts/_/mathjax.org/math-on-web-cg</a>
</pre>
</div>Peter Krautzbergerpeter.krautzberger@mathjax.orghttp://lists.w3.org/Archives/Public/public-mathonwebpages/Re: ForAll & its matemid:e9237119-5e98-c29e-489e-01dd50440e26@tbbs.net2016-11-27T01:58:38+00:00<div>
<pre id="body">
<a shape="rect" name="start2" accesskey="j" id="start2"></a>2016/11/24 09:13 ... David Carlisle:
> Changing the names has quite a high cost (as it involves getting changes
> into HTML) there has only been one new name introduced
> since the original MathML set was proposed in 1998 so there has
> been no change here for 18 years:-)
Of course ... therefore did I wistfully wish that I had noticed when
those names with small and capital letters were added to a set with only
small letters, when "ForAll" began to stand beside "forall", that I then
could suggest "ForSome" to stand beside "exist". *sigh*
</pre>
</div>Hal.sz S.ndorhsv@tbbs.nethttp://lists.w3.org/Archives/Public/www-math/Re: ForAll & its matemid:3dd5cfcb-9a13-74e6-412b-d46002fa1489@nag.co.uk2016-11-24T14:13:27+00:00<div>
<pre id="body">
<a shape="rect" name="start1" accesskey="j" id="start1"></a>On 23/11/2016 23:07, Hal.sz S.ndor wrote:
> When I last looked at such names, they were short and all in small
> letters. Now I see that they are longer, and capitals are in them. If I
> had known that change was a-coming, I would have suggested that the
> other quantifier than ForAll get another name besides that which it got,
> one much more a complement to "ForAll", namely "ForSome". If not all
> people like something, then some people do not like that.
>
Changing the names has quite a high cost (as it involves getting changes
into HTML) there has only been one new name introduced
since the original MathML set was proposed in 1998 so there has
been no change here for 18 years:-)
Of course in local XML processing you can easily define any names that
you like. For a published XML it is usually best to expand all the
entities out to character data, even the standard ones, as an XML
fragment using an entity reference is not well formed once it has
lost the <!DOCTYPE reference to the dtd definitions.
David
________________________________
The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
This e-mail has been scanned for all viruses by Microsoft Office 365.
________________________________
</pre>
</div>David Carlisledavidc@nag.co.ukhttp://lists.w3.org/Archives/Public/www-math/ForAll & its matemid:9a1d5bf3-9505-9498-ec2e-180c243cb4ab@tbbs.net2016-11-23T23:07:34+00:00<div>
<pre id="body">
<a shape="rect" name="start0" accesskey="j" id="start0"></a>When I last looked at such names, they were short and all in small
letters. Now I see that they are longer, and capitals are in them. If I
had known that change was a-coming, I would have suggested that the
other quantifier than ForAll get another name besides that which it got,
one much more a complement to "ForAll", namely "ForSome". If not all
people like something, then some people do not like that.
</pre>
</div>Hal.sz S.ndorhsv@tbbs.nethttp://lists.w3.org/Archives/Public/www-math/[CSSWG] Minutes Lisbon F2F 2016-09-19 Part III: Joint Meeting with DPUB [mediaqueries] [css-text] [css-page]mid:CADhPm3uMfKnsR1RSJcn=4dowGcCSXwMciNywkPrqNK1Uf1gEMA@mail.gmail.com2016-11-16T01:57:19+00:00<div>
<pre id="body">
<a shape="rect" name="start71" accesskey="j" id="start71"></a>=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Joint Meeting with DPUB
=======================
Media Queries - MathML
----------------------
- RESOLVED: Add a MQ that reports MathML support, with some way
for scripts to claim support.
- glazou will inform epub of the resolution and Florian will write
the new MQ.
Text - Character-based Alignment
--------------------------------
- Progress on this issue seemed to be awaiting good examples to
dauwhe will collect them and bring them to the attention of
the Text 4 editors.
- dino expressed that the way to get this on Apple's radar is to
reach out with statements of customer/publishing house need.
CSS vs XSL-FO: Gap Analysis
---------------------------
- liam will identify the things in XSL-FO that are hard to do in
CSS, and write up some results.
Page floats
-----------
- Johannes has done a bunch of work and has the basics of level 1
in places but it needs better error handling.
Text - Hanging punctuation
-------------------
- myles proposed waiting until level 4 of Text to address hanging
punctuation as it only works well for CJK in the current
definition.
- There was some proposals around solving for Latin punctuation.
- dauwhe will look more into what inDesign is doing.
- fantasai suggested pair-kerning against the margins
- RESOLVED: Keep hanging-punctuation in level 3, marked as
at-risk, study whether it needs to be punted.
===== FULL MINUTES BELOW ======
Agenda: <a shape="rect" href="https://www.w3.org/dpub/IG/wiki/Detailed_TPAC_2016_Agenda#Meeting_with_CSS_WG">https://www.w3.org/dpub/IG/wiki/Detailed_TPAC_2016_Agenda#Meeting_with_CSS_WG</a>
and <a shape="rect" href="https://wiki.csswg.org/planning/tpac-2016#agenda">https://wiki.csswg.org/planning/tpac-2016#agenda</a>
Scribe: TabAtkins
Joint Meeting with DPUB
=======================
dauwhe: We wanted to discuss a few issues with CSS, mostly to get
input as to what are good areas to continue working in, so
we don't conflict with design/impl of CSS.
fantasai: Work on hyphenation!
Media Queries - MathML
----------------------
dauwhe: The first thing is MQs. We have some interesting use-cases.
dauwhe: Daniel created one of the them.
glazou: The epub world has an issue with MathML. Legacy systems
don't know about it.
glazou: In particular, the image fallback for MathML.
glazou: The publishers are not really willing to invest in MathML
inside of ebooks, because they're pretty sure legacy
systems won't show anything.
glazou: MathML won't render, nor will the fallback.
glazou: One possible solution is to have a feature MQ for MathML
(like the script one).
glazou: So you can display:block/none for the (separate) image
fallback.
glazou: Not the *only* options for epub, but one of them.
TabAtkins: And this implies that the fallback is done outside of
the MathML, so it'll render normally?
glazou: Yes.
Rossen: You mean native support for MathML, not mathjax?
glazou: Yes. Generally just doesn't support MathML. Sometimes
they'll render the text, sometimes not; they usually don't
render the fallback.
Florian: And if you do have support for script, you load MathJax?
dauwhe: These usually don't have scripting
Bill_Kasdorf: And right now, because of no MathML support, the
epubs don't have accessible math at all.
dino: So let's say you're not in a legacy system. You'll say
display:block on the MathML and display:none on the fallback?
dino: So it's just testing for native; script support will be
something else?
TabAtkins: In script, if it runs, you can handle that yourself.
tzviya: We're not just talking about MathML here. We want to talk
about the future of MQs in general.
tzviya: Some work with ARIA has talked about using MQs for some
solutions there, so we wanted some more general ideas
about MQs.
tzviya: Maybe something about affecting the chrome?
Florian: One topic is that we used to have media types; these
worked poorly. We're deprecating as much as we can, and
instead finding the more granular level of things that
distinguish the types. Pages vs not, interactive vs
static, etc.
Florian: Granular rather than bundled. That's a big theme we've
been running towards.
Florian: Another is to expose various user prefs. User wants
high-contrast, etc.
Florian: Not working on that yet, sometimes tricky. Some OSes
forcibly invert the screen or contrast; others just
express the preference to the app.
Florian: We need to reflect both; whether you've been inverted
(and you should maybe respond to that), and whether the
user requests inverting (that you're expected to do).
duga: About native support, a lot of reading systems provide
polyfills.
duga: I don't necessarily care that the browser renders native
MathML; I care whether it'll look good on a device.
duga: So they need to be able to respond to that.
glazou: So we might to have the MQ respond to script backfilling
support. Some DOM API.
TabAtkins: I'm okay with adding a MathML query, with the added
clarification that having a switch to claim support
would be useful.
dino: That forces a style reflow?
TabAtkins: Yes.
RESOLVED: Add a MQ that reports MathML support, with some way for
scripts to claim support.
ACTION glazou to report to Epub about the MathML MQ being approved.
<trackbot> Created ACTION-789
ACTION Florian to write the MathML MQ.
<trackbot> Created ACTION-790
Rossen: We have a new CSS-AAM joint task force with APA.
Rossen: Intent is to define a11y APIs for all CSS modules/features
that are deemed inaccessible - like the 'order' property
of Flexbox.
Rossen: Just an FYI, I'll drop a link.
Rossen: Please reach out to us with a11y/CSS-related problems or
requests.
<Rossen> CSS Accessibility Task Force -
<a shape="rect" href="http://lists.w3.org/Archives/Public/public-aria-admin/2016Aug/0018.html">http://lists.w3.org/Archives/Public/public-aria-admin/2016Aug/0018.html</a>
<Rossen> Here's the initial set of features interested to the
CSS/APA task force
<a shape="rect" href="https://github.com/w3c/aria/wiki/CSS-AAM-Potential-Features">https://github.com/w3c/aria/wiki/CSS-AAM-Potential-Features</a>
Character-based Text Alignment
------------------------------
dauwhe: Next: tables.
dauwhe: Aligning on characters in table cells.
dauwhe: Old feature in specs; it's a high-priority for publishing
community. There's some Text 4 language for it.
dauwhe: dbaron did a quick reading from an implementor's POV and
raised 10 or 15 issues.
<dbaron> <a shape="rect" href="https://drafts.csswg.org/css-text-4/#character-alignment">https://drafts.csswg.org/css-text-4/#character-alignment</a>
dauwhe: We get to a point in these things where the issues need
more input from the impls than on the design.
dauwhe: Wondering what the next steps are on that.
dauwhe: And how we get more interest when we need browser details;
it gets over our heads, as people who don't write
rendering engines.
Florian: I get the impression both groups are waiting on each
other.
Florian: CSS is waiting on epub to come up with examples, so
dbaron's examples can be solved.
Florian: But I think this isn't happening, because those cases
don't happen in "normal" content, they're weird corner
cases.
Florian: Like, mostly aligning numbers with a period or comma.
Florian: So not really questions about nested markup, or different
font sizes, etc.
dbaron: One question is a really substantive one - about intrinsic
width.
dbaron: If you're in a constrained-width situation, is this
flexible? Do you break the char alignment - does your
min-content width include the char alignment? Or something
else?
dbaron: In general, if your table has char alignment but is too
small to fit.
dbaron: Different font size is mostly not much to care, but people
will use bold, and that's a different width. Maybe can
punt, maybe people will notice.
dauwhe: I can try to translate your questions into actual examples
to get feedback on.
dbaron: Another is what happens when you break a line in something
that specifies char alignment.
dauwhe: Interesting, don't have an answer.
David_Wood: Speaking as a rep of an editor company, all of these
are familiar use-cases. We run into all of them,
trying to make WYSIWYG of content, especially with
tiny mobile interfaces.
David_Wood: Bold fonts in a RTL in a list in a table.
[violent agreement]
david_wood: I can take an action to construct examples.
Florian: And preferably pair with preferred answers.
dauwhe: I can try to collect this info and bring it directly to
Text 4 editors.
astearns: I support this, but it's makework until browsers sign
onto it. Any chance browsers are going to do this?
dino: If your customers/publishing houses came to Apple asking for
it, you'd get results.
Tzviya, Wiley: Chemical journals have a huge need for it.
Bill_Kasdorf: And lining up numbers in financial contexts.
dino: I'd appreciate - you can send emails to me - an email saying
you're a publishing house, you have these customers, they
need X.
r12a: Dave, when you're doing these examples, can you put up some
rtl ones?
Florian: Hiroshi provided some Japanese examples, don't think
they're much different.
r12a: But the bidi ones I'd quite like to see.
dino: Send emails asap. Now is a great time to get into Apple's
planning cycle. ^_^
<dino> Send email to <a shape="rect" href="mailto:dino@apple.com?Subject=Re%3A%20%5BCSSWG%5D%20Minutes%20Lisbon%20F2F%202016-09-19%20Part%20III%3A%20Joint%20Meeting%20with%20%20DPUB%20%5Bmediaqueries%5D%20%5Bcss-text%5D%20%5Bcss-page%5D&In-Reply-To=%3CCADhPm3uMfKnsR1RSJcn%3D4dowGcCSXwMciNywkPrqNK1Uf1gEMA%40mail.gmail.com%3E&References=%3CCADhPm3uMfKnsR1RSJcn%3D4dowGcCSXwMciNywkPrqNK1Uf1gEMA%40mail.gmail.com%3E">dino@apple.com</a>
CSS vs XSL-FO: Gap Analysis
---------------------------
dauwhe: High-level future task thing.
dauwhe: Relationship between CSS and XSL-FO.
dauwhe: Seems to be a general trend of using CSS for a lot of
document creation tasks, rather than XSL-FO.
dauwhe: Might be useful to have a more formal summary of what we
can do right now in CSS, and what we can't.
liam: I've worked on that somewhat, but not made a document.
liam: Been writing a program the last few weeks to auto-convert
from XSL-FO to CSS, to try and find the easy vs hard things.
liam: Previously I approached it architecturally, but the specs
are so different that's hard.
ACTION liam to identify the things in XSL-FO that are hard to do
in CSS, and write up some results.
<trackbot> Created ACTION-791
Page floats
-----------
dauwhe: Status of Page Floats?
Florian: Johannes did a lot of work; at Vivliostyle we want to
work on it, but haven't prioritized it recently.
Florian: The basics of level 1 are in place, needs more
error-handling.
[discussing whether further topics are best done here, or in the
Houdini day]
Hanging punctuation
-------------------
<astearns> <a shape="rect" href="https://drafts.csswg.org/css-text/#propdef-hanging-punctuation">https://drafts.csswg.org/css-text/#propdef-hanging-punctuation</a>
myles: In Text 3 we have a hanging-punctuation property.
myles: The keywords in this property describe character sets *and*
situations to apply hanging punctuation, and the amount to
hang that punctuation.
myles: A single keyword does all of these.
myles: These keywords are not very compatible with western-style
punctuation. They're designed for Japanese.
myles: Because this isn't very useful for western-style, and
keywords pull together all three pieces, it's impossible to
extend syntax in the future to separate these out.
myles: It's common for different authors to want to specify
different sets of characters to hang.
myles: It should be postponed to level 4.
fantasai: We had a long ML discussion on this.
fantasai: Both western and eastern hanging-punctuation wants to
say "put parens/quotes on outside"; hanging-punc does
that.
fantasai: In CJK you want to hang certain characters fully outside
the box, because want to maintain the character grid.
But in Western punctuation you want optical alignment
along that edge, don't have a grid.
fantasai: So it's not about specific chars, but based on the shape
of the glyphs instead.
fantasai: Different typesetting engines have different features to
try and get this effect.
fantasai: Some hang hyphens, some period, some both, some more...
fantasai: In each case you're not maintaining a grid, you're just
looking for a sharper edge.
fantasai: It seems to me that classing chars and saying how much
they hang isn't the ideal way to control this.
fantasai: You don't want that level of details, you want to say
"do optical alignment".
fantasai: So better solved by having a "pairs kerning" value that
pairs a character with the edge of the paragraph.
fantasai: So just a single switch in CSS that turns that on.
fantasai: Don't know much about font data, but there is a
kerning-pairs table. Is there an entry for char+end of
line?
lrosenth: No.
fantasai: Ah, would be useful. Powerful and simple for the author.
fantasai: I would rather provide that as a switch, rather than the
author listing all the unicode codepoints that should
hang, how much they hang--they're basically writing a
kerning table in CSS.
fantasai: Also, different fonts have different glyph shapes,
different amount of hang is appropriate.
fantasai: Then there's glyph variants, e.g. swash vs non-swash
fantasai: So then not even character-based, it's glyph-based.
fantasai: This is a font-based thing, so should be in the font.
CSS switch can then be simple.
fantasai: Just too much complexity for author and CSS otherwise.
dauwhe: I'm gonna action myself to see what InDesign does, to see
if they're that fancy.
liam: Saying the solution is simpler if it just requires all the
fonts in the world to be edited, slight problem there.
liam: There have been system in the past with "margin kerning", a
kern pair against a margin.
liam: Could see something like that added, with CSS being able to
augment/override the kerning.
liam: But not sure if that's simpler in practice than what we've
seen.
fantasai: We can also just have an automatic thing where the UA
just makes up values.
astearns: That's what InDesign does.
fantasai: So happy to have UA synthesize values when they don't
exist in the font.
fantasai: But adding character-based kerning in CSS is a lot of
complexity for everyone, and doesn't really belong at
this level.
SimonSapin: We already have codepoint sets in CSS with
unicode-range.
SimonSapin: But not maps.
ChrisL: Two ways of doing kerning - kern-pair table, and a new way
with gpos, based on contextual information.
ChrisL: No way to kern at end of line, because end-of-line isn't
given to the text renderer.
myles: People who know more about pPenType than me says the spec
allows kerning against margins.
lrosen: But nothing in the gpos or other font tables that define
that. You can synthesize something external, is all.
fantasai: So I'd say rather than doing this character-based (which
is wrong anyway, because it's really glyph-based), we
can add a switch that turns on automatic end-of-line
kerning, and that'd be as good as what InDesign does.
Then we can work with the fonts to bake this into the
data tables so they can get more fine-tuned results.
lrosen: If the goal is to do something with fonts, and we're okay
with it only working with future fonts, the OT group is in
the midst of doing OT advancements. Just completed SVG
fonts, now doing the variable fonts.
lrosen: So good opportunity for change right now.
dauwhe: I think we do want to decide on which chars hang and which
don't - only hang period and quotes, but not hyphens (more
subtle), or be really aggressive and hang em-dashes and
question marks.
dauwhe: Doing this off the spec list makes this an all-or-nothing
proposal, which I'm wary of.
fantasai: We also have requests from CJK that they want specific
punctuation chars as linebreak.
fantasai: And we're like, that's great, but we'll start with
generic sets, and in the future add specific controls.
fantasai: Much more complicated than doing presets.
dauwhe: The set here is inadequate right now, as it has no
quotation marks. Definitely want that, possibly a hyphen.
fantasai: Other than quotes, what common things do you want to
control? Chars that are common in books/etc.
dauwhe: open/close single/double quote, period, comma, hyphen
myles: In Latin it's uncommon to hang brackets/parentheses/etc,
but the spec hangs them.
Bill_Kasdorf: Even on a char basis, French quotes aren't the same
as English - French quotes might not want hanging
when you do want English ones.
fantasai: Could see wanting hanging on first/last, but not
internal lines.
fantasai: Spec currently does that. Only periods/commas/??? hang
internally.
David_wood: People want to quote English in French, this is common.
fantasai: You can use whatever quotes you want.
koji: I agree with fantasai about fonts.
koji: Some fonts want 49% hang vs 51% hang, we don't want to go
there.
koji: The idea of pair kerning on beginning/end of line isn't
great for browsers.
koji: We shape logical runs, *then* make linebreaks.
koji: When we pair-kern, we need to reshape on every linebreak,
and that's very expensive.
myles: My proposal was to push this out to Text 4. Judging by
disagreement, sounds like a good idea.
myles: It also seems very clear that some people want to hang
different punctuation. Maybe font is one input, but not
*only* input.
myles: I think having web author list codepoints would be
extremely easy to create typographically bad-looking
hanging paragraphs.
myles: People forget the codepoints all the time, or put in the
wrong codepoints.
<SimonSapin> <a shape="rect" href="http://www.fileformat.info/info/unicode/category/Pd/list.htm">http://www.fileformat.info/info/unicode/category/Pd/list.htm</a>
Florian: I'm convinced there's no easy answer for western
punctuation. Not convinced the property as designed can't
be extended to this later. For CJK, it might need
extension, but it *works* and is clear.
* fantasai agrees with Florian
Florian: So I'd rather not push it, unless it currently prevents
us from extending in the future.
myles: I opened with the idea that the current values conflate
character sets and ways to hang them, and a reasonable
future will separate those out.
fantasai: I think they'll default; there would be an auto value.
fantasai: So we can add another property, or make this a
shorthand; as long as there's a good initial value
matching our current, I don't think we're blocked.
fantasai: So I also want to keep the current, as it does work for
CJK, and for pullquotes it works for Latin. Refinements
I think we can extend into later.
dauwhe: I would first like to get together and design it for
Latin, make sure there's no conflict.
Rossen: Objections to pushing to level 4?
fantasai: Implemented in WebKit?
Rossen: But they're the ones trying to defer it. ^_^
r12a: What about CJK users that want it now rather than in a few
years?
Florian: The JP gov *will* care about referring to something
that's not CR.
fantasai: I think we shouldn't push it unless we find that it's
not going to work.
koji: epub referred to the spec before it was CR...
<bobbytung> Hanging Punctuation not happens to Trad. Chinese.
Simp. Chinese ebooks recently follow japanese rules in
several Reading System.
myles: The keywords are "first", "force-end", "allow-end", "last".
And these specify char sets.
fantasai: Right. If we want to customize, we can add a different
property, or extend this prop to specify.
<fantasai> e.g. hanging-punctuation: first quotes last quotes;
<fantasai> i.e. hanging-punctuation: [ <position> <charset>* ]+
<fantasai> Can split into longhands, or add a parallel property
* skk thinks hanging-punctuation is not referred from EPUB3.0.1,
at least...
koji: correction: this property was not referred to by epub.
skk: epub already renders with hanging-punctuation, even if not
explicitly referencing the spec.
<addison> we implemented it...
fantasai: I think we should leave it at level 3, unless someone
shows me a problem.
dauwhe: I'll work on the syntax.
r12a: Worried we're on a closed community; leaving it off of epub
list might have just been an oversight.
Florian: I'd say you can't nicely typeset a book in Japanese
without this, and as it is works for most books.
<addison> +1
RESOLVED: Keep hanging-punctuation in level 3, marked as at-risk,
study whether it needs to be punted.
</pre>
</div>Dael Jacksondaelcss@gmail.comhttp://lists.w3.org/Archives/Public/www-style/FMath: MathML Implementation Version 3.0 betatag:blogger.com,1999:blog-8964504625475983740.post-27279706180385897912016-11-01T14:03:29+00:00Hi,<br /><br /> <a href="http://www.fmath.info/">www.fmath.info</a> is happy to announce a new version for MathML implementation. The big change for this version is the refactoring for "Content Markup".<br /><br /><div> The implementation of MathML is done for :</div><div><ul><li><a href="http://www.fmath.info/formula/js/how_to_use.jsp">Javascript applications</a>;</li><li><a href="http://www.fmath.info/formula/java/how_to_use.jsp">Java</a> applications;</li><li><a href="http://www.fmath.info/formula/csharp/how_to_use.jsp">C#</a> applications;</li><li>As3 - for <a href="http://www.fmath.info/flash/formula.jsp">Flash</a> ans <a href="http://www.fmath.info/flex/formula.jsp">Flex</a> applications;</li></ul><div>The code will have the same "look" on all technologies.</div></div><div><br /></div><div>Details about what is already implemented and test pages:</div><br /><ul><li>Here is the link with <a href="http://www.fmath.info/whatIsImplemented.jsp#index">"what is already implemented"</a> from MathML;</li><li>The tests for my implementation are <a href="http://www.fmath.info/formula/examples.jsp">here</a>;</li></ul><div><br /></div><div>For Web Applications I created:</div><ul><li>Plugin for Google Chrome. Details <a href="http://www.fmath.info/formula/js/chrome-plugin.jsp">here</a>;</li></ul><div class="separator"><a href="https://2.bp.blogspot.com/-WnWPeQhmdJs/WBjygIa3T8I/AAAAAAAAAbc/17N4Mga0Fw4W8DoRJ4Gu1gjMi7Hq6z3iACLcB/s1600/plugin.png"><img border="0" height="84" src="https://2.bp.blogspot.com/-WnWPeQhmdJs/WBjygIa3T8I/AAAAAAAAAbc/17N4Mga0Fw4W8DoRJ4Gu1gjMi7Hq6z3iACLcB/s320/plugin.png" width="320" /></a></div><div><br /></div><ul><li>Page with details about: How to use my implementation for "<a href="http://www.fmath.info/formula/js/allBrowser.jsp">All Browsers Solution</a>".</li></ul><div><br /></div><div>regards</div><div>Ionel Alexandru</div><br /><br /><br /><img src="http://feeds.feedburner.com/~r/MathmlForAdobeFlashPlayer/~4/RaHdYEsStWA" height="1" width="1" alt="" />Ionel Alexandrunoreply@blogger.comhttp://mathmlflash.blogspot.com/2016/10/27 follow ups: question on mathmlmid:CABqxo82betLXABXi-XiFALsD1StjvLur0u6S73e8nsL8DGCLTA@mail.gmail.com2016-10-31T11:46:48+00:00<div>
<pre id="body">
<a shape="rect" name="start3" accesskey="j" id="start3"></a>Hi everyone,
At the last call, Jean raised the question in how far people on the CG are
interested in becoming active regarding MathML. As I said on the call,
"historically" MathML was off-topic for the CG since the CG started when
the Math WG was still running.
As promised, Dani and I reached out to Ivan Herman (W3C).
Ivan's response (with permission) was:
> This is what the Math WG home page says today:
>
> [[[
> The Working Group is currently closed. It will re-open
> when a new revision of MathML is needed or another standard
> related to mathematics on the Web. In the mean time, please,
> use the<<a shape="rect" href="mailto:www-math@w3.org?Subject=Re%3A%202016%2F10%2F27%20follow%20ups%3A%20question%20on%20mathml&In-Reply-To=%3CCABqxo82betLXABXi-XiFALsD1StjvLur0u6S73e8nsL8DGCLTA%40mail.gmail.com%3E&References=%3CCABqxo82betLXABXi-XiFALsD1StjvLur0u6S73e8nsL8DGCLTA%40mail.gmail.com%3E">www-math@w3.org</a>> mailing list (see Joining >
> the discussion) to report errors and suggestions for
> improvements (or contact the W3C team).
> ]]]
>
> That is all. If this community group wants to work on the
> improvement of MathML, I do not think that would be a
> problem, and if there are very specific features that should
> be added to the the spec, then, well, the quote above points
> at the right place.
So if people want to get together for a specialized meeting, feel free to
set one up.
Best regards,
Peter.
</pre>
</div>Peter Krautzbergerpeter.krautzberger@mathjax.orghttp://lists.w3.org/Archives/Public/public-mathonwebpages/[math-on-web] change of schedule for Nov 2016mid:CABqxo81foAi5ffGOMFR0a7BftxV7MwXqWJQL5fqFqL-DZUH-Lw@mail.gmail.com2016-10-28T09:32:03+00:00<div>
<pre id="body">
<a shape="rect" name="start2" accesskey="j" id="start2"></a>Hi everyone,
For the next meeting, we should deviate from our usual schedule to avoid
meeting on US Thanksgiving.
I would propose to skip a week and meet
*December 1, 2016, 6pm UTC*
As discussed yesterday (see the minutes), sub groups should meet
independently (scheduled separately).
Best,
Peter.
</pre>
</div>Peter Krautzbergerpeter.krautzberger@mathjax.orghttp://lists.w3.org/Archives/Public/public-mathonwebpages/[math-on-web] meeting minutes, 2016/10/27mid:CABqxo81JgRJJDg1DE1OGbrx0eGh7JTbErSRneBWvAN2nxcJ34A@mail.gmail.com2016-10-28T09:28:07+00:00<div>
<pre id="body">
<a shape="rect" name="start1" accesskey="j" id="start1"></a>Hi everyone,
Below are the minutes to yesterday's call.
Best,
Peter.
# Minutes Math-on-Web-CG, 2016/10/27
* present: Tzviya Siegman, Kevin Cheung, Jean Kaplansky, Jos de Jong, John
Pedersen, Volker Sorge, Daniel Marques, Peter Krautzberger
* scribe: Peter Krautzberger
* plain math notation
* Jos: have not yet picked it up again
* Tzviya: what's the goal for this?
* Peter: aligning different text based input, cf. commonmark effort
* Jean: why is MathML no there? It's text based, no?
* Jos: this is more focused on "simple", "human readable", not "full
scale" markup
* Jean: concern: most people with MathML are not math-savvy, TeX is less
human readable than markup to them
* Peter: it's not about grand unified standard, but getting
practitioners together, helping them
* Jean: we need to be careful about audiences
* on this call, mostly math people
* but users are not mostly math people
* Peter: agree. But many tools provide this and have users (MS Office,
Libre Office etc)
* Volker: background on the semantic tree format in speechruleengine "dumb
semantics"
* Peter: this connects to what Jean said, because people have looked for a
lightweight data format for exchange (discussions on mathquill, mathjax,
mathjs lists)
* it connects with XML markup without brining in the full power of
* Dani: what is the connection to accessibility?
* Volker: from such a format, you can generate other renderings directly
(e.g. speech, braille)
* Peter: also: stability across conversion
* Kevin: would help with authoring as well. A simpler syntax is often
great (e.g., matrices in LaTeX are a pain)
* Jean: you need to define the community here
* otherwise not inclusive.
* [Strong agreement throughout]
* Jean: for me, MathJax solves most of my problems b/c problems are mathml
based
* publishing would need something that can convert to MathML
* Jean: unclear what the "charter" is
* several subjects but for my background, not a place yet
* lots of people out there doing math-on-the-web
* not a math background
* Dani: MathML is fine as a format, but when you put that in the browser,
you need another format
* you lose information
* publisher might be reliable for MathML but also accessible description
* e.g., accessible tree
* maybe the tools for this are not so powerful. Maybe that's a place
where discussions could start
* Jean: agree
* Peter: there is no charter, which is both blessing and curse
* John: what are the topics we focus on?
* Peter: emails after first one about conversation starter
* Jean: use wiki? Use WCIG discourse?
* Peter: at 1st meeting, the group decided on github pages (like most W3C
groups)
* recent discussion were focused on: layout, a11y, plain text notation
* Jean: you need to break it out
* Peter: are you volunteering? ;-)
* Jean: MathML is a core issue for a lot of people
* Peter: it was off limits when we started
* Jean: some tasks I see interested in:
* accessibility
* lobbying browser vendors
* Jean: if we are more organized, we can get more interest
* John: if there were more specific topics, it would be helpful
* Dani: @Jean could you write a summary email after the meeting?
* for discussion at the next meeting.
* Jean: ACTION will make a task
* subgroups need deliverables
* Peter: ACTION will update github pages with topics we're exploring
* Jos: +1
</pre>
</div>Peter Krautzbergerpeter.krautzberger@mathjax.orghttp://lists.w3.org/Archives/Public/public-mathonwebpages/reminder: next meeting tomorrow, Thursday, Oct 27, 6pm UTCmid:CABqxo80Hkm=3_xQhwvHSSTdVcQgFMAN_mc1vbg2R12XuUR1QxQ@mail.gmail.com2016-10-26T10:27:16+00:00<div>
<pre id="body">
<a shape="rect" name="start0" accesskey="j" id="start0"></a>Dear math-on-webpages CG,
The next meeting will be
*Thursday, October 27, 2016, 6pm UTC*
For an agenda, we should continue the discussion about plain math notation
as well as accessibility.
The link for Google Hangouts is [1] below.
Best wishes,
Peter.
[1] <a shape="rect" href="https://hangouts.google.com/hangouts/_/mathjax.org/math-on-web-cg">https://hangouts.google.com/hangouts/_/mathjax.org/math-on-web-cg</a>
</pre>
</div>Peter Krautzbergerpeter.krautzberger@mathjax.orghttp://lists.w3.org/Archives/Public/public-mathonwebpages/MathJax v2.7 now availablehttp://www.mathjax.org/mathjax-v2-7-now-available/2016-10-14T00:00:00+00:00<p>After a very smooth <a href="http://www.mathjax.org/mathjax-v2-7-beta-now-available/">beta run</a>, we’re happy to officially release MathJax v2.7.</p>
<h2 id="new-in-mathjax-v27">New in MathJax v2.7</h2>
<p>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:</p>
<ol>
<li><em>CommonHTML output improvements</em> Several important bugs in the layout model have been fixed, in particular tabular layout is now much more robust.</li>
<li><em>Accessibility extensions.</em> After the completion of the <a href="https://www.mathjax.org/mathjax-accessibility-extensions-v1-now-available/">MathJax Accessibility Extensions</a>, we are integrating the lightweight opt-in into the MathJax core. This allows readers to opt into the following features via the MathJax Menu:
<ul>
<li><em>Responsive Equations.</em> An innovative responsive rendering of mathematical content through collapsing and exploration of subexpressions.</li>
<li><em>Universal aural Rendering.</em> An aural rendering tool providing on-the-fly speech-text for mathematical content and its subexpressions using various rule sets.</li>
<li><em>Full Exploration.</em> A fully accessible exploration tool, allowing for meaningful exploration of mathematical content including multiple highlighting features and synchronized aural rendering.</li>
<li>For detailed information check the accessibility extensions’ <a href="https://www.mathjax.org/mathjax-accessibility-extensions-v1-now-available/">release announcement</a>.</li>
</ul>
</li>
<li><em>Opt-in for mhchem v3</em> 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 <a href="http://docs.mathjax.org/en/latest/options/ThirdParty.html">MathJax Third Party Extension repository</a></li>
<li><em>Simplified opt-in for third party extensions</em> MathJax v2.7 configures the <code class="highlighter-rouge">[Contrib]</code> path variable to the URL of the third party extension repository on the MathJax CDN. This simplifies loading contributed extensions.</li>
<li><em>Third Party Extension Updates</em> Our Third Party Extension repository as seen some great additions recently. <strong>The MathJax team is grateful for these contributions from the community!</strong>
<ul>
<li><a href="https://github.com/mathjax/MathJax-third-party-extensions/tree/master/arabic">arabic.js</a>: Omar Al-Ithawi (<a href="https://github.com/omarithawi">@omarithawi</a>) from Edraak.org contributed this extension for basic Arabic support in the TeX input.</li>
<li><a href="https://github.com/mathjax/MathJax-third-party-extensions/tree/master/physics">physics.js</a> An extension by <a href="https://github.com/ickc">@ickc</a> providing basic support for the <a href="http://ctan.org/pkg/physics">physics package</a> for $\rm \LaTeX$.</li>
<li><a href="https://github.com/mathjax/MathJax-third-party-extensions/tree/master/siunitx">siunitx.js</a>: Yves Delley (<a href="https://github.com/burnpanck">@burnpanck</a>) contributed a basic implementation of the <a href="http://www.ctan.org/pkg/siunitx">siunitx package</a> for $\rm \LaTeX$ .</li>
<li><a href="https://github.com/mathjax/MathJax-third-party-extensions/tree/master/mhchem">mhchem.js</a>: As already mentioned, Martin Hensel (<a href="https://github.com/mhchem">@mhchem</a>) re-wrote the mhchem extension to better match his well-known <a href="https://www.mathjax.org/ctan.org/pkg/mhchem">mhchem package</a> for $\rm \LaTeX$.</li>
</ul>
</li>
</ol>
<p>For details on all bug fixes, please <a href="https://www.mathjax.org/feed.xml#new-in-release">see below</a>.</p>
<p>Please note the following.</p>
<h3 id="changes-to-the-combined-configuration-files">Changes to the combined configuration files</h3>
<p>If you are using <a href="https://docs.mathjax.org/en/v2.7-latest/config-files.html">a combined configuration</a>, please note that we added the the accessibility menu extension to all combined configuration files. This extension will always load from <code class="highlighter-rouge">cdn.mathjax.org/mathjax/contrib</code>. If you are hosting your own copy of MathJax and if your users will not be able to access <code class="highlighter-rouge">cdn.mathjax.org</code>, then you should disable the <code class="highlighter-rouge">[Contrib]</code> path by adding <code class="highlighter-rouge">noContrib</code> to the query string, e.g., <code class="highlighter-rouge">MathJax.js?config=...&noContrib</code> to avoid unnecessary failed requests.</p>
<hr />
<h2 id="release-on-the-mathjax-cdn">Release on the MathJax CDN</h2>
<p>MathJax v2.7 is available on the CDN, and for download from GitHub; see <a href="http://docs.mathjax.org/en/latest/installation.html#obtaining-mathjax-via-an-archive">the documentation for details</a>.</p>
<p>Version 2.7 is available on the CDN at</p>
<blockquote>
<p><a href="http://cdn.mathjax.org/mathjax/2.6-latest/MathJax.js">http://cdn.mathjax.org/mathjax/2.7-latest/MathJax.js</a></p>
</blockquote>
<p>and <strong>starting today</strong> the files at the</p>
<blockquote>
<p><a href="http://cdn.mathjax.org/mathjax/latest/MathJax.js">http://cdn.mathjax.org/mathjax/latest/MathJax.js</a></p>
</blockquote>
<p>address will be switched over the v2.7. If you are using the <code class="highlighter-rouge">mathjax/latest</code> address you might get a mixture of files in your browser cache, and so may need to clear your browser cache and for some browsers (e.g., Chrome) restart your browser in order to get a consistent version of all files.</p>
<p>If you are a page author and concerned about this, you can change (temporarily) to the <code class="highlighter-rouge">mathjax/2.7-latest</code> URL instead of <code class="highlighter-rouge">mathjax/latest</code> since that is a new address that will not have any cached older versions to worry about. You can switch back to <code class="highlighter-rouge">mathjax/latest</code> in a few days when the new version has migrated to all the locations in the cloud. If you want to keep using Mathjax v2.6 you can switch to <code class="highlighter-rouge">mathjax/2.6-latest</code>.</p>
<p>Thanks for your continuing interest in MathJax. We hope that this release makes your MathJax experience even better.</p>
<p>The MathJax Team.</p>
<hr />
<h2 id="new-in-release">New in MathJax v2.7</h2>
<p>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.</p>
<h2 id="features">Features</h2>
<ul>
<li><em>Common HTML output improvements</em> Several important bugs in the layout model have been fixed, in particular tabular layout is now much more robust.</li>
<li><em>Accessibility improvements.</em> After the completion of the MathJax Accessibility Extensions, we are integrating the opt-in for the MathJax menu into the core distribution. We are grateful to the web accessibility community for their guidance, support, and feedback in our efforts towards making MathJax completely accessible to all users. This allows end-users to opt into the following features via the MathJax Menu:
<ul>
<li><em>Responsive Equations.</em> An innovative responsive rendering of mathematical content through collapsing and exploration of subexpressions.</li>
<li><em>Universal aural Rendering.</em> An aural rendering tool providing on-the-fly speech-text for mathematical content and its subexpressions using various rule sets.</li>
<li><em>Full Exploration.</em> A fully accessible exploration tool, allowing for meaningful exploration of mathematical content including multiple highlighting features and synchronized aural rendering.</li>
<li>For more information check the <a href="https://www.mathjax.org/mathjax-accessibility-extensions-v1-now-available/">release announcement</a> and the dedicated repository at <a href="https://github.com/mathjax/MathJax-a11y">mathjax/mathjax-a11y</a>.</li>
</ul>
</li>
</ul>
<p>For a detailed listing please check the <a href="https://github.com/mathjax/MathJax/milestone/14?closed=1">release milestone</a>.</p>
<h2 id="accessibility">Accessibility</h2>
<ul>
<li><a href="https://github.com/mathjax/MathJax-dev/issues/20">mathajx-dev/#20</a> Add the Menu extension from the <a href="https://github.com/mathjax/MathJax-a11y">MathJax Accessibility tools</a> to all combined configuration files.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1465">#1465</a> CHTML and HTML-CSS output: do not add <code class="highlighter-rouge">role=math</code> by default.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1483">#1483</a> Catch IE8 errors with inserting MathML from AssistiveMML extension.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1513">#1513</a> Disable the AssistiveMML extension when the output renderer is PlainSource.</li>
</ul>
<h2 id="interface">Interface</h2>
<ul>
<li><a href="https://github.com/mathjax/MathJax/issues/1463">#1463</a> Reset message strings for <code class="highlighter-rouge">messageStyle=simple</code> for each typeset.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1556">#1556</a> Improve menu placement.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1627">#1627</a> Add Accessibility submenu.</li>
</ul>
<h2 id="htmlsvgnativemml-display">HTML/SVG/nativeMML display</h2>
<ul>
<li><a href="https://github.com/mathjax/MathJax/issues/1454">#1454</a> SVG output: Use full location URL for <code class="highlighter-rouge">xlink</code> references in SVG <code class="highlighter-rouge"><use></code> elements.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1457">#1457</a> Common-HTML output: Fix problem with characters from Unicode Plane 1 not being mapped to the MathJax fonts properly</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1458">#1458</a> SVG output: Fix problem with container width when math is scaled.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1459">#1459</a> CommonHTML output: Improve <code class="highlighter-rouge">getNode()</code> to fix processing errors when line-breaking.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1460">#1460</a> HTML-CSS output: Adjust position of rule for square root when it is made via <code class="highlighter-rouge">createRule()</code>.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1461">#1461</a> HTML-CSS output: Make sure <code class="highlighter-rouge">0</code> remains <code class="highlighter-rouge">0</code> when rounding to pixels (plus a bit).</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1462">#1462</a> CommonHTML output: Bubble percentage widths up while line breaking.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1475">#1475</a> PreviewHTML: Avoid error when <code class="highlighter-rouge">\overset</code> or <code class="highlighter-rouge">\underset</code> is empty.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1479">#1479</a> All outputs: Properly determine (shrink-wrapping) container widths.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1503">#1503</a> CommonHTML output: Handle adjusting table cell heights properly.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1507">#1507</a> SVG output: Remove invalid <code class="highlighter-rouge">src</code> attribute from <code class="highlighter-rouge"><mglyph></code> output.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1510">#1510</a> CommonHTML output: Prevent CSS bleed-through for box-sizing.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1512">#1512</a> CommonHTML output: make <code class="highlighter-rouge"><mglyph></code> scale image size by hand.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1530">#1530</a> All outputs: Fix problem with Safari inserting line breaks before in-line math.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1533">#1533</a> CommonHTML output: improve aligning labels with their table rows.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1534">#1534</a> CommonHTML output: ensure output stays a table-cell when focused.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1538">#1538</a> All outputs: Don’t let preview width interfere with the determination of the container width.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1542">#1542</a> CommonHTML output: improve stretching <code class="highlighter-rouge"><mover></code> in <code class="highlighter-rouge"><mtd></code> elements.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1547">#1547</a> HTML-CSS output: improve line breaks within fractions.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1549">#1549</a> All outputs: Improve determination of line-breaking parent element.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1550">#1550</a> CommonHTML output: Improve vector arrow positioning.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1552">#1552</a> All outputs: Handle <code class="highlighter-rouge">href</code> correctly when line breaking.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1574">#1574</a> HTML-CSS and SVG output: Use <code class="highlighter-rouge">currentColor</code> for <code class="highlighter-rouge"><menclose></code> with no <code class="highlighter-rouge">mathcolor</code>.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1595">#1595</a> CommonHTML output: Properly scale elements with <code class="highlighter-rouge">font-family</code> specified.</li>
</ul>
<h2 id="tex-emulation">TeX emulation</h2>
<ul>
<li><a href="https://github.com/mathjax/MathJax/issues/1455">#1455</a> Fix <code class="highlighter-rouge">TeX.Environment()</code> to use the correct end environment.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1464">#1464</a> Make sure <code class="highlighter-rouge">resetEquationNumbers</code> is always defined.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1484">#1484</a> Mark accented operators as not having movable limits.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1485">#1485</a> Allow line breaks within <code class="highlighter-rouge">TeXAtom</code> elements</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1508">#1508</a> Surround <code class="highlighter-rouge">\middle</code> with <code class="highlighter-rouge">OPEN</code> and <code class="highlighter-rouge">CLOSE</code> TeXAtoms to match TeX spacing</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1509">#1509</a> Make delimiters (in particular arrows) symmetric for <code class="highlighter-rouge">\left</code> and <code class="highlighter-rouge">\right</code>.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1514">#1514</a> Don’t unwrap rows when creating fenced elements.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1523">#1523</a> Don’t copy environment into <code class="highlighter-rouge">array</code> environments.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1537">#1537</a> mhchem: add config parameter to select mhchem v3.0.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1596">#1596</a> Prevent <code class="highlighter-rouge">\require{mhchem}</code> to override one already loaded.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1551">#1551</a> Allow <code class="highlighter-rouge"><wbr></code> in TeX code.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1565">#1565</a> Handle <code class="highlighter-rouge">\+SPACE</code> in macro definitions.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1569">#1569</a> Treat control sequences as a unit when matching a macro template.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1587">#1587</a> Make sure <code class="highlighter-rouge">trimSpaces()</code> doesn’t remove tailing space in <code class="highlighter-rouge">\+SPACE</code>.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/">#1602</a> Handle <code class="highlighter-rouge">\ref</code> properly when there is a <code class="highlighter-rouge"><base></code> tag.</li>
</ul>
<h2 id="asciimath">Asciimath</h2>
<ul>
<li><a href="https://github.com/asciimath/asciimathml/commit/f649ba49f639b7e5322d6552193226c03e88ba7e">asciimath/f649ba4</a> Add <code class="highlighter-rouge">newsymbol</code> command for adding a new symbol object</li>
</ul>
<h2 id="mathml">MathML</h2>
<ul>
<li><a href="https://github.com/mathjax/MathJax/issues/1505">#1505</a> Handle <code class="highlighter-rouge">rowlines=""</code> and <code class="highlighter-rouge">rowlines=" "</code> like <code class="highlighter-rouge">rowlines="none"</code>.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1511">#1511</a> Don’t convert attribute to boolean unless the default is a boolean.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1526">#1526</a> Make minus in <code class="highlighter-rouge"><mn></code> produce <code class="highlighter-rouge">U+2212</code> rather than <code class="highlighter-rouge">U+002D</code>.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1567">#1567</a> Fix spacing for initial fraction in exponent position.</li>
</ul>
<h2 id="fonts">Fonts</h2>
<ul>
<li><a href="https://github.com/mathjax/MathJax/issues/1521">#1521</a> STIX fonts: Make left arrow use combining left arrow for accents.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1092">#1092</a> STIX fonts: Make <code class="highlighter-rouge">U+222B</code> (integral) stretchy.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1154">#1154</a> STIX fonts: Remap <code class="highlighter-rouge">|</code> to variant form (with descender) and map variant to original form.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1175">#1175</a> Use <code class="highlighter-rouge">U+007C</code> and <code class="highlighter-rouge">U+2016</code> for delimiters rather than <code class="highlighter-rouge">U+2223</code> and <code class="highlighter-rouge">U+2225</code>.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1421">#1421</a> MathJax TeX fonts: Fix SVG font data for stretchy characters.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1418">#1418</a> Alias <code class="highlighter-rouge">U+2206</code> to <code class="highlighter-rouge">U+0394</code> and remove incorrect <code class="highlighter-rouge">U+2206</code> from SVG font files.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1187">#1187</a> Make height and depth of minus match that of plus (needed for TeX-layout super/subscript algorithm to work properly), and adjust for that when it is used as an extender in stretchy characters.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1546">#1546</a> MathJax TeX fonts: Add stretchy data for <code class="highlighter-rouge">U+20D7</code>.</li>
</ul>
<h2 id="localization">Localization</h2>
<ul>
<li><a href="https://github.com/mathjax/MathJax/issues/1604">#1604</a> Updated locales thanks to the contributors at Translatewiki.net; activate locale for Zazaki.</li>
</ul>
<h2 id="apis">APIs</h2>
<ul>
<li><a href="https://github.com/mathjax/MathJax/issues/1504">#1504</a> Make <code class="highlighter-rouge">getJaxForMath()</code> work even during chunking.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1522">#1522</a> Add Third Party Extensions Repository to the Ajax paths as <code class="highlighter-rouge">[Contrib]</code>.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1525">#1525</a> Allow MathJax root to be configured.</li>
</ul>
<h2 id="misc">Misc.</h2>
<ul>
<li><a href="https://github.com/mathjax/MathJax/issues/1456">#1456</a> Prevent removal of DOM elements while MathJax is running from stopping processing, or to leaving duplicate math in place.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1524">#1524</a> Prevent pre-processors from adding duplicate preview elements.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1554">#1554</a> Safe extension: Add filtering of CSS styles like <code class="highlighter-rouge">padding</code>, <code class="highlighter-rouge">margin</code>.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1590">#1590</a> Set previews to have <code class="highlighter-rouge">display:none</code>.</li>
<li><a href="https://github.com/mathjax/MathJax/issues/1591">#1591</a> Change <code class="highlighter-rouge">rev=</code> to <code class="highlighter-rouge">V=</code> in cache breaking code.</li>
</ul>MathJax Consortiumhttp://www.mathjax.org/RE: The MQ (or not) issue; what we are seekingmid:CY1PR0601MB14221F616298B4F11E4CB8A3DFC70@CY1PR0601MB1422.namprd06.prod.outlook.com2016-10-06T15:50:57+00:00<div>
<pre id="body">
<a shape="rect" name="start81" accesskey="j" id="start81"></a>Sorry for the tardy response, Liam.
Fundamentally, this issue isn't about "working in ebook readers" in the sense of rendering the math.
From the accessibility point of view, and specifically in the context of EPUBs, we are really looking for a solution where the pre-rendered equation (an image, typically rendered by a workflow from MathML upstream, ideally SVG) is what is displayed visually. We need that EPUB to be able to also _contain_ the MathML without triggering an RS to try to render it instead of the image; the publisher (now) wants to prioritize the image for visual rendering. Instead, that MathML needs to be available to AT.
Nobody thinks this is the ideal or ultimate solution. What we need is something that works right now (or soon) while MathML rendering in browsers and EPUB RSs is still so unreliable, so that publishers can safely stick that MathML in the EPUB and know that it will just get used for AT, without the RS trying to render it and failing. Otherwise they simply omit or comment out the MathML, which makes it unavailable to AT.
--Bill
-----Original Message-----
From: Liam R. E. Quin [mailto:<a shape="rect" href="mailto:liam@w3.org?Subject=RE%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3CCY1PR0601MB14221F616298B4F11E4CB8A3DFC70%40CY1PR0601MB1422.namprd06.prod.outlook.com%3E&References=%3CCY1PR0601MB14221F616298B4F11E4CB8A3DFC70%40CY1PR0601MB1422.namprd06.prod.outlook.com%3E">liam@w3.org</a>]
Sent: Wednesday, October 05, 2016 7:52 PM
To: Bill Kasdorf; Alan Stearns; Siegman, Tzviya - Hoboken; Peter Krautzberger; <a shape="rect" href="mailto:public-digipub-ig@w3.org?Subject=RE%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3CCY1PR0601MB14221F616298B4F11E4CB8A3DFC70%40CY1PR0601MB1422.namprd06.prod.outlook.com%3E&References=%3CCY1PR0601MB14221F616298B4F11E4CB8A3DFC70%40CY1PR0601MB1422.namprd06.prod.outlook.com%3E">public-digipub-ig@w3.org</a>
Subject: Re: The MQ (or not) issue; what we are seeking
On Wed, 2016-10-05 at 15:17 +0000, Bill Kasdorf wrote:
> What we need is an interim solution that will make it safe for
> publishers to deliver the MathML along with the image that they want
> displayed visually. For now.
Does this have to work in ebook readers (which might or might not support JavaScript) as well as in Web browsers?
Liam
>
</pre>
</div>Bill Kasdorfbkasdorf@apexcovantage.comhttp://lists.w3.org/Archives/Public/public-digipub-ig/Re: The MQ (or not) issue; what we are seekingmid:56208EFE-9BE1-4418-A54C-BC620E6FD821@benetech.org2016-10-06T14:04:33+00:00<div>
<pre id="body">
<a shape="rect" name="start80" accesskey="j" id="start80"></a>While that may be true that JS wasn’t permitted in EPUB 2 readers, the main point here is that publishers won’t put JS inside their EPUB files because certain distribution chains flat out reject any JS for just that point of potential security issues. The reading system may or may not be able to support JS, which is why the default presentation must be an image with alt text, and only systems which understand MathML “could” expose the MathML to assistive technologies, if the user chooses to do so. But ideally that mathML would be hidden visually but accessible to AT and the visual Image still present for low vision users and sighted assistants / teachers helping the reader navigate the MathML with AT.
Now there could be some older reading systems that may not honor the request to have the MathML offscreen/hidden and “could” display the presentational MathML visually in addition to the static image of the mathML, and this although undesired is something that we may just have to live with and make note of when testing on various reading systems.
The IDPF’s EPUB 3.1 Accessibility Task Force would like to have one or more examples of possible ways to "have our cake and eat it too”, which we will add to our EPUB 3.1 Accessibility Techniques document where we will list the pros and cons to each approach after testing the various options on as many reading systems we can. Then leave it up to the publisher to decide which implementation they choose based on what their target markets are the results from our testing.
We would love as Florian has asked for some real examples that we can test against.
Thanks
EOM
Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
E-mail: <a shape="rect" href="mailto:charlesl@benetech.org?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E&References=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E">charlesl@benetech.org</a>
Twitter: @CLaPierreA11Y
Skype: charles_lapierre
Phone: 650-600-3301
> On Oct 6, 2016, at 4:44 AM, Leonard Rosenthol <<a shape="rect" href="mailto:lrosenth@adobe.com?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E&References=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E">lrosenth@adobe.com</a>> wrote:
>
> Unfortunately, not. Since JS wasn’t permitted in an EPUB 2 reader, there are many of those out there that do not even have a JS engine included.
>
> Leonard
>
> On 10/6/16, 1:07 AM, "Paul Topping" <<a shape="rect" href="mailto:pault@dessci.com?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E&References=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E">pault@dessci.com</a>> wrote:
>
> When it is suggested that there are ebook readers that don't support JavaScript, what is meant is that they don't support JS embedded in the ebook content itself. Am I correct? AFAIK, virtually all ebook readers are browser engine-based and use JS code in their implementation. They just don't want content to contain JS as it is a potential security risk. I only point this out in case it makes a difference in this MQ discussion.
>
> Paul
>
>> -----Original Message-----
>> From: George Kerscher [mailto:<a shape="rect" href="mailto:kerscher@montana.com?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E&References=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E">kerscher@montana.com</a>]
>> Sent: Wednesday, October 05, 2016 6:44 PM
>> To: 'Liam R. E. Quin' <<a shape="rect" href="mailto:liam@w3.org?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E&References=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E">liam@w3.org</a>>; 'Bill Kasdorf'
>> <<a shape="rect" href="mailto:bkasdorf@apexcovantage.com?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E&References=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E">bkasdorf@apexcovantage.com</a>>; 'Alan Stearns' <<a shape="rect" href="mailto:stearns@adobe.com?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E&References=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E">stearns@adobe.com</a>>;
>> 'Siegman, Tzviya - Hoboken' <<a shape="rect" href="mailto:tsiegman@wiley.com?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E&References=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E">tsiegman@wiley.com</a>>; Peter Krautzberger
>> <<a shape="rect" href="mailto:peter.krautzberger@mathjax.org?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E&References=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E">peter.krautzberger@mathjax.org</a>>; <a shape="rect" href="mailto:public-digipub-ig@w3.org?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E&References=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E">public-digipub-ig@w3.org</a>
>> Subject: RE: The MQ (or not) issue; what we are seeking
>>
>> You ask: "Does this have to work in ebook readers (which might or might not
>> support JavaScript) as well as in Web browsers?"
>>
>> George responds: Yes, the publishers want to distribute their content into all
>> markets. The visual presentation is essential, and people using access
>> technology need to get at the semantically rich information.
>>
>> Best
>> George
>>
>>
>>
>> -----Original Message-----
>> From: Liam R. E. Quin [mailto:<a shape="rect" href="mailto:liam@w3.org?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E&References=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E">liam@w3.org</a>]
>> Sent: Wednesday, October 05, 2016 5:52 PM
>> To: Bill Kasdorf; Alan Stearns; Siegman, Tzviya - Hoboken; Peter Krautzberger;
>> <a shape="rect" href="mailto:public-digipub-ig@w3.org?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E&References=%3C56208EFE-9BE1-4418-A54C-BC620E6FD821%40benetech.org%3E">public-digipub-ig@w3.org</a>
>> Subject: Re: The MQ (or not) issue; what we are seeking
>>
>> On Wed, 2016-10-05 at 15:17 +0000, Bill Kasdorf wrote:
>>> What we need is an interim solution that will make it safe for
>>> publishers to deliver the MathML along with the image that they want
>>> displayed visually. For now.
>> support JavaScript) as well as in Web browsers?
>>
>> Liam
>>
>>>
>>
>>
>>
>
>
>
</pre>
</div>Charles LaPierrecharlesl@benetech.orghttp://lists.w3.org/Archives/Public/public-digipub-ig/Re: The MQ (or not) issue; what we are seekingmid:DB0A064B-DEB6-4C71-9337-0EC49A1A5D75@adobe.com2016-10-06T11:44:33+00:00<div>
<pre id="body">
<a shape="rect" name="start79" accesskey="j" id="start79"></a>Unfortunately, not. Since JS wasn’t permitted in an EPUB 2 reader, there are many of those out there that do not even have a JS engine included.
Leonard
On 10/6/16, 1:07 AM, "Paul Topping" <<a shape="rect" href="mailto:pault@dessci.com?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E&References=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E">pault@dessci.com</a>> wrote:
When it is suggested that there are ebook readers that don't support JavaScript, what is meant is that they don't support JS embedded in the ebook content itself. Am I correct? AFAIK, virtually all ebook readers are browser engine-based and use JS code in their implementation. They just don't want content to contain JS as it is a potential security risk. I only point this out in case it makes a difference in this MQ discussion.
Paul
> -----Original Message-----
> From: George Kerscher [mailto:<a shape="rect" href="mailto:kerscher@montana.com?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E&References=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E">kerscher@montana.com</a>]
> Sent: Wednesday, October 05, 2016 6:44 PM
> To: 'Liam R. E. Quin' <<a shape="rect" href="mailto:liam@w3.org?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E&References=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E">liam@w3.org</a>>; 'Bill Kasdorf'
> <<a shape="rect" href="mailto:bkasdorf@apexcovantage.com?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E&References=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E">bkasdorf@apexcovantage.com</a>>; 'Alan Stearns' <<a shape="rect" href="mailto:stearns@adobe.com?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E&References=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E">stearns@adobe.com</a>>;
> 'Siegman, Tzviya - Hoboken' <<a shape="rect" href="mailto:tsiegman@wiley.com?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E&References=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E">tsiegman@wiley.com</a>>; Peter Krautzberger
> <<a shape="rect" href="mailto:peter.krautzberger@mathjax.org?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E&References=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E">peter.krautzberger@mathjax.org</a>>; <a shape="rect" href="mailto:public-digipub-ig@w3.org?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E&References=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E">public-digipub-ig@w3.org</a>
> Subject: RE: The MQ (or not) issue; what we are seeking
>
> You ask: "Does this have to work in ebook readers (which might or might not
> support JavaScript) as well as in Web browsers?"
>
> George responds: Yes, the publishers want to distribute their content into all
> markets. The visual presentation is essential, and people using access
> technology need to get at the semantically rich information.
>
> Best
> George
>
>
>
> -----Original Message-----
> From: Liam R. E. Quin [mailto:<a shape="rect" href="mailto:liam@w3.org?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E&References=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E">liam@w3.org</a>]
> Sent: Wednesday, October 05, 2016 5:52 PM
> To: Bill Kasdorf; Alan Stearns; Siegman, Tzviya - Hoboken; Peter Krautzberger;
> <a shape="rect" href="mailto:public-digipub-ig@w3.org?Subject=Re%3A%20The%20MQ%20(or%20not)%20issue%3B%20what%20we%20are%20seeking&In-Reply-To=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E&References=%3CDB0A064B-DEB6-4C71-9337-0EC49A1A5D75%40adobe.com%3E">public-digipub-ig@w3.org</a>
> Subject: Re: The MQ (or not) issue; what we are seeking
>
> On Wed, 2016-10-05 at 15:17 +0000, Bill Kasdorf wrote:
> > What we need is an interim solution that will make it safe for
> > publishers to deliver the MathML along with the image that they want
> > displayed visually. For now.
> support JavaScript) as well as in Web browsers?
>
> Liam
>
> >
>
>
>
</pre>
</div>Leonard Rosenthollrosenth@adobe.comhttp://lists.w3.org/Archives/Public/public-digipub-ig/