1

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:

Compiled picture by LaTeXiT

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.

Felix
  • 199
  • 2
    Welcome to TeX.SE. You're table is just too wide, that's all ;-) That's not the fault of LaTeXit etc. –  Feb 07 '17 at 09: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 07 '17 at 09:45
  • I assume it's ok to replace -1.1809e-16 with 0, right? – Mico Feb 07 '17 at 09:46
  • 1
    @Mico: The electron charge is -1.6e-19 Coloumb, not 0, as a counter - example ;-) –  Feb 07 '17 at 09:48
  • Yes, its an numerical artifact. In this example this also reduces the width. My question is however more how to fix this in general. So suppose all numbers are (and stay) as they are written here.

    @Christian: important is the distance of largest to smallest (non-zero) element in the matrix. Since it is 16 decades away here, its 0 for all practical purposes. Let's not discuss this further ;)

    – Felix Feb 07 '17 at 09:49
  • 1
    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 07 '17 at 09:49
  • @Felix: How about a rotated table, i.e. sideways -- the table has a reasonable height, so it would fit on a page both horizontally and vertically without leaking into margins –  Feb 07 '17 at 09:50
  • @Fran: Digits: no, my question is general, independent of the data Font size: doesn't work, at least when I use the font-size-switch in latexit – Felix Feb 07 '17 at 09:51
  • Then search about tabular*, tabularx and tabulary environments. – Fran Feb 07 '17 at 09:53
  • @ Christian: using the rotating package and sidewaystable environment does not work. – Felix Feb 07 '17 at 09:55
  • @Fran tested the tabular*, tabularx and tabulary environments, all get cut off – Felix Feb 07 '17 at 09:59
  • 1
    @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 07 '17 at 10:02
  • Thanks everybody! @gernot its close to a duplicate, the idea for the solution I got from there. I hope I managed this the right way here (meaning adding the solution to the question above...) – Felix Feb 07 '17 at 10:12
  • @ChristianHupfer - Something telse me that this table isn't about charges, in Coulomb, of subatomic particles... :-) – Mico Feb 07 '17 at 15:13
  • @Mico: That's not the point :-P Small figures are not equivalent to zero ;-) –  Feb 07 '17 at 15:29
  • @ChristianHupfer - Small numbers are definitely not the same as 0 -- except, maybe, if they look suspiciously like the machine representation of the smallest displayable non-zero number. Given that the next-smallest (in absolute value) non-zero number in the table is 2.3e-3, my hunch is that -1.2e-16 is not a real (pun intended) number but a failure to apply sensible rounding criteria. Hopefully, the OP will weigh in and explain what the numbers actually represent. – Mico Feb 07 '17 at 15:46

1 Answers1

1

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?

enter image description here

\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}
Mico
  • 506,678
  • 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 07 '17 at 10:17