LaTeX users online
In total there are 17 users online :: 1 registered, 0 hidden and 16 guests (based on users active over the past 5 minutes)Most users ever online was 1327 on Tue Nov 05, 2013 7:11 pm
Users browsing this forum: Google [Bot] and 16 guests
Why is table width ignored?LaTeX Forum: GeneralAdd tags
8 posts
• Page 1 of 1
Hi folks,
I just joined and am hoping someone here can enlighten me. My problem example has two tables with nearly identical text. In the first table, pdflatex ignores the table width and the table goes right off the right side of the page. In the second table, the table width is respected and the table looks correct. I'm using a fairly well up-to-date MikTex 2.7 on Windows XP. This problem is driving me crazy. Any ideas would be much appreciated. Thanks. -steve
The problem seems to come from the entry "Avoids Physically Ordered Stream Dependence". I don't know why, in one table, it is broken in two lines, but it is not in the other table. Anyway it is simple to search for solutions. You can manually break that entry by inserting \\ where appropriate (after "Stream", in this case). You can also prevent too wide columns by setting a length called \tymax (see the documentation of tabulary). Add something like
The CTAN lion is an artwork by Duane Bibby. Courtesy of www.ctan.org.
Thanks, Sven. I saw that too. The log gives a rather bland overfull warnings in the failing case. I don't want to manually correct the basic formatting, since that's why we have latex.
I think this is a bug, but am not sure where to go with it. The problem is extremely sensitive to the length of the line, which makes me suspect something going wrong with raggedright behavior.
This looks like a slippery tabulary bug. For those lines with natural lengths between the target line length and the smaller adjusted target line length (with inter-column space deducted?), tabular mistakenly thinks there is nothing to do.
This fix works for me: In tabulary.sty (line 195 for me), comment out the line as shown below, and substitute the next line.
Note that the difference is comparing \TY@linewidth instead of \linewidth. \TY@linewidth is the adjusted smaller value and is the the one that should be used in the comparison, not \linewidth. -steve
Certainly, but not by the reason you point out.
The test you have modified (see below) just tries to compare the natural length of the table with the linewidth. If the former length is lower than the latter, there is no need to scale columns (there is room to write them). The problem, IMHO, is that the natural length is not always correctly computed.
In the line right above the one you commented out, there is a length assignment: the value of \TY@linewidth is set equal to \TY@tablewidth. Hence, the test \ifdim\TY@tablewidth <\TY@linewidth is always false. Consequently, the line \def\TY@ratio{1} is never processed and so \TY@ratio is computed somehow. The fact that \TY@ratio is not automatically set to 1 is the reason that makes your examples work; hence, the reason is not that now you perform a comparison with the "right" length. If you simply leave untouched the original code and just comment out the line \def\TY@ratio{1}, you get exactly the same results as with your code. Needless to say that the code of the tabulary package is complex enough for me, so I cannot devise solutions... but the "manual" ones given in my preceding post. You said
OK, but LaTeX is not perfect. As a product of human beings, LaTeX sometimes needs the help of other human beings. Why not you? The CTAN lion is an artwork by Duane Bibby. Courtesy of www.ctan.org.
Juanjo,
I disagree. The problem and fix I gave are correct. Please let me try to explain in better detail. With the option 'debugshow', the unfixed tabulary produces the following output with the two tables in my original example: For the first bad table, we see this (note the line I highlighted in red): Target Width: 487.8225pt \tabcolsep: 6.0pt \arrayrulewidth: 0.4pt \doublerulesep: 2.0pt \tymin: 10.0pt \tymax: 690.0pt Col 5: Initial=86.63905pt -12.0pt Final=74.63905pt > tymin Col 4: Initial=77.03896pt -12.4pt Final=64.63896pt > tymin Col 3: Initial=87.58345pt -12.0pt Final=75.58345pt > tymin Col 2: Initial=66.86119pt -12.0pt Final=54.86119pt > tymin Col 1: Initial=218.58371pt -12.0pt Final=206.58371pt > tymin Line Width: 427.4225pt, Natural Width: 476.30637pt, Ratio: 1 206.58371pt, 54.86119pt, 75.58345pt, 64.63896pt, 74.63905pt, For the good table, we see this: Target Width: 487.8225pt \tabcolsep: 6.0pt \arrayrulewidth: 0.4pt \doublerulesep: 2.0pt \tymin: 10.0pt \tymax: 690.0pt Col 5: Initial=82.83351pt -12.0pt Final=70.83351pt > tymin Col 4: Initial=80.73349pt -12.4pt Final=68.3335pt > tymin Col 3: Initial=98.1114pt -12.0pt Final=86.1114pt > tymin Col 2: Initial=70.33347pt -12.0pt Final=58.33347pt > tymin Col 1: Initial=218.58371pt -12.0pt Final=206.58371pt > tymin Line Width: 427.4225pt, Natural Width: 490.19559pt, Ratio: 0.87195 180.1303pt, 50.86375pt, 75.08469pt, 59.58327pt, 61.76315pt, The ratio in the first (bad) case should not be 1. It should be 0.89742. The bug here is that the comparison was between natural width and the original target line length. The check should be between natural table width and the adjusted target line length, which compensates for the inter-column space requirements. If the natural length is greater than the original line length, as in the good table example above (487 < 490), then the ratio is correct and everything works. So, the bug only bites tables with a natural width that falls between the original target line length and original target line length less the inter-column space. This is indeed the case in the first example (427 < 476 < 487) The fixed code now gives the correct behavior for the bad table: Target Width: 487.8225pt \tabcolsep: 6.0pt \arrayrulewidth: 0.4pt \doublerulesep: 2.0pt \tymin: 10.0pt \tymax: 690.0pt Col 5: Initial=86.63905pt -12.0pt Final=74.63905pt > tymin Col 4: Initial=77.03896pt -12.4pt Final=64.63896pt > tymin Col 3: Initial=87.58345pt -12.0pt Final=75.58345pt > tymin Col 2: Initial=66.86119pt -12.0pt Final=54.86119pt > tymin Col 1: Initial=218.58371pt -12.0pt Final=206.58371pt > tymin Line Width: 427.4225pt, Natural Width: 476.30637pt, Ratio: 0.89742 185.39134pt, 49.23326pt, 67.82973pt, 58.00798pt, 66.98221pt, You also said:
No, the line above the one I commented out computes the ratio. The test is not always false and only returns a ratio of 1 for tables with a natural width already width less than the target width. Hope this helps, -steve
Well, this has been one obvious situation in which I should have remained quiet instead of making mistakes You're right. I've been confused by the fact that, in the considered examples, the target width is the linewidth of the text surrounding the table. In addition, my first thought was that, in the line, \Gscale@div\TY@ratio\TY@linewidth\TY@tablewidth, the macro \Gscale@div had one argument, so \TY@linewidth\TY@tablewidth became a length assignment. I should have verified that \Gscale@div has three arguments. No excuses, I was wrong.
I suppose that you'll write to the author of tabulary to report the bug and your solution. I've realized that \TY@ratio is always less than or equal to 1 (am I right?) This implies that, if the natural length is relatively short (i.e \TY@tablewidth<\TY@linewidth), the target width is not reached. Perhaps it would be a nice feature to add an option package so that, when active, the test \TY@tablewidth<\TY@linewidth is skipped. This would allow ratios greater than 1. The table would then fit the length indicated in the first mandatory argument of tabulary. Nice to have learn a bit more about tabulary. The CTAN lion is an artwork by Duane Bibby. Courtesy of www.ctan.org.
8 posts
• Page 1 of 1
LaTeX users onlineUsers browsing this forum: Google [Bot] and 16 guests |