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: Scheduling in 2017

Source: Mail Archives • Peter Krautzberger ( • December 15, 2016 • Permalink

Hi MathOnWeb CG,

Just a quick reminder that we have two open doodles:

1) Frequency (weekly/biweekly/monthly)

2) day&time (Mon-Fri, 10am-3pm Eastern Time)

Please take the time to respond to them.

Best regards,

On Mon, Dec 12, 2016 at 3:42 PM, Peter Krautzberger <> wrote:

> Hi everyone,
> As mentioned in the minutes to the last meeting, we want to discuss a
> change of schedule for the CG.
> I've created two doodles for this:
> 1) Frequency (weekly/biweekly/monthly)
> bmhzfi5ikg2ph3h3
> 2) day&time (Mon-Fri, 10am-3pm Eastern Time)
> 7kngku9z4hifrik7
> As usual, please ignore the specific dates in 2) and only consider the
> weekday.
> Best regards,
> Peter.

Scheduling in 2017

Source: Mail Archives • Peter Krautzberger ( • December 12, 2016 • Permalink

Hi everyone,

As mentioned in the minutes to the last meeting, we want to discuss a
change of schedule for the CG.

I've created two doodles for this:

1) Frequency (weekly/biweekly/monthly)

2) day&time (Mon-Fri, 10am-3pm Eastern Time)

As usual, please ignore the specific dates in 2) and only consider the

Best regards,

[math-on-web] meeting minutes, 2016/12/01

Source: Mail Archives • Peter Krautzberger ( • December 12, 2016 • Permalink

Hi everyone,

Below are the minutes from the last meeting


# Math on web CG 2016/12/01

* Present: Tzviya, Volker, Peter, Jos, Kevin, Han

* Agenda:
  * updates on actions
  * a11y TF report
  * scheduling 2017

* Updates on actions:
  * Peter: webpages have been updated as discussed
    * GitHub pages now the default; old "main" now points there
    * clean up homepage
  * Jos: I want to update the linear formats page
    * => ACTION Jos
    * Peter: suggestion: look at new UnicodeMath version (by Murray
Sargent, Microsoft).
      * includes comparison with computational system notation
    * Peter: another suggestion jqmath, Unicode-driven, MathML equivalent
  * Jean's message on her ACTION (structure for subgroups) => later update
* Peter: now that conversation starters have have we will need to see how
much attention we can get around a) accessibility, b) layout, c) plain-text
  * Tzviya: suggestion from my experience leading such groups: follow the
directions that members lead you to

* Peter reported on the a11y task force meeting
  * [walk-through of Dani's demo]
    * easy markup to follow (derived from MathML)
    * mockup, focused on markup ideas that could work (not markup that WILL
work today)
    * revisiting role=math (e.g., where Dani uses title)
    * use of labels (as titles)
    * the fraction line problem of MathML
  * [walk-through of Peter's demo]
    * more focused on resulting output
    * MathML-based but not essential
    * aria-label to provide voicing since MathML lacks semantics (e.g.,
mover => derviative)
      * also improved customizability (e.g., P(E) => "Probability of E")
    * binomial vs mfrac issue
    * exploration by DOM
  * Peter: sample was motivated by mediaquery for MathML discussion.
Florian asked what alternatives might work
    * start by handwritten versions, identify what works, where limitations
    * then discuss automation via tools like speechruleengine
  * Jos: to check: the idea is to use existing accessibility attributes via
MathML in HTML?
    * Peter: yes.
      * Enrich MathML since it's not semantic.
      * Do it in a way that survives the transformation into HTML or SVG
      * seems to work reasonably well
      * there are obvious limits when expressions get very complicated but
that's not different from other content
      * from working with speechruleengine, I've focused on things that
could be automated
  * Peter: the task force meeting discussed the different approaches
    * identify points of aligning our approaches
    * Volker more thinking about automation (his speechruleengine,
    * identify limitations
    * points where standards could help
  * Jos: how does it survive MathJax's SVG output?
    * Peter: the SVG output optimizes the SVGs which causes losts labels
      * but that's a comparatively minor issue as this optimization could
easily be disabled
* Tzviya: a couple of suggestions
  *  look into SVG accessibility mappings
    * Peter: +1. Volker has been on a task force
  * Tzviya: next ARIA rec coming out, then a good time to talk about ARIA
  * Tzviya: the ARIA Document Model draft should be relevant
    * Jos: is there a good example for a11y that is independent of the DOM?
      * Tzviya: audio books
* Peter: scheduling -- would like to increase to weekly or biweekly
  * Peter: given the quorum, do a Doodle by email as before?
    * Kevin: +1
    * Jos: +1 both date and frequency
    * Tzviya: +1
* Peter: personal goal for 2017: get a layout task force going
  * evaluate current techniques, explore next gen technologies (grid etc)
  * update on plain text syntax document (Jos)
    * update on MathSON (Han)
  * update from a11y TF (a11y TF)
  * scheduling (Peter)

STIX Two in Gecko and WebKit

Source: Updates | Frédéric Wang • December 09, 2016 • Permalink

On the 1st of December, the STIX Fonts project announced the release of STIX 2. If you never heard about this project, it is described as follows:

The mission of the Scientific and Technical Information Exchange (STIX) font creation project is the preparation of a comprehensive set of fonts that serve the scientific and engineering community in the process from manuscript creation through final publication, both in electronic and print formats.

This sounds a very exciting goal but the way it has been achieved has made the STIX project infamous for its numerous delays, for its poor or confusing packaging, for delivering math fonts with too many bugs to be usable, for its lack of openness & communication, for its bad handling of third-party feedback & contribution

Because of these laborious travels towards unsatisfactory releases, some snarky people claim that the project was actually named after Styx (Στύξ) the river from Greek mythology that one has to cross to enter the Underworld. Or that the story of the project is summarized by Baudelaire’s verses from L’Irrémédiable:

Une Idée, une Forme, un Être
Parti de l’azur et tombé
Dans un Styx bourbeux et plombé
Où nul œil du Ciel ne pénètre ;

More seriously, the good news is that the STIX Consortium finally released text fonts with a beautiful design and a companion math font that is usable in math rendering engines such as Word Processors, LaTeX and Web Engines. Indeed, WebKit and Gecko have supported OpenType-based MathML layout for more than three years (with recent improvements by Igalia) and STIX Two now has correct OpenType data and metrics!

Of course, the STIX Consortium did not address all the technical or organizational issues that have made its reputation but I count on Khaled Hosny to maintain his more open XITS fork with enhancements that have been ignored for STIX Two (e.g. Arabic and RTL features) or with fixes of already reported bugs.

As Jacques Distler wrote in a recent blog post, OS vendors should ideally bundle the STIX Two fonts in their default installation. For now, users can download and install the OTF fonts themselves. Note however that the STIX Two archive contains WOFF and WOFF2 fonts that page authors can use as web fonts.

I just landed patches in Gecko and WebKit so that future releases will try and find STIX Two on your system for MathML rendering. However, you can already do the proper font configuration via the preference menu of your browser:

Finally, here is a screenshot of MathML formulas rendered by Firefox 49 using STIX Two:

Screenshot of MathML formulas rendered by Firefox using STIX 2

And the same page rendered by Epiphany 3.22.3:

Screenshot of MathML formulas rendered by Epiphany using STIX 2

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

Source: Mail Archives • Peter Krautzberger ( • December 01, 2016 • Permalink

PS: The hangout is now ready.


On Thu, Dec 1, 2016 at 7:13 PM, Peter Krautzberger <> 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" <
>> 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]

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

Source: Mail Archives • Peter Krautzberger ( • December 01, 2016 • Permalink


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.

On Nov 29, 2016 10:19 AM, "Peter Krautzberger" <> 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]

Re: plain text math notation

Source: Mail Archives • Han ( • 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
<>, 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.)


> ------------------------------
> *From:* Paul Topping <>
> *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
> *From:* Jos de Jong []
> *Sent:* Thursday, September 22, 2016 11:52 AM
> *To:* Robin Berjon <>
> *Cc:* Peter Krautzberger <>;
> public-mathonw. <>
> *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 <> 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]
> [1]
> --
> • Robin Berjon - - @robinberjon
> • — intelligent science publishing
> •

Re: plain text math notation

Source: Mail Archives • Peter Krautzberger ( • 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,


On Mon, Sep 26, 2016 at 4:27 PM, Robin Berjon <> 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}>
> >>         {
> >>  => <li>{}</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 - - @robinberjon
> • — intelligent science publishing
> •

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

Source: Mail Archives • Jean Kaplansky ( • 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.


On Tue, Nov 29, 2016 at 4:19 AM, Peter Krautzberger <> 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]

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

On Tue, Nov 29, 2016 at 4:19 AM, Peter Krautzberger <> 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]

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

Source: Mail Archives • Peter Krautzberger ( • 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.


# CG a11y TF meeting 2016-11-28

* Peter: working on demos,
  * works reasonably well in AT
  * required reading:
* Dani's example (replicated at
  * 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
   * 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
     * 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
    * 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
  * Peter: me too!
* Volker: back to navigation: is just tapping through?
  * Dani: should be just like any other content
  * Volker: cf. HighChart examples,
    * 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: Mail Archives • Peter Krautzberger ( • 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].



Re: ForAll & its mate

Source: Mail Archives • S.ndor ( • 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: Mail Archives • David Carlisle ( • November 24, 2016 • Permalink

On 23/11/2016 23:07, 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.



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: Mail Archives • S.ndor ( • 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: Mail Archives • Dael Jackson ( • 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
  - 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.



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
  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
  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
  <Rossen> CSS Accessibility Task Force -
  <Rossen> Here's the initial set of features interested to the
           CSS/APA task force

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

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

  [discussing whether further topics are best done here, or in the
      Houdini day]

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

  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
  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 ( • November 01, 2016 • Permalink

Hi, 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:

Ionel Alexandru

2016/10/27 follow ups: question on mathml

Source: Mail Archives • Peter Krautzberger ( • 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<> 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,

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

Source: Mail Archives • Peter Krautzberger ( • 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).


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

Source: Mail Archives • Peter Krautzberger ( • October 28, 2016 • Permalink

Hi everyone,

Below are the minutes to yesterday's call.


# 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
 * 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
   * 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
   * 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: Mail Archives • Peter Krautzberger ( • 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,



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

(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