openmathdocs / precalc

Modelling-based approach to pre-calculus materials: exponential, logarithmic, polynomial, rational, piecewise-defined, and trigonometric functions; transformations and composition of functions; parametric curves. Emphasizing the rule of four: graphically, numerically, verbally, and algebraically
0 stars 1 forks source link

Do we need the <tgroup> node? #11

Closed cmhughes closed 9 years ago

cmhughes commented 9 years ago

Our table elements seem to contain <tgroup> nodes--do we actually need them? We have thead and tbody which make perfect sense, but I'm struggling to see why we would need tgroup, but perhaps I've missed something?

Alex-Jordan commented 9 years ago

I believe that in Rob's scheme, <table /> corresponds to a LaTeX table environment, and <tgroup /> corresponds to a tabular environment. <tgroup /> is where he defines column types (in a too-simple way for our needs). <table /> contains the caption, etc.

I think <tgroup /> could be configured to alternately produce tabular* and tabularx environments too.

Alex-Jordan commented 9 years ago

But I see how it seems irrelevant in html.

In the tex side, I envision: <table> \begin{table}\centering <caption />\caption{} <tgroup> \begin{tabular} or a variant of tabular depending on attributes <coltypes> { <col /> crS[], etc </coltypes> } <thead> <row>...</row> header formatting on elements </thead> </tbody> <row>...</row> body formatting on elements <row>...</row> body formatting on elements </tbody> </tfoot> <row>...</row> footer formatting on elements </tfoot> </tgroup> \end{tabular} </table> \end{table}

And on the html side: <table> -> <table> <caption /> -> <caption /> <tgroup> -> does nothing <coltypes> -> <colgroup> <col /> -> <col /> uses CSS to control formatting within a column </coltypes> -> </colgroup> <thead> <row>...</row> -> header formatting on elements </thead> </tbody> <row>...</row> -> body formatting on elements <row>...</row> -> body formatting on elements </tbody> </tfoot> <row>...</row> -> footer formatting on elements </tfoot> </tgroup> -> does nothing </table> -> </table>

cmhughes commented 9 years ago

Thanks for the follow-up.

It sounds like we're agreed that tgroup does nothing in html. I'd actually like to make a case that tgroup does nothing in .tex as well.

We have a lot of different ways of putting tables into our .tex:

one table on its own

\begin{table}[!htb]
\centering
table code
\end{table}

two tables, side by side

\begin{table}[!htb]
\begin{minipage}{<width>}
\centering
table code
\end{minipage}
\begin{minipage}{<width>}
\centering
table code
\end{minipage}
\end{table}

table next to a figure

\begin{table}[!htb]
\begin{minipage}{<width>}
\centering
table code
\end{minipage}
\begin{minipage}{<width>}
\centering
figure code
\end{minipage}
\end{table}

subtables next to each other

\begin{table}[!htb]
\begin{subtable}{<width>}
\centering
table code
\end{subtable}
\begin{subtable}{<width>}
\centering
table code
\end{subtable}
\end{table}

If you have a look at exponentialfunctions.xml you'll see that we have encountered most of these cases already. I dealt with them by introducing <multobjects> which stands for multiple objects; it allows us to put tables next to each other; tables next to figures; subtables; subfigures; the numbering and cross referencing works as expected.

I think that Rob's original intention was to do this using the tgroup element, but there was a comment in the code saying that he was unsure how to deal with multiple tables: <!-- Unclear how to handle *multiple* tgroups in latex -->.

The multobjects approach makes sense to me, but I'm certainly open to other ideas. Have a look through exponentialfunctions.xml and its associated output, and let me know what you think.

Alex-Jordan commented 9 years ago

I'll keep thinking about it. One thing that occurs to me is what would we do if we ever want a (very small, of course) nonfloating piece of tabular material?

Also, have you looked at what I did for margin tables? I think that needs revising. It's only a "margin table" in the tex side, at least right now. Would it be a "margin table" for html too? Would it be in a frame off to the side? Or should it be called something different and handled differently?

On Sun, Jan 11, 2015 at 4:24 AM, cmhughes notifications@github.com wrote:

Thanks for the follow-up.

It sounds like we're agreed that tgroup does nothing in html. I'd actually like to make a case that tgroup does nothing in .tex as well.

We have a lot of different ways of putting tables into our .tex: one table on its own

\begin{table}[!htb] \centering table code \end{table}

two tables, side by side

\begin{table}[!htb] \begin{minipage}{} \centering table code \end{minipage} \begin{minipage}{} \centering table code \end{minipage} \end{table}

table next to a figure

\begin{table}[!htb] \begin{minipage}{} \centering table code \end{minipage} \begin{minipage}{} \centering figure code \end{minipage} \end{table}

subtables next to each other

\begin{table}[!htb] \begin{subtable}{} \centering table code \end{subtable} \begin{subtable}{} \centering table code \end{subtable} \end{table}

If you have a look at exponentialfunctions.xml you'll see that we have encountered most of these cases already. I dealt with them by introducing

which stands for multiple objects; it allows us to put tables next to each other; tables next to figures; subtables; subfigures; the numbering and cross referencing works as expected. I think that Rob's original intention was to do this using the tgroup element, but there was a comment in the code saying that he was unsure how to deal with multiple tables: . The multobjects approach makes sense to me, but I'm certainly open to other ideas. Have a look through exponentialfunctions.xml and its associated output, and let me know what you think. — Reply to this email directly or view it on GitHub https://github.com/openmathdocs/precalc/issues/11#issuecomment-69492727.

Alex Jordan Mathematics Instructor Portland Community College

cmhughes commented 9 years ago

I've actually come up against the non-floating piece already as figures in solutions don't float; this particular instance was easy to deal with using an ancestor check. A general non-floating table (that just used a tabular) could be achieved using an attribute, say <table no-float="true"> or something similar; a more sophisticated approach might check for the presence of a caption child node.

I believe I modified margintable and marginfigure to have the syntax <figure style="margin"> and <table style="margin">. In the .tex side, this puts it in the margin; in the html side, it currently does nothing.

I think the idea of putting a margin table it in the margin in html is a good one. The current html set-up has 3 columns; the toc is in the left, the body is in the middle, and the right column is currently unused. This right-hand column could be a good place for such 'floats'. I was thinking the right hand margin could also display figures/tables when referred to from links; for example, when we have sentences such as see Figure 1.3, instead of dragging the reader to the location of Figure 1.3, it would copy it into the right hand margin.

One of the many nice things about our approach is that as long as we're happy with the xml in the chapter file itself, it seems like the fine tweaking of the html and other behaviours can happen later.

Alex-Jordan commented 9 years ago

What does Rob use the 3rd column for?

Have you visited his book? When he refers something like a definition or an example that was pages away, you can click on the reference, and a knowl magically opens up with a copy of that content.

The winter SAC meeting is this week and I am going to make a pitch to adapt and then adopt his book for 261. I think it needs some application examples inserted, but passing that I'll be surprised if there is strong objection.

On Sun, Jan 11, 2015 at 10:18 AM, cmhughes notifications@github.com wrote:

I've actually come up against the non-floating piece already as figures in solutions don't float; this particular instance was easy to deal with using an ancestor check. A general non-floating table (that just used a tabular) could be achieved using an attribute, say

or something similar; a more sophisticated approach might check for the presence of a caption child node.

I believe I modified margintable and marginfigure to have the syntax <figure style="margin"> and

. In the .tex side, this puts it in the margin; in the html side, it currently does nothing.

I think the idea of putting a margin table it in the margin in html is a good one. The current html set-up has 3 columns; the toc is in the left, the body is in the middle, and the right column is currently unused. This right-hand column could be a good place for such 'floats'. I was thinking the right hand margin could also display figures/tables when referred to from links; for example, when we have sentences such as see Figure 1.3, instead of dragging the reader to the location of Figure 1.3, it would copy it into the right hand margin.

One of the many nice things about our approach is that as long as we're happy with the xml in the chapter file itself, it seems like the fine tweaking of the html and other behaviours can happen later.

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

Alex Jordan Mathematics Instructor Portland Community College

cmhughes commented 9 years ago

I've submitted a pull request to Rob's Mathbook, which has prompted the discussion here: https://groups.google.com/forum/#!topic/mathbook-xml-support/i6-S0j-wmkY

Closing this issue.