Closed cmhughes closed 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.
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>
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
:
\begin{table}[!htb]
\centering
table code
\end{table}
\begin{table}[!htb]
\begin{minipage}{<width>}
\centering
table code
\end{minipage}
\begin{minipage}{<width>}
\centering
table code
\end{minipage}
\end{table}
\begin{table}[!htb]
\begin{minipage}{<width>}
\centering
table code
\end{minipage}
\begin{minipage}{<width>}
\centering
figure code
\end{minipage}
\end{table}
\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.
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
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.
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 agoI'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.
Our
table
elements seem to contain<tgroup>
nodes--do we actually need them? We havethead
andtbody
which make perfect sense, but I'm struggling to see why we would needtgroup
, but perhaps I've missed something?