3

I'm working on a mathematical problem (too much detail will be a spoiler) which involves getting data via a third-party program (there's a complicated algorithm involved that I do not understand, but the guy who wrote the program did).
The program produced data in the form of a LaTeX table (ampersand delimited) with, among other things, extremely many columns (it started at more than 30, and went up from there).

I have already searched on various ways of fitting the result into a page (landscape orientation, small font, shrinking the whole thing, etc). They worked well enough in the simple cases (up to around 150 columns).
However, I've encountered a bigger problem.

My latest table is about 300 columns wide (301 or 302, I think), but when I put it in my MiKTeX (and add the header, and shrink, and landscape-orient, etc) I can only see the data in the last several dozen columns. Most of the rest is empty.
The number of surviving columns is close to 300-256, so I suppose it could be a byte overflow. No idea what it is really.

As such: is there any reasonable way (package, environment, ...) to make the table work so that all the 300 columns are visible? (Assuming that if the text is there, however small, it counts as visible; since it's a vector format, I can always just crank up the PDF magnification.) If yes, would it mesh well with the usual shrinking methods (shrinking the table object, in particular)?

Bonus: is there a (reasonably easy) way to make the document sheet itself large enough to fit the table? I'd rather not need too much magnification, because on some models of PDF viewers, it only goes up so far (in some cases, IIRC, as low as 8x).

January First-of-May
  • 131
  • 4
    How is anyone meant to read this? It sounds like a data dump which is not meant for human consumption (and thus not for typesetting). – Joseph Wright Jan 25 '16 at 16:44
  • 1
    just \resizebox{\textwidth}{!}{\begin{tabular}.... will scale it arbitrarily to fit the specified text width or you can split up the table and print so many columns per page, for which there are answers on site – David Carlisle Jan 25 '16 at 16:44
  • 1
    If your cells contain something, at least half a centimeter must be allocated (probably more); for 300 columns, this makes for 150 cm, that is, very wide sheets are needed. – egreg Jan 25 '16 at 16:46
  • 300 columns is a bit much for standard page sizes. I would put it on a big scroll of paper. Looks fancy as well ;-) – Johannes_B Jan 25 '16 at 16:47
  • 1
    @JosephWright - it is kind of meant for human consumption (carefully, on 16x magnification), and definitely not meant for physical typesetting but that's not important anyway. "Data dump" is a good description, but we do need to do something to that data later. – January First-of-May Jan 25 '16 at 16:52
  • 2
    If you are not limited to a phhysical page size, package geometry will allow you to easily define a page of 150cm by 50cm (or whatever values are needed). – Johannes_B Jan 25 '16 at 16:54
  • @DavidCarlisle - that's basically what I did, for the former. As for the latter... is there a reasonable way to split up the table without splitting each row individually (and carefully counting the ampersands)? I'd rather not have to do that - at least, not without a regex solution ready. – January First-of-May Jan 25 '16 at 16:54
  • @DavidCarlisle - to be precise, I did a \resizebox with a specified factor, IIRC (about 0.07 for one of the smaller tables, thus the 16x magnification). – January First-of-May Jan 25 '16 at 17:00
  • 2
    see http://tex.stackexchange.com/questions/93808/column-wise-break-of-extra-wide-tables/93810#93810 – David Carlisle Jan 25 '16 at 17:00
  • @DavidCarlisle Thanks! I was unaware of this question (it didn't come up in my searches, or on the "similar" lists when i create this one). It's still an ampersand-counting solution, and might be too long for the 300-column table, but I'll definitely try to use it to make the old 30/60/150 column tables neater. – January First-of-May Jan 25 '16 at 17:08
  • What is in the cells? numbers? if so, it could be better to just plot the data (using pgfplots). – alfC Jan 26 '16 at 22:20
  • @alfC I don't want to explain too much about the underlying mathematical research, but no, it's not numbers. (Not that I would have used a plot, anyway; the data dump is too big.) – January First-of-May Jan 26 '16 at 23:06

2 Answers2

1

Not an answer to the question asked, but maybe helpful and too long for a comment.

Excel can be told to read an ampersand delimited file. Perhaps browsing the data there (scrolling, hiding columns) will be useful. You can save (parts of the file) as a pdf from Excel

And Excel is likely to be the right place to "do something to that data later".

Ethan Bolker
  • 9,333
  • 3
  • 42
  • 69
0

It looks like you are hitting some hard coded limit or stack limit. This cannot be a problem with space because in principle you can use a larger page or \scalebox{0.1}{...}.

Two possible ways to overcome this:

1) Try using lualatex, which has higher memory limits.

2) Divide the table into 4 (2x2) smaller tables and put them together (vertical and horizontal spacing can be adjusted to have a smooth join).

alfC
  • 14,350