Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

"decimalpoint" value definition #180

Open
NSoiffer opened this issue Dec 30, 2019 · 6 comments
Open

"decimalpoint" value definition #180

NSoiffer opened this issue Dec 30, 2019 · 6 comments
Labels
compatibility Issues affecting backward compatibility MathML 4 Issues affecting the MathML 4 specification need specification update Issues requiring specification changes

Comments

@NSoiffer
Copy link
Contributor

The MathML 3 spec says 'mstyle' defines a decimalpoint value (typically '.' or ','). That is used in 'maligngroup' and elementary math for decimal alignment. We have dropped it from core.

We have not made any decisions about mstyle in full, and perhaps decimalpoint can remain in it. However, I'm dubious about keeping about maligngroup and malignmark because AFAIK, only MathPlayer implemented those and no one uses it (it's way too complicated IMHO). That leaves the only use being elementary math and it is probably simpler (both in use and implementation) to add a decimalpoint attr to mstack than to support it in mstyle.

In writing this, I had thought that mtable supported decimal point as part of column alignment, but too my surprise it is only supported in 'maligngroup'. I don't remember why that omission. It is also not supported in CSS table alignment. It was maybe in HTML 4 but pulled from HTML 5 (see 'char' attr). There is a request to support something like in CSS from 2017, but that doesn't seem to be going anywhere. Maybe there is something else to address this in another CSS proposal?

Note: @davidcarlisle raised decimal point alignment in w3c/mathml-core#125, so it is slightly related to this issue.
@NSoiffer NSoiffer added compatibility Issues affecting backward compatibility MathML 4 Issues affecting the MathML 4 specification need resolution Issues needing resolution at MathML Refresh CG meeting need specification update Issues requiring specification changes labels Jan 2, 2020
@fred-wang fred-wang mentioned this issue Jan 21, 2020
Closed
@fred-wang fred-wang removed the need resolution Issues needing resolution at MathML Refresh CG meeting label Aug 12, 2020
@davidcarlisle
Copy link
Collaborator

Since this issue is raised th draf has simplified maliggroup and dropped the groupalign attribute.

https://w3c.github.io/mathml/#presm_ex_alignment_1

Still has the now invalid example

<mtable groupalign="{decimalpoint left left decimalpoint left left decimalpoint}">
  <mtr>
    <mtd>
      <mrow>
        <mrow>
          <mrow>
            <maligngroup/>
            <mn> 8.44 </mn>
            <mo> &#x2062;<!--InvisibleTimes--> </mo>
            <maligngroup/>
            <mi> x </mi>
          </mrow>
...

groupalign can be replaced by adding explicit <maligmark/> but I think ths requires

left : nothing needed(default)

right : Needs <maligmark/><mo/> with an empty following token

decimalpoint needs the <mn> splitting with aligment at . and the 8 right aligned against the . so I think it needs

<mrow>
<mrow intent="8.44"><maligngroup/><mn>8</mn><maligmark/><mo>.</mo><mn>44</mn></mrow>
 <maligngroup/>
 <mo> &#x2062;<!--InvisibleTimes--> </mo>
<mi> x </mi>
</mrow>

Is that OK or should we just drop the example?

@davidcarlisle
Copy link
Collaborator

@NSoiffer or we could re-allow <malignmark/> in token elements or (probably simpler) add groupalign back to (just) <maligngroup/> so you could do

          <mrow>
            <maligngroup groupalign="decimalpoint"/>
            <mn> 8.44 </mn>
            <mo> &#x2062;<!--InvisibleTimes--> </mo>
            <maligngroup/>
            <mi> x </mi>
          </mrow>

@davidcarlisle
Copy link
Collaborator

On further reflection, I think my above suggestions to re-complicate <maligngroup/> are wrong.

I think the plan was that aligned equations would not be supportable with <malignmark/> and we should use <mtd> cells for alignment and intent to hint at the equation structure.

That would suggest the example is

<!DOCTYPE html>
<html>
  <head>
  </head>
  <body>

   <math>
    <mtable columnspacing="0pt" displaystyle="true"
	    columnalign="right left left right left left right left">
      <mtr intent="equals(sum(times(8.44,$x),times(55,$y)),0)">
       <mtd><mn>8</mn></mtd>
       <mtd><mn>.44 </mn></mtd>
       <mtd><mi arg="x">x</mi><mo form="infix">+</mo></mtd>
       <mtd><mn>55</mn></mtd>
       <mtd></mtd>
       <mtd><mi arg="y">y</mi><mo form="infix">=</mo></mtd>
       <mtd><mn>0</mn></mtd>
       <mtd></mtd>
      </mtr>
      <mtr intent="equals(sum(times(3.1,$x),times(minus(0.7),$y)),minus(1.1))">
       <mtd><mn>3</mn></mtd>
       <mtd><mn>.1</mn></mtd>
       <mtd><mi arg="x">x</mi><mo form="infix">−</mo></mtd>
       <mtd><mn>0</mn></mtd>
       <mtd><mn>.7</mn></mtd>
       <mtd><mi arg="y">y</mi><mo>=</mo><mo form="infix">−</mo></mtd>
       <mtd><mn>1</mn></mtd>
       <mtd><mn>.1</mn></mtd>
      </mtr>
    </mtable>
   </math>

   <hr/>

   <img src="../image/alignat.png"/>

   <hr/>

   <pre>
\documentclass{article}
\usepackage{amsmath,stix2}
\begin{document}
\begin{alignat*}{5}
  8&amp;.44 &amp;&amp;x + {}&amp;55&amp;  &amp;&amp;y = {}&amp;0&amp;\\
  3&amp;.1  &amp;&amp;x - {}&amp;0&amp;.7 &amp;&amp;y = {}&amp;- 1&amp;.1 
\end{alignat*}
\end{document}
   </pre>
  </body>
</html>

Which renders in firefox as

image

Showing the structure is a more or less direct copy of the LaTeX structure used to generate the reference image in the spec.

this works in firefox but is not core due to columnalign=

If we go this way the example doesn't use <malign... at all so would need to move out of

https://w3c.github.io/mathml/#presm_using_malignmark

We could add it to the tables section of intent in chapter 5

https://w3c.github.io/mathml/#mixing_intent_examples_mtr

@NSoiffer
Copy link
Contributor Author

From an implementation standpoint, I think allowing malignmark in a token might be a little easier than supporting decimalpoint: just record the location of the malignmark when doing layout and then adjust. It is also a little more powerful since one can align on any char.

I see two big downsides for re-allowing maliignmark in tokens:

  • allowing markup in tokens makes implementations much uglier though. If mglyph is removed from full (it isn't in core), then that would be a huge simplification for implementers.
  • allowing it makes (in this case) numbers ugly, although striping them out is easy.

malignmark in tokens is less ugly than the table layout. That is not easily stripped and definitely requires intent to repair. But at least it doesn't make implementing token elements hard.

I think for now, I'll flag this issue with the example and after FPWD let's circle back because the all examples need to change for this section without a change to what's allowed.

@davidcarlisle
Copy link
Collaborator

@NSoiffer If it was just adding <maligmark/> to tokens it woud be a relatively small re-addition, but you also need to re-add right-aligned groups: in <mn>8<maligmark/>.44</mn> the 8 needs to right align towards the . So unless we can somehow make that automatic for malign-in-tokens you also need groupalign="right left right left right left" (which is the alignment used by all the latex math alignments such as align or flalign etc)

But just adding the issue ref to ths issue is OK for FPWD

@NSoiffer
Copy link
Contributor Author

At the meeting today, we agreed that if malignmark, etc., goes away (#181), then we can remove decimal alignment from mystyle. The only remaining decimal alignment is an attribute value of stackalign in elementary math, and that wouldn't be part of mstyle. Hence...

Status: awaiting resolution of #181.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compatibility Issues affecting backward compatibility MathML 4 Issues affecting the MathML 4 specification need specification update Issues requiring specification changes
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@fred-wang @davidcarlisle @NSoiffer