Turning data into something a person can read
CSV is a transport format, not a presentation one. It is excellent at moving rows between systems and poor at being read: open one in a text editor and you get comma-separated chaos, open it in a spreadsheet and the recipient can accidentally re-sort a column and change what the data says.
A PDF fixes both. The table is laid out with visible columns and readable alignment, and it cannot be edited by the person receiving it. For a report, an invoice line listing, a price list or a set of results being circulated for review, that combination is exactly right.
It also makes the data printable in a predictable way, which spreadsheets are notoriously bad at — anyone who has printed a wide spreadsheet and received nine pages with two columns each knows the problem.
Handling wide tables
The main constraint is page width. A table with six or seven columns fits comfortably on a portrait page; one with twenty does not, and something has to be done about it.
The options, in rough order of preference: switch to landscape, which buys you roughly forty percent more width for very little cost; reduce the font size, which works until the text stops being readable; or drop columns that the recipient does not need. The last is usually the best answer, because a table nobody can read is not more useful for containing every field.
Where every column genuinely matters, splitting the table across two pages by column group — key identifiers repeated on both — reads far better than shrinking everything to fit. It takes more setting up and produces something people can actually use.
Getting the source data right first
Most problems with converted tables originate in the CSV rather than the conversion. Check that the first row is a proper header, since a table whose columns are labelled 1, 2 and 3 tells the reader nothing.
Watch for fields containing commas — addresses and free-text notes are the usual offenders. Properly quoted CSV handles them correctly, but files exported by hand or assembled by a script frequently are not properly quoted, and the result is a row whose columns have shifted by one.
Finally, decide about number formatting before converting rather than after. Thousands separators, currency symbols, decimal places and date formats are far easier to fix in the data than in the finished document, and inconsistency in a printed table is much more noticeable than it is on screen.
Presenting numbers so they can be read at a glance
A few conventions make a table markedly easier to read, and they cost nothing. Right-align numbers so that digits line up by place value, which lets a reader compare magnitudes down a column without reading each figure. Left-align text. Never centre either, since centred columns give the eye no consistent edge to follow.
Use a consistent number of decimal places within a column. A column mixing 1.5, 1.75 and 2 reads as inconsistent even though the values are fine, and it destroys the alignment that makes scanning possible.
Where a table is long, banded rows or a rule every five lines helps the eye stay on a row across the page width. This matters far more in print than on screen, where a reader can use the cursor as a guide, and a printed table without it is where transcription errors come from.
Give the table a caption saying what the data is, where it came from and as at what date. A table of figures with no provenance invites exactly the questions the document was meant to answer, and six months later nobody — including you — will remember which extract produced it.