lvjr
Unexpected new page in long tabularray
First of all, sorry for the contrived example --- I could not reduce it anymore. The problem is that the third "long" tblr in this document is split even if all the page is available.
I can fix it quite easily by adding * to the lines (I do not know if there is an option to "undo" the long in the template), but I thought it could be useful to pin it down --- maybe I did something wrong.
The result is this one:
\documentclass[10pt,a4paper]{article}
\usepackage[a4paper,top=3cm,bottom=3cm,left=3cm,right=3cm,headheight=36pt]{geometry}
\usepackage{tabularray}
\NewTblrEnviron{MyTblr}
\SetTblrInner[MyTblr]{rowhead=1, rowfoot=0, hlines, vlines}
\SetTblrOuter[MyTblr]{long, label=none, entry=none}
%
\newcommand{\lineadatos}[1]{% linea, left aligned, with a full-size underline
\begingroup
\parindent=0pt\parskip=-3pt\baselineskip=1pt
\strut #1\par
\hrulefill\par
\endgroup
\nobreak\medskip
}
\newcommand{\lineatitle}[1]{%
\par\bigbreak\goodbreak
\textbf{#1}\par%
\nobreak\medskip\nobreak
}
\begin{document}
\lineatitle{Start}
\vspace{3cm}
\lineadatos{}
\lineadatos{}
\lineadatos{}
\lineadatos{}
\lineadatos{}
\lineadatos{}
\lineadatos{}
\lineadatos{}
\lineadatos{}
\lineadatos{}
\lineadatos{}
\lineadatos{}
\vspace{0.25cm}
\lineatitle{} Education
\begin{MyTblr}{X[1,l]*3{X[0.5,l]}}
{Degrees} & {School} & {Date} & mark (when available)\\
%% data starts here
{\strut \\ \strut \\ \strut \\ \strut}& & & \\
{\strut \\ \strut \\ \strut \\ \strut}& & & \\
{\strut \\ \strut \\ \strut \\ \strut}& & &
\end{MyTblr}
Additional info on Ph.D. thesis:
\begin{MyTblr}{*{2}{X[1,l]}}
Title & Tutor/School \\
{\strut \\ \strut }& &
\end{MyTblr}
% this is exploding... I need to force it not to break!
\lineatitle{} Language Proficiency
\begin{MyTblr}[
note{*}={\textbf{B}= Basic, \textbf{M}= Moderate, \textbf{H}=High}
]{Xllll}
{Language} & {Speaking\TblrNote{*}} & {Listening\TblrNote{*}} &
{Reading\TblrNote{*}} & {Writing\TblrNote{*}} \\
Italian & H & H & H & H \\
Spanish & H & H & H & H \\
English & H & M & H & M \\
Frrench & B & B & M & B \\
\end{MyTblr}
\end{document}
Maybe this bug could be fixed together with #184. In #184, tabularray fails to pagebreak after first body row. And here tabularray pagebreaks wrongly after first body row.
PS: At least some \usepackage lines could be removed from the example.
PS: At least some
\usepackagelines could be removed from the example.
Yes, you're right. I'll try to minimize the MWE as soon as I have some time (RL kicking in...)
PS: At least some
\usepackagelines could be removed from the example.Yes, you're right. I'll try to minimize the MWE as soon as I have some time (RL kicking in...)
Done. It seems that both geometry and my awful messing with break penalties are needed to trigger the bug...
Adding \SetTblrTracing{-step,+page} to the example I get from the log file:
> \pagegoal=674.33032pt. > \pagetotal=311.27136pt.
> \pagegoal=674.33032pt. > \pagetotal=323.27136pt.
> \pagegoal=674.33032pt. > \pagetotal=323.27136pt.
> \pagegoal=674.33032pt. > \pagetotal=341.27136pt.
> \pagegoal=674.33032pt. > \pagetotal=341.27136pt.
> \l__tblr_curr_i_int=2.
> \l__tblr_curr_i_int=3.
> \l__tblr_curr_i_int=4.
> \pagegoal=674.33032pt. > \pagetotal=545.27133pt.
> \pagegoal=674.33032pt. > \pagetotal=552.21577pt.
> \pagegoal=674.33032pt. > \pagetotal=552.21577pt.
> \pagegoal=674.33032pt. > \pagetotal=570.21577pt.
> \pagegoal=674.33032pt. > \pagetotal=570.21577pt.
> \l__tblr_curr_i_int=2.
> \pagegoal=674.33032pt. > \pagetotal=639.41576pt.
> \pagegoal=674.33032pt. > \pagetotal=651.41576pt.
> \pagegoal=674.33032pt. > \pagetotal=651.41576pt.
> \pagegoal=674.33032pt. > \pagetotal=671.3602pt.
> \pagegoal=674.33032pt. > \pagetotal=671.3602pt.
> \l__tblr_curr_i_int=2.
> \pagegoal=674.33032pt. > \pagetotal=661.3602pt.
> \l__tblr_curr_i_int=3.
[1]
[2]
> \pagegoal=674.33032pt. > \pagetotal=0.0pt.
> \l__tblr_curr_i_int=4.
> \l__tblr_curr_i_int=5.
[3]
It is strange there are no tracing messeges between [1] and [2].
With version 2023A I get two-page output:
> \pagegoal=674.33032pt. > \pagetotal=311.27136pt.
> \pagegoal=674.33032pt. > \pagetotal=323.27136pt.
> \pagegoal=674.33032pt. > \pagetotal=323.27136pt.
> \pagegoal=674.33032pt. > \pagetotal=341.27136pt.
> \pagegoal=674.33032pt. > \pagetotal=341.27136pt.
> \l__tblr_curr_i_int=2.
> \l__tblr_curr_i_int=3.
> \l__tblr_curr_i_int=4.
> \pagegoal=674.33032pt. > \pagetotal=545.27133pt.
> \pagegoal=674.33032pt. > \pagetotal=552.21577pt.
> \pagegoal=674.33032pt. > \pagetotal=552.21577pt.
> \pagegoal=674.33032pt. > \pagetotal=570.21577pt.
> \pagegoal=674.33032pt. > \pagetotal=570.21577pt.
> \l__tblr_curr_i_int=2.
> \pagegoal=674.33032pt. > \pagetotal=639.41576pt.
> \pagegoal=674.33032pt. > \pagetotal=651.41576pt.
> \pagegoal=674.33032pt. > \pagetotal=651.41576pt.
> \pagegoal=674.33032pt. > \pagetotal=671.3602pt.
> \pagegoal=674.33032pt. > \pagetotal=671.3602pt.
> \l__tblr_curr_i_int=2.
[1]
> \pagegoal=674.33032pt. > \pagetotal=0.0pt.
> \l__tblr_curr_i_int=3.
> \l__tblr_curr_i_int=4.
> \l__tblr_curr_i_int=5.
[2]
Hi @lvjr — I’ve been digging into this issue and was able to consistently reproduce and isolate the problem. Here's what I found:
If I add the following just before the third table:
\enlargethispage{2.6pt}
…then the table breaks properly in two pages. But if I lower it to:
\enlargethispage{2.55pt}
…the table breaks again into 3pages.
This shows the issue is not the actual table height, but the page break threshold is narrowly overshot due to internal vertical list computation — likely involving \strut \\ combinations and tabularray’s vbox logic.
It seems like the vbox used to hold the table body is being inserted before its height is fully realized, and TeX misestimates the needed space — causing an unnecessary break. A vertical box that’s only ~2.6pt too tall appears to trigger the break.
Happy to test any dev builds or further traces if helpful. Thanks for all your work on this fantastic package!
Hi @lvjr, I noticed that when using longtblr inside the cuted package’s strip environment (e.g., in a twocolumn document), the table breaks across multiple pages — but strange output see bwlow :
\SetTblrTracing{-step,+page} produces no tracing diagnostics at all for the longtblr pages;
The log has no \pagegoal, \pagetotal, or l__tblr_curr_i_int output;
It appears the tracing hooks are bypassed entirely when longtblr is inside the special box created by cuted.
This might be because strip inserts content in a boxed float that doesn’t go through the usual vertical list building process where tabularray injects its page-tracing logic.
Would it be possible to:
Add compatibility for boxed inserts like cuted?
Or at least warn that \SetTblrTracing doesn’t operate when used inside strip?
Let me know if you'd like a reproducible .tex file or .log.
\documentclass[twocolumn]{article}
\usepackage{tabularray,color}
\usepackage{kantlipsum,cuted}
\SetTblrTracing{-step,+page}
\begin{document}
\kant[1-2]
\begin{strip}
\kant[4]
\begin{longtblr}[
caption = {Table caption}
]{
colspec = {|Q[l]|X[c]|X[c]|},
}
{{{Numbers}}} & {{{Week}}} & {{{Values}}} \\
One & Monday & 123.4 \\
Two & Tuesday & 56.78 \\
Three & Wednesday & 9.012 \\
Four & Thursday & 345.6 \\
Five & Friday & 78.9 \\
Six & Saturday & 123.4 \\
Seven & Sunday & 56.78 \\
Eight & Monday & 9.012 \\
Nine & Tuesday & 345.6 \\
Ten & Wednesday & 78.9 \\
One & Thursday & 123.4 \\
Two & Friday & 56.78 \\
Three & Saturday & 9.012 \\
Four & Sunday & 345.6 \\
Five & Monday & 78.9 \\
Six & Tuesday & 123.4 \\
Seven & Wednesday & 56.78 \\
Eight & Thursday & 9.012 \\
Nine & Friday & 345.6 \\
Ten & Saturday & 78.9 \\
One & Sunday & 123.4 \\
Two & Monday & 56.78 \\
Three & Tuesday & 9.012 \\
Four & Wednesday & 345.6 \\
Five & Thursday & 78.9 \\
Six & Friday & 123.4 \\
Seven & Saturday & 56.78 \\
Eight & Sunday & 9.012 \\
Nine & Monday & 345.6 \\
Ten & Tuesday & 78.9 \\
One & Wednesday & 123.4 \\
Two & Thursday & 56.78 \\
Three & Friday & 9.012 \\
Four & Saturday & 345.6 \\
Five & Sunday & 78.9 \\
Six & Monday & 123.4 \\
Seven & Tuesday & 56.78 \\
Eight & Wednesday & 9.012 \\
Nine & Thursday & 345.6 \\
Ten & Friday & 78.9 \\
One & Saturday & 123.4 \\
Two & Sunday & 56.78 \\
Three & Monday & 9.012 \\
Four & Tuesday & 345.6 \\
Five & Wednesday & 78.9 \\
Six & Thursday & 123.4 \\
Seven & Friday & 56.78 \\
Eight & Saturday & 9.012 \\
Nine & Sunday & 345.6 \\
Ten & Monday & 78.9 \\
One & Tuesday & 123.4 \\
Two & Wednesday & 56.78 \\
Three & Thursday & 9.012 \\
Four & Friday & 345.6 \\
Five & Saturday & 78.9 \\
Six & Sunday & 123.4 \\
Seven & Monday & 56.78 \\
Eight & Tuesday & 9.012 \\
Nine & Wednesday & 345.6 \\
Ten & Thursday & 78.9 \\
One & Friday & 123.4 \\
Two & Saturday & 56.78 \\
Three & Sunday & 9.012 \\
Four & Monday & 345.6 \\
Five & Tuesday & 78.9 \\
Six & Wednesday & 123.4 \\
Seven & Thursday & 56.78 \\
Eight & Friday & 9.012 \\
Nine & Saturday & 345.6 \\
Ten & Sunday & 78.9 \\
One & Monday & 123.4 \\
Two & Tuesday & 56.78 \\
Three & Wednesday & 9.012 \\
Four & Thursday & 345.6 \\
Five & Friday & 78.9 \\
Six & Saturday & 123.4 \\
Seven & Sunday & 56.78 \\
Eight & Monday & 9.012 \\
Nine & Tuesday & 345.6 \\
Ten & Wednesday & 78.9 \\
\end{longtblr}
\end{strip}
\kant[5]
\end{document}
I can trigger the same issue inside a regular tblr when using the long outer key. Here is the link to a stackexchange question I posted earlier today, including an MVE. Changing the long keyword to tall fixes the issue for me - a commenter added, that long tables should never be inside a table environment, according to the documentation tall tables can be inside a table environment (see section 4.6).
Any progress on this issue?
With doxygen generated tables we also run into this problem. Changing to the talltblr instead of the longtblr environment does have some severe disadvantages as at that moment very large tables run into the page footer (as the tall tables are not split over multiple pages).
The example I have is quite complex and is generated (I could already make it much smaller, though it is still a lot of work to make it into a minimal example). I can provide what I have now though. My remark was just to see whether there is any progress on this issue and I think that the examples given are quite illustrative already. My remark about doxygen was just a support about that the problem also occurs for other users.
It might be related to #366.
It seems the fix for #361 there is not perfect. In current tabularray.sty
\dim_set:Nn \l__tblr_page_overfill_dim
{
% Issue #361: enough to overfill the page (including shrink).
\pagegoal - \pagetotal + \l__tblr_next_rows_dim
+ \__tblr_box_height:N \l__tblr_table_firsthead_box
+ \__tblr_box_height:N \l__tblr_table_firstfoot_box
}
\skip_vertical:n { \l__tblr_page_overfill_dim }
\tex_penalty:D 9999
\skip_vertical:n { -\l__tblr_page_overfill_dim }
If I increase \l__tblr_page_overfill_dim by 3pt before the first \skip_vertical:n, then the output is correct.
@Yodude2002 Do you have any ideas on this issue?
@lvjr
To do some local tests on my project: how should the code in tabularray.sty look like
@albert-github Download latest tabularray.sty in the repository and add one line:
\dim_set:Nn \l__tblr_page_overfill_dim
{
% Issue #361: enough to overfill the page (including shrink).
\pagegoal - \pagetotal + \l__tblr_next_rows_dim
+ \__tblr_box_height:N \l__tblr_table_firsthead_box
+ \__tblr_box_height:N \l__tblr_table_firstfoot_box
}
\dim_add:Nn \l__tblr_page_overfill_dim { 3pt } %%<==== add this line
\skip_vertical:n { \l__tblr_page_overfill_dim }
\tex_penalty:D 9999
\skip_vertical:n { -\l__tblr_page_overfill_dim }
You may try to change 3pt to other values.
@lvjr Looks like it didn't help in my situation (I even tried 30pt)
This is the reason why I requested your minimal example.
What about 100pt or 300pt?
I 100% agree with your request for a minimal example.
I tried:
- 100pt failed
- 200pt OK
but I don't like to use such a (large) heuristic value as I expect that it will backfire (later another table will need an even larger value or some "weird" white space will appear (at the bottom of a page?.
It won't be easy to create a real minimal example as I expect that the problem is depending on the specific use case where it happens.
For completeness I've added the "small" case (I already made it much smaller) I used for testing: example.tar.gz
- I left the not working fix with 100pt in the used tabularray file
- to run use
make
the result can be seen in refman.pdf page 5 / 6 (in the good version page 6 isn't present anymore).
For completeness also the log file refman.log and the generated pdf (100pt) refman.pdf
I 100% agree with your request for a minimal example.
I tried:
- 100pt failed
- 200pt OK
but I don't like to use such a (large) heuristic value as I expect that it will backfire (later another table will need an even larger value or some "weird" white space will appear (at the bottom of a page?.
This is not a fix for the bug. Just a try to locate the bug.
It won't be easy to create a real minimal example as I expect that the problem is depending on the specific use case where it happens.
For completeness I've added the "small" case (I already made it much smaller) I used for testing: example.tar.gz
- I left the not working fix with 100pt in the used tabularray file
- to run use
makethe result can be seen in refman.pdf page 5 / 6 (in the good version page 6 isn't present anymore).
For completeness also the log file refman.log and the generated pdf (100pt) refman.pdf
The example is not that small since it loads quite a few other packages. But at least it can be tested.
I think I have fixed this bug. Please try latest tabularray.sty in the repository.
Thanks for the fix.
I did a test on the entire project with the adjustments and I didn't see the problem in my (test) project. Hopefully others can confirm this.
- Is here a new release planned? When ?
Sorry to be late: I can confirm that the new tabularray.sty fixes the original problem I had.
Thanks.
@albert-github May I suggest doxygen to provide an option for generating a single file refman.tex by combining all latex code into it? Therefore you can make a minimal example by simplifying that file only.
You definitely can suggest it and this has been done before, see https://github.com/doxygen/doxygen/issues/4482, but it has been rejected.
Image and bibliography and other non-tex files need not to be merged. To save my limited time I am afraid I have to reject future issue reports with an example in a compressed tarball of lots of files.
I will merge just the required files in future. This is much easier than starting from a monolitic file as with a monolitic file one has to remove quite a bit of tex code beforehand to get a usable example. In case of a non monolitic file it is just including a few files into refman.tex as one can easily test by removing some include files from refman.tex (as I'd already done for the given example, which was just 2 tex files, 3 sty files and 2 supporting files to show how we normally build, The original problem contained 68 tex files).