Align siunitx numbers in tabu
Martin Hehn
I am experiencing some issues with the following example. Numbers with
exponents are offset vertically to the "regular" numbers. Is anyone
aware of this problem?
\documentclass[parskip=half]{scrartcl}
\usepackage{siunitx}
\usepackage{tabu,booktabs}
\begin{document}
\newcolumntype Z{X[c,m]{%
S[%
tight-spacing = true,
round-mode=places,
round-precision=2,
]
}}
\tabucolumn Z
\begin{tabu} to \linewidth {X[l,m,1.2]ZZZZZ}
\hline
Water vapour* & 18.01534 & -2.418379e+8 & 1.886964e+5 &
2.605& 572.4\\
\hline
\end{tabu}
\end{document}
Martin Hehn
tex.stackexchange.com/questions/17792/align-siunitx-numbers-in-a-tabu-
table)
There you can also find a screenshot illustrating the problem
GL
> Hi all,
>
> I am experiencing some issues with the following example. Numbers with
> exponents are offset vertically to the "regular" numbers. Is anyone
> aware of this problem?
>
> \documentclass[parskip=half]{scrartcl}
>
> \usepackage{siunitx}
> \usepackage{tabu,booktabs}
>
> \begin{document}
>
> \newcolumntype Z{X[c,m]{%
> S[%
> tight-spacing = true,
> round-mode=places,
> round-precision=2,
> ]
> }}
> \tabucolumn Z
Well. In next version, thank to Bruno Le Floch rewritting process,
there is no \tabucolumn command:
\newcolumntype Z{ XS[m, tight-spacing=true,round-mode=places,
round-precision=2] }
X[options]{S[option]} is implemented as XS[ X option , S option]
but both still work.
\tabucolumn indeed has no signifiance: I put it there due to some
potential parsing problems of the tabu preamble. Problems that no
more exist thank to B Le Floch.
XS ( or X[..]{S[...]} ) is always centered: there is no point
to set the horizontal alignment for S and s columns: the alignment
can't be chosen.
> \begin{tabu} to \linewidth {X[l,m,1.2]ZZZZZ}
Avoid X[l,m,1.2] -> for XS columns the comma is "reserved"
to separate the options of X with the options for S. Thus it's
good practice not to use any delimiter for X options :
X [1.2 lm] (and more readable imho)
> \hline
> Water vapour*& 18.01534& -2.418379e+8& 1.886964e+5&
> 2.605& 572.4\\
> \hline
> \end{tabu}
>
> \end{document}
Now the problem of the vertical alignment: ;-)
The problem is not tabu but siunitx (sorry ;-( ): siunitx
leaves too much fixed space before the numbers, because
the S column mechanism proceeds with "fixed width". To
be able to adjust the spacing, the S column should read
the whole tabular and then choose the spacing depending
on the "natural length" of each typeset number in each
column.
This is what is done inside tabu X, but tabu cannot adjust
the spacing made by siunitx: the spaces are inside a box,
and tabu can't destroy the box (and thereafter re-align
the numbers ! )
If you try with:
\newcolumntype Z{X[-1 m]{S[tight-spacing = true,round-mode=places,
round-precision=2]}}
\begin{tabu} to \linewidth {X[lm] | *5{Z|}}
\hline
Water vapour* & 18.01534 & -2.418379e+8 & 1.886964e+5 &
2.605& 572.4\\
\hline
\end{tabu}
There is no more problems of alignment. But the columns width
are not the same. You can understand the problem with :
\newcolumntype Z{S[tight-spacing = true,round-mode=places,
round-precision=2]}
\begin{tabu} to \linewidth {X[-1 lm] | *5{Z|}}
\hline
Water \par vapour* & 18.01534 & -2.418379e+8 & 1.886964e+5 &
2.605& 572.4\\
\hline
\end{tabu}
This shows that siunitx needs more space than the X coefs
allow. Hence the line break inside the X[m] ( ie m ) column.
So: change your margin, or artificially raise the tabu width:
\newcolumntype Z{X[m]{S[tight-spacing = true,round-mode=places,
round-precision=2]}}
\hskip-10mm
\begin{tabu} to 500pt {X[-1 lm] | *5{Z|}}
\hline
Water \par vapour* & 18.01534 & -2.418379e+8 & 1.886964e+5 &
2.605& 572.4\\
\hline
\end{tabu}
Here there is no more problem. (for future version 2.9 at least)
GL
> Le 09/05/2011 13:01, Martin Hehn a écrit :
>> Hi all,
>
> the spacing made by siunitx: the spaces are inside a box,
> and tabu can't destroy the box (and thereafter re-align
> the numbers ! )
But may be this could be possible to use the measurement made by
tabu in order to set some spacing option of the S column (provided
that such options exist...)
I could look at that but other points are more urgent.
Thanks for your example.
Joseph Wright
> The problem is not tabu but siunitx (sorry ;-( ): siunitx
> leaves too much fixed space before the numbers, because
> the S column mechanism proceeds with "fixed width". To
> be able to adjust the spacing, the S column should read
> the whole tabular and then choose the spacing depending
> on the "natural length" of each typeset number in each
> column.
The mechanism used by siunitx is a deliberate decision. Collecting all
of the table would require a pretty serious hack into the \tabular
macro, which then would not carry through to other table types. That
looks pretty complicated and prone to error, as there are a *lot* of
LaTeX2e table packages. (Indeed, I have a bug to fix related to a
slightly obscure one at the moment.)
--
Joseph Wright
GL
Yes. I think mine will overtake every other packages on tabulars.
May be not v2.9 but there will probably be a v3 one day... ;-)
Ok, I'm a big boaster... "Rendez-vous" after the upload, some day.
But tabu could manage to align the numbers, removing the extra space
quite easily:
. tabu collects its body, and it can collect its cells on demand.
then it can apply \num[option]{on the cell content} and measure
the width.
. Thereafter, it can say to S [which space shall be used] on each
column. If S allows to be informed of [which space shall be used].
> slightly obscure one at the moment.)
And I'm on tabu \multicolumn feature. I think I'll solve the issue,
step by step...
> --
> Joseph Wright
>
Regards.
Martin Hehn
font size in the table.
No problem in this application. looking forward to v2.9, tabu is
already my favourite table package
On May 12, 6:24 pm, GL <gouail...@gmail.com> wrote:
> Le 12/05/2011 18:28, Joseph Wright a écrit :
>
> > On May 9, 12:33 pm, GL<gouail...@gmail.com> wrote:
> >> The problem is nottabubutsiunitx(sorry ;-( ):siunitx
> >> leaves too much fixed space before the numbers, because
> >> the S column mechanism proceeds with "fixed width". To
> >> be able to adjust the spacing, the S column should read
> >> the whole tabular and then choose the spacing depending
> >> on the "natural length" of each typeset number in each
> >> column.
>
> > The mechanism used bysiunitxis a deliberate decision. Collecting all
> > of the table would require a pretty serious hack into the \tabular
> > macro, which then would not carry through to other table types. That
> > looks pretty complicated and prone to error, as there are a *lot* of
> > LaTeX2e table packages. (Indeed, I have a bug to fix related to a
>
> Yes. I think mine will overtake every other packages on tabulars.
> May be not v2.9 but there will probably be a v3 one day... ;-)
>
> Ok, I'm a big boaster... "Rendez-vous" after the upload, some day.
>
> Buttabucould manage to align the numbers, removing the extra space
> quite easily:
>
> .tabucollects its body, and it can collect its cells on demand.
> then it can apply \num[option]{on the cell content} and measure
> the width.
> . Thereafter, it can say to S [which space shall be used] on each
> column. If S allows to be informed of [which space shall be used].
>
> > slightly obscure one at the moment.)
>
> And I'm ontabu\multicolumn feature. I think I'll solve the issue,
GL
Please look at this ;-) I don't know why I never tried it before !
\documentclass {minimal}
\usepackage [T1]{fontenc}
\begin{document}
{\loggingall
\toks0 {}
\def\startbox #1{\bgroup \hsize #1\sloppy }
\def\endbox {\egroup }
\halign{\hfil\vtop \startbox{3cm} #\endbox \vrule& \hfil\vtop
\startbox{3cm} #\endbox \vrule \cr
Hello & \hsize3cm\sloppy Hello \cr
}
\def\startbox #1#2\endbox {\bgroup
\global\toks0
\expandafter{\the\toks\expandafter0\expandafter{#2}}\egroup }
\halign{\hfil\vtop \startbox{3cm} #\endbox \vrule& \hfil\vtop
\startbox{3cm} #\endbox \vrule \cr
Hello & Hello \cr
}
Token 0 :
\detokenize\expandafter{\the\toks0 }
}
\end{document}\endinput
How to collect a \halign cell without scanner !
I don't think it's possible to do it quicker ...
GL
And this way, I will really implement what I thought it should be the
correct implementation of \tabularnewline :
\let \tabularnewline =\cr
That's all ! The *\\[dimen] is not part of the last cell, it should be
parsed by \everycr.
Regards.
Robin Fairbairns
> Yes. I think mine will overtake every other packages on tabulars.
> May be not v2.9 but there will probably be a v3 one day... ;-)
that would be a great outcome. i shall undertake a background review of
the faq, looking for places where i can say "forget all that, use tabu".
however, don't forget (a) the tendency not to update old documents'
strategies, and (b) the simple conservatism of people who've worked out
their own way through what they consider the "latex minefield" and are
loath to start again.
> Ok, I'm a big boaster...
no! surely not? ;-)
(you know i'm a fan of tabu -- since you first uploaded, and before i
had installed it...)
--
Robin Fairbairns, Cambridge
my address is @cl.cam.ac.uk, regardless of the header. sorry about that.
Joseph Wright
>> How to collect a \halign cell without scanner !
>> I don't think it's possible to do it quicker ...
>
> And this way, I will really implement what I thought it should be the
> correct implementation of \tabularnewline :
>
> \let \tabularnewline =\cr
>
> That's all ! The *\\[dimen] is not part of the last cell, it should be
> parsed by \everycr.
>
> Regards.
I had a look at your idea, but I'm not sure it works for a LaTeX tabular
(as opposed to a TeX \halign). For a LaTeX tabular, we are looking for
\\ to end a row, and using \let\\\cr fails with the optional argument to
\\. While conceptually you are correct that it's not part of the last
cell, \everycr adds material *after* the row is complete, which does not
help.
(I should also add that collecting material is not really too much of an
issue. There is a lot more time spent deciding what type of material has
been collected. Grabbing the whole cell in one go does not make too much
difference to that. I have added this as a 'to do' for v2.3, which I
might look at while on holiday in early June.)
--
Joseph Wright
GL
> On 13/05/2011 11:41, GL wrote:
>>> How to collect a \halign cell without scanner !
>>> I don't think it's possible to do it quicker ...
>>
>> And this way, I will really implement what I thought it should be the
>> correct implementation of \tabularnewline :
>>
>> \let \tabularnewline =\cr
>>
>> That's all ! The *\\[dimen] is not part of the last cell, it should be
>> parsed by \everycr.
>>
>> Regards.
>
> I had a look at your idea, but I'm not sure it works for a LaTeX tabular
> (as opposed to a TeX \halign). For a LaTeX tabular, we are looking for
> \\ to end a row, and using \let\\\cr fails with the optional argument to
> \\. While conceptually you are correct that it's not part of the last
> cell, \everycr adds material *after* the row is complete, which does not
> help.
Heu... The optional argument for \\ namely \\*[4mm] for example can
obviously be parsed by \everycr. Actually, \\[4mm] is parsed inside the
cell and thereafter executes \cr which triggers \everycr... So there is
no difference:
If \\ = \cr then
& last cell of the row \cr[4mm]
|
|-> \everycr -> \@ifnextchar [ etc.
The "problem" of LaTeX is that \everycr is always empty inside a tabular
(unless the very dirty - sorry but it's /very dirty/ - implementation of
colortbl and xcolor with \CT@everycr...)
But for tabu it's more complex, because I added the syntax :
\\>> or \\[4mm]>>
this allows to complete the row with the possibly missing & alignment
tab characters.
Very usefull when using frames (vertical leaders) or backgrounds
(coloured cells): this avoids to count the columns, choose the number
of & to add. Very usefull inside a user command too, where the number of
columns can be a parameter. But \\>> must be read and executed inside
the cell of course. Thus this makes things more complex when collecting
cells that ends with \\>> -- the implementation of that point is not
ready yet (since I'm still working on multicolumn) but I've in mind that
it not at all impossible ;-)
> (I should also add that collecting material is not really too much of an
> issue. There is a lot more time spent deciding what type of material has
> been collected. Grabbing the whole cell in one go does not make too much
> difference to that. I have added this as a 'to do' for v2.3, which I
> might look at while on holiday in early June.)
Yes and no... For siunitx, the cell contents are relativement short.
tabu provides a mechanism to collect the cell contents in a column,
and if the cell contains several paragraphs etc., in longtabu where
the tabular extends on 50 pages... well you see there can be a
difference. And anyway it's cleaner in my mind: if this is possible
with delimited arguments, while "sticking to \halign", it's always
cleaner in my mind... It's true that I'm a "\halign lover" -- how TeX
works within is too beautiful ;-)
Regards.
Joseph Wright
> Heu... The optional argument for \\ namely \\*[4mm] for example can
> obviously be parsed by \everycr. Actually, \\[4mm] is parsed inside the
> cell and thereafter executes \cr which triggers \everycr... So there is
> no difference:
> If \\ = \cr then
>
> & last cell of the row \cr[4mm]
> |
> |-> \everycr -> \@ifnextchar [ etc.
I'm not sure that it's possible to avoid affecting the output this way.
As currently coded, \\[<space>] adds vspace to the last cell of the row.
This therefore 'knows' where the baseline is in that cell, and places
the space below that. On the other hand, moving the code to \everycr
places the insertion in the first cell of the next row. So the
displacement is relative to the new baseline, which is not what is wanted.
(I am not table/box expert - I stick to other things when I can. So if
there is a solution, I'll be happy to hear about if, if not for now then
for 'later'!)
--
Joseph Wright
GL
> On 28/05/2011 17:24, GL wrote:
>> Heu... The optional argument for \\ namely \\*[4mm] for example can
>> obviously be parsed by \everycr. Actually, \\[4mm] is parsed inside the
>> cell and thereafter executes \cr which triggers \everycr... So there is
>> no difference:
>> If \\ = \cr then
>>
>> & last cell of the row \cr[4mm]
>> |
>> |-> \everycr -> \@ifnextchar [ etc.
>
> I'm not sure that it's possible to avoid affecting the output this way.
> As currently coded, \\[<space>] adds vspace to the last cell of the row.
> This therefore 'knows' where the baseline is in that cell, and places
> the space below that. On the other hand, moving the code to \everycr
> places the insertion in the first cell of the next row. So the
> displacement is relative to the new baseline, which is not what is wanted.
Yes you're perfectly right, and that's why tabular alignments are not
"regular". I have some examples !
But tabu is different: there is no strut in any cell, therefore the
baseline of the cell content is neutral. Instead, tabu inserts only
one strut per row and the height/depth are exactly the height/depth
of this row...
As a result, \\[4mm] is interpreted as "during trial, notice that the
user wants to add 4mm to the depth; at final stage add 4mm to the depth
of the row/the single "tabu@arstrutbox".
> (I am not table/box expert - I stick to other things when I can. So if
I'm not a table expert either. Just the author of the tabu package, and
"I have the devil of a job" to finish it ;-(
Joseph Wright
>> I'm not sure that it's possible to avoid affecting the output this way.
>> As currently coded, \\[<space>] adds vspace to the last cell of the row.
>> This therefore 'knows' where the baseline is in that cell, and places
>> the space below that. On the other hand, moving the code to \everycr
>> places the insertion in the first cell of the next row. So the
>> displacement is relative to the new baseline, which is not what is
>> wanted.
>
> Yes you're perfectly right, and that's why tabular alignments are not
> "regular". I have some examples !
>
> But tabu is different: there is no strut in any cell, therefore the
> baseline of the cell content is neutral. Instead, tabu inserts only
> one strut per row and the height/depth are exactly the height/depth
> of this row...
>
> As a result, \\[4mm] is interpreted as "during trial, notice that the
> user wants to add 4mm to the depth; at final stage add 4mm to the depth
> of the row/the single "tabu@arstrutbox".
There are two distinct points here: the general one about collecting up
cells and the specific one about siunitx. On the later, I can't afford
to break LaTeX2e behaviour, so have to be cautious. I think that means
that messing with \\ is not a great idea. On the other hand, with my
'LaTeX3 hat' on then a mechanism in which tables are done very
differently is entirely reasonable. It's just that at the moment I have
other things to do.
--
Joseph Wright
GL
Suppose you collect the cell content at high speed though the \halign
window :
\halign {\store #\endstore & # & # \cr
The cell content & et cetera\cr
}
Then: \store #1\endstore can work with #1 -- and also play with it.
Today: \store #1\endstore transform #1 into
-> " #1 & Let's play with halign "
TeX says at once: ! Misplaced alignment tab character &.
too bad !
& is not allowed before \outer endtemplate:
\halign's definitely not a toy ;-)