0

I was reading the tabularx documentation and stumbled over a few things unclear to me.

  1. In 4.3. Point 1 suggests that the the sum (of the fractions before \hsize) should always be the number of columns used. Will it do any harm if this does not fit (except that if you calculated the numbers in advance, the columns width won't exactly fit the calculation (I'm asking just, because sometimes you do the maths but then you think that one column should be a bit bigger, so one just want to increase that one number instead of recalculating everything))

  2. In 4.3. Point 2: What is meant by crossing? Should one have no multicolumn [lXl] (going over the left and right bound of a X column), [XX] (spanning over multiple X columns) or even [lX] (contain a X column)? - And why is that a problem, when the size does not fit, the package will just recalculate the sizes (from my understanding)

  3. Why should \hsize be used to "weight" the column width and not another length like \testwidht or \linewidth (from what I know, they are somewhat similar (and on most occasions the same)?

1 Answer 1

3
  1. tabularx really won't do anything sensible if you don't make the sizes add up. It does something and in some cases you may accept the result but any output in that case is accidental untested code paths

  2. it means if you have an X column in column 2 you shouldn't have a \multicolumn{..}{c}{...} which spans over column 2, but has no X. You can break this rule sometimes and sometimes you can't. Details are a bit fuzzy 30 years after I wrote the code:-)

  3. because you need to set \hsize as that is the tex primitive used for linebreaking widths. It's a good idea to set \linewidth to match (as shown in that item) so then nested latex lists will use the right length.

The reason (2) is a problem is that it essentially makes you violate (1). If the width or a column declared as X is actually forced by an entry with a fixed natural length \multicolumn{1}{c}{long text here} then tabularx essentially ignores the X in that column and works as if there is one less X column in the table, and re-calulates. that's fine if it is X that was being spanned but if it was >{\hsize=.5\hsize}X then when this column is ignored and the number of active X columns is reduced the remaining modified widths will not meet the constraint set by (1).

7
  • 2. So multicolumn spanning over XX is ok, but over Xr is not good right (in general)?
    – atticus
    May 26, 2020 at 11:38
  • 1
    @atticus I added some more words. It is spanning over X that is the problem, if that X has a modified hsize. May 26, 2020 at 11:41
  • I understand now that there is a problem with that, but now I don't understand why this is not always a problem. If a \multicolumn{2}{c}{text} is spanning over [XX] (with normal hsize), then the two X are ignored and tabularx works as if there were two columns less in that table? (maybe some examples would help)
    – atticus
    May 26, 2020 at 11:50
  • 1
    @atticus try some examples with \tracingtabularx set so the log shows what it is doing in each trial run (the answer to your question is yes) The X are not ifnored for typesetting but teh effective number of X columns is reduced. May 26, 2020 at 11:54
  • I don't get it, I specify 2 columns in the tabularx preamble but in the output while compiling, tabularx does its first trial with 3 columns, is the first trial always with one more column? And when I have two Xcolumns and a multicolumn spanning over therse two columns, tabularx still starts its first trial with 3 columns (this fails, 2 fails too and when reaching 1 some boundary is hit so it stops)... (I thought in that case it would calculare with a reduced number of columns?)
    – atticus
    May 26, 2020 at 16:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .