Tables and charts in a print book: what survives typesetting (and eBooks)

By Tracy Atkins, founder of BookDesigner.ai and BookDesignTemplates.com · 15+ years of print files, 70,000+ authors · Updated August 21, 2026

Why a table that looks fine on screen fails on the page

Most tables start life in a word processor or spreadsheet, built for a widescreen monitor. A print trim is nowhere near that wide. A 6x9 book, for example, has a text block considerably narrower than a laptop screen, and every column in that table has to fit inside it at a size a reader can actually read without a magnifying glass.

The failure shows up in one of three ways: columns get squeezed until numbers wrap awkwardly, the whole table gets shrunk below body text size to make it fit, or the table simply runs off the page and the designer has to rebuild it from the source data. None of these is a formatting nicety; each one is a decision that changes how usable the table is for the reader holding the finished book.

What holds up at trim width

• Tables with three to five columns and short cell contents (numbers, single words, short phrases)
• Tables set at or near body text size, not shrunk to squeeze in more columns
• Tables that break across a page cleanly, with repeated header rows if they run long
• Wide tables rebuilt as two stacked tables, or turned sideways as a landscape spread, rather than crammed narrower

If a table genuinely needs more columns than the trim can hold at a readable size, the honest options are: simplify the data, split it into two tables, or accept that the page will need a wider trim size than the rest of the book, which most printers do not support within a single interior. In practice, simplifying the table is almost always the better outcome for the reader anyway.

Charts: resolution and readability

A chart exported from spreadsheet software is usually built for a screen, and screens and printed pages are different targets entirely. IngramSpark's file requirements call for 300 PPI at the image's final print size, and files under roughly 200 PPI risk rejection outright. That means the chart has to be exported, or the source graphic sized, so that at the exact width and height it will appear on the page, it still meets that resolution. A chart that looks crisp on a monitor can come out visibly soft or blurred once it is placed at full page width in a print interior, because the underlying image never had enough pixel density for that physical size.

The fix is straightforward but easy to skip: decide the chart's final trim-page dimensions first, then export or re-render the image at 300 PPI for those exact dimensions, rather than dropping a screen-resolution chart into the layout and scaling it up.

Grayscale is the real test

If your interior prints in black and white, every chart needs a second check: does it still make sense with the color removed? A line chart that distinguishes two trends only by red versus green becomes two identical gray lines. A pie chart that relies on hue to separate five slices becomes five shades of gray that are hard to tell apart. Bar charts and scatter plots have the same problem whenever color is the only thing carrying the meaning.

The practical fix is to build charts with more than color doing the work: distinct line styles (solid, dashed, dotted), patterns or textures on bar fills, and direct labels on the chart itself rather than a color-keyed legend. A chart designed this way reads correctly whether the book prints in color or black and white, and it also serves readers with color vision differences, which is worth doing regardless of print format.

What happens when the same book goes to eBook

EPUB is built to reflow. A reader can bump the font size up, switch fonts, or read on a phone instead of a tablet, and the text reshapes itself to fit. A table or chart built as a fixed grid cannot reflow the same way, which is why tables and charts are one of the most common places an EPUB conversion visibly breaks even when the print interior looks perfect.

Two paths generally work. Simple tables, meaning a handful of columns with short entries, can often survive as real HTML tables inside the EPUB and will reflow along with the rest of the text, though they may still look cramped on a small phone screen. Complex tables and virtually all charts are safer treated as images: exported once, sized reasonably for an eBook page, and dropped in with descriptive alt text so a screen reader or accessibility tool can still convey what the table or chart shows, even to a reader who cannot see the image itself.

Whichever path you choose, decide it once per table or chart rather than case by case in the middle of formatting. Consistency across a book's tables and charts is part of what makes an interior feel professionally produced rather than assembled piecemeal.

The habit that prevents most of this

Decide early whether your book leans on tables and charts as a core part of the content, and if so, build them with the final trim size and print method in mind from the start rather than importing screen-native graphics late in the process. A book with heavy data visualization, dense reference tables, or technical diagrams is also a case where it is worth being honest about scope: this kind of interior sits outside what most general-purpose formatting tools, including ours, are built to handle well, alongside cookbooks and heavily illustrated titles.

Sources: IngramSpark File Creation Guide (5.11.26) resolution and rejection thresholds. Related: PDF/X-1a, explained · Trim size guide · Cream vs. white paper