Planet MathML

The Planet MathML aggregates posts from various blogs that concern MathML. Although it is hosted by W3C, the content of the individual entries represent only the opinion of their respective authors and does not reflect the position of W3C.

Latest articles

Re: [math-on-web] reminder: next meeting Thursday, Dec 1

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

PS: The hangout is now ready.

Best,
Peter.

On Thu, Dec 1, 2016 at 7:13 PM, Peter Krautzberger <
peter.krautzberger@mathjax.org> 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" <
> peter.krautzberger@mathjax.org> 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] https://hangouts.google.com/hangouts/_/mathjax.org/math-on-web-cg
>>
>

Re: [math-on-web] reminder: next meeting Thursday, Dec 1

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

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" <
peter.krautzberger@mathjax.org> 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] https://hangouts.google.com/hangouts/_/mathjax.org/math-on-web-cg
>

Re: plain text math notation

Source: public-mathonwebpages@w3.org Mail Archives • Han (laughinghan@gmail.com) • December 01, 2016 • Permalink

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

Re: plain text math notation

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

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]
https://blogs.msdn.microsoft.com/murrays/2016/11/30/unicodemath-version-3-1/

On Mon, Sep 26, 2016 at 4:27 PM, Robin Berjon <robin@berjon.com> 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 - http://berjon.com/ - @robinberjon
> • http://science.ai/ — intelligent science publishing
> •
>

Re: [math-on-web] reminder: next meeting Thursday, Dec 1 JeanKap

Source: public-mathonwebpages@w3.org Mail Archives • Jean Kaplansky (jeankap@earthlink.net) • November 29, 2016 • Permalink

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 <
peter.krautzberger@mathjax.org> 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] https://hangouts.google.com/hangouts/_/mathjax.org/math-on-web-cg
>

*Jean Kaplansky*
Content Architect/Strategist | Technical Account Manager | UI/UX |
Accessibility Analyst | XML, HTML, and CSS Developer |
Instructional Designer
+1.518.930.1068
jeankap@earthlink.net
@jeankaplansky <jeankap@earthlink.net>

On Tue, Nov 29, 2016 at 4:19 AM, Peter Krautzberger <
peter.krautzberger@mathjax.org> 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] https://hangouts.google.com/hangouts/_/mathjax.org/math-on-web-cg
>

[math-on-web] a11y TF minutes 2016-11-28

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

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, https://codepen.io/pkra/pen/VmZLgZ
<https://codepen.io/pkra/pen/VmZLgZ?editors=1010>
  * works reasonably well in AT
  * required reading:
http://blog.jantrid.net/2015/12/woe-aria-surprisingly-but-ridiculously.html
* Dani's example (replicated at https://codepen.io/pkra/pen/dOVPVL)
  * 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,
http://www.highcharts.com/docs/chart-concepts/accessibility.
    * 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

[math-on-web] reminder: next meeting Thursday, Dec 1

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

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] https://hangouts.google.com/hangouts/_/mathjax.org/math-on-web-cg

Re: ForAll & its mate

Source: www-math@w3.org Mail Archives • Hal.sz S.ndor (hsv@tbbs.net) • November 27, 2016 • Permalink

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*

Re: ForAll & its mate

Source: www-math@w3.org Mail Archives • David Carlisle (davidc@nag.co.uk) • November 24, 2016 • Permalink

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.

________________________________

ForAll & its mate

Source: www-math@w3.org Mail Archives • Hal.sz S.ndor (hsv@tbbs.net) • November 23, 2016 • Permalink

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.

[CSSWG] Minutes Lisbon F2F 2016-09-19 Part III: Joint Meeting with DPUB [mediaqueries] [css-text] [css-page]

Source: www-style@w3.org Mail Archives • Dael Jackson (daelcss@gmail.com) • November 16, 2016 • Permalink

=========================================
  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: https://www.w3.org/dpub/IG/wiki/Detailed_TPAC_2016_Agenda#Meeting_with_CSS_WG
        and https://wiki.csswg.org/planning/tpac-2016#agenda

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 -
           http://lists.w3.org/Archives/Public/public-aria-admin/2016Aug/0018.html
  <Rossen> Here's the initial set of features interested to the
           CSS/APA task force
https://github.com/w3c/aria/wiki/CSS-AAM-Potential-Features

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> https://drafts.csswg.org/css-text-4/#character-alignment
  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 dino@apple.com

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> https://drafts.csswg.org/css-text/#propdef-hanging-punctuation
  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> http://www.fileformat.info/info/unicode/category/Pd/list.htm

  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.

FMath: MathML Implementation Version 3.0 beta

Source: FMath • Ionel Alexandru (noreply@blogger.com) • November 01, 2016 • Permalink

Hi,

     www.fmath.info is happy to announce a new version for MathML implementation. The big change for this version is the refactoring for "Content Markup".

    The implementation of MathML is done for :
The code will have the same "look" on all technologies.

Details about what is already implemented and test pages:


For Web Applications I created:


regards
Ionel Alexandru



2016/10/27 follow ups: question on mathml

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

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<www-math@w3.org> 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.

[math-on-web] change of schedule for Nov 2016

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

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.

[math-on-web] meeting minutes, 2016/10/27

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

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

reminder: next meeting tomorrow, Thursday, Oct 27, 6pm UTC

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

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] https://hangouts.google.com/hangouts/_/mathjax.org/math-on-web-cg

MathJax v2.7 now available

Source: MathJax • October 14, 2016 • Permalink

After a very smooth beta run, we’re happy to officially release MathJax v2.7.

New in MathJax v2.7

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

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

For details on all bug fixes, please see below.

Please note the following.

Changes to the combined configuration files

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


Release on the MathJax CDN

MathJax v2.7 is available on the CDN, and for download from GitHub; see the documentation for details.

Version 2.7 is available on the CDN at

http://cdn.mathjax.org/mathjax/2.7-latest/MathJax.js

and starting today the files at the

http://cdn.mathjax.org/mathjax/latest/MathJax.js

address will be switched over the v2.7. If you are using the mathjax/latest 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.

If you are a page author and concerned about this, you can change (temporarily) to the mathjax/2.7-latest URL instead of mathjax/latest since that is a new address that will not have any cached older versions to worry about. You can switch back to mathjax/latest 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 mathjax/2.6-latest.

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

The MathJax Team.


New in MathJax v2.7

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

Features

For a detailed listing please check the release milestone.

Accessibility

Interface

HTML/SVG/nativeMML display

TeX emulation

Asciimath

MathML

Fonts

Localization

APIs

Misc.

RE: The MQ (or not) issue; what we are seeking

Source: public-digipub-ig@w3.org Mail Archives • Bill Kasdorf (bkasdorf@apexcovantage.com) • October 06, 2016 • Permalink

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:liam@w3.org] 
Sent: Wednesday, October 05, 2016 7:52 PM
To: Bill Kasdorf; Alan Stearns; Siegman, Tzviya - Hoboken; Peter Krautzberger; public-digipub-ig@w3.org
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

> 

Re: The MQ (or not) issue; what we are seeking

Source: public-digipub-ig@w3.org Mail Archives • Charles LaPierre (charlesl@benetech.org) • October 06, 2016 • Permalink

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: charlesl@benetech.org
Twitter: @CLaPierreA11Y
Skype: charles_lapierre
Phone: 650-600-3301



> On Oct 6, 2016, at 4:44 AM, Leonard Rosenthol <lrosenth@adobe.com> 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" <pault@dessci.com> 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:kerscher@montana.com]
>> Sent: Wednesday, October 05, 2016 6:44 PM
>> To: 'Liam R. E. Quin' <liam@w3.org>; 'Bill Kasdorf'
>> <bkasdorf@apexcovantage.com>; 'Alan Stearns' <stearns@adobe.com>;
>> 'Siegman, Tzviya - Hoboken' <tsiegman@wiley.com>; Peter Krautzberger
>> <peter.krautzberger@mathjax.org>; public-digipub-ig@w3.org
>> 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:liam@w3.org]
>> Sent: Wednesday, October 05, 2016 5:52 PM
>> To: Bill Kasdorf; Alan Stearns; Siegman, Tzviya - Hoboken; Peter Krautzberger;
>> public-digipub-ig@w3.org
>> 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
>> 
>>> 
>> 
>> 
>> 
> 
> 
> 



Re: The MQ (or not) issue; what we are seeking

Source: public-digipub-ig@w3.org Mail Archives • Leonard Rosenthol (lrosenth@adobe.com) • October 06, 2016 • Permalink

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" <pault@dessci.com> 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:kerscher@montana.com]
    > Sent: Wednesday, October 05, 2016 6:44 PM
    > To: 'Liam R. E. Quin' <liam@w3.org>; 'Bill Kasdorf'
    > <bkasdorf@apexcovantage.com>; 'Alan Stearns' <stearns@adobe.com>;
    > 'Siegman, Tzviya - Hoboken' <tsiegman@wiley.com>; Peter Krautzberger
    > <peter.krautzberger@mathjax.org>; public-digipub-ig@w3.org
    > 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:liam@w3.org]
    > Sent: Wednesday, October 05, 2016 5:52 PM
    > To: Bill Kasdorf; Alan Stearns; Siegman, Tzviya - Hoboken; Peter Krautzberger;
    > public-digipub-ig@w3.org
    > 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
    > 
    > >
    > 
    > 
    > 
    
    

Feeds

Planet MathML features:

If you own a blog with a focus on MathML, and want to be added or removed from this aggregator, please get in touch with Bert Bos at bert@w3.org.

(feed)This page as an Atom feed

A mechanical calculation machine (with an added W3C logo)

Bert Bos, math activity lead
Copyright © 2008–2015 W3C®

Powered by Planet