tabularx enhancement to finally get rid of `tabu` and it's shortcomings

[mrpiggi]

Brief outline of the feature request

I am pretty sure that you are already annoyed because of the many requests and problem reports concerning the package tabu. Nevertheless, I wanted to ask if there is a chance to integrate some of the core functionalities of the package in the long term, for example in tabularx. In my humble opinion these are:

Width as Maximum

Package tabu allows to consider the given width as a maximum and not as the desired one in order to obtain the natural column width if possible. This is done by \begin{tabu} spread 0pt {...} I dont't think, that the whole spread functionality is necessary, but the special case 0pt is quite useful.

Extended Column Definitions

I know, tabularx already makes it possible to set different widths for multiple X columns but I think specifying coulmns like {>{\hsize=.5\hsize\linewidth=\hsize}X>{\hsize=1.5\hsize\linewidth=\hsize}X} is not that elegant as the tabu interface with the simple specifier {XX[3]}.

Something like \newcolumntype{Z}[1]{>{\hsize=\dimexpr\hsize*#1\relax\linewidth=\hsize}X} would at least allow a simpler column specification like {Z{1/2}Z{3/2}} but the user has still to ensure that the sum of all factors is equal to the count of X columns. So adding or deleting a X column would it make necessary do revise all factors. Implementing this feature would most likely require a new column type as redefining the X column could lead to several problems with documents using the current definition and already setting \hsize like originally proposed.

The usage of negative rational numbers as specifier for the maximum width of a column would be an additional nice to have. The usage of an optional alignment parameter like X[2,l] is not necessary as using >{\raggedright} is common and would be fine in my eyes.

Improved support of longtable

I am aware of the two packages ltxtable and ltablex with this concern. The first does the job quite well but is difficult to use, if the table body is created dynamically for something like a glossary or list of symbols etc. The latter redefines the tabularx environment as a longtable at any time, which is not suitable at all and redeclares \TX@endtabularx which is very error-prone in my eyes. But this is probably something for https://github.com/latex3/latex2e/projects/7

Minimal example showing the desired features

\documentclass{article}
\usepackage{tabu}
\usepackage{tabularx}
\begin{document}

\newcommand*\tabletestbody[1][%
  This is some text as a simple example. This is some text as a simple example.%
]{%
#1
&
This is some text as a simple example. This is some text as a simple example. 
This is some text as a simple example. This is some text as a simple example. 
&
This is some text as a simple example. This is some text as a simple example. 
This is some text as a simple example. This is some text as a simple example. 
This is some text as a simple example. This is some text as a simple example. 
}


\section{Width as Maximum}
\setlength\tabudefaulttarget{10cm}
\noindent
\begin{tabu} spread 0pt {XXX}
\hline
This & is & text. 
\tabularnewline\hline
\end{tabu}

\bigskip\noindent
\begin{tabularx}{10cm}{XXX}
\hline
This & is & text. 
\tabularnewline\hline
\end{tabularx}


\section{Extended Column Definitions}
\subsubsection*{same column definition for \texttt{tabu}}
\noindent
\begin{tabu} to \textwidth {X[-2,r]|X[3,l]|X[4c]}
\hline\tabletestbody[This is text]\tabularnewline\hline
\end{tabu}

\smallskip\noindent
\begin{tabu} to \textwidth {X[-2,r]|X[3,l]|X[4c]}
\hline\tabletestbody\tabularnewline\hline
\end{tabu}

\subsubsection*{different column definition for \texttt{tabularx}}
\newcolumntype{Z}[1]{>{\hsize=\dimexpr\hsize*#1\relax\linewidth=\hsize}X}
\noindent
\begin{tabularx}\textwidth{%
  r|>{\raggedright}Z{3/7}|>{\centering}Z{4/7}
}
\hline\tabletestbody[This is text]\tabularnewline\hline
\end{tabularx}

\smallskip\noindent
\begin{tabularx}\textwidth{%
  >{\raggedleft}Z{2/9}|>{\raggedright}Z{3/9}|>{\centering}Z{4/9}
}
\hline\tabletestbody\tabularnewline\hline
\end{tabularx}
\end{document}

Log file (required) and possibly PDF file

document.log document.pdf

[c-alpha]

I concur for most part with @mrpiggi's findings and conclusions. I am evaluating the xltabular package (which is a wrapper for tabularx and longtable, and a more recent addition than the two packages @mrpiggi quotes) in my search for a tabu replacement.

\rowfont command

The only thing I haven't been able to find an alternate solution for seems to be the \rowfont command (and which I am using apparently). Looking at how it is implemented in tabu (without understanding too much of it though), and some small experiments, it seems that in order to change the font of all cells in a row, one has to repeat the font setting at the beginning of each cell's content. If this were the case, it would mean that \rowfont would need to be implemented as part of tabularx (and maybe longtable too?), or I'm out of luck.

Hence two questions:

1. Is my guesswork about how changing the font of a table row would need to be done going in the right direction?
2. If yes, would you feel inclined to consider implementing a \rowfont command in tabularx (and maybe longtable too)?

As I'm using the command to give the header row a different look, so having the option to also override the horizontal alignment for the row in question:

\rowfont[align]{font spec} Modify the font and optionally the alignment of each cell in one row.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.

[c-alpha]

Hi @davidcarlisle, any chances this enhancement request could make it onto your scrum board https://github.com/latex3/latex2e/projects/7 ?

[davidcarlisle]

@c-alpha I'm not sure.

longtable integration probably needs to be done as part of a general longtable re-write (there are some longtable v5 trials in my github).

On a syntax for setting the widths

{>{\hsize=.5\hsize\linewidth=\hsize}X>{\hsize=1.5\hsize\linewidth=\hsize}X} is not that elegant

saying it is not elegant is putting it politely, it wasn't in the design at all it just came out of comments from initial users so I documented that it was possible rather than actually adding it as a real feature (that may not have been the best thing to do, but it was a long time ago...)

But if we add a syntax like X[2.5] that more or less prevents later adding any more expressive possibilities, compare with siunitx S column S[table-number-alignment = center] so you might want

X[max-width=.., format=raggedright, vertical-align=m]

or some such.

As "just" adding a simple optional argument for the hsize scale factor has the inevitable price of compatibility issues with changing the syntax and no actual feature gain, I'm inclined to wait until we (it doesn't have to be me:-) has some time to design an interface rather than simply adding small features incrementally.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.

[c-alpha]

This looks interesting: https://ctan.org/pkg/tabularray It has a means to set font per row, and many other interesting features. The only thing I perceive as lacking is a mechanism for tables spanning more than one page (i.e. sth. akin to longtable).

[davidcarlisle]

@c-alpha yes I have a gh watch on that:-) longtable is in their plans: https://github.com/lvjr/tabularray/issues/8

[c-alpha]

It seems support for long tables is pretty much there: lvjr/tabularray#12