the `\num` issue

[cmhughes]

I think that we introduced \num{3/4} from the siunitx package. I'm not sure how easy this is to handle with MathJax or with other outputs.

Should we create a new xml tag called <num> and translate it accordingly? Would this mean that we would need a fraction tag as well?

[Alex-Jordan]

I've been doing that regarding \num. Sorry I haven't pushed recently. I'll take care of that now.

And sorry for the clutter, but I've been using omdchapter2tex.xsl, where I have made . omdchapter2tex.xsl leaves out preamble stuff, since we are still using our original hub file.

I've been having trouble compartmentalizing. Should we eliminate our hub file, and put its components into omd2tex.xsl?

How do we compartmentalize our chapter files properly? I've been thinking that instead of basing our progress on Rob's sample, which is not a book, we should look into how his source files for his book are structured.

Regarding siunitx, I'm not sure what to do long term. But I do know that people are interested in a MathJax extension that handles siunitx commands: https://github.com/mathjax/MathJax/issues/447. Is it too much to hope that one will come about before we are done? If such a thing is built, we could keep using siunitx for now. In math mode, MathJax would handle it. Outside of math mode, we still have siunitx functionality to consider. \num{}, \si{}, \SI{}{}, and the S column are things I am aware of where siunitx is in play outside of math mode. Perhaps make xml tags for the first 3? No idea what to do about S columns - I've asked Rob what we can do to have a wider breadth of table possibilities: https://groups.google.com/forum/?fromgroups#!forum/mathbook-xml-support

On Sat, Dec 6, 2014 at 1:04 PM, cmhughes notifications@github.com wrote:

I think that we introduced \num{3/4} from the siunitx package. I'm not sure how easy this is to handle with MathJax or with other outputs.

Should we create a new xml tag called and translate it accordingly? Would this mean that we would need a fraction tag as well?

— Reply to this email directly or view it on GitHub https://github.com/openmathdocs/precalc/issues/5.

Alex Jordan Mathematics Instructor Portland Community College

[cmhughes]

Lots of good questions for us to try and answer :)

I don't believe that we should eliminate the hub file, at least not yet. I think that this xml approach is very helpful for generating chapter content, but less useful for mode-specific content. For example, knowls don't exist in a pdf format, but are very useful in html format.

I think that we should continue to use siunitx--I didn't mean to suggest that we stop using it. My only question is, how do we handle it in html? For example, let's say that we wrote something like:

<m><num><fraction numerator="1" denominator="3"/></num></m>

We would like to translate this into .tex as $\num{1/3}$ and into html as something like $\frac{1}{3}$. If we were to adopt a process like this, it would be robust enough to handle any updates in the future, such as a MathJax extension for SIunits.

What do you think?

[Alex-Jordan]

I don't believe that we should eliminate the hub file, at least not yet. I think that this xml approach is very helpful for generating chapter content, but less useful for mode-specific content. For example, knowls don't exist in a pdf format, but are very useful in html format.

For that specific example of knowls, you can see what Rob does. The knowls content is just there in the pdf without anything special about it. I want to spend some time with Rob's book before I think too much more about this. There is probably wisdom in what he has done, and we just can't see it because so far at lest, I've only been looking at his sample document, which is not the book class.

I think that we should continue to use siunitx--I didn't mean to suggest

that we stop using it. My only question is, how do we handle it in html? For example, let's say that we wrote something like:

We would like to translate this into .tex as $\num{1/3}$ and into html as something like $\frac{1}{3}$. If we were to adopt a process like this, it would be robust enough to handle any updates in the future, such as a MathJax extension for SIunits.

MathJax can't currently handle siunitx commands, so the MathJax siunitx combos will render on screen with red errors. I'm (perhaps foolishly) optimistic that siunitx support from MathJax will eventually exist, although maybe without its full spectrum of capabilities. But minimally, these three macros and the macros they make use of should some day have support.

I'd suggest the following. See what you think. Suppose \num{1/2} of a \si{\kilo\gram} is \SI{1/2}{\kilo\gram}

is a sentence from our original tex source. In xml source, write it as <num syntax="siunitx">1/2</num> of a <unit syntax="siunitx">\kilo\gram</unit> is <quantity syntax="siunitx" unit="\kilo\gram">1/2</quantity>

and basically keep it true to the siunitx syntax. We know what to do with this for the mod2tex.xsl. And in html, we know what to do with siunitx macros that are inside math mode, assuming future siunitx support from MathJax.

For html, for content not in math mode, for now, encase these things in math mode anyway with a text mode inside that, and pass the buck to MathJax. Each instance of , etc, can detect if it is nested inside a parent tag. If it is, don't put more math delimiters. If it is not, do put it all inside $\text{...}$ or something similar.

Since I've put the syntax="siunitx" in there, in the future we could do something more true to the philosophy of using xml that would not assume siunitx syntax.

So that's my thoughts for now. It's perhaps lazy, but I don't want to go down a rabbit hole early on, trying to reinvent siunitx things at the xml level.

On Sat, Dec 6, 2014 at 1:54 PM, cmhughes notifications@github.com wrote:

Lots of good questions for us to try and answer :)

I don't believe that we should eliminate the hub file, at least not yet. I think that this xml approach is very helpful for generating chapter content, but less useful for mode-specific content. For example, knowls don't exist in a pdf format, but are very useful in html format.

I think that we should continue to use siunitx--I didn't mean to suggest that we stop using it. My only question is, how do we handle it in html? For example, let's say that we wrote something like:

We would like to translate this into .tex as $\num{1/3}$ and into html as something like $\frac{1}{3}$. If we were to adopt a process like this, it would be robust enough to handle any updates in the future, such as a MathJax extension for SIunits.

What do you think?

— Reply to this email directly or view it on GitHub https://github.com/openmathdocs/precalc/issues/5#issuecomment-65915632.

Alex Jordan Mathematics Instructor Portland Community College

[Alex-Jordan]

Oh, how about eliminating ... and ..., and instead just having:

without the ... structure? If num or unit are empty, use \si{} or \num{}, and if they are both nonempty use \SI{}{}.

Future work could provide alternatives for syntax="siunitx".

On Sat, Dec 6, 2014 at 2:27 PM, Alex Jordan alex.jordan@pcc.edu wrote:

I don't believe that we should eliminate the hub file, at least not yet. I

think that this xml approach is very helpful for generating chapter content, but less useful for mode-specific content. For example, knowls don't exist in a pdf format, but are very useful in html format.

For that specific example of knowls, you can see what Rob does. The knowls content is just there in the pdf without anything special about it. I want to spend some time with Rob's book before I think too much more about this. There is probably wisdom in what he has done, and we just can't see it because so far at lest, I've only been looking at his sample document, which is not the book class.

I think that we should continue to use siunitx--I didn't mean to suggest

that we stop using it. My only question is, how do we handle it in html? For example, let's say that we wrote something like:

We would like to translate this into .tex as $\num{1/3}$ and into html as something like $\frac{1}{3}$. If we were to adopt a process like this, it would be robust enough to handle any updates in the future, such as a MathJax extension for SIunits.

MathJax can't currently handle siunitx commands, so the MathJax siunitx combos will render on screen with red errors. I'm (perhaps foolishly) optimistic that siunitx support from MathJax will eventually exist, although maybe without its full spectrum of capabilities. But minimally, these three macros and the macros they make use of should some day have support.

I'd suggest the following. See what you think. Suppose \num{1/2} of a \si{\kilo\gram} is \SI{1/2}{\kilo\gram}

is a sentence from our original tex source. In xml source, write it as <num syntax="siunitx">1/2</num> of a <unit syntax="siunitx">\kilo\gram</unit> is <quantity syntax="siunitx" unit="\kilo\gram">1/2</quantity>

and basically keep it true to the siunitx syntax. We know what to do with this for the mod2tex.xsl. And in html, we know what to do with siunitx macros that are inside math mode, assuming future siunitx support from MathJax.

For html, for content not in math mode, for now, encase these things in math mode anyway with a text mode inside that, and pass the buck to MathJax. Each instance of , etc, can detect if it is nested inside a parent tag. If it is, don't put more math delimiters. If it is not, do put it all inside $\text{...}$ or something similar.

Since I've put the syntax="siunitx" in there, in the future we could do something more true to the philosophy of using xml that would not assume siunitx syntax.

So that's my thoughts for now. It's perhaps lazy, but I don't want to go down a rabbit hole early on, trying to reinvent siunitx things at the xml level.

On Sat, Dec 6, 2014 at 1:54 PM, cmhughes notifications@github.com wrote:

Lots of good questions for us to try and answer :)

I don't believe that we should eliminate the hub file, at least not yet. I think that this xml approach is very helpful for generating chapter content, but less useful for mode-specific content. For example, knowls don't exist in a pdf format, but are very useful in html format.

I think that we should continue to use siunitx--I didn't mean to suggest that we stop using it. My only question is, how do we handle it in html? For example, let's say that we wrote something like:

We would like to translate this into .tex as $\num{1/3}$ and into html as something like $\frac{1}{3}$. If we were to adopt a process like this, it would be robust enough to handle any updates in the future, such as a MathJax extension for SIunits.

What do you think?

— Reply to this email directly or view it on GitHub https://github.com/openmathdocs/precalc/issues/5#issuecomment-65915632.

Alex Jordan Mathematics Instructor Portland Community College

Alex Jordan Mathematics Instructor Portland Community College

[cmhughes]

Both suggestions sound great to me, and managable too :) It seems like the main philosophy is to have the xml make sense, and do the heavy lifting in the xsl translation.

With the latest version of functions.xml, I see that table numeration and cross referencing has gone to pot--I hope to have a look at this today.

On Sat, Dec 6, 2014 at 11:13 PM, Alex Jordan notifications@github.com wrote:

Oh, how about eliminating ... and ..., and instead just having:

without the ... structure? If num or unit are empty, use \si{} or \num{}, and if they are both nonempty use \SI{}{}.

Future work could provide alternatives for syntax="siunitx".

On Sat, Dec 6, 2014 at 2:27 PM, Alex Jordan alex.jordan@pcc.edu wrote:

I don't believe that we should eliminate the hub file, at least not yet. I

think that this xml approach is very helpful for generating chapter content, but less useful for mode-specific content. For example, knowls don't exist in a pdf format, but are very useful in html format.

For that specific example of knowls, you can see what Rob does. The knowls content is just there in the pdf without anything special about it. I want to spend some time with Rob's book before I think too much more about this. There is probably wisdom in what he has done, and we just can't see it because so far at lest, I've only been looking at his sample document, which is not the book class.

I think that we should continue to use siunitx--I didn't mean to suggest

that we stop using it. My only question is, how do we handle it in html? For example, let's say that we wrote something like:

We would like to translate this into .tex as $\num{1/3}$ and into html as something like $\frac{1}{3}$. If we were to adopt a process like this, it would be robust enough to handle any updates in the future, such as a MathJax extension for SIunits.

MathJax can't currently handle siunitx commands, so the MathJax siunitx combos will render on screen with red errors. I'm (perhaps foolishly) optimistic that siunitx support from MathJax will eventually exist, although maybe without its full spectrum of capabilities. But minimally, these three macros and the macros they make use of should some day have support.

I'd suggest the following. See what you think. Suppose \num{1/2} of a \si{\kilo\gram} is \SI{1/2}{\kilo\gram}

is a sentence from our original tex source. In xml source, write it as <num syntax="siunitx">1/2</num> of a <unit syntax="siunitx">\kilo\gram</unit> is <quantity syntax="siunitx" unit="\kilo\gram">1/2</quantity>

and basically keep it true to the siunitx syntax. We know what to do with this for the mod2tex.xsl. And in html, we know what to do with siunitx macros that are inside math mode, assuming future siunitx support from MathJax.

For html, for content not in math mode, for now, encase these things in math mode anyway with a text mode inside that, and pass the buck to MathJax. Each instance of , etc, can detect if it is nested inside a parent tag. If it is, don't put more math delimiters. If it is not, do put it all inside $\text{...}$ or something similar.

Since I've put the syntax="siunitx" in there, in the future we could do something more true to the philosophy of using xml that would not assume siunitx syntax.

So that's my thoughts for now. It's perhaps lazy, but I don't want to go down a rabbit hole early on, trying to reinvent siunitx things at the xml level.

On Sat, Dec 6, 2014 at 1:54 PM, cmhughes notifications@github.com wrote:

Lots of good questions for us to try and answer :)

I don't believe that we should eliminate the hub file, at least not yet. I think that this xml approach is very helpful for generating chapter content, but less useful for mode-specific content. For example, knowls don't exist in a pdf format, but are very useful in html format.

I think that we should continue to use siunitx--I didn't mean to suggest that we stop using it. My only question is, how do we handle it in html? For example, let's say that we wrote something like:

We would like to translate this into .tex as $\num{1/3}$ and into html as something like $\frac{1}{3}$. If we were to adopt a process like this, it would be robust enough to handle any updates in the future, such as a MathJax extension for SIunits.

What do you think?

— Reply to this email directly or view it on GitHub https://github.com/openmathdocs/precalc/issues/5#issuecomment-65915632.

Alex Jordan Mathematics Instructor Portland Community College

Alex Jordan Mathematics Instructor Portland Community College

— Reply to this email directly or view it on GitHub https://github.com/openmathdocs/precalc/issues/5#issuecomment-65918525.

[Alex-Jordan]

What do you mean about table numeration going to pot? I should say that I have not been following the html side. Maybe we have a merge issue? I had been working on functions.xml locally, and yesterday I fetched and merged, and there were two merge conflicts. One was where you had done something with \num differently than I had. The other looked to me to just be a change in indentation. I took my version of the first, and your version of the second. But I did not see any merge conflicts elsewhere. Still, did my version somehow overwrite progress you had made?

On Sun, Dec 7, 2014 at 12:17 AM, cmhughes notifications@github.com wrote:

Both suggestions sound great to me, and managable too :) It seems like the main philosophy is to have the xml make sense, and do the heavy lifting in the xsl translation.

With the latest version of functions.xml, I see that table numeration and cross referencing has gone to pot--I hope to have a look at this today.

On Sat, Dec 6, 2014 at 11:13 PM, Alex Jordan notifications@github.com wrote:

Oh, how about eliminating ... and ..., and instead just having:

without the ... structure? If num or unit are empty, use \si{} or \num{}, and if they are both nonempty use \SI{}{}.

Future work could provide alternatives for syntax="siunitx".

On Sat, Dec 6, 2014 at 2:27 PM, Alex Jordan alex.jordan@pcc.edu wrote:

I don't believe that we should eliminate the hub file, at least not yet. I

think that this xml approach is very helpful for generating chapter content, but less useful for mode-specific content. For example, knowls don't exist in a pdf format, but are very useful in html format.

For that specific example of knowls, you can see what Rob does. The knowls content is just there in the pdf without anything special about it. I want to spend some time with Rob's book before I think too much more about this. There is probably wisdom in what he has done, and we just can't see it because so far at lest, I've only been looking at his sample document, which is not the book class.

I think that we should continue to use siunitx--I didn't mean to suggest

that we stop using it. My only question is, how do we handle it in html? For example, let's say that we wrote something like:

We would like to translate this into .tex as $\num{1/3}$ and into html as something like $\frac{1}{3}$. If we were to adopt a process like this, it would be robust enough to handle any updates in the future, such as a MathJax extension for SIunits.

MathJax can't currently handle siunitx commands, so the MathJax siunitx combos will render on screen with red errors. I'm (perhaps foolishly) optimistic that siunitx support from MathJax will eventually exist, although maybe without its full spectrum of capabilities. But minimally, these three macros and the macros they make use of should some day have support.

I'd suggest the following. See what you think. Suppose \num{1/2} of a \si{\kilo\gram} is \SI{1/2}{\kilo\gram}

is a sentence from our original tex source. In xml source, write it as <num syntax="siunitx">1/2</num> of a <unit syntax="siunitx">\kilo\gram</unit> is <quantity syntax="siunitx" unit="\kilo\gram">1/2</quantity>

and basically keep it true to the siunitx syntax. We know what to do with this for the mod2tex.xsl. And in html, we know what to do with siunitx macros that are inside math mode, assuming future siunitx support from MathJax.

For html, for content not in math mode, for now, encase these things in math mode anyway with a text mode inside that, and pass the buck to MathJax. Each instance of , etc, can detect if it is nested inside a parent tag. If it is, don't put more math delimiters. If it is not, do put it all inside $\text{...}$ or something similar.

Since I've put the syntax="siunitx" in there, in the future we could do something more true to the philosophy of using xml that would not assume siunitx syntax.

So that's my thoughts for now. It's perhaps lazy, but I don't want to go down a rabbit hole early on, trying to reinvent siunitx things at the xml level.

On Sat, Dec 6, 2014 at 1:54 PM, cmhughes notifications@github.com wrote:

Lots of good questions for us to try and answer :)

I don't believe that we should eliminate the hub file, at least not yet. I think that this xml approach is very helpful for generating chapter content, but less useful for mode-specific content. For example, knowls don't exist in a pdf format, but are very useful in html format.

I think that we should continue to use siunitx--I didn't mean to suggest that we stop using it. My only question is, how do we handle it in html? For example, let's say that we wrote something like:

We would like to translate this into .tex as $\num{1/3}$ and into html as something like $\frac{1}{3}$. If we were to adopt a process like this, it would be robust enough to handle any updates in the future, such as a MathJax extension for SIunits.

What do you think?

— Reply to this email directly or view it on GitHub < https://github.com/openmathdocs/precalc/issues/5#issuecomment-65915632>.

Alex Jordan Mathematics Instructor Portland Community College

Alex Jordan Mathematics Instructor Portland Community College

— Reply to this email directly or view it on GitHub https://github.com/openmathdocs/precalc/issues/5#issuecomment-65918525.

— Reply to this email directly or view it on GitHub https://github.com/openmathdocs/precalc/issues/5#issuecomment-65930250.

Alex Jordan Mathematics Instructor Portland Community College

[cmhughes]

I saw the merge conflict too, but as you say, I don't think it was anything serious; you didn't overwrite anything :)

The table numbers are currently reset every subsection, so in the current version of functions.html you'll see that there are two Table 1s. The hyperlinks are also getting a bit crazy because our examples and definitions are not enumerated.

I'm working on a fix--I'm part way there, and hope to push something soon. Of course, if you get there first so much the better :)

On Sunday, December 7, 2014, Alex Jordan notifications@github.com wrote:

What do you mean about table numeration going to pot? I should say that I have not been following the html side. Maybe we have a merge issue? I had been working on functions.xml locally, and yesterday I fetched and merged, and there were two merge conflicts. One was where you had done something with \num differently than I had. The other looked to me to just be a change in indentation. I took my version of the first, and your version of the second. But I did not see any merge conflicts elsewhere. Still, did my version somehow overwrite progress you had made?

On Sun, Dec 7, 2014 at 12:17 AM, cmhughes <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

Both suggestions sound great to me, and managable too :) It seems like the main philosophy is to have the xml make sense, and do the heavy lifting in the xsl translation.

With the latest version of functions.xml, I see that table numeration and cross referencing has gone to pot--I hope to have a look at this today.

On Sat, Dec 6, 2014 at 11:13 PM, Alex Jordan <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

Oh, how about eliminating ... and ..., and instead just having:

without the ... structure? If num or unit are empty, use \si{} or \num{}, and if they are both nonempty use \SI{}{}.

Future work could provide alternatives for syntax="siunitx".

On Sat, Dec 6, 2014 at 2:27 PM, Alex Jordan <alex.jordan@pcc.edu javascript:_e(%7B%7D,'cvml','alex.jordan@pcc.edu');> wrote:

I don't believe that we should eliminate the hub file, at least not yet. I

think that this xml approach is very helpful for generating chapter content, but less useful for mode-specific content. For example, knowls don't exist in a pdf format, but are very useful in html format.

For that specific example of knowls, you can see what Rob does. The knowls content is just there in the pdf without anything special about it. I want to spend some time with Rob's book before I think too much more about this. There is probably wisdom in what he has done, and we just can't see it because so far at lest, I've only been looking at his sample document, which is not the book class.

I think that we should continue to use siunitx--I didn't mean to suggest

that we stop using it. My only question is, how do we handle it in html? For example, let's say that we wrote something like:

We would like to translate this into .tex as $\num{1/3}$ and into html as something like $\frac{1}{3}$. If we were to adopt a process like this, it would be robust enough to handle any updates in the future, such as a MathJax extension for SIunits.

MathJax can't currently handle siunitx commands, so the MathJax siunitx combos will render on screen with red errors. I'm (perhaps foolishly) optimistic that siunitx support from MathJax will eventually exist, although maybe without its full spectrum of capabilities. But minimally, these three macros and the macros they make use of should some day have support.

I'd suggest the following. See what you think. Suppose \num{1/2} of a \si{\kilo\gram} is \SI{1/2}{\kilo\gram}

is a sentence from our original tex source. In xml source, write it as <num syntax="siunitx">1/2</num> of a <unit syntax="siunitx">\kilo\gram</unit> is <quantity syntax="siunitx" unit="\kilo\gram">1/2</quantity>

and basically keep it true to the siunitx syntax. We know what to do with this for the mod2tex.xsl. And in html, we know what to do with siunitx macros that are inside math mode, assuming future siunitx support from MathJax.

For html, for content not in math mode, for now, encase these things in math mode anyway with a text mode inside that, and pass the buck to MathJax. Each instance of , etc, can detect if it is nested inside a parent tag. If it is, don't put more math delimiters. If it is not, do put it all inside $\text{...}$ or something similar.

Since I've put the syntax="siunitx" in there, in the future we could do something more true to the philosophy of using xml that would not assume siunitx syntax.

So that's my thoughts for now. It's perhaps lazy, but I don't want to go down a rabbit hole early on, trying to reinvent siunitx things at the xml level.

On Sat, Dec 6, 2014 at 1:54 PM, cmhughes <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

Lots of good questions for us to try and answer :)

I don't believe that we should eliminate the hub file, at least not yet. I think that this xml approach is very helpful for generating chapter content, but less useful for mode-specific content. For example, knowls don't exist in a pdf format, but are very useful in html format.

I think that we should continue to use siunitx--I didn't mean to suggest that we stop using it. My only question is, how do we handle it in html? For example, let's say that we wrote something like:

We would like to translate this into .tex as $\num{1/3}$ and into html as something like $\frac{1}{3}$. If we were to adopt a process like this, it would be robust enough to handle any updates in the future, such as a MathJax extension for SIunits.

What do you think?

— Reply to this email directly or view it on GitHub < https://github.com/openmathdocs/precalc/issues/5#issuecomment-65915632>.

Alex Jordan Mathematics Instructor Portland Community College

Alex Jordan Mathematics Instructor Portland Community College

— Reply to this email directly or view it on GitHub < https://github.com/openmathdocs/precalc/issues/5#issuecomment-65918525>.

— Reply to this email directly or view it on GitHub https://github.com/openmathdocs/precalc/issues/5#issuecomment-65930250.

Alex Jordan Mathematics Instructor Portland Community College

— Reply to this email directly or view it on GitHub https://github.com/openmathdocs/precalc/issues/5#issuecomment-65930713.

[cmhughes]

Just to clarify--the table numeration wasn't any fault of either of us or our merging, it was from omd2html.xsl. I've fixed it in https://github.com/openmathdocs/precalc/commit/72ea02bc197023cfa7b614c3a37c9b12ad540fe5 together with the hyperlink-anchor creation issue.

You probably know these commands already, but I thought I'd put some useful git commands here, for my reference for the future:

git show 72ea02bc197023cfa7b614c3a37c9b12ad540fe5 xsl/omd2html.xsl

will show the differences in xsl/omd2html.xsl. I found this useful when looking at the changes that another user makes :)

There's also

git show --name-only 72ea02bc197023cfa7b614c3a37c9b12ad540fe5

and

 git show HEAD chapters/functions.xml

for example :)

[cmhughes]

<quantity syntax="sinuitx" num="1/2" unit="\kilo\gram" />

Or how about

<si num="1/2" unit="\kilo\gram" />

I wonder about the backslash....

[cmhughes]

I believe that this has been resolved as part of the quant feature, https://github.com/openmathdocs/mathbook/pull/2.

Closing this issue