I am using this code from tabu docu:

\providecommand{\numalign}[1]{\numprint[{\zap@space #1 \@empty}}
\nprounddigits{1} \npprintnull \npthousandsep{\,} \npunitseparator{~}

\begin{table}[H]
   \renewcommand{\arraystretch}{1.4}
   \normalfont\normalsize
   \rmfamily\small
   \rowcolors{1}{tablerowcolor}{white!100}
%
\begin{tabu} 
to\textwidth{p{0.2\textwidth}*5{>{\tabudecimal{\numalign}}X[c]}}
\hline
\rowfont[c]{\sffamily\bfseries}
NA & $0,30$ & $0,35$ & $0,50$ & $0,65$ & $0,80$
\tabularnewline
\hline
  Verluste / $-\unitfrac{dB}{cm}$ &
  $9,8\pm 1,6$ & & $5,4 \pm 1,3$ & $4,4 \pm 1,1 $ & $10,7	\pm 2,6$
  \hline
\end{tabu}
\end{table}


here I would like to align at "\pm" instead of "," - is that possible, 
if how?

Also the whole alignment only works for math mode. Then however the font 
changes. Is it possible to align without math mode, or disable the
\tabudecimal for a single line?

If necessary I can provide a full example.
Matthias

I have set up a small example using tabu and numprint which shows that 
numprint does not align anymore:

\documentclass{scrartcl}
\usepackage[table]{xcolor}
\usepackage{numprint}
\usepackage{units}
\usepackage{tabu}
\usepackage{textcomp}
\begin{document}


\providecommand{\numalign}[1]{\numprint{\zap@space #1 \@empty}}
\nprounddigits{1} \npprintnull \npthousandsep{\,} \npunitseparator{~}

\colorlet{tablerowcolor}{gray!10.0}


\begin{table}[H]
   \renewcommand{\arraystretch}{1.4}
   \normalfont\normalsize
   \rmfamily\small
   \rowcolors{1}{tablerowcolor}{white!100}
%
\begin{tabu}
to\textwidth{%
p{0.2\textwidth}%
*8{>{\tabudecimal{\numalign}}X[]|}%
*2{>{\tabudecimal{\numalign}}X[]}|}
\hline
\rowfont[c]{\sffamily\bfseries}
NA &
\multicolumn{2}{c}{0,30} &
\multicolumn{2}{c}{0,35} &
\multicolumn{2}{c}{0,50} &
\multicolumn{2}{c}{0,65} &
\multicolumn{2}{c}{0,80}
\tabularnewline
\hline
  Verluste / $-\unitfrac{dB}{cm}$ &
  $9,8$  & $\pm 1,6$ &
  & &
  $5,4$  & $\pm 1,3$ &
  $4,4$  & $\pm 1,1$ &
  $10,7$ & $\pm 2,6$
  \tabularnewline
  %
  Breite / \textmu m &
  $11,1$ & $\pm 1,4$	&
  & &
  $4,4$ & $\pm 0,2$ &
  $5,9$ & $\pm 0,8$ &
  $8,4$ & $\pm 2,0$
  \tabularnewline
  %
  H�he / \textmu m &
  $14,9$ & $\pm 1,5$	&
  & &
  $9,4$ & $\pm 1,9$ &
  $9,6$ & $\pm 1,6$ &
  $8,3$ & $\pm 2,2$
  \tabularnewline
  %
  \hline
\end{tabu}
\end{table}

\end{document}

Matthias Pospiech wrote:
> I have set up a small example using tabu and numprint which shows that 
> numprint does not align anymore:
> 
> \documentclass{scrartcl}
> \usepackage[table]{xcolor}
> \usepackage{numprint}
> \usepackage{units}
> \usepackage{tabu}
> \usepackage{textcomp}
> \begin{document}
> 
> 
> \providecommand{\numalign}[1]{\numprint{\zap@space #1 \@empty}}
> \nprounddigits{1} \npprintnull \npthousandsep{\,} \npunitseparator{~}
> 
> \colorlet{tablerowcolor}{gray!10.0}
> 
> 
> \begin{table}[H]
>   \renewcommand{\arraystretch}{1.4}
>   \normalfont\normalsize
>   \rmfamily\small
>   \rowcolors{1}{tablerowcolor}{white!100}
> %
> \begin{tabu}
> to\textwidth{%
> p{0.2\textwidth}%
> *8{>{\tabudecimal{\numalign}}X[]|}%
> *2{>{\tabudecimal{\numalign}}X[]}|}
> \hline
> \rowfont[c]{\sffamily\bfseries}
> NA &
> \multicolumn{2}{c}{0,30} &
> \multicolumn{2}{c}{0,35} &
> \multicolumn{2}{c}{0,50} &
> \multicolumn{2}{c}{0,65} &
> \multicolumn{2}{c}{0,80}
> \tabularnewline
> \hline
>  Verluste / $-\unitfrac{dB}{cm}$ &
>  $9,8$  & $\pm 1,6$ &
>  & &
>  $5,4$  & $\pm 1,3$ &
>  $4,4$  & $\pm 1,1$ &
>  $10,7$ & $\pm 2,6$
>  \tabularnewline
>  %
>  Breite / \textmu m &
>  $11,1$ & $\pm 1,4$    &
>  & &
>  $4,4$ & $\pm 0,2$ &
>  $5,9$ & $\pm 0,8$ &
>  $8,4$ & $\pm 2,0$
>  \tabularnewline
>  %
>  H�he / \textmu m &
>  $14,9$ & $\pm 1,5$    &
>  & &
>  $9,4$ & $\pm 1,9$ &
>  $9,6$ & $\pm 1,6$ &
>  $8,3$ & $\pm 2,2$
>  \tabularnewline
>  %
>  \hline
> \end{tabu}
> \end{table}
> 
> \end{document}

isn't siunutx compatible with tabu? I would think siunitx can align on 
various items

though you may need to write it as

8,3(1,9)

and then use siunitx to format it as

8,3 \pm 1,9



-- 

/daleif (remove RTFSIGNATURE from email address)

LaTeX FAQ:      http://www.tex.ac.uk/faq
LaTeX book:     http://www.imf.au.dk/system/latex/bog/    (in Danish)
Remember to post minimal examples, see URL below
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=minxampl
http://www.minimalbeispiel.de/mini-en.html

Le 25/01/2011 17:24, Lars Madsen a �crit :
> Matthias Pospiech wrote:
>
> isn't siunutx compatible with tabu? I would think siunitx can align on
> various items
>
> though you may need to write it as
>
> 8,3(1,9)
>
> and then use siunitx to format it as
>
> 8,3 \pm 1,9

Yes I think siunitx S column is the solution ( but the doc has to be
checked to find the correct parameters for S[....] )

tabu is compatible with array, and therefore allows any newcolumn
type, in particular siunitx S columns... However, you cannot embed
S into X (or p or m or b):  S columns widths cannot be set.

I believe J. Wright will provide a [column-width=<dimen>] key to get
easily several S columns of the same width, in the future...

I'll leave \tabudecimal in the future release of tabu package, because
some poeple seem to use it, but it's not a good feature, even less the
aim of tabu.

I'm thinking of the possibility to embed S into X, but it's rather
difficult (because of the S scanner, because expanding `S' code into a
loop may increase the compilation time dramatically, because of LaTeX3)

I'm still working hard on tabu to give a clear, neat, fast code, with
many new features and improved robustness ;-)

Your sincerely.

Am 25.01.2011 18:38, schrieb GL:
> Le 25/01/2011 17:24, Lars Madsen a �crit :
>> Matthias Pospiech wrote:
>>
>> isn't siunutx compatible with tabu? I would think siunitx can align on
>> various items
>>
.... However, you cannot embed
> S into X (or p or m or b): S columns widths cannot be set.
>
that is why I do not consider to use siuntitx. I have never tried to use 
siuntitx before, because it provides so much functionality that I
do not need that it is really hard to find the few pieces I would need.

>
> I'll leave \tabudecimal in the future release of tabu package, because
> some poeple seem to use it, but it's not a good feature, even less the
> aim of tabu.
>
true. siunits or numprint handle most of it already. It should rather be 
a matter of integration between tabu and num/si packages.

What I neverthelss do not understand is why the numprint example does 
not align at the ",". It only aligns according to the X[spec].
At least your docu says it should align according to numprint.

> I'm still working hard on tabu to give a clear, neat, fast code, with
> many new features and improved robustness ;-)
>
I do not want to be offensive, but have you once considered to switch 
your syntax in future releases to a more key-value and less TeX-like 
syntax? I personally prefer readability and easy to understand syntax 
highly over short syntax.(Therefore I also consider the alignmend 
specifiers Xclr... not a good design)
As a side not: "tabu" means in german "never use it"

On 25/01/2011 17:38, GL wrote:
> I believe J. Wright will provide a [column-width=<dimen>] key to get
> easily several S columns of the same width, in the future...

Indeed: probably to be looked at around Easter time, for v2.2 (at least
at present).

> I'm thinking of the possibility to embed S into X, but it's rather
> difficult (because of the S scanner, because expanding `S' code into a
> loop may increase the compilation time dramatically, because of LaTeX3)

I'm not 100% clear on this, but my impression is that the X column deals
with collecting material up itself. It would certainly be possible for
me to define a macro which would take 'pre-grabbed' number data, plus an
option, to be used by tabu. Let me know what'd needed and I'll add a
documented interface (currently, no part of the internals of siunitx is
documented).
-- 
Joseph Wright

Le 25/01/2011 19:14, Matthias Pospiech a �crit :
> Am 25.01.2011 18:38, schrieb GL:
>> Le 25/01/2011 17:24, Lars Madsen a �crit :
>>> Matthias Pospiech wrote:
>>>
>>> isn't siunutx compatible with tabu? I would think siunitx can align on
>>> various items
>>>
> ... However, you cannot embed
>> S into X (or p or m or b): S columns widths cannot be set.
>>
> that is why I do not consider to use siuntitx. I have never tried to use
> siuntitx before, because it provides so much functionality that I
> do not need that it is really hard to find the few pieces I would need.
>
>>
>> I'll leave \tabudecimal in the future release of tabu package, because
>> some poeple seem to use it, but it's not a good feature, even less the
>> aim of tabu.
>>
> true. siunits or numprint handle most of it already. It should rather be
> a matter of integration between tabu and num/si packages.
>
> What I neverthelss do not understand is why the numprint example does
> not align at the ",". It only aligns according to the X[spec].
> At least your docu says it should align according to numprint.

Well the doc is not perfect. It aligns according to the glyphs..
So if numprint pads with zeros, numbers are aligned according to
the comma/the dot.

>> I'm still working hard on tabu to give a clear, neat, fast code, with
>> many new features and improved robustness ;-)
>>
> I do not want to be offensive, but have you once considered to switch
> your syntax in future releases to a more key-value and less TeX-like
> syntax? I personally prefer readability and easy to understand syntax
> highly over short syntax.(Therefore I also consider the alignmend
> specifiers Xclr... not a good design)
> As a side not: "tabu" means in german "never use it"

;-)
tabu is a low level package, written in TeX and i make sure it is
efficient. key value syntax require the loading of a package that
manage with key=value... i know only one such package (apart
kvoptions for package options): this is pgfkeys.
Then a \tabusetup macro might be provided in a module of interfaces,
but not in tabu.

Anyway, this will take some time because a key-value interface is
usefull only if the package is (nearly) finished. tabu is still
under development, but i hope not for long (depending on the time
i need to complete the doc...)

Yours sincerely.

Le 25/01/2011 20:19, Joseph Wright a �crit :
> On 25/01/2011 17:38, GL wrote:
>> I believe J. Wright will provide a [column-width=<dimen>] key to get
>> easily several S columns of the same width, in the future...
>
> Indeed: probably to be looked at around Easter time, for v2.2 (at least
> at present).
>
>> I'm thinking of the possibility to embed S into X, but it's rather
>> difficult (because of the S scanner, because expanding `S' code into a
>> loop may increase the compilation time dramatically, because of LaTeX3)
>
> I'm not 100% clear on this, but my impression is that the X column deals
> with collecting material up itself. It would certainly be possible for
> me to define a macro which would take 'pre-grabbed' number data, plus an
> option, to be used by tabu. Let me know what'd needed and I'll add a
> documented interface (currently, no part of the internals of siunitx is
> documented).

The point is: this is equally the same for TeX, if the datas (I mean,
the tabu body) comes from the reading of the file, or from the expansion
of \the\toks@ (which temporarily stores the body).

The only matter is modification of catcodes: next version will be able
to embed Verbatim environments (by the mean of \scantokens).

The only problem with the embedding of S into X is the following:


\hskip \col@sep
\vtop \@startpbox { X }
         \tabu@celllalign 			=> ok
         \siunitx_table_collect_begin:Nn S{}
         \tabu@cellleft 				=> misplaced
         \ignorespaces \@sharp \unskip
         \siunitx_table_print:
         \tabu@cellright 			=> misplaced
         \tabu@cellralign 			=> misplaced
         \relax
     \@endpbox
\hskip \col@sep
&

well, clear, not difficult: just remove the \tabu@cell stuff
for S columns: they are used to change the alignment / font

In fact, only \tabucellleft and \tabu@cellright have to be
removed, the other ones are expandable until \@endpbox
(liar, but it's the same, i can manage with them, because
their contents are exclusively defined by tabu internals)

It is just silly because S columns have their own parameters
for font, alignement etc., which are complex and have priority,
of course.

1)
Saying that, I see that I can easily detect the presence of
"\siunitx_table_collect_begin:Nn S" in the tokens inserted
during the parsing of >{...}  <{...} but this is not "pretty":

\expandafter\in@ \expandafter \siunitx_... \expandafter{\the\toks<i>}
\ifin@ :
	=> do not insert \tabu@cellleft
The same for \tabu@cellright with \siunitx_table_print.

2) Other possibility: you scanner remove those control sequences.
But as long as their definition can be anything given by the user,
\ifx is not the good choice, and a test like \in@ (formal detection)
is required.

3) Other possibility: the cleaner, the prettier: during the
rewritting process. That depends on the final syntax one wish.

If this is what i thought about:  X[2,m,$]{ S[ key-values ] }
then the rewritting macro for X shall be modified. It is
quite heavy yet, but...

The rewritting macro will then say: Warning: the 2nd and 3rd X
columns are embeding siunitx S scanner ! Well. Unfortunately,
this is not enough.

While rewritting columns, you have no idea of which one it is,
you only know:
	. This is a X column (or S, or n or whatever)
	. This is the <nth> X column (or the <nth> S etc.)
But you can't say: this is the column <i> for the tabular.

This was the rewritting process:
	\@whilesw \if@tempswa\fi {\@tempswafalse \the\NC@list}

While during the next stage, building the \halign preamble from
the fundamental tokens:
	\@for \@nextchar:=<rewritten preamble>\do{%
		\@chnum \@chclass \@testpach
		\@acolampacol
		\@addtopreamble 	etc.
	}
	- (parenthesis: many packages: colortbl, arydshln, tabls,
	    and plenty of others modify this loop, while it
	    is absolutely not necessary, and make compatibility
	    nearly impossible) -

columns are built one after another, and you know the order.
This is the strategy of tabu:
	Just plug some code onto \prepnext@tok and you get
all the information you need:
	\count@ \@temptokena \@chclass \@chnum \@lastchclass.

I can't figure out how to make a brigde - a link - between the
rewritting of X and the numbering of tokens containing

	\siunitx_table_collect_begin:Nn

Well. Next version will be, i hope, sufficiently clear and neat
to be able to add such a feature without extreme endeavours.

After this discussion, I would say that \in@ whould be the solution,
apart that
	\siunitx_table_collect_begin:Nn S{...}
contains braces... => \in@ is not happy with braces !


but looking again at the initial problem, very simple,
I can conclude:

-------------------------------------------
\hskip \col@sep
\vtop \@startpbox { X }
         \tabu@celllalign 			=> ok
         \siunitx_table_collect_begin:Nn S{}
         \tabu@cellleft 				=> misplaced
         \ignorespaces \@sharp \unskip
         \siunitx_table_print:
         \tabu@cellright 			=> misplaced
         \tabu@cellralign 			=> misplaced
         \relax
     \@endpbox
\hskip \col@sep
--------------------------------------------

\tabu@celllalign could do the job very efficiently:

	\futurelet \@let@token \testmacro

\testmacro: \ifx \@let@token \siunitx_table_collect_begin:Nn
		=> deactivate \tabu@cellleft and \tabu@cellright,
	           locally inside the alignment template group
	           (inside the \vbox, \vtop or \vcenter precisely)
		   just :
			\let\tabu@cellleft = \@empty  etc.
	    \else
		ok do you job as usual:
			\expandafter\tabu@celllalign_ORI		
	    \fi

Nice ! Here is the solution i could implement. And it is very
efficient: just one \futurelet, one \ifx and one \expandafter !

But it does not worth the pain if the other features of tabu don't
work, and i have to finish ;-)

Thanks,

Yours sincerely.

Le 25/01/2011 20:19, Joseph Wright a �crit :
> On 25/01/2011 17:38, GL wrote:
>> I believe J. Wright will provide a [column-width=<dimen>] key to get
>> easily several S columns of the same width, in the future...
>
> Indeed: probably to be looked at around Easter time, for v2.2 (at least
> at present).

Well, leaving tabu and going back to siunitx -- your package, inpired by
former siunits -- i'm quite agree with Matthias Pospiech when he says:

that is why I do not consider to use siuntitx. I have never tried to use 
siuntitx before, because it provides so much functionality that I
do not need that it is really hard to find the few pieces I would need.

i know examples are time consuming to built, and also that users are
almost always better informed about the difficult cases you didn't
thought about as a developper.

What i suggest is a description - *siunitx for the impatient* -
of all the options by category, possibly with hyperlinks to the
corresponding paragraph/definition in the manual. tabulars could be
a good idea to keep things tight.

For example:

Commands:
^^^^^^^^
     \num [options]{number} => formats the number in text and math modes
     \si [options]{units}   => prints units with SI standards
     \SI[options]{value}[pre-units]{units} => dimension with units
     \numlist ...

     \ang

   + \sisetup => general purpose macro to set any parameter
				(locally/globally etc..)

Units:
^^^^^^
  *All defined units (alphabetic order)*
    (a list is enough, not to explain what a meter or a second are...)

Units are given naturally: f.ex. \meter\per\second

\meter			\Hz
\ampere			\percent
\candela		\farad
\volt			etc.

  *Prefixes*
	\milli \femto \pico \Tera \kilo etc.

  *\per modes*

Typesetting:
^^^^^^^^^^^
    * Options for units and symbols *
       option  type   possible values = short description or example
				       or reference to the manual
		     ---             = ---
                      ---             = ---
      option   type   possible values etc.

    * Options for numbers *

    * Options for fonts *

    * Specific options for tabulars material *

It's quite fastidious, but I think you get the material ready, and
should be able to set up such a "dictionary" on a paper in a couple of
hours... But I'm sure it would be nice - for the users - and also for
you, because the code is always easier to maintain, when you can have
a look at all feature in a few minutes.

Well, this wes just a suggestion of mine...

Yours sincerely.

On 26/01/2011 00:17, GL wrote:
> Le 25/01/2011 20:19, Joseph Wright a �crit :
>> On 25/01/2011 17:38, GL wrote:
>>> I believe J. Wright will provide a [column-width=<dimen>] key to get
>>> easily several S columns of the same width, in the future...
>>
>> Indeed: probably to be looked at around Easter time, for v2.2 (at least
>> at present).
> 
> Well, leaving tabu and going back to siunitx -- your package, inpired by
> former siunits -- i'm quite agree with Matthias Pospiech when he says:
> 
> that is why I do not consider to use siuntitx. I have never tried to use
> siuntitx before, because it provides so much functionality that I
> do not need that it is really hard to find the few pieces I would need.
> 
> i know examples are time consuming to built, and also that users are
> almost always better informed about the difficult cases you didn't
> thought about as a developper.
> 
> What i suggest is a description - *siunitx for the impatient* -
> of all the options by category, possibly with hyperlinks to the
> corresponding paragraph/definition in the manual. tabulars could be
> a good idea to keep things tight.
> 
> For example:
> 
> Commands:
> ^^^^^^^^
>     \num [options]{number} => formats the number in text and math modes
>     \si [options]{units}   => prints units with SI standards
>     \SI[options]{value}[pre-units]{units} => dimension with units
>     \numlist ...
> 
>     \ang
> 
>   + \sisetup => general purpose macro to set any parameter
>                 (locally/globally etc..)
> 
> Units:
> ^^^^^^
>  *All defined units (alphabetic order)*
>    (a list is enough, not to explain what a meter or a second are...)
> 
> Units are given naturally: f.ex. \meter\per\second
> 
> \meter            \Hz
> \ampere            \percent
> \candela        \farad
> \volt            etc.
> 
>  *Prefixes*
>     \milli \femto \pico \Tera \kilo etc.
> 
>  *\per modes*
> 
> Typesetting:
> ^^^^^^^^^^^
>    * Options for units and symbols *
>       option  type   possible values = short description or example
>                        or reference to the manual
>              ---             = ---
>                      ---             = ---
>      option   type   possible values etc.
> 
>    * Options for numbers *
> 
>    * Options for fonts *
> 
>    * Specific options for tabulars material *
> 
> It's quite fastidious, but I think you get the material ready, and
> should be able to set up such a "dictionary" on a paper in a couple of
> hours... But I'm sure it would be nice - for the users - and also for
> you, because the code is always easier to maintain, when you can have
> a look at all feature in a few minutes.
> 
> Well, this wes just a suggestion of mine...
> 
> Yours sincerely.
> 

Um, that sounds rather like the way the manual already _is_ organised!
-- 
Joseph Wright

Le 26/01/2011 22:33, Joseph Wright a �crit :
> On 26/01/2011 00:17, GL wrote:
>> Le 25/01/2011 20:19, Joseph Wright a �crit :
>>> On 25/01/2011 17:38, GL wrote:
>>>> I believe J. Wright will provide a [column-width=<dimen>] key to get
>>>> easily several S columns of the same width, in the future...
>
> Um, that sounds rather like the way the manual already _is_ organised!

The matter is the matter, it is difficult to find the option you need,
and the manual (very often) presents an option name by not its possible
values. You said there is about a hundred and fifty options: difficult
to remember too...

Yours sincerely.

On 26/01/2011 22:21, GL wrote:
> The matter is the matter, it is difficult to find the option you need,

I have done my best, trying to organise them into areas then into
tables. I will of course take another look at the documentation and see
what I can do to improve it.

> and the manual (very often) presents an option name by not its possible
> values. 

Any unexplained or missing values would be bugs in the manual. Please
let me know where they are and I will endeavour to fix them.

> You said there is about a hundred and fifty options: difficult
> to remember too...

I am aware of that: I cannot say I know all of the options. Most people
need only a small subset, but _which_ subset varies a lot. I would not
have written that many options if they did not seem to be needed. As I
said, I've tried to keep them organised in the documentation.
-- 
Joseph Wright

Le 27/01/2011 22:55, Joseph Wright a �crit :
[...]

Well, i finally manage to embed S and s into X. i just have to test
it carefully...

In fact it will not be so slow as i first thought, because i noticed
that in the case of X columns with a non negative width coefficient
(that is just like tabularx), there is not need to make real trials
to find the target.

I mean, if :
		| X[2] | X | 	much reach say 200pt

you may replace the content of each cell by:
	For the first column: 	a rule of length   2X
	For the second column:	a rule of length    X

then your final table will have exactly the same width as if you
really built the tabular material. This is because p column have
a *fixed width*. This is a great optimisation I made already for
the case of nested tabulars !

Therefore, I will neutralise/disable the siunitx scanner during such
trials.

For the case of | X[-2] | X[-1] | one have to measure the natural width
of the content: it is required to built the tabular cells. But this
natural width is measured only once.

To conclude: in any case, the siunitx scanner will work at most 3 times
on each cell:
	1st : for natural width measure (only if asked by the user)
	2nd : for vertical measure of the rows (no more struts in the
						next version!)
	3rd : for the final print

I think it'll be OK, and let you know when finishing the doc...
with some examples of

\begin{tabu}{|*2{X[-1]{S[round-integer-to-decimal=true,
                          round-precision=2,
                          round-mode=places]}}|}
123.1 & 546,4518e4
\end{tabu}


Good night.

Yours sincerely,
F Chervet.

Le 25/01/2011 16:40, Matthias Pospiech a �crit :
> I have set up a small example using tabu and numprint which shows that
> numprint does not align anymore:

I don't know what you are looking for with such a complex example...

However, you cannot keep the alignment on the comma if your X column
is left align or justified (which is the same for only one line)

You should say:

	>{\tabudecimal{\numalign}}X[r]}

instead of
	>{\tabudecimal{\numalign}}X[]}

I'll look at siunitx options to align on \pm

Yours sincerely.



>
> \documentclass{scrartcl}
> \usepackage[table]{xcolor}
> \usepackage{numprint}
> \usepackage{units}
> \usepackage{tabu}
> \usepackage{textcomp}
> \begin{document}
>
>
> \providecommand{\numalign}[1]{\numprint{\zap@space #1 \@empty}}
> \nprounddigits{1} \npprintnull \npthousandsep{\,} \npunitseparator{~}
>
> \colorlet{tablerowcolor}{gray!10.0}
>
>
> \begin{table}[H]
> \renewcommand{\arraystretch}{1.4}
> \normalfont\normalsize
> \rmfamily\small
> \rowcolors{1}{tablerowcolor}{white!100}
> %
> \begin{tabu}
> to\textwidth{%
> p{0.2\textwidth}%
> *8{>{\tabudecimal{\numalign}}X[]|}%
> *2{>{\tabudecimal{\numalign}}X[]}|}
> \hline
> \rowfont[c]{\sffamily\bfseries}
> NA &
> \multicolumn{2}{c}{0,30} &
> \multicolumn{2}{c}{0,35} &
> \multicolumn{2}{c}{0,50} &
> \multicolumn{2}{c}{0,65} &
> \multicolumn{2}{c}{0,80}
> \tabularnewline
> \hline
> Verluste / $-\unitfrac{dB}{cm}$ &
> $9,8$ & $\pm 1,6$ &
> & &
> $5,4$ & $\pm 1,3$ &
> $4,4$ & $\pm 1,1$ &
> $10,7$ & $\pm 2,6$
> \tabularnewline
> %
> Breite / \textmu m &
> $11,1$ & $\pm 1,4$ &
> & &
> $4,4$ & $\pm 0,2$ &
> $5,9$ & $\pm 0,8$ &
> $8,4$ & $\pm 2,0$
> \tabularnewline
> %
> H�he / \textmu m &
> $14,9$ & $\pm 1,5$ &
> & &
> $9,4$ & $\pm 1,9$ &
> $9,6$ & $\pm 1,6$ &
> $8,3$ & $\pm 2,2$
> \tabularnewline
> %
> \hline
> \end{tabu}
> \end{table}
>
> \end{document}