Tabular columns in mathmode (for .html and others)

[cmhughes]

When we write code like the following in .xml

          <table xml:id="exp-tab-salary">
            <caption/>
                    <tgroup tabletype="S[table-format=2.0]S[table-format=10.0]">
                        <thead>
                          <row><entry><m>d</m> (days worked)</entry><entry><m>p</m> (cents)</entry></row>
                        </thead>
                        <tbody>
                          <row><entry>1  </entry><entry>2         </entry></row> 
                          <row><entry>2  </entry><entry>4         </entry></row>
                          <row><entry>3  </entry><entry>8         </entry></row>
                          <row><entry>4  </entry><entry>16        </entry></row>
                          <row><entry>5  </entry><entry>32        </entry></row>
                          <row><entry>10 </entry><entry>1024      </entry></row>
                          <row><entry>30 </entry><entry>1073741824</entry></row>
                      </tbody>
                    </tgroup>
                </table>

we translate into .tex and receive

\begin{tabular}{S[table-format=2.0]S[table-format=10.0]}
\beforeheading 
\heading{$d$ (days worked)}&\heading{$p$ (cents)}\\
\afterheading 
1  &2         \\\normalline
2  &4         \\\normalline
3  &8         \\\normalline
4  &16        \\\normalline
5  &32        \\\normalline
10 &1024      \\\normalline
30 &1073741824\\\lastline
\end{tabular}

The .tex version uses the siunitx package which automatically puts each entry into mathmode. The .html version isn't quite as clever--any ideas on how we can fix this?

One possible (clumsy, heavy) solution is to put each entry into a new tag, perhaps <cm> for 'conditional mathmode' which would do nothing in the .tex version, and put the entry into mathmode for .html and other versions. In such a scheme the above snippet might look like, for example,

<row><entry><cm>1</cm> </entry><entry><cm>2</cm> </entry></row> <row><entry><cm>2</cm> </entry><entry><cm>4</cm> </entry></row>

This raises a more general question: when we hit questions/issues such as this, should we stop until they're resolved, or just plough forward?

[Alex-Jordan]

I'm sure it's wiser to resolve them. However sometimes I think if we
resolve them too quickly, we don't get a really good solution; just one
that hacks our current problem.

I don't think Scolumns are math mode. I could be wrong, but I think that
an S column assumes the entries are arguments for \num{}. Is that not
right?

For the bigger picture, we should aim to keep the xml philosophy. What is
it that we actually want: a column that is decimal aligned and centered in
a nice way.

How about something like this:

<table>
<caption />
<tgroup>
<coltypes>
 <col type=centered>  (or less verbose)
 <col type=left-aligned>
 <col type=decimal-aligned>
</coltypes>
.<thead>
...
</thead>
<tbody>
...
</tbody>
</tgroup>
</table>

For the tex side, this would be easy to implement.

For the HTML side, when it gets to the ..., for each ...,can we
execute loops based on what what in ? Surely this should be
possible if we store the info in an array or a hash. If so,
then we can get decimal alignment (what we really want out of S column)
using something like the answer to this
http://stackoverflow.com/questions/1363239/aligning-decimal-points-in-html.

Am I off target? I'm not in a position where I can experiment.

On Tue, Dec 30, 2014 at 6:23 AM, cmhughes notifications@github.com wrote:

When we write code like the following in .xml

      <table xml:id="exp-tab-salary">
        <caption/>
                <tgroup tabletype="S[table-format=2.0]S[table-format=10.0]">
                    <thead>
                      <row><entry><m>d</m> (days worked)</entry><entry><m>p</m> (cents)</entry></row>
                    </thead>
                    <tbody>
                      <row><entry>1  </entry><entry>2         </entry></row>
                      <row><entry>2  </entry><entry>4         </entry></row>
                      <row><entry>3  </entry><entry>8         </entry></row>
                      <row><entry>4  </entry><entry>16        </entry></row>
                      <row><entry>5  </entry><entry>32        </entry></row>
                      <row><entry>10 </entry><entry>1024      </entry></row>
                      <row><entry>30 </entry><entry>1073741824</entry></row>
                  </tbody>
                </tgroup>
            </table>

we translate into .tex and receive

\begin{tabular}{S[table-format=2.0]S[table-format=10.0]}
\beforeheading
\heading{$d$ (days worked)}&\heading{$p$ (cents)}
\afterheading
1 &2 \normalline
2 &4 \normalline
3 &8 \normalline
4 &16 \normalline
5 &32 \normalline
10 &1024 \normalline
30 &1073741824\lastline
\end{tabular}

The .tex version uses the siunitx package which automatically puts each
entry into mathmode. The .html version isn't quite as clever--any ideas
on how we can fix this?

One possible (clumsy, heavy) solution is to put each entry into a new tag,
perhaps for 'conditional mathmode' which would do nothing in the .tex
version, and put the entry into mathmode for .html and other versions. In
such a scheme the above snippet might look like, for example,

1 2
2 4

This raises a more general question: when we hit questions/issues such as
this, should we stop until they're resolved, or just plough forward?

—
Reply to this email directly or view it on GitHub
#10.

Alex Jordan
Mathematics Instructor
Portland Community College

[cmhughes]

I think you're right about siunitx columns--the \num argument sounds more
accurate.

I also like your idea about the idea; looping in xsl seems
interesting so far, but I think you're absolutely right about keeping the
xml philosophy, and using a hybrid of LaTeX column types seems unnatural in
this context.

On Tue, Dec 30, 2014 at 3:26 PM, Alex Jordan notifications@github.com
wrote:

I'm sure it's wiser to resolve them. However sometimes I think if we
resolve them too quickly, we don't get a really good solution; just one
that hacks our current problem.

I don't think Scolumns are math mode. I could be wrong, but I think
that
an S column assumes the entries are arguments for \num{}. Is that not
right?

For the bigger picture, we should aim to keep the xml philosophy. What is
it that we actually want: a column that is decimal aligned and centered in
a nice way.

How about something like this:

<table>
<caption />
<tgroup>
<coltypes>
<col type=centered> (or less verbose)
<col type=left-aligned>
<col type=decimal-aligned>
</coltypes>
.<thead>
...
</thead>
<tbody>
...
</tbody>
</tgroup>
</table>

For the tex side, this would be easy to implement.

For the HTML side, when it gets to the ..., for each ...,can we
execute loops based on what what in ? Surely this should be
possible if we store the info in an array or a hash. If so,
then we can get decimal alignment (what we really want out of S column)
using something like the answer to this
<
http://stackoverflow.com/questions/1363239/aligning-decimal-points-in-html>.

Am I off target? I'm not in a position where I can experiment.

On Tue, Dec 30, 2014 at 6:23 AM, cmhughes notifications@github.com
wrote:

When we write code like the following in .xml

d (days worked)p (cents)1 2 2 4 3 8 4 16 5 32 10 1024 30 1073741824

we translate into .tex and receive

\begin{tabular}{S[table-format=2.0]S[table-format=10.0]}
\beforeheading
\heading{$d$ (days worked)}&\heading{$p$ (cents)}
\afterheading
1 &2 \normalline
2 &4 \normalline
3 &8 \normalline
4 &16 \normalline
5 &32 \normalline
10 &1024 \normalline
30 &1073741824\lastline
\end{tabular}

The .tex version uses the siunitx package which automatically puts each
entry into mathmode. The .html version isn't quite as clever--any ideas
on how we can fix this?

One possible (clumsy, heavy) solution is to put each entry into a new
tag,
perhaps for 'conditional mathmode' which would do nothing in the
.tex
version, and put the entry into mathmode for .html and other versions.
In
such a scheme the above snippet might look like, for example,

1 2
2 4

This raises a more general question: when we hit questions/issues such
as
this, should we stop until they're resolved, or just plough forward?

—
Reply to this email directly or view it on GitHub
#10.

Alex Jordan
Mathematics Instructor
Portland Community College

—
Reply to this email directly or view it on GitHub
#10 (comment).

[cmhughes]

I think you're absolutely right for us to try to resolve issues as we go; the siunitx issue in MathJax looks like it is gaining traction with a few people (citing the link you posted previously, mathjax/MathJax#447).

Of course, we want to keep our xml robust enough to work in other formats as well, so siunitx syntax may not be robust enough for us for, e.g, ePUB..... So, at what point do we want to try to commit to an idea around an si xml tag? For the moment, I'm inclined to keep going with the siunitx syntax--perhaps ideas will come to us naturally?

_{PS: happy new year!}

[Alex-Jordan]

How about the following, perhaps too verbose:

Reverse engineer \num{15} to:

Reverse engineer \si{\kilo\gram} to:

Reverse engineer \si{\kilo\gram\squared} to:

Reverse engineer \SI{15}{\kilo\gram\meter\squared\per\second\squared} to

So quant (quantity) is the element, with attributes:
n = number part
u = unit's numerator part, an array of arrays, with each array having three
parts, an optional prefix, base unit, and optional power
per = similar, for denominator

Separately, we have siunitx's S column to deal with.

On Wed, Dec 31, 2014 at 7:10 PM, cmhughes notifications@github.com wrote:

I think you're absolutely right for us to try to resolve issues as we go;
the siunitx issue in MathJax looks like it is gaining traction with a few
people (citing the link you posted previously, mathjax/MathJax#447
mathjax/MathJax#447).

Of course, we want to keep our xml robust enough to work in other formats
as well, so siunitx syntax may not be robust enough for us for, e.g,
ePUB..... So, at what point do we want to try to commit to an idea around
an si xml tag? For the moment, I'm inclined to keep going with the siunitx
syntax--perhaps ideas will come to us naturally?

PS: happy new year!

—
Reply to this email directly or view it on GitHub
#10 (comment).

Alex Jordan
Mathematics Instructor
Portland Community College

[cmhughes]

I like the syntax you're suggesting, it makes a lot of sense. The only part of it that worries me is the implementation (!)....

If we go down this route of re-building an siunit-style syntax, should we re-build all of the other LaTeX syntax as well, e.g \frac{1}{2}? Or is that a separate issue?

[cmhughes]

I've been working on a prototype, but I've slightly modified your syntax....

How do you feel about:

 <quant n="15" />
<quant u="kilo;gram;meter;" />
<quant u="kilo:1;gram:2;meter:3;" />

I've used a colon (:) to separate units from their exponent, and
semi-colons (;) to separate units. Would you be ok with this?

Will we ever need more than one 'per' statement?

On Thu, Jan 1, 2015 at 1:45 AM, Alex Jordan notifications@github.com
wrote:

How about the following, perhaps too verbose:

Reverse engineer \num{15} to:

Reverse engineer \si{\kilo\gram} to:

Reverse engineer \si{\kilo\gram\squared} to:

Reverse engineer \SI{15}{\kilo\gram\meter\squared\per\second\squared} to

So quant (quantity) is the element, with attributes:
n = number part
u = unit's numerator part, an array of arrays, with each array having
three
parts, an optional prefix, base unit, and optional power
per = similar, for denominator

Separately, we have siunitx's S column to deal with.

On Wed, Dec 31, 2014 at 7:10 PM, cmhughes notifications@github.com
wrote:

I think you're absolutely right for us to try to resolve issues as we
go;
the siunitx issue in MathJax looks like it is gaining traction with a
few
people (citing the link you posted previously, mathjax/MathJax#447
mathjax/MathJax#447).

Of course, we want to keep our xml robust enough to work in other
formats
as well, so siunitx syntax may not be robust enough for us for, e.g,
ePUB..... So, at what point do we want to try to commit to an idea
around
an si xml tag? For the moment, I'm inclined to keep going with the
siunitx
syntax--perhaps ideas will come to us naturally?

PS: happy new year!

—
Reply to this email directly or view it on GitHub
#10 (comment).

Alex Jordan
Mathematics Instructor
Portland Community College

—
Reply to this email directly or view it on GitHub
#10 (comment).

[Alex-Jordan]

No, I'm not suggesting anything that would affect any math mode content. I'm treating \SI{}{} and \si{}{} as non-math mode commands. Occasionally they are used in math mode, but that's actually the easy part. For that, all we have to do is give custom definitions to things like \kilo and \gram in the MathJax configuration, and the HTML side will fake siunitx support for \SI{}{} and \si{}. The hard part is using units outside of math mode.

In HTML, as long as siunitx remains unsupported by MathJax, we would produce direct typesetting of a nice looking "15 kg m". For starters, just putting an unbreakable thinspace between the number and between any units would be great. If there is a per, I'd start with putting u in superscript, then a $frasl;, then the per part in subscript, like <sup>kg m</sup>&frasl;<sub>s<sup>2</sup></sub>. I'd be content to leave it until later to make it look any nicer than that.

I'm not sure about <quant u="kilo:1;gram:2;meter:3;" /> though. What is the 1 for after kilo? Unit prefixes would never get exponents, so this could be confusing. And while this is nice because it is compact, I'm not sure it's easy to parse out the components of the string and use them in the right way.

It looks like you can work with arrays in xml. I wish I had time right now to see this through, but I can't until at least next weekend. My reading so far makes me think we can get 15 kg m / s^2 like:

<quant mag="15">
  <unit prefix="kilo" base="gram" />
  <unit base="meter" />
  <per base="second" exp="2" />
</quant>

and we can treat unit as an array with (in this case) two items. Each unit gets its prefix-base-exponent glued together in the right way, then put a thin, unbreakable space between units. If there are more than 0 per items, do the same for them and do something to make a fraction (like the superscript/subscript example above).

[cmhughes]

Thanks for the clarification, you've certainly helped to highlight the
issues, and your last example is very helpful.

I belies that my current prototype isn't inline with what you've described,
but putting it together should help me with implementing something along
the lines of your last example.

We should be able to check if quant is being used outside of math mode, and
add it appropriately as necessary.

On Friday, January 2, 2015, Alex Jordan notifications@github.com wrote:

No, I'm not suggesting anything that would affect any math mode content.
I'm treating \SI{}{} and \si{}{} as non-math mode commands. Occasionally
they are used in math mode, but that's actually the easy part. For
that, all we have to do is give custom definitions to things like \kilo and
\gram in the MathJax configuration, and the HTML side will fake siunitx
support for \SI{}{} and \si{}. The hard part is using units outside of
math mode.

In HTML, as long as siunitx remains unsupported by MathJax, we would
produce direct typesetting of a nice looking "15 kg m". For starters, just
putting an unbreakable thinspace between the number and between any units
would be great. If there is a per, I'd start with putting u in
superscript, then a $frasl;, then the per part in subscript, like ^kg
m⁄_s². I'd be content to leave it until
later to make it look any nicer than that.

I'm not sure about though. What is
the 1 for after kilo? Unit prefixes would never get exponents, so this
could be confusing. And while this is nice because it is compact, I'm not
sure it's easy to parse out the components of the string and use them in
the right way.

It looks like you can work with arrays in xml. I wish I had time right now
to see this through, but I can't until at least next weekend. My reading so
far makes me think we can get 15 kg m / s^2 like:

and we can treat unit as an array with (in this case) two items. Each unit
gets its prefix-base-exponent glued together in the right way, then put a
thin, unbreakable space between units. If there are more than 0 per
items, do the same for them and do something to make a fraction (like the
superscript/subscript example above).

—
Reply to this email directly or view it on GitHub
#10 (comment).

[cmhughes]

If you get a chance, do you think you could have a look at the latest commits (starting from 53d18c7)?

If you run

xsltproc xsl/omd2tex.xsl chapters/mainfile.xml

you should see the following output:

\typeout{************************************************}
\typeout{Chapter 1}
\typeout{************************************************}
%
\chapter{}
%
test  ??magnitude needed?? 
%
\par test  \num{42} 
%
\par test  \SI{42}{\kilo\gram\meter} 
%
\par test  \si{\kilo\gram\meter\per\second\tothe{2}} 
%
\par test  \SI{13}{\kilo\gram\tothe{-23}\meter\per\second\tothe{2}} 

I believe that this is what we want. I certainly appreciate that I haven't tackled the html version, but is the markup in mainfile.xml as you would like it? (I believe I've followed your description above....)

[Alex-Jordan]

I can confirm that output, and the syntax is what I was thinking. I did mean to ask you though, do you think it would be better if unit were shortened to u and per were shortened to p?

However there are some issues. We'd want it to work in the same way regardless of what order units and pers are declared. But if I put a per before a unit, it breaks, as with

<quant><per base="gram" prefix="kilo"/><unit base="meter" /><per base="second" exp="2" /></quant>

Also it broke if there was a per but no unit, as with

<quant mag="42"><per base="gram" prefix="kilo"/></quant>

Note: I looked into treating per as a unit with \tothe{} taking a negative power, but siunitx does not handle that in the way we would want. I mean, if you have per-mode=fraction, \gram\tothe{-1} is not handled the same as \per\gram.

Note: siunitx doesn't actually care if \per items come before numerator items.

Overall: I think you need to modify your code to not only look for presence of unit children, but also of per children.

[Alex-Jordan]

Also, I have an outline in my head for the HTML side. I just need some time to get it down. But if you would like to try something in the meantime, please do.

Note: when units are showing up within a math element like <m /> or <me />, we should just directly use things like \SI{42}{\meter\per\second}. Even if the MathJax is not supporting siunitx right now, we can define simpler versions of all of the relevant commands in the MathJax configuration. And if siunitx becomes supported in the future, we can just remove those parts from our config.

So it's just when units are showing up in text mode that we have significant xsl construction to work on.

[cmhughes]

Thanks for the test cases--it hadn't occured to me that per might come before unit, or indeed without a unit. I've added your test cases and fixed them in 945da77

I did mean to ask you though, do you think it would be better if unit were shortened to u and per were shortened to p? *

I think I would vote in favour of using unit and per; I appreciate that it seems more verbose, but I think that their 'full-name versions' may make the xml easier to read....? Having <p></p> tag would conflict with the paragraph tag (of course, it doesn't matter from the xml/xslt perpesctive). I'm not too worried either way, so if you have a preference for <p> and <u>, we can certainly go for it.

Also, I have an outline in my head for the HTML side. I just need some time to get it down. But if you would like to try something in the meantime, please do.

I'm very happy to leave this for you--my main focus is to get the xml mark-up to a point at which we're happy to keep moving forward with chapter generation.

[cmhughes]

You've probably just started term, so this subscription e-mail might not be welcome (hope you're filtering them!), but when you get a moment, have a look at 75357be

If you run

xsltproc xsl/omd2html.xsl chapters/mainfile.xml

then you should get test.html which should display an html page that contains the following table:

What do you think? Most importantly, is the .xml the kind of syntax that you would like? The xsl is not as important to me at the moment....

The adaption to omd2tex.xsl should be trivial.

[cmhughes]

The latest commits give the following output in test.html:

It does so using only one span element; you can see what it's doing by adding border: solid red 2px; to the span.left element in css/omd.css:

The idea is to make a span element that has length $integerPart+.5+$fractionalPartLength where $fractionalPartLength is the length of the string after the decimal.

In contrast to the two-span element idea (in previous commits), this allows the cell entry to be put in one, clean MathJax element :)