# Prevent LaTeXiT from cropping large Tables [duplicate]

This question already has an answer here:

I have a question specific to LaTeXiT 2.8.1 (pierre chachatelier, www.chachatelier.fr):

When I use LaTeXiT to compile (use in text or align mode; this is a minimal working example since LaTexiT adds the standard document wrapper itself.)

\begin{tabular}{|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|l|}
\hline
0.12048&0.40072&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0\\\hline
-1.1481&0.73661&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&1.8117&-0.73617&-0.94101&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&1.1531&-0.58694&-1.0686&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&-1.1809e-16&1.0385&0.66551&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&0&0&0&-0.19095&0.51543&0&0&0&0&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&0&0&0&-0.55884&1.1195&0&0&0&0&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&0&0&0&0&0&-0.10547&1.016&0&0&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&0&0&0&0&0&-0.0023264&-0.15124&0&0&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&0&0&0&0&0&0&0&0.087568&0.28791&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&0&0&0&0&0&0&0&-1.1187&0.96495&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&0&0&0&0&0&0&0&0&0&0.1361&0.40732&0.44114&0&0&0&0&0&0&0\\\hline
\end{tabular}


I get:

Which is cut off on the right side (the actual picture is cut off, its not like I did not scale or zoom correctly.)

Does anybody have a suggestions for what goes wrong and how it can be fixed?

Thanks everybody!

LaTeXiT 2.8.1; GPL Ghostscript 9.19; pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015); macOS Sierra 10.12.1;

Wrapper to run the example outside of LaTexiT:

\documentclass{article}
\begin{document}
(...)
\end{document}


The Solution

\documentclass{article}
\usepackage{graphicx}
\begin{document}
\resizebox{\textwidth}{!}{
(...)
}
\end{document}


Scales the table down to the available space. Works also in LaTeXiT.

## marked as duplicate by gernot, Fran, Chris H, clemens, user31729 Feb 7 '17 at 10:20

• Welcome to TeX.SE. You're table is just too wide, that's all ;-) That's not the fault of LaTeXit etc. – user31729 Feb 7 '17 at 9:41
• Hi Christian, thanks for the warm welcome and the fast response! I was guessing already that the width is the problem ;) The question is: where does the limitation come from? Can I get around it? Btw when I use a very small font, the width reduces but it still fails... – Felix Feb 7 '17 at 9:45
• @Mico: The electron charge is -1.6e-19 Coloumb, not 0, as a counter - example ;-) – user31729 Feb 7 '17 at 9:48
• Your options: reduce the digits (really ift is useful more than 2-3 decimal places?) o reduce further the font size. For another content, you can use columns as p{3cm} to limit the width, but not for single numbers. – Fran Feb 7 '17 at 9:49
• @Felix more detail on the "does not work" would help: Do you mean it throws an error, doesn't achieve your aim, or introduces a new failure mode? – Chris H Feb 7 '17 at 10:02

Your table contains 21 [!] columns. The final 7 columns contain nothing but zeros. For the first 14 columns, I'd use the S column type (provided by the siunitx package) and apply some rounding to three digits. (I simply can't imagine that the readers are supposed to pick up a difference between, say, -0.55884 and -0.559.) Something like the following may work for you.

Incidentally, what's the benefit to the reader of showing 7 columns of zeros? Put differently, might your readers prefer not to be shown those 7 columns?

\documentclass{article}
\usepackage[letterpaper,margin=1in]{geometry} % set text block parameters
\usepackage{siunitx} % for 'S' column type
\usepackage{array} % for '\extrarowheight' macro
\begin{document}

\begingroup  % keep effects of the following instructions local
\setlength\tabcolsep{1.5pt}   % default: 6pt
\setlength\extrarowheight{1pt}
\footnotesize
\centering
\begin{tabular}{| *{14}{S[table-format=-1.3,round-mode=places,round-precision=3]|}
*{7}{c|}}
\hline
0.12048&0.40072&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0\\\hline
-1.1481&0.73661&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&1.8117&-0.73617&-0.94101&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&1.1531&-0.58694&-1.0686&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&0&1.0385&0.66551&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&0&0&0&-0.19095&0.51543&0&0&0&0&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&0&0&0&-0.55884&1.1195&0&0&0&0&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&0&0&0&0&0&-0.10547&1.016&0&0&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&0&0&0&0&0&-0.00233&-0.15124&0&0&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&0&0&0&0&0&0&0&0.087568&0.28791&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&0&0&0&0&0&0&0&-1.1187&0.96495&0&0&0&0&0&0&0&0&0&0\\\hline
0&0&0&0&0&0&0&0&0&0&0&0.1361&0.40732&0.44114&0&0&0&0&0&0&0\\\hline
\end{tabular}
\endgroup

\end{document}

• Thanks a lot Mico. You solution also works fine while taking the angle more from the readability / content point of view. The actual embedding of my problem is more technical, I really just need to render the table as it is. (You could not know this though.) So thanks again, this gives to possible solutions now. One technical as edit below my question, and yours, being more content oriented. – Felix Feb 7 '17 at 10:17