# Content of tabularx environment squeezed at left margin - nesting problem?

Under circumstances that I do not understand the content of a tabularx environment gets squeezed to the left margin. The following code example produces the problem on my system (using xelatex):

\documentclass{article} % -*- coding: utf-8-unix -*-
\usepackage[german]{babel}
\usepackage{geometry}
\usepackage{tabularx}
\geometry{a4paper,margin=1cm}
\begin{document}
\newcommand{\usrchord}[2]{
\vspace{0ex}
\begin{tabularx}{0.23\textwidth}{*{#1}{X}}
\Huge \bf #2
\end{tabularx}
}
\newcommand{\usrlyricsxx}[2]{
\vspace{0ex}
\begin{tabularx}{0.2\textwidth}{X|X}
#1 & #2 \\
\end{tabularx}
}
\begin{tabularx}{\textwidth}{*{4}{|X}|}
% Comment randomly any of the following lines to see the difference
\usrchord{1}{A}    & \usrchord{1}{D}    & \usrchord{1}{E}    & \usrchord{1}{A}    \\
\usrlyricsxx{a}{b} & \usrlyricsxx{c}{d} & \usrlyricsxx{e}{f} & \usrlyricsxx{g}{h} \\
\usrchord{1}{A}    & \usrchord{1}{D}    & \usrchord{1}{E}    & \usrchord{1}{E}    \\
\usrlyricsxx{i}{j} & \usrlyricsxx{k}{l} & \usrlyricsxx{m}{n} & \usrlyricsxx{o}{p} \\
\usrlyricsxx{q}{}  \\
\end{tabularx}
\end{document}


Which results in the following output:

If, as described in the comment, one of the rows of the tabularx environment is commented (for example, the first one), the result looks more like what I expect:

The example above is only one MWE as a representative of several constellations when this happens. However, I hope that what I am doing wrong in this example applies to all the constellations.

• Welcome to TeX.SX! You can have a look at our starter guide to familiarize yourself further with our format. – Mike Renfro Apr 19 '17 at 0:01
• Purpose of \usrchord is not clear. Its use gives result independent from number #1. The same result can be obtained with \newcommand{\usrchord}[1]{\textbf{\Huge #1}}. – Zarko Apr 19 '17 at 2:00
• @Zarko: It shall also be usable like \usrchord{2}{A&D}. – Dirk Herrmann Apr 19 '17 at 12:26
• @DirkHerrmann, than you should add this case on your MWE ... By the way,. nesting tabularx in tabularx usually make problems. Now I will try to make an answer :) – Zarko Apr 19 '17 at 12:50

\documentclass{article}
\usepackage{tabularx}
\usepackage[a4paper,margin=1cm]{geometry}

\newcommand{\usrchord}[2]{
\begin{tabularx}{\dimexpr\hsize+\tabcolsep\relax}{*{#1}{>{\bfseries\Huge}X}}
#2
\end{tabularx}
}
\newcommand{\usrlyricsxx}[2]{
\begin{tabular}{p{\dimexpr0.5\hsize-1.5\tabcolsep\relax}|
p{\dimexpr0.5\hsize-1.5\tabcolsep\relax}}
#1 & #2 \\
\end{tabular}
}

\usepackage{showframe}% for show page layout in this MWE ...
\renewcommand\ShowFrameLinethickness{0.15pt}
\renewcommand*\ShowFrameColor{\color{red}}

\begin{document}
\noindent
\begin{tabularx}{\textwidth}{*{4}{|X}|}
\usrchord{1}{A}    & \usrchord{1}{D}    & \usrchord{1}{E}    & \usrchord{1}{A}    \\
\usrlyricsxx{a}{b} & \usrlyricsxx{c}{d} & \usrlyricsxx{e}{f} & \usrlyricsxx{g}{h} \\
\usrchord{1}{A}    & \usrchord{1}{D}    & \usrchord{1}{E}    & \usrchord{1}{E}    \\
\usrlyricsxx{i}{j} & \usrlyricsxx{k}{l} & \usrlyricsxx{m}{n} & \usrlyricsxx{o}{p} \\
\usrchord{2}{A & B}&\usrchord{4}{C & D & E & F}  \\
\end{tabularx}
\end{document}


Changes:

• new definitions of \usrchord and \usrlyricsxx
• \usrchord use standard tabular environment with p{...} columns type
• showed use \usrchord with more sub-cells

The reason why the output for the MWE becomes garbled is the number of X columns: If this number gets too big the inner workings of the tabularx environment lead to a tex internal overflow (see How to typeset tabularx with 34 columns? (Error message)). And, the number of X columns considered for an outer tabularx environment includes all the X columns of all nested tabularx environments.

This can easily be verified by adding \tracingtabularx to the preamble of the MWE from the question: Running xelatex then produces the following debug output about the outermost tabularx environment:

(tabularx)     Table Width    Column Width    X Columns
(tabularx)      2212.40952pt    540.60239pt      31
(tabularx) Don't exceed \maxdimen


The number of 31 columns is one more than the 4 X columns of the outermost tabularx environment, plus the 8 X columns due to the uses of the \usrchord command, plus the 2*9 X columns due to the uses of the \usrlyricsxx command.

Coincidentially, the number 31 from the MWE is the exact boundary at which the overflow occurs: The number of columns (minus one) is multiplied with the initial column width, that is 31 * 540.60239pt = 16758.67409pt, which exceeds the tex limit of 16384pt minus epsilon. Just removing one single of the X columns (e. g. by taking out one of the \usrchord commands) will avoid the overflow, as 30 * 540.60239pt = 16218.0717pt < 16384pt. Therefore, also the commenting of any of the lines of the outer tabularx environment (as was described in the question) lead to a sufficiently small number of columns such that things worked as expected.

The problem of the overflow can only be solved by ensuring for each tabularx environment that the aggregated number of X columns does not become too big. To achieve this it may be necessary to switch from tabularx to a different environment. For the example from the question this would be recommendable for both the \usrchord and the \usrlyricsxx commands: If only one of them gets replaced, the problem will re-occur if more lines get added and thus again the column limit will be exceeded.

• How you found that your MWE has 31 columns? I see only 4 which each has nested two columns tables. This gives 8 columns. Width of nested tables should be determined in main table, right? But it seems that this is not a case (As far I see there is enough space for all columns in your table). If you somehow fix main columns width (as I did with \usrlyricsxx in my answer), then your problem disappear. I didn't tested possibilities (and now I haven't time for this) to use use p{...} columns instead of X and then use your original definition for \usrchord and \usrlyricsxx. – Zarko Apr 21 '17 at 23:01
• @Zarko: Each \usrchord introduces a table of its own with one column, and each \usrlyricsxx introduces a table of its own with two columns. The fact that they all finally give an optical impression of only 8 columns is something that the tabularx algorithm does not even try to predict when processing the outermost table. As I said, it is easy to verify using \tracingtabularx`, which is also what brought me closer to understanding the reason for the strange behaviour I had encountered. – Dirk Herrmann Apr 24 '17 at 20:01