Repository navigation
Other ways to distribute space for X columns #365
Description
Discussed in #362
Originally posted by note286 February 4, 2023
\documentclass{article}
\usepackage{showframe}
\usepackage{tabularray}
\begin{document}
\begin{table}
\centering
\caption{title}
\begin{tblr}
{
colspec = {*{6}{l}},
% colsep = 7.5pt,
colsep = 0pt,
hlines,vlines
}
Lorem & ipsum & dolor & sit & amet & consectetur \\
tempor & incididunt & ut & labore & et & dolore \\
quis & nostrud & exercitation & ullamco & laboris & nisi \\
consequat & Duis & aute & irure & dolor & in \\
cillum & dolore & eu & fugiat & nulla & pariatur \\
proident & sunt & in & culpa & qui & officia \\
\end{tblr}
\end{table}
\end{document}
In the table above, we set colsep = 0pt. I hope tblr can automatically complete the setting of colsep so that the table width is the specified width, such as \textwidth.
I try to set colsep = 7.5pt to meet the demand in this example. But this is inconvenient and not accurate. Whether there is a method to automatically complete this step. If you can provide an interface, such as width = \textwidth, colsep = autofill, it will be even better.
I know the existence of the X column format, but I don't want this. In many cases, the proportion between columns is not easy to see, so it is not very convenient to use the X column format. All I want is to set colsep automatically.
Activity
lvjr commentedon Feb 11, 2023
Issue #100 (about X columns with both
coandwdsettings) is related.lvjr commentedon Feb 11, 2023
@note286 You can use
Xcolumns with negative coefficients. The result is similar (but not totally the same) to that of manually settingcolsep=7.5pt. See the documentaion oftabupackage for how extra space is distributed amongXcolumns.Also you can use traditional
tabular*environment to fill extra spaces. But when there are vertical lines the result is not ideal.lvjr commentedon Feb 11, 2023
I am planning to add a new inner key
hspacingwhich takes the following possible values:default: distribute total available space to the widths ofXcolumns.fixed: similar todefault, but colseps and borders are included into column widths in calculation (#292).colsep: distribute extra space to the colseps ofXcolumns (#362).When
hspacing=fixed, users can only use positive coefficients and it is better to make surerules=smashis also applied (#215). We first subtract half of the widths of the first and last vborders from total width and then distribute remaining width to all columns in proportion to their coefficients.When
hspacing=colsep, users can only use positive coefficients and all cell text must be short.note286 commentedon Feb 11, 2023
If change the width of paper, I found
X[-1]is not not working correctly.I read the
tabudocument and got a certain understanding of using negative number in columnX. A positive number means that the column width is fixed, but in the case of a negative number, if the column content width is less than the set width, the natural width will be displayed. This is a example:Question
When there are positive
Xcolumns, everything can be understood. When all column formats are negative, how is the width of each column allocated? For example, the following example makes me very confused.Finally, I'm looking forward to the new inner key
hspacing.lvjr commentedon Feb 13, 2023
Columns with larger natural widths get more extra space.
You could read chapter 11 of
tabudocumentation if you are still confused.lvjr commentedon Feb 15, 2023
Sorry, it turns out that my memory on
Xcolumns is inaccurate: when all coefficents ofXcolumns are positive, the column widths are fixed. I have updated my comments above accordingly.[-]Other ways to distribute extra space for X columns[/-][+]Other ways to distribute space for X columns[/+]lvjr commentedon Apr 19, 2023
We can also consider what
tabularypackage does: distributing widths according to natural widths of columns. See discussion #397.fredrikpaues commentedon Apr 21, 2023
Perhaps the column types of the
tabularyare so different as to warrant a separate letter?Y?HolgerGerhardt commentedon Mar 26, 2025
I know I’m a bit late to the party, but I started using the (awesome!) tabularray package only recently.
I realized that I would also appreciate having the envisioned
hspacingoption.Currently, there seems to be a single workaround to automatically achieve a uniform distribution of space between columns of natural width when using tabularray-only environments: inserting artificial, empty
Xcolumns to separate the actual columns.This yields exactly the same spacing as the traditional
tabular*environment with@{\extracolsep{\fill}}. By contrast, usingX[-1]columns leads to slightly different spacing, as @lvjr already pointed out:HolgerGerhardt commentedon Mar 26, 2025
I have to correct myself. Here is an approach that does not mess with the number of columns in the table:
This yields:
HolgerGerhardt commentedon Mar 26, 2025
You can, of course, also put this in a command (requires the calc package) such as
Or, even more flexibly:
Here are a few examples typeset with
\booktabsTextwidth:lvjr commentedon Jul 23, 2025
There is one problem if we want to follow what
tabular*does: if the natural width of a table is larger than\textwidth, the table will overflow. Should we do something to prevent the overflow in this case?pratap120431 commentedon Jul 25, 2025
Hi Ivjr, Is there any possibility to handle equal intercolumn space for the Table column with more content?
Example Table body with more content:
\toprule
Test Test Test Test Test Test Test Test Test Test & Test Test Test Test Test Test Test Test Test Test Test 1 & Test Test Test Test Test Test Test Test Test Test Test 12 & Test Test Test Test Test Test Test Test Test Test Test 123 & Test Test Test Test Test Test Test Test Test Test Test 1234 & Test Test Test Test Test Test Test Test Test Test Test 12345 & Test Test Test Test Test Test Test Test Test Test Test 123456 & Test Test Test Test Test Test Test Test Test Test Test 1234567 \
\bottomrule
HolgerGerhardt commentedon Aug 16, 2025
Good catch!
With the code that I suggested,
tblrdoes not generate an overflowing table (whiletabular*does). Instead, the code reducescolsepand thereby makes the columns move closer to each other—which I find quite nice, actually.Of course, if the natural width exceeds the target width by too much, the columns will not be visually separated anymore or even overlap. I would thus suggest to issue a warning message in the case that
colsepbecomes negative (or, say, less than1em).Here’s an illustration of what I describe above:
And here’s the code for that example:
HolgerGerhardt commentedon Aug 16, 2025
The following actually works pretty well (I would say):
Here’s the output:
I would assume that such complicated tables—in which some cells span a single line, while others span multiple lines—will almost always require manual adjustments by the author of the manuscript.
After all, one can have different objectives in mind:
An algorithm that is supposed to determine the column widths for the author will need to know which objective the author pursues.
pratap120431 commentedon Sep 2, 2025
Hi Holger Gerhardt,
Thank you for the solution. In the given sample, all columns are distributed equally. Is there a way to automatically allocate more width to Column VI (which contains more text) by using options in the table preamble, such as X[-1,l], X[l], etc.
In addition to this, When i use longtblr (from tabularray) with rowspan, the table cannot break across pages inside a spanning cell.
A rowspan cell is treated as a single vertical box, so TeX cannot split it between pages. is there any possibility to capture each row height. Thank you