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] CG meeting minutes, 2017/12/07

Source: public-mathonwebpages@w3.org Mail Archives • Charles LaPierre (charlesl@benetech.org) • December 08, 2017 • Permalink

Thanks for the minutes, sorry I wasn’t able to attend, I got tied up in another project.
EOM

Charles LaPierre
Technical Lead, DIAGRAM and Born Accessible
E-mail: charlesl@benetech.org<mailto:charlesl@benetech.org>
Twitter: @CLaPierreA11Y
Skype: charles_lapierre
Phone: 650-600-3301



On Dec 8, 2017, at 2:37 AM, Peter Krautzberger <peter@krautzource.com<mailto:peter@krautzource.com>> wrote:

Hi everyone,

Below are the minutes from the yesterday's CG meeting.

The next meeting is scheduled for Dec 22. But it's likely there will be too many regrets.

Best regards,
Peter.

# Math on Web Community Group 2017-12-07

On call: Dani, Neil, Peter, Volker

* Dani: I wanted to discuss two topics
  * another example of math layout through HTML
    * align column with different row than first
    * chatting with Igalia devs at TPAC gave new ideas
    * this solves an important piece
  * we should try to explain things more publicly
    * get people to understand what's difficult about this
  * revisiting accessibility
    * for me, that means talking about MathML
    * hoping to find common position
    * if the CG has a joint position, we can approach other groups better
* Neil: about HTML+CSS approach
  * how does it differ from MathJax?
  * looking at the code is partially a mystery
  * it works but don't knnow how
  * I think it would be good for everyone if people could understand this better
* Dani: we've been thinking more about future solutions
  * we know the limitations of current tech
  * Neil: MathJax v3 changes seem promising
  * Peter: [screensharing and talking about v3 alpha / https://mathjax.github.io/mj3-demos/mj3-mml2html.html ]
* Peter: I think talking about font-independent solutions is important
  * also, even MathJax v3 won't be "bleeding edge" because it's a production-ready tool
  * adopting new CSS (e.g., grids) is still not possible b/c at least IE11 is required
* Neil: identifying what's missing in the platform would be very valuable
* Dani: we need to identify the limitations, then get the community to follow up with CSS
* Neil: what was TPAC like?
  * Dani: good discussions
* Peter: we need allies beyond math, e.g., the SVG example I gave for baseline alignment
  * math community is usually not too much in tune with web tech trends
  * Dani: we can't build these but we need to find those who do
* Peter: and admittedly we are too few in this group
  * I've certainly had trouble getting people to respond / come here
  * it would be good for others in the group to reach out more widely
* [some discussion about various MathML details]
* Dani: back to a11y
  * we need to have a joint position if we want to get anywhere
  * Peter: I'm aware of the disagreement I posted at https://github.com/w3c/aria/issues/660 but I believe it's a mistake to use MathML for anything web-related.
  * Neil: I would revise MathML and add an mrole attribute, open-ended,
  * [Volker's idea: which I didn't catch in the minutes]
  * Dani: I could imagine roles in MathML, then passed through to HTML/SVG
  * Peter: I don't like mrole because it is open ended and a MathML revision seems very unlikely
    * DPUB aria shows ARIA is open to modules
    * there's ARIA role-description for open-ended stuff
  * Dani: I'd also hope to get copy&paste of subexpressions into an editor
    * Peter: that seems like a tough problem to solve, not even HTML or SVG work well here
    * Neil: but a critical feature!
    * Peter: I'm not so sure but you could already build tools like this if you wanted (e.g., MathJax exposes the MathML structure as classes)


[math-on-web] CG meeting minutes, 2017/12/07

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • December 08, 2017 • Permalink

Hi everyone,

Below are the minutes from the yesterday's CG meeting.

The next meeting is scheduled for Dec 22. But it's likely there will be too
many regrets.

Best regards,
Peter.

# Math on Web Community Group 2017-12-07

On call: Dani, Neil, Peter, Volker

* Dani: I wanted to discuss two topics
  * another example of math layout through HTML
    * align column with different row than first
    * chatting with Igalia devs at TPAC gave new ideas
    * this solves an important piece
  * we should try to explain things more publicly
    * get people to understand what's difficult about this
  * revisiting accessibility
    * for me, that means talking about MathML
    * hoping to find common position
    * if the CG has a joint position, we can approach other groups better
* Neil: about HTML+CSS approach
  * how does it differ from MathJax?
  * looking at the code is partially a mystery
  * it works but don't knnow how
  * I think it would be good for everyone if people could understand this
better
* Dani: we've been thinking more about future solutions
  * we know the limitations of current tech
  * Neil: MathJax v3 changes seem promising
  * Peter: [screensharing and talking about v3 alpha /
https://mathjax.github.io/mj3-demos/mj3-mml2html.html ]
* Peter: I think talking about font-independent solutions is important
  * also, even MathJax v3 won't be "bleeding edge" because it's a
production-ready tool
  * adopting new CSS (e.g., grids) is still not possible b/c at least IE11
is required
* Neil: identifying what's missing in the platform would be very valuable
* Dani: we need to identify the limitations, then get the community to
follow up with CSS
* Neil: what was TPAC like?
  * Dani: good discussions
* Peter: we need allies beyond math, e.g., the SVG example I gave for
baseline alignment
  * math community is usually not too much in tune with web tech trends
  * Dani: we can't build these but we need to find those who do
* Peter: and admittedly we are too few in this group
  * I've certainly had trouble getting people to respond / come here
  * it would be good for others in the group to reach out more widely
* [some discussion about various MathML details]
* Dani: back to a11y
  * we need to have a joint position if we want to get anywhere
  * Peter: I'm aware of the disagreement I posted at
https://github.com/w3c/aria/issues/660 but I believe it's a mistake to use
MathML for anything web-related.
  * Neil: I would revise MathML and add an mrole attribute, open-ended,
  * [Volker's idea: which I didn't catch in the minutes]
  * Dani: I could imagine roles in MathML, then passed through to HTML/SVG
  * Peter: I don't like mrole because it is open ended and a MathML
revision seems very unlikely
    * DPUB aria shows ARIA is open to modules
    * there's ARIA role-description for open-ended stuff
  * Dani: I'd also hope to get copy&paste of subexpressions into an editor
    * Peter: that seems like a tough problem to solve, not even HTML or SVG
work well here
    * Neil: but a critical feature!
    * Peter: I'm not so sure but you could already build tools like this if
you wanted (e.g., MathJax exposes the MathML structure as classes)

Remember meeting tomorrow

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • December 07, 2017 • Permalink

Hi,

Just remember the meeting we have tomorrow 9PST and 6CET.

I've added another example about how to do align columns at
https://codepen.io/daniwiris/pen/bYERoL

After the TPAC conference I learned how to to align columns by a child
different of the first one, with the help of Igalia. Now it is worth to
share the "discovery" with all members of the CG.

I remember you the objectives I try to accomplish:

   1. To use only html5/css/web-fonts (no JavaScript) to display statically
   independent-target-device math (but also some physics and chemistry)
   simple-enough formulas. This means:
      1. To target a common subset of simple math formulas.
      2. To be robust to browser and OS change. Firefox, Chrome, Safari,
      Edge, ... Windows, Mac, Linux, iOs, Android, ...
      3. To be robust to scale. For example, device pixel ratio in retina
      display and browser zoom.
      4. To be robust to font family change within the same type of font
      (Arial, Helvetica or Lucida Sans). Changing from Arial to
Courier New might
      not work so well.
      5. To be robust to font size change and colors.
      6. It is fine to embed fonts for math symbols. Especially stretchy
      parts, including parts of roots.
      7. To break a formula into lines
      2. To be enough semanticaly rich for copying, pasting and providing
   accessibility.
   3. To be able to recompose a formula if any subpart of such formula is
   dynamically changed with the help of JavaScript. Because, if you are able
   to change subparts of a formula, it means that the device is using
   JavaScript anyway.

I would like to know whether it is worth to continue in this line and make
it part of the results we achieve together as community group.

Regards,

Dani

-- 

------------------------------
WIRIS and Design Science, makers of MathType, have joined forces!
Thank you for your patience as we transition from dessci.com to wiris.com.

Other Office Math Editing Facilities

Source: Murray Sargent: Math in Office • MurrayS3 • November 30, 2017 • Permalink

Many posts of this blog are about the native Office math facility introduced in Microsoft Word in 2007 and added to PowerPoint, OneNote, and in Excel Text Boxes in 2010. But the first native math-text facility in Microsoft Word was the EQ field, one of many fields, such as time and date. Design Science designed MathType, which first shipped on the Mac in 1987 and was released on Windows in 1990. A simplified version of MathType called the Equation Editor was introduced in 1992 and has shipped as part of Office on Windows and the Mac ever since. This post overviews these three facilities for representing math text in Microsoft Office along with what math formats they support. There are more math programs, such as Mathematica, that interoperate with Office apps typically via MathML.

EQ Field

The EQ field was added in an early version of Word and still works, although the user is responsible for math spacing and inserting the desired math symbols. Any Unicode characters can be used including the complete Unicode math set of 2310 characters. To enter an equation, click on Insert/Quick Parts/Field… and select Eq from the list. Click on Field Codes and the Options… button to see the possible math constructs, such as \F(,) for fraction. With alt+x’ing in the Unicode math symbols, adding spaces around the operators and using the Cambria Math font, one can insert the solution to the quadratic equation as

The EQ field for this is {EQ 𝑥 = \F(−𝑏 ± \R(,𝑏\S(2) − 4𝑎𝑐),2𝑎)} formatted with Cambria Math and Unicode math italic alphabetics for a, b, c, and x. You can toggle the EQ field between the math display and the field codes by right-clicking on the field and choosing “Toggle Field Codes”. Note that the math axis doesn't line up between the equal sign and the fraction bar. The display isn’t as typographically pretty as that of the Office math facility (type alt+= \quadratic<space><space>)

and it’s appreciably harder to use. Also, the superscript size for the square must be formatted explicitly. If you change the size of the formula, you have to reformat the superscript with an appropriate smaller size. The Office math facility automatically chooses superscript and subscript sizes appropriate for the base text. The EQ field doesn't support important constructs such as matrices and N-ary expressions other than simple integrals. Word represents ruby objects using EQ fields, although it uses LineServices in rendering them.

MathType

MathType and its limited edition, the Equation Editor, made math entry easier and considerably more general than the EQ field by adding intuitive tool bars giving access to mathematical symbols and function templates. All common math constructs are supported, and the typography includes niceties such as automatic math spacing around operators and trig functions. You can download the current version of MathType and use it for free for 30 days. After that it goes into a “lite” version unless you pay $99. The lite version has advantages over the Equation Editor not the least of which is that it’s currently maintained.

Both MathType and the Equation Editor display the solution to the quadratic equation as                                                  This is easy to enter using hot keys or the templates on the template tool bar. You can also enter it by hand writing using the Math Input Panel which communicates with client apps via MathML.

On Windows and the Mac, MathType and the Equation Editor use embedded OLE objects for displaying and editing math text. As such they can be used by any programs that support OLE such as WordPad. For WordPad, click on Insert Object and choose Microsoft Equation 3.0. But OLE is only available on Win32 Windows and the Mac. Also, a program’s search and formatting commands don’t work with embedded OLE objects, while they do work with native Office math zones.

MathType incorporates the Unicode 2.0 math characters and adds many others in the Unicode Private Use Area (see the MTCode Encoding Tables). 364 characters have the math property in Unicode 2.0. This is considerably less than the 2310 math characters in the current Unicode Standard. Most of the characters in the MTCode Encoding Tables are in the current Unicode Standard, but there might be backward compatibility issues if MathType were to upgrade to that version of the standard. There are many math characters in the Unicode Standard that are not in MathType. I haven’t been able to enter such characters into MathType or the Equation Editor. Since these characters are not common, it’s not a major limitation. Chapter 6 of Creating Research and Scientific Documents with Microsoft Word describes both the native Office math facility discussed in many of this blog’s posts as well as MathType.

Math entities

Now let’s consider how various math entities are represented in these math facilities and the file formats they support. The formats are Presentation MathML, OMML (Office MathML), RTF, [La]TeX, UnicodeMath, braille, and MathType. Math entities such as fractions and integrals have arguments. The number of arguments and the order in which they occur may differ between the representations. The MathType equation format is a binary format and is documented in detail in the MathType SDK. The discussion here is limited to what the templates reveal when one runs MathType and/or the Equation Editor.

Fractions

All math formats have a numerator and a denominator for fractions and they occur in that order. The EQ field and math braille only have stacked fractions (numerator above denominator), but the other formats also have slashed, linear, and small fractions.

Math functions

Math functions, such as trigonometric and log, have an explicit two-argument entity in OMML and RTF, but are handled by character formatting alone in the other formats. Having an object with two explicit arguments reveals the content better in the user interface and facilitates typographic refinements, such as precise spacing.

Integrals and summations

OMML, RTF and MathType have three arguments for N-ary entities such as integral and summation, namely the upper and lower limits and the integrand or summand, which can be called N-aryands. [La]TeX and braille only have the two limits. Presentation MathML doesn’t have an explicit N-ary entity; instead it overloads other entities (msub, msup, msubsup, mover, munder, munderover) which don't have an N-aryand. This is a shortcoming of Presentation MathML. The EQ field has integrals with all three arguments, but no summations or other N-ary entities. UnicodeMath defines the N-aryand to be the first operand following the N-ary operator and its limits (if present). MathType puts the N-aryand before the limits, while OMML and RTF put it afterward since it follows the limits visually. Having it afterward makes navigating with arrow keys more natural. MathType traverses integrals and summations with the Tab key in visual order, but the left/right arrow keys bypass the limit arguments.

Subscripts and superscripts

Subscript and superscript bases are not arguments in MathType, [La]TeX, braille or the EQ field. They are arguments in MathML, OMML and RTF. In UnicodeMath, the base is the variable, function name, number, or object immediately preceding the sub/sup operators. Knowing the base allows proper kerning of the base onto the script (superscript or subscript) as well as providing more exact semantics in interoperating with mathematical calculation engines. While the base can be determined algorithmically as in MathType, [La]TeX and UnicodeMath, having an explicit argument for it automatically gives it helpful shading in Office math zones and lends precision to the fine-grained math speech needed for unambiguous editing of math using speech.

Parentheses, brackets, braces

The EQ field has the \B() option which puts appropriately sized parentheses around its argument. It doesn’t allow for other kinds of delimiters, such as [] and {}. Also, it doesn’t have multiple argument expressions that size the argument dividers appropriately, such as in Dirac notation. The other formats have many delimiter options and can handle multiple arguments correctly.

 

[MathOnWeb] CANCEL meeting Nov 23, 2017

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • November 23, 2017 • Permalink

Hi everyone,

Due to Thanksgiving in the US, we'll skip the meeting this week.

Best,
Peter.

Re: [MathOnWeb] CANCEL meeting Nov 9, 2017

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • November 23, 2017 • Permalink

Hi,

Tomorrow is Thanksgivings in the USA. I won't be able to attend the meeting
since I'm out camping.

Dani

On Wed, Nov 8, 2017 at 10:01 AM, Peter Krautzberger <peter@krautzource.com>
wrote:

> Hi everybody,
>
> With TPAC ongoing and various people traveling, we've decided to cancel
> this week's meeting.
>
> Best regards,
> Peter and Dani.
>

-- 

------------------------------
WIRIS and Design Science, makers of MathType, have joined forces!
Thank you for your patience as we transition from dessci.com to wiris.com.

Igalia launches a project to fund MathML in Chromium

Source: W3C Math Home • November 20, 2017 • Permalink

Igalia launches a project to fund MathML in Chromium

[MathOnWeb] CANCEL meeting Nov 9, 2017

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • November 08, 2017 • Permalink

Hi everybody,

With TPAC ongoing and various people traveling, we've decided to cancel
this week's meeting.

Best regards,
Peter and Dani.

Re: Polyfill and meeting

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • November 02, 2017 • Permalink

Hi Neil,

I created some *academic *tests at https://codepen.io/daniwiris/pen/ooXmov
to study how to use flex-boxes.

Then, I created more practical example with a formula:
https://codepen.io/daniwiris/pen/bYERoL

Both tested in Firefox, Chrome, IE and Edge.

The only thing I miss is to be able to select which row to use for baseline
alignment when a column based flex-box is inside a row based flex-box. I'm
still planning to talk to Alan Steams. Any other suggestion?

Dani

On Mon, Oct 30, 2017 at 8:07 PM, Neil Soiffer <soiffer@alum.mit.edu> wrote:

> FYI:  CSS Flexible Box Layout Module Level 1
> <https://www.w3.org/TR/2017/CR-css-flexbox-1-20171019/#align-content-property>
> just announced call for implementations. Anything in there of use for
> alignment or otherwise? If something is missing, it's getting late in the
> game to suggest a missing feature for flex boxes, but with a good
> justification, you never know.
>
>     Neil
>
>
>
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free.
> www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#m_6316207308334725962_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Mon, Oct 30, 2017 at 3:09 PM, Daniel Marques <dani@wiris.com> wrote:
>
>> Hi,
>>
>>
>> Just uploaded the examples at https://codepen.io/daniwiris/p
>> roject/editor/ZWbYxB .
>>
>>
>> My first thought was to extend the CSS style vertical-align. But then, I
>> changed my mind in favor of the CSS style baseline-shift (
>> https://www.w3.org/TR/css-inline-3/#baseline-shift-property). That’s
>> more powerful since, for example, it would be possible to combine
>> vertical-align="mathematical" with baseline-shift.
>>
>>
>> In any case, I would like to sate the following objectives:
>>
>>
>>    1. To use only html5/css/web-fonts (no JavaScript) to display
>>    statically independent-target-device math (but also some physics and
>>    chemistry) simple-enough formulas. This means:
>>       1. To target a common subset of simple math formulas.
>>       2. To be robust to browser and OS change. Firefox, Chrome, Safari,
>>       Edge, ... Windows, Mac, Linux, iOs, Android, ...
>>       3. To be robust to scale. For example, device pixel ratio in
>>       retina display and browser zoom.
>>       4. To be robust to font family change within the same type of font
>>       (Arial, Helvetica or Lucida Sans). Changing from Arial to Courier New might
>>       not work so well.
>>       5. To be robust to font size change.
>>       6. It is fine to embed fonts for math symbols. Especially stretchy
>>       parts, including parts of roots.
>>    2. To be enough semanticaly rich for copying, pasting and providing
>>    accessibility.
>>    3. To be able to recompose a formula if any subpart of such formula
>>    is dynamically changed with the help of JavaScript. Because, if you are
>>    able to change subparts of a formula, it means that the device is using
>>    JavaScript anyway.
>>
>> Of course, the html5/css/web-fonts representation of a given formula can
>> be generated once programmatically. Since it must not depend on the target
>> device, it can be generated either in the server or in the browser. Once
>> such formula is created, the exactly same html is send to all devices.
>> eBooks will be published with static html formulas.
>>
>>
>> After giving many thoughts to the topic I realized that current HTML
>> technology has already solved problem 1. Maybe one possible task of the
>> MathOnWebPages CG could be to explain how to do it. In a form of paper in a
>> conference? In a blog? A new project in Github?
>>
>>
>> For formulas that cannot be achieved with html5/css/web-fonts, let’s use
>> SVG. I don’t think it is possible to do all imaginable formulas with either
>> LaTeX or MathML. Remember that math are more than just formulas: plots,
>> graphs, movies…
>>
>>
>> The second objective is more ambitious. What I suggest is that we need to
>> markup the html in order to be able to recover the underlying math
>> structure. We are entering in the swampy zone of the semantics. I suggest a
>> lightweight semantics style like presentation-MathML on first place and,
>> optionally, add an extra layer of heavyweight semantics the way
>> content-MathML, Open Math or whatever format is decided.
>>
>>
>> It should be possible to add this layer of semantics also to a SVG image.
>>
>>
>> Dani
>>
>> On Wed, Oct 25, 2017 at 4:03 PM, Daniel Marques <dani@wiris.com> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> First of all, my apologies since I’m not available tomorrow/today for
>>> the meeting since I’m travelling to a conference.
>>>
>>>
>>>
>>> The good news is that I’ve not been idle and I’ve added two further
>>> examples to the polyfill:
>>>
>>> 1.     Matrix alignment with fences
>>> 2.     Grammar analysis (language subject)
>>>
>>> Unfortunately, I’m travelling and I’m not able to update the examples
>>> online. The old version is still available at:
>>> https://codepen.io/daniwiris/pen/rGKENd
>>>
>>>
>>>
>>> From the current examples, I learnt that the minimum requirements are to
>>> be able to align respect to a given child in the following two scenarios:
>>>
>>> 1.     A vertical flexbox
>>> 2.     A table or grid
>>>
>>> For the table, the alignment is only well defined when the affected row
>>> (the children of tables are rows) has all its cells aligned by the
>>> baseline, which is already possible to do with the current CSS
>>> specification. Things are a little more disgusting because tables contain
>>> an extra tbody element…
>>>
>>>
>>>
>>> Despite these minimal requirements, I implemented a version of the
>>> polyfill that is able to align a flexbox or table according to any of its
>>> descendants using a CSS like selector. It is fine to have such
>>> functionality but maybe we are overkilling the solution.
>>>
>>>
>>>
>>> I used the handy selectionQuery method in JavaScript which seemed an
>>> ideal solution until I discovered that selectionQuery never returned the
>>> node I expected when multiple nodes satisfied the criteria. For example,
>>> “:nth-child(2)” actually means any second child of any successor.
>>>
>>>
>>>
>>> Another idea is that probably makes more sense defining the “baseline”
>>> than change the “vertical-align”. Thus,
>>>
>>> Preferred solution:
>>>
>>>             baseline: “:nth-child(2)”;
>>>
>>>             vertical-align: “baseline”;
>>>
>>> Less preferred solution:
>>>
>>>              vertical-align: “:nth-child(2)”
>>>
>>>
>>>
>>> I’ve also experimented with the stretchy solution. I think that it is
>>> great but at the same time discovered that the browser does not render in
>>> the same form normal text than scaled one (we already saw that in Peter’s
>>> demo). This yields, again, that the different parts do not match perfectly.
>>> For example, the minus sign had different weight when zoomed horizontally.
>>> So the theory that this is a solution for perfect fraction lines is not
>>> true. I’m not worried about that. Eventually we could blame the browsers
>>> and they might fix it from their side.
>>>
>>>
>>> I'm still with the idea of going to TPAC. But I'm not satisfied with the
>>> current polyfill status.
>>>
>>>
>>> Regards,
>>>
>>>
>>> Dani
>>>
>>>
>>>
>>
>> ------------------------------
>> WIRIS and Design Science, makers of MathType, have joined forces!
>> Thank you for your patience as we transition from dessci.com to wiris.com
>> .
>>
>
>

-- 

------------------------------
WIRIS and Design Science, makers of MathType, have joined forces!
Thank you for your patience as we transition from dessci.com to wiris.com.

Re: Polyfill and meeting

Source: public-mathonwebpages@w3.org Mail Archives • Neil Soiffer (soiffer@alum.mit.edu) • October 31, 2017 • Permalink

FYI:  CSS Flexible Box Layout Module Level 1
<https://www.w3.org/TR/2017/CR-css-flexbox-1-20171019/#align-content-property>
just announced call for implementations. Anything in there of use for
alignment or otherwise? If something is missing, it's getting late in the
game to suggest a missing feature for flex boxes, but with a good
justification, you never know.

    Neil


<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Oct 30, 2017 at 3:09 PM, Daniel Marques <dani@wiris.com> wrote:

> Hi,
>
>
> Just uploaded the examples at https://codepen.io/daniwiris/
> project/editor/ZWbYxB .
>
>
> My first thought was to extend the CSS style vertical-align. But then, I
> changed my mind in favor of the CSS style baseline-shift (
> https://www.w3.org/TR/css-inline-3/#baseline-shift-property). That’s more
> powerful since, for example, it would be possible to combine
> vertical-align="mathematical" with baseline-shift.
>
>
> In any case, I would like to sate the following objectives:
>
>
>    1. To use only html5/css/web-fonts (no JavaScript) to display
>    statically independent-target-device math (but also some physics and
>    chemistry) simple-enough formulas. This means:
>       1. To target a common subset of simple math formulas.
>       2. To be robust to browser and OS change. Firefox, Chrome, Safari,
>       Edge, ... Windows, Mac, Linux, iOs, Android, ...
>       3. To be robust to scale. For example, device pixel ratio in retina
>       display and browser zoom.
>       4. To be robust to font family change within the same type of font
>       (Arial, Helvetica or Lucida Sans). Changing from Arial to Courier New might
>       not work so well.
>       5. To be robust to font size change.
>       6. It is fine to embed fonts for math symbols. Especially stretchy
>       parts, including parts of roots.
>    2. To be enough semanticaly rich for copying, pasting and providing
>    accessibility.
>    3. To be able to recompose a formula if any subpart of such formula is
>    dynamically changed with the help of JavaScript. Because, if you are able
>    to change subparts of a formula, it means that the device is using
>    JavaScript anyway.
>
> Of course, the html5/css/web-fonts representation of a given formula can
> be generated once programmatically. Since it must not depend on the target
> device, it can be generated either in the server or in the browser. Once
> such formula is created, the exactly same html is send to all devices.
> eBooks will be published with static html formulas.
>
>
> After giving many thoughts to the topic I realized that current HTML
> technology has already solved problem 1. Maybe one possible task of the
> MathOnWebPages CG could be to explain how to do it. In a form of paper in a
> conference? In a blog? A new project in Github?
>
>
> For formulas that cannot be achieved with html5/css/web-fonts, let’s use
> SVG. I don’t think it is possible to do all imaginable formulas with either
> LaTeX or MathML. Remember that math are more than just formulas: plots,
> graphs, movies…
>
>
> The second objective is more ambitious. What I suggest is that we need to
> markup the html in order to be able to recover the underlying math
> structure. We are entering in the swampy zone of the semantics. I suggest a
> lightweight semantics style like presentation-MathML on first place and,
> optionally, add an extra layer of heavyweight semantics the way
> content-MathML, Open Math or whatever format is decided.
>
>
> It should be possible to add this layer of semantics also to a SVG image.
>
>
> Dani
>
> On Wed, Oct 25, 2017 at 4:03 PM, Daniel Marques <dani@wiris.com> wrote:
>
>> Hi,
>>
>>
>>
>> First of all, my apologies since I’m not available tomorrow/today for the
>> meeting since I’m travelling to a conference.
>>
>>
>>
>> The good news is that I’ve not been idle and I’ve added two further
>> examples to the polyfill:
>>
>> 1.     Matrix alignment with fences
>> 2.     Grammar analysis (language subject)
>>
>> Unfortunately, I’m travelling and I’m not able to update the examples
>> online. The old version is still available at: https://codepen.io/daniwir
>> is/pen/rGKENd
>>
>>
>>
>> From the current examples, I learnt that the minimum requirements are to
>> be able to align respect to a given child in the following two scenarios:
>>
>> 1.     A vertical flexbox
>> 2.     A table or grid
>>
>> For the table, the alignment is only well defined when the affected row
>> (the children of tables are rows) has all its cells aligned by the
>> baseline, which is already possible to do with the current CSS
>> specification. Things are a little more disgusting because tables contain
>> an extra tbody element…
>>
>>
>>
>> Despite these minimal requirements, I implemented a version of the
>> polyfill that is able to align a flexbox or table according to any of its
>> descendants using a CSS like selector. It is fine to have such
>> functionality but maybe we are overkilling the solution.
>>
>>
>>
>> I used the handy selectionQuery method in JavaScript which seemed an
>> ideal solution until I discovered that selectionQuery never returned the
>> node I expected when multiple nodes satisfied the criteria. For example,
>> “:nth-child(2)” actually means any second child of any successor.
>>
>>
>>
>> Another idea is that probably makes more sense defining the “baseline”
>> than change the “vertical-align”. Thus,
>>
>> Preferred solution:
>>
>>             baseline: “:nth-child(2)”;
>>
>>             vertical-align: “baseline”;
>>
>> Less preferred solution:
>>
>>              vertical-align: “:nth-child(2)”
>>
>>
>>
>> I’ve also experimented with the stretchy solution. I think that it is
>> great but at the same time discovered that the browser does not render in
>> the same form normal text than scaled one (we already saw that in Peter’s
>> demo). This yields, again, that the different parts do not match perfectly.
>> For example, the minus sign had different weight when zoomed horizontally.
>> So the theory that this is a solution for perfect fraction lines is not
>> true. I’m not worried about that. Eventually we could blame the browsers
>> and they might fix it from their side.
>>
>>
>> I'm still with the idea of going to TPAC. But I'm not satisfied with the
>> current polyfill status.
>>
>>
>> Regards,
>>
>>
>> Dani
>>
>>
>>
>
> ------------------------------
> WIRIS and Design Science, makers of MathType, have joined forces!
> Thank you for your patience as we transition from dessci.com to wiris.com.
>

Re: Polyfill and meeting

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • October 30, 2017 • Permalink

Hi,


Just uploaded the examples at
https://codepen.io/daniwiris/project/editor/ZWbYxB .


My first thought was to extend the CSS style vertical-align. But then, I
changed my mind in favor of the CSS style baseline-shift (
https://www.w3.org/TR/css-inline-3/#baseline-shift-property). That’s more
powerful since, for example, it would be possible to combine
vertical-align="mathematical" with baseline-shift.


In any case, I would like to sate the following objectives:


   1. To use only html5/css/web-fonts (no JavaScript) to display statically
   independent-target-device math (but also some physics and chemistry)
   simple-enough formulas. This means:
      1. To target a common subset of simple math formulas.
      2. To be robust to browser and OS change. Firefox, Chrome, Safari,
      Edge, ... Windows, Mac, Linux, iOs, Android, ...
      3. To be robust to scale. For example, device pixel ratio in retina
      display and browser zoom.
      4. To be robust to font family change within the same type of font
      (Arial, Helvetica or Lucida Sans). Changing from Arial to
Courier New might
      not work so well.
      5. To be robust to font size change.
      6. It is fine to embed fonts for math symbols. Especially stretchy
      parts, including parts of roots.
   2. To be enough semanticaly rich for copying, pasting and providing
   accessibility.
   3. To be able to recompose a formula if any subpart of such formula is
   dynamically changed with the help of JavaScript. Because, if you are able
   to change subparts of a formula, it means that the device is using
   JavaScript anyway.

Of course, the html5/css/web-fonts representation of a given formula can be
generated once programmatically. Since it must not depend on the target
device, it can be generated either in the server or in the browser. Once
such formula is created, the exactly same html is send to all devices.
eBooks will be published with static html formulas.


After giving many thoughts to the topic I realized that current HTML
technology has already solved problem 1. Maybe one possible task of the
MathOnWebPages CG could be to explain how to do it. In a form of paper in a
conference? In a blog? A new project in Github?


For formulas that cannot be achieved with html5/css/web-fonts, let’s use
SVG. I don’t think it is possible to do all imaginable formulas with either
LaTeX or MathML. Remember that math are more than just formulas: plots,
graphs, movies…


The second objective is more ambitious. What I suggest is that we need to
markup the html in order to be able to recover the underlying math
structure. We are entering in the swampy zone of the semantics. I suggest a
lightweight semantics style like presentation-MathML on first place and,
optionally, add an extra layer of heavyweight semantics the way
content-MathML, Open Math or whatever format is decided.


It should be possible to add this layer of semantics also to a SVG image.


Dani

On Wed, Oct 25, 2017 at 4:03 PM, Daniel Marques <dani@wiris.com> wrote:

> Hi,
>
>
>
> First of all, my apologies since I’m not available tomorrow/today for the
> meeting since I’m travelling to a conference.
>
>
>
> The good news is that I’ve not been idle and I’ve added two further
> examples to the polyfill:
>
> 1.     Matrix alignment with fences
> 2.     Grammar analysis (language subject)
>
> Unfortunately, I’m travelling and I’m not able to update the examples
> online. The old version is still available at: https://codepen.io/
> daniwiris/pen/rGKENd
>
>
>
> From the current examples, I learnt that the minimum requirements are to
> be able to align respect to a given child in the following two scenarios:
>
> 1.     A vertical flexbox
> 2.     A table or grid
>
> For the table, the alignment is only well defined when the affected row
> (the children of tables are rows) has all its cells aligned by the
> baseline, which is already possible to do with the current CSS
> specification. Things are a little more disgusting because tables contain
> an extra tbody element…
>
>
>
> Despite these minimal requirements, I implemented a version of the
> polyfill that is able to align a flexbox or table according to any of its
> descendants using a CSS like selector. It is fine to have such
> functionality but maybe we are overkilling the solution.
>
>
>
> I used the handy selectionQuery method in JavaScript which seemed an ideal
> solution until I discovered that selectionQuery never returned the node I
> expected when multiple nodes satisfied the criteria. For example,
> “:nth-child(2)” actually means any second child of any successor.
>
>
>
> Another idea is that probably makes more sense defining the “baseline”
> than change the “vertical-align”. Thus,
>
> Preferred solution:
>
>             baseline: “:nth-child(2)”;
>
>             vertical-align: “baseline”;
>
> Less preferred solution:
>
>              vertical-align: “:nth-child(2)”
>
>
>
> I’ve also experimented with the stretchy solution. I think that it is
> great but at the same time discovered that the browser does not render in
> the same form normal text than scaled one (we already saw that in Peter’s
> demo). This yields, again, that the different parts do not match perfectly.
> For example, the minus sign had different weight when zoomed horizontally.
> So the theory that this is a solution for perfect fraction lines is not
> true. I’m not worried about that. Eventually we could blame the browsers
> and they might fix it from their side.
>
>
> I'm still with the idea of going to TPAC. But I'm not satisfied with the
> current polyfill status.
>
>
> Regards,
>
>
> Dani
>
>
>

-- 

------------------------------
WIRIS and Design Science, makers of MathType, have joined forces!
Thank you for your patience as we transition from dessci.com to wiris.com.

[math-on-web] CG meeting minutes, 2017/10/26

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • October 26, 2017 • Permalink

Hi everyone,

Due to low attendance and connection issue, this meeting was mostly a
casual chat about various projects. We cut it short after 30 minutes and
did not keep formal minutes.

The next meeting will be on November 9 and we plan to continue the
discussion around CSS polyfills.

Best,
Peter.

# [math on web CG] minutes 2017-10-26

[no formal minutes]

[math-on-web] CG meeting minutes, 2017/10/12

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • October 26, 2017 • Permalink

Hi everyone,

Below are the minutes from the last CG meeting.

As Dani wrote, the next meeting is today (and about to start actually --
sorry for the delay for the minutes).

Best,
Peter.


# MathOnWeb CG meeting 2017/10/12

* Dani's demo
  * https://codepen.io/daniwiris/pen/rGKENd/
  * https://codepen.io/daniwiris/pen/rGKENd/
  * Dani: should we use a new name or a new value?
    * flex-vertical-align vs vertical-align
  * Volker: "1child" looks weird is that normal?
    * Peter: nth-child(n+kl)
  * Volker: what about binomial notation? Where to align?
  * Peter: Tab wrote at https://github.com/w3c/csswg-drafts/issues/1339
    * "Usually, rather than explicitly indicating an element in a property,
we invert control and have the target indicate that it's the one to be used
(and when necessary, have some sort of tie-breaker for ambiguous
situations)."
  * Dani: example maybe overly complicated due to alignment at minus
    * brings in all kinds of other topics (stretchy etc)
    * maybe 3x3 matrix is better
    * [discussion]
  * Neil: if we have to tell the child to be target, in the 3x3, can we
expect it to bubble it up? I.e. cell tells row tells matrix tells ...
    * Peter: CSSWG would tell us. I don't know if there are problems
      * e.g., expect we can have different cells influencing their rows and
the rows working differently
  * Volker: with matrix, what if we want to align in "the middle"
    * and we remove a row.
  * Neil: maybe it's then more about making Dani's polyfill bubble up the
property
  * Dani: minus sign stretch.
* Peter: stretchy chars in MathJax v3
  * https://codepen.io/pkra/pen/aLjGxZ
  * https://codepen.io/pkra/pen/NaBMOE/
  * Dani: so the main trick is scaling in the direction and using
overflow-hidden to crop it
* Dani: what are fractions like in MathJax v3?
  * Peter: I'll have to ask Davide
    * but links to pre-alpha example:
      * https://groups.google.com/d/msg/mathjax-dev/RCOg-Ca4aIk/GFRKNP-wBAAJ
      * https://rawgit.com/mathjax/mathjax-v3/demo/demo/index.html
* ACTIONS
 * Dani rewrite

[CSSWG] Minutes Telecon 2017-10-25 [css-ui-3] [css-ui-4] [css-fonts] [css-text-decor]

Source: www-style@w3.org Mail Archives • Dael Jackson (daelcss@gmail.com) • October 26, 2017 • 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.
=========================================


CSS UI 3 & 4
------------

  - RESOLVED: Take CSS UI 3 to PR.
  - RESOLVED: Take CSS UI 4 to an updated WD.
  - RESOLVED: Re-point CSS UI link to CSS UI 4 spec.

Fonts 3
-------

  - RESOLVED: Publish a new Fonts 3 CR.

HTML
----

  - Though the group is generally supportive of the effort to
      incorporate better typography in issue #1888, the proposal to
      change <sup> and <sub> has a very high likelihood of causing
      breakage. This should instead be filed as a bug against Fonts 4
      or 5 as a proposal to change CSS. Any request should also have
      test cases to demonstrate what would be different between the
      current and proposed approach.

CSS Text Decor
--------------

  - RESOLVED: Add the statement that stroke should follow the curve of
              the glyph as well as adding a non-normative note that
              points out anything captured in the Github issue and add
              better pictures.

CSS Grid
--------

  - The remaining open topics on issue #509 (percentages and intrinsic
      sizes: https://github.com/w3c/csswg-drafts/issues/509 ) will be
      discussed at the F2F.

F2F Meetings
------------

  - RESOLVED: Have the mid-2018 meeting held week of July 2nd in
              Sydney with Google as host.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2017Oct/0042.html

Present:
  Rossen Atanassov
  Daid Baron
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Javier Fernandez
  Dael Jackson
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Anton Prowse
  Manuel Rego Casasnovas
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Greg Whitworth

Regrets:
  Rachel Andrew
  Tab Atkins
  Tony Graham
  Michael Miller
  Lea Verou

Scribe: dael

  Rossen: Let's get going. Hello everyone.
  Rossen: Are there any additional items for the agenda or any changes
          we need to make?
  Chris: I sent one for CSS Fonts 3 which could do with a republish.
         Updated CR.
  Rossen: Thank you.
  Rossen: Any others?

Spec Rec Next Steps
===================

CSS UI 3 & 4
------------

  Rossen: First one is CSS 3 UI.
  <florian> http://www.w3.org/mid/BBBF6365-4251-426D-A3F0-4F3E7D6C48A4@rivoal.net
  Email Body:
      [
      ## CSS-UI-3 ##
          * There are 0 open issues:
https://github.com/w3c/csswg-drafts/labels/css-ui-3
          * The change section is up to date:
https://drafts.csswg.org/css-ui-3/#changes
          * All changes are fairly minor: mostly clarifications, and
              some small tweaks to align the spec with implementation
          * All testable / normative changes since last CR have tests
              updates or additions, linked to from the changes section.
          * The test suite is (IMO) sufficiently complete for REC
              advancement purposes.
          * The pass rate of the test suite meets CR exit criteria:
              https://test.csswg.org/harness/results/css-ui-3_dev/grouped/
              (minus one test, which is pending the next build of the
              test-suite builder, and will be fine once that happens)
          * Implementation report:
https://drafts.csswg.org/css-ui-3/implementation-report
          * The DoC is up to date:
https://drafts.csswg.org/css-ui-3/issues-2017-2
       ]

  <Rossen> https://drafts.csswg.org/css-ui-3/implementation-report
  Rossen: florian sent an email yesterday summarizing state. There are
          no issues open, changes are up to date. Test suite is, in
          his opinion, meeting exit criteria. There is an
          implementation report ^
  <Rossen> https://drafts.csswg.org/css-ui-3/issues-2017-2
  Rossen: DoC is up to date.

  florian: Clarification. Since I wrote this there was a new test
           using box-sizing with grid. That test has bugs and isn't
           passing, but since it's grid I don't think we need to take
           it into account. Test isn't fail/pass it's just buggy.
  Rossen: Is the test necessary?
  <Chris> mark the test as optional
  florian: No, it's just linked because it uses box-sizing. I just
           wanted to clarify.
  Rossen: Reasonable.
  Chris: florian I suggest we mark the test as optional.
  florian: It's not optional for grid.
  florian: We can't mark it as optional just for UI.
  Chris: Okay. Then we just have to explain in the request.
  florian: I'll update the impl report to mention that.

  Chris: Everything looks great. Are there substantive changes since
         last CR?
  florian: Yes, there are some. I think that we might not have to
           cycle CR, but that's a judgment.
  Chris: My preference would be assemble a proposed PR and if it fails
         cycle CR.
  Rossen: Okay, that sounds great.
  Rossen: Are there any reasons why we shouldn't take this to a PR?
  Rossen: Chris any reasons?
  Chris: Nope.
  tantek: We should do it.
  Rossen: Not hearing objections.

  RESOLVED: Take CSS UI 3 to PR.

  Rossen: Congrats to editors and all involved.
  florian: Thanks tantek for giving me the shoulders to stand on to
           get this done.
  tantek: Thanks for all the work for the tests.
  florian: Chris will you work with me on requests?
  Chris: Yes. You notice I've been doing them as markdown. Is that
         okay?
  florian: Yes.
  Chris: I'll give you the checklist after the call.

  tantek: Do we have a PR template?
  tantek: The markdown template, is there a blank?
  Chris: No. That's a good idea.

  Rossen: There was a tag on topic to this summary about UI 4.
  florian: UI 4 was a delta over 3, but since 3 is kinda done I merged
           in the 3 stuff to L4. I also caught up on pending actions
           and warnings on unstable sections. I think that warrants a
           2nd public WD. Should we?
  Chris: Go for it.
  Rossen: Objections?

  RESOLVED: Take CSS UI 4 to an updated WD.

  florian: Two follow-ups on this topic.
  florian: Should we switch unversioned prefix to be L4?
  Rossen: I don't see why we wouldn't.
  Rossen: CSS UI 4 will be the currently worked on.
  tantek: Do we have a policy of when we do that switch?
  Chris: We don't. We do it when the current one worked on switches.
  plinss: Policy is what's considered current. Someone looking for the
          first time, where do they look.
  Rossen: 3 isn't intended to move so 4 is the current.
  plinss: It's no longer a delta.
  florian: Yeah.
  plinss: Then it should be 4.
  tantek: It's reasonable to do at same time as PR request.
  florian: A resolution on that would be nice.

  RESOLVED: Re-point CSS UI link to CSS UI 4 spec.

  <plinss> (switch css-ui to css-ui-4 done)

  florian: Last, there is one thing in CSS UI that doesn't really
           belong. It's box-sizing. It's a patch over from CSS2.1.
           Some other spec should cover that...it should go into css
           sizing I think. Once that happens we can remove the patch
           from L4. For now it will be there, but I think other
           editors should look into doing this.
  tantek: That's a long standing request.
  florian: I think it was waiting for this patch to get to REC so it's
           a decent time to start looking at that.
  tantek: We looked at the permalinking.
  florian: Keep the section heading, but if a non-patch version starts
           to exist I can point there.
  plinss: No one should use unversioned short paths for permalinks.
  tantek: Is there a github?
  florian: No, but I'll make one.

Flexbox
-------

  Rossen: Moving on. Flexbox testing.
  Rossen: There was a bunch of work by gregwhitworth and company. I
          called for volunteers last week. I don't think there were
          updates. gregwhitworth can you summarize what you need help
          with?
  gregwhitworth: Melanie offered, but it would help for there to be
                 more people. I opened all the issues about
                 non-trivial stuff on github. At somebody's leisure
                 they could start squashing those. Melanie and I have
                 started pivoting in that direction. They are where
                 they should live. If you can do any part of if and
                 submit a PR it helps me out.
  Chris: I can try and help depending on what else I have to do.
  Rossen: Thank you Chris.

  Rossen: gregwhitworth You said you needed help with bucketizing?
  gregwhitworth: No, I sent it to the list yesterday.
  <gregwhitworth>
https://github.com/w3c/web-platform-tests/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20%5Bcss-flex%5D%5Bspec-rec%5D
  gregwhitworth: I bucketized the non-trivial ones. I need to do some
                 trivial stuff but these are the buckets of tests we
                 need. If you can help, please self-assign and
                 describe what you're going to do. These are the 6
                 categories of areas we need help.
  gregwhitworth: Reach out to me if you have questions or update it on
                 the thread.
  Rossen: Thank you gregwhitworth for this awesome work and thanks
          Chris for volunteering.

Fonts 3
-------

  Rossen: Next and final is Fonts.
  Chris: What's happened is there are a few sections marked as at
         risk. Some may need to move, some we're not sure. Seems
         worthwhile to update the spec that was last published in 2013
         so people know things are at risk. Means if we drop moving to
         PR we're good.
  Chris: I believe changes list is up to date. Maybe need to mention
         more on OM stuff.
  myles: I thought it was, but you're probably right I need to make
         another pass.
  Chris: I think it's just putting it in the changes section.
  myles: Sure. And if we republish I'll need help.
  Chris: Right.
  Rossen: Is this CR or WD?
  Chris: Updated CR with technical changes?
  Rossen: When will you be ready?
  Chris: I'll leave it to myles.
  myles: End of the week.
  Chris: Ping me when you're ready and I can send the request.

  Rossen: But you want a resolution.
  Chris: Yes, please.
  Rossen: Objections to publish a new Fonts 3 CR spec?

  RESOLVED: Publish a new Fonts 3 CR

  Rossen: Thank you chris and myles for all the awesome work.

HTML
====

Change default <sup> and <sub> styling?
---------------------------------------
  github: https://github.com/w3c/csswg-drafts/pull/1888

  Rossen: Anyone want to take this? florian and dbaron were involved,
          I know. Or myles.
  myles: I can summarize.
  myles: In HTML there's <sup> and <sub> that are defined in UA
         stylesheet to do vertical align and reduce font size. Now
         that open type fonts are available it may be that there are
         specific information in the font for this.
  myles: Issue proposes we change UA style sheet to turn on the font
         features.
  * tantek is going to go out on a limb and say there are likely major
           compat issues with touching this
  <tantek> perhaps experiment with MathML super/subscripts first?

  fantasai: Problem with this is that it doesn't handle anything that
            is nested so if you have any elements inside it like
            something to an exponent and the exponent has an exponent
            in it the feature won't work. So this breaks cases that
            would have worked.
  fantasai: We had when designing font variant feature it was decided
            not to do that which is why font spec doesn't recommend
            this as a replacement. Given that's the case we should
            advise HTML to not make this change.
  <tantek> fantasai's answer makes sense and would likely make a good
           FAQ in the spec.

  florian: I followed up trying to make a hybrid using font features
           for first level and then fallback for nesting. I'm not sure
           it handles all cases. If people want to keep investigating
           if we can write such rules maybe we can look into that. I'm
           not confident it's sufficient.
  Chris: I think it's a good approach. The PR is sent for tests for
         CSS 3 fonts actually mentions that. I think it's better to
         make the single level of nesting use the open type feature
         which will give you a better result in the common and if
         you're complex maybe you should use MathML.
  dbaron: I don't think...I think what chris suggests for top level
          won't work if the font metrics are inaccurate which is
          common. There's no guarantee it'll work or that a subscript
          will align anywhere correct so you could distinguish the
          super script of a superscript.
  florian: I think it works mostly.
  dbaron: It depends on how well the font metrics match the characters.
  fantasai: It also doesn't handle images in the subscript so I think
            there's a lot of things that will break.

  myles: First, I'd like to agree with fantasai and dbaron. Apart from
         that we would like some ability for the UA to use the glyphs
         if it can figure out the right way. We don't think this
         proposal is sufficient, but it is possible for a UA to use
         these glyphs. This proposal isn't the right way but we'd like
         some sort of affordance in the future.
  fantasai: But that would require new CSS features. We've discussed
            that in the past and people didn't want to do it. We can
            re-open those discussions. We should close this request
            and say you can't do that, but if you want to make a bug
            against Fonts 4 or 5 to make this possible you can do that.
  myles: I agree. This isn't the right place but the goal is noble.
  fantasai: We appreciate the effort to incorporate better typography,
            but this isn't the right place and it's not able to handle
            it currently.
  Rossen: Any other comments or suggestions?
  Rossen: If not we can close with fantasai's suggested rec.

  tantek: A couple of comments. I would suspect that changing this for
          sub and sup it will break compat in unpredictable ways
          since those tags have been used so long.
  tantek: Second question is, I didn't see a URL to a test case that
          demos what this would look like old vs new style. I think at
          a minimum we need that to consider this proposal.
  <fantasai> tantek's got a good point
  * bradk agrees with tantek, just didn’t want to beat a dead horse
  Rossen: Anyone have a test case or code that can demo this side by
          side?
  Rossen: I don't hear any. We can go back to the issue and wait for
          the people discussing it to see if anything will come
          through.

  fantasai: I think tantek has a good point about how this has been
            used a long time. People have tweaked their style sheet to
            make these tags look better and may be relying on
            vertical-align or font-size cascading through. We will
            break pages if we try and change the default stylesheet.
  * bradk always changes font-size, vertical-align, and relative
          position in order to “fix” SUPs
  fantasai: That will apply to any case where we try and make things
            better unless it's really automagic.

  Rossen: Anything else on this topic?

CSS Text Decor
==============

ink skipping should conform to glyph shape
------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1093

  <Rossen> illustration https://twitter.com/TobiReif/status/839809400529383424
  fantasai: There was a complaint about how implementations, when they
            cut off the underline they cut off in a straight line. You
            don't want the underline to stop with a blunt edge and
            then have a gap between glyph edges, you want it to follow
            the edges of the glyph.
  fantasai: The spec doesn't say anything specific so I was thinking
            we could have advice, you should have underline edges hug
            the glyph.
  fantasai: There was a concern on performance which is why I'm
            suggesting a should. An implementation could decide to do
            it if font size is large enough, but not in general case.
            That would resolve a lot of performance considerations. I
            think spec should offer this advice.
  <fantasai> https://www.ietf.org/rfc/rfc2119.txt
  <fantasai> proposed text: "stroke endings should follow the curve of
             the glyph"

  myles: You can have a description of good typography. There's more
         to good underlining then having it follow contours of glyph.
         You'll want a larger explanation of good typography of
         underlines and that doesn't feel like it should be a
         normative description. It feels another spec or note.
  florian: Are they big enough that they cannot be phrased as shoulds?
  florian: Do you think it's too high level for normative?
  myles: Yeah.
  myles: If you're going to have a couple paragraphs on good
         typography it shouldn't be normative.

  Rossen: I'm hearing one proposal for adding the should which
          suggests how a good typography works for underlining and I
          heard some push back on why is this normative and not
          informative somewhere.
  dbaron: One comment on myles' statement. I don't want to get into a
          situation where you need to be an expert in other fields to
          impl the spec. The spec ought to say what you need to do to
          impl. If there's advice on good typography that should be
          known by an impl it should be on the WG to have that as part
          of the behavior the spec describes.
  myles: I think the spec does that as is.
  fantasai: It describes certain necessary things. We'd like the
            impl...given the option we'd say yes you should have the
            curve follow the glyph curve. What follow means, you have
            to think about that, but that's why we shouldn't be over
            specific. That's why we word things with an appropriate
            level of specificity so you know what to do.
  myles: Point I was trying to make...for example if the spec says
         underline should follow contour of glyph and implementors
         could use mask-base and then you have underlines in the curve
         of the g and that's worse typography. If you're going to have
         this it needs to be much longer. If it's a general of how
         underlines should work...
  fantasai: Typography is very broad. If you want more description on
            ways you can mess this up, that's fine. Typography of
            underlines in general is out of scope for this.
  myles: Right. Doing this..
  fantasai: It's not out of scope for the spec. L4 has the ability to
            adjust underline and will have much more detail. This
            topic isn't position, this is where you don't draw a line.
            A description here should assume position and thickness
            was chosen already.
  myles: I'm not talking position and thickness.
  <dbaron> If the spec says "use the position and thickness specified
           in the font metrics" then position and thickness aren't
           something that implementors need to think about

  Rossen: myles is your push back on adding this statement very strong
          or is this something you can live with?
  myles: I'm not going to object.
  Rossen: Okay. And fantasai if this was a non-normative note would
          you be okay or would you prefer the should?
  fantasai: I'd prefer the should so it's clear to implement this is
            the behavior that we want. We can add a note saying
            there's things you need to watch out for and if myles
            wants to point out anything not in the issue when doing
            the note I can add that.
  Rossen: In summary you propose to add the stroke of the underline
          should follow the curve of the glyph. That's the text?
  fantasai: Yes and a note to address myles's concerns.
  myles: We should also add a picture because the one in the spec is
         2px tall.
  fantasai: Good idea. We can have some of those Gs.
  dbaron: Will the note have the thing about maybe doing it only at
          large font sizes?
  fantasai: I can do that.
  <tantek> "large" = when it uses a lot of physical pixels
  <fantasai> probably px units is appropriate here, as resolutions
             increase we don't want to be doing it for paragraph-size
             text

  Rossen: Proposed resolution: add the statement that stroke should
          follow the curve of the glyph as well as adding a
          non-normative note that points out anything captured in the
          Github issue and add better pictures.

  RESOLVED: Add the statement that stroke should follow the curve of
            the glyph as well as adding a non-normative note that
            points out anything captured in the Github issue and add
            better pictures.

CSS Grid
========

Percentages and intrinsic size
------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/509

  Rossen: mats added a quick explanation of what Mozilla's back
          computation looks like for grid-gap.
  <rego> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-334075296
  Rossen: I want to ask if anyone is prepared to speak to this issue.
  Rossen: If not we can push to next week or F2F.
  rego: Last week we said we'd leave for TPAC. We need more
        implementors. We resolved that we should back compute, but
        anyway it needs a lot further discussion.
  Rossen: I agree. It sounds like...I don't see in last week's
          resolution we'll discuss for F2F. I'll tag for F2F and
          remove the agenda+ for weekly calls.
  Rossen: I propose we switch topics if there are any.

F2F Meetings
============

  Rossen: If there's no other topics we can end early or we can
          discuss mid-2018 F2F.
  Rossen: Are we ready to discuss mid-2018 F2F meeting?
  Rossen: If not we can push this off.
  tantek: I'd like thoughts on that.

  Rossen: The last discussions were about Google hosting either at
          Australia or Toronto.
  <tantek> +1 to both
  ericwilligers: We thought we were picking Sydney and dates the week
                 of July 2nd
  <nainar> I'm not on the call. But what ericwilligers said.
  ericwilligers: Do we need to wait for someone to confirm?
  Rossen: We did pick dates, but there was an open question as to if
          Toronto was still on the table. That's my recollection. If
          we agree it's Sydney week of July 2 we can put that on the
          record and go with it.
  ericwilligers: That's my understanding.
  Rossen: I see nainar confirmed on IRC that's the proposal.
  Rossen: Objections to having mid-2018 meeting held week of July 2nd
          in Sydney with Google as host?
  <tantek> for some reason I recall August, but ok with July
  <nainar> I would say lets lock in July 2nd week for Sydney.
  <tantek> note US Holiday July 4th
  <tantek> just a note, no objection :)

  RESOLVED: Have the mid-2018 meeting held week of July 2nd in Sydney
            with Google as host.

  Rossen: Any 4 minute topics?
  Rossen: Thank you everyone and thanks Google to host us mid-2018.
          We'll talk next week.
  <nainar> Rossen happy to host! :)
  Rossen: Please remember to add agenda, book travel, book
          accommodation for F2F.
  Rossen: Remember next week is different time.
  <dbaron> next week's call will also be an hour earlier for Europeans
           than other APAC calls
  <dbaron> since Europe will have changed off summer time, but the US
           won't

Polyfill and meeting

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • October 25, 2017 • Permalink

Hi,



First of all, my apologies since I’m not available tomorrow/today for the
meeting since I’m travelling to a conference.



The good news is that I’ve not been idle and I’ve added two further
examples to the polyfill:

1.     Matrix alignment with fences
2.     Grammar analysis (language subject)

Unfortunately, I’m travelling and I’m not able to update the examples
online. The old version is still available at:
https://codepen.io/daniwiris/pen/rGKENd



>From the current examples, I learnt that the minimum requirements are to be
able to align respect to a given child in the following two scenarios:

1.     A vertical flexbox
2.     A table or grid

For the table, the alignment is only well defined when the affected row
(the children of tables are rows) has all its cells aligned by the
baseline, which is already possible to do with the current CSS
specification. Things are a little more disgusting because tables contain
an extra tbody element…



Despite these minimal requirements, I implemented a version of the polyfill
that is able to align a flexbox or table according to any of its
descendants using a CSS like selector. It is fine to have such
functionality but maybe we are overkilling the solution.



I used the handy selectionQuery method in JavaScript which seemed an ideal
solution until I discovered that selectionQuery never returned the node I
expected when multiple nodes satisfied the criteria. For example,
“:nth-child(2)” actually means any second child of any successor.



Another idea is that probably makes more sense defining the “baseline” than
change the “vertical-align”. Thus,

Preferred solution:

            baseline: “:nth-child(2)”;

            vertical-align: “baseline”;

Less preferred solution:

             vertical-align: “:nth-child(2)”



I’ve also experimented with the stretchy solution. I think that it is great
but at the same time discovered that the browser does not render in the
same form normal text than scaled one (we already saw that in Peter’s
demo). This yields, again, that the different parts do not match perfectly.
For example, the minus sign had different weight when zoomed horizontally.
So the theory that this is a solution for perfect fraction lines is not
true. I’m not worried about that. Eventually we could blame the browsers
and they might fix it from their side.


I'm still with the idea of going to TPAC. But I'm not satisfied with the
current polyfill status.


Regards,


Dani

-- 

------------------------------
WIRIS and Design Science, makers of MathType, have joined forces!
Thank you for your patience as we transition from dessci.com to wiris.com.

[MathOnWeb] Reminder: Meeting today

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • October 12, 2017 • Permalink

Hi everyone,

A uick reminder that we are scheduled to meet today, Oct 12, 12pm Eastern
time on appear.in.

We'll focus on polyfill ideas for layout (e.g., Dani's vertical align,
MathJax v3's new approach to stretchy) .

Best,
Peter.

Vertical align polyfil

Source: public-mathonwebpages@w3.org Mail Archives • Daniel Marques (dani@wiris.com) • October 12, 2017 • Permalink

HI,

Just uploaded the vertical-align polyfill to codepen.io
https://codepen.io/daniwiris/pen/rGKENd/

Tomorrow (or today depending on the time zone) during the meeting I would
appreciate any feedback!

Dani

-- 

------------------------------
WIRIS and Design Science, makers of MathType, have joined forces!
Thank you for your patience as we transition from dessci.com to wiris.com.

Setting and Getting Math Speech, Braille, UnicodeMath, LaTeX…

Source: Murray Sargent: Math in Office • MurrayS3 • September 28, 2017 • Permalink

This post augments the post Inserting and Getting Math Text in RichEdit by documenting the RichEdit options for ITextRange2::SetText2(options, bstr) and ITextRange2::GetText2(options, pbstr) including those for math speech and math braille. As such, this post is for programmers. But more generally, it reveals that RichEdit supports Nemeth math braille (!). All options work in the current Microsoft Office RichEdit (riched20.dll in an Office subdirectory); the Windows RichEdit (msftedit.dll) hasn’t exposed math functionality yet. The options are defined in the following table in which s/g stands for SetText2/GetText2. For convenience, non-math-specific flags are also included

Option Value s/g Meaning
tomUnicodeBiDi 0x00000001 s Use Unicode BiDi algorithm for inserted text
tomAdjustCRLF 0x00000001 g If range start is inside multicode unit like CRLF, surrogate pair, etc., move to start of unit
tomUseCRLF 0x00000002 g Paragraph ends use CRLF (U+000D U+000A)
tomTextize 0x00000004 g Embedded objects export alt text; else U+FFFC
tomAllowFinalEOP 0x00000008 g If range includes final EOP, export it; else don’t
tomUnlink 0x00000008 s Disables link attributes if present
tomUnhide 0x00000010 s Disables hidden attribute if present
tomFoldMathAlpha 0x00000010 g Replace math alphanumerics with ASCII/Greek
tomIncludeNumbering 0x00000040 g Lists include bullets/numbering
tomCheckTextLimit 0x00000020 s Only insert up to text limit
tomDontSelectText 0x00000040 s After insertion, call Collapse(tomEnd)
tomTranslateTableCell 0x00000080 g Export spaces for table delimiters
tomNoMathZoneBrackets 0x00000100 g Used with tomConvertUnicodeMath and tomConvertTeX. Set discards math zone brackets
tomLanguageTag 0x00001000  s/gg Sets BCP-47 language tag for range; gets tag
tomConvertRTF 0x00002000  s/g Set or get RTF
tomGetTextForSpell 0x00008000 g Export spaces for hidden/math text, table delims
tomConvertMathML 0x00010000  s/g Set or get MathML
tomGetUtf16 0x00020000 g Causes tomConvertRTF, etc. to get UTF-16. SetText2 accepts 8-bit or 16-bit RTF
tomConvertLinearFormat 0x00040000  s/g Alias for tomConvertUnicodeMath
tomConvertUnicodeMath 0x00040000  s/g UnicodeMath
tomConvertOMML 0x00080000  s/g Office MathML
tomConvertMask 0x00F00000  s/g Mask for mutually exclusive modes
tomConvertRuby 0x00100000 s See Inserting and Getting Math Text…
tomConvertTeX 0x00200000  s/g See LaTeX Math in Office
tomConvertMathSpeech 0x00300000 g Math speech (English only here)
tomConvertSpeechTokens 0x00400000 g Simple Unicode and speech tokens
tomConvertNemeth 0x00500000  s/g Nemeth math braille in U+2800 block
tomConvertNemethAscii 0x00600000 g Corresponding ASCII braille
tomConvertNemethNoItalic 0x00700000 g Nemeth braille in U+2800 block w/o math italic
tomConvertNemethDefinition 0x00800000 g Fine-grained speech in braille
tomConvertCRtoLF 0x01000000 g Plain-text paragraphs end with LF, not CRLF
tomLaTeXDelim 0x02000000 g Use LaTeX math-zone delimiters \(...\) inline, \[...\] display; else $...$, $$...$$. Set handles all

 

Mutually exclusive options

Nonzero values within the mask defined by tomConvertMask (0x00F00000) are mutually exclusive, that is, they cannot be combined (OR’d) with one another. These options include setting text as UnicodeMath, [La]TeX (tomConvertTeX), and Nemeth math braille (tomConvertNemeth). You can set only one at a time. But other options can be OR’d in if desired.

Nemeth math braille options

A string bstr of Nemeth math braille coded in the Unicode range U+2800..U+283F can be inserted and built up by calling ITextRange2::SetText2(tomConvertNemeth, bstr). If the string is valid, you can get it back in any of the math formats including Nemeth math braille. For example, if you insert the string

⠹⠂⠌⠆⠨⠏⠼⠮⠰⠴⠘⠆⠨⠏⠐⠹⠨⠈⠈⠙⠨⠹⠌⠁⠬⠃⠀⠎⠊⠝⠀⠨⠹⠼⠀⠨⠅⠀⠹⠂⠌⠜⠁⠘⠆⠐⠤⠃⠘⠆⠐⠻⠼

you see

You can also input braille with a standard keyboard by typing a control word \braille assigned to the Unicode character U+24B7 (Ⓑ). (See LaTeX Math in Office for how to add commands to math autocorrect). The \braille command causes math input to accept braille input via a regular keyboard using the braille ASCII codes sometimes referred to as North American Braille Computer Codes. The character ~ (U+007E) disables this input mode. These braille codes are described in the post Nemeth Braille—the first math linear format and can be input using refreshable braille displays. Alternatively, such input can be automated by calling ITextSelection::TypeText(bstr). Just as in entering UnicodeMath, the equations build up on screen as soon as the math braille input becomes unambiguous. The implementation includes the math braille UI that cues the user where the insertion point is for unambiguous editing of math zones using braille. Note that as of this posting, the math braille facility isn’t hooked up to Narrator or other screen readers.

Getting (and Setting?) Math Speech

The tomConvertMathSpeech currently only gets math speech in English. Microsoft Office apps like Word, PowerPoint and OneNote deliver math speech in over 18 languages to the assistive technology (AT) program Narrator via the UIA ITextRangeProvider::GetText() function. Other ATs could also get math speech this way. Dictating (setting) math speech would be nice for both blind and sighted folks. Imagine, you can say a² + b² = c² faster than you can type it or write it! The SetText2(tomConvertMathSpeech, bstr) is ready to handle such input, but it’s not implemented yet anyhow.

 

[MathOnWeb] skip meeting Sept 28 / next meeting Oct 12

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • September 28, 2017 • Permalink

Hi MathOnWebCG,

Due to several regrets we suggest to skip today's meeting.

The next meeting will be on Oct 12.

I suspect "recent news" will be a sufficient topic for the next meeting but
please suggest another one if you prefer.

Best wishes,
Peter.

[mathonweb] Reminder: Meeting today

Source: public-mathonwebpages@w3.org Mail Archives • Peter Krautzberger (peter@krautzource.com) • September 14, 2017 • Permalink

Hi everyone,

We are scheduled to meet today, Sept 14, 12pm Eastern time.

Best,
Peter.

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