Book proofing, in the publishing production sense, means typeset proofing and prepress/layout validation: verifying that your final PDF or EPUB file is geometrically correct, resource-complete, and platform-ready before you upload. It has nothing to do with catching typos. The three things to run first are:
- Verify PDF geometry — confirm trim size, bleed (0.125" / 3.2 mm), and page boxes match your platform template exactly.
- Run EPUBCheck — target zero errors and zero warnings on your EPUB 3 file before submitting to any distributor.
- Run a platform preflight — use the KDP or IngramSpark preflight checklist on the exact files you plan to upload, not an earlier draft.
Alhora automates these validation checks inside its typesetting engine, flagging geometry and resource issues before you export.
Key Takeaways
A print-ready PDF and a conformant EPUB 3 file require geometry, resource, and platform checks in that order — run them on the final export, not a draft.
| Point | Details |
|---|---|
| Geometry first | Verify trim size, bleed (0.125"), TrimBox, and spine width before checking anything else. |
| 300 DPI minimum | Print images must meet this resolution at final size; upscaling a low-res source does not fix it. |
| EPUBCheck zero target | Target zero errors and zero warnings for broadest distributor compatibility across Apple Books, Kobo, and KDP. |
| Validate the final export | Run EPUBCheck and PDF preflight on the exact file you plan to upload, versioned and named clearly. |
| Alhora automates the checks | Alhora's typesetting engine and built-in validation flags geometry and resource issues before export. |
Table of Contents
- What book proofing actually covers (and what it doesn't)
- A quick 3-step proofing workflow to run before every upload
- PDF preflight checklist for print-ready files
- EPUB 3 validation: running EPUBCheck and fixing the top problems
- Platform-specific preflight rules and common rejection causes
- How many proof rounds to expect, and when
- Tools to run and what each one tells you
- Triage map: validator messages and first corrective actions
- When to DIY and when to hire a pro
- Proofing accessibility features in your ebook
- How to prepare and submit proofs to a professional
- Print-on-demand vs. offset printing: proofing differences
- What authors consistently get wrong about proofing
- Alhora handles the technical layer so you can focus on the book
- Sources
What book proofing actually covers (and what it doesn't)
This guide covers PDF and EPUB layout validation: pagination, typography, trim/bleed/gutter geometry, font embedding, image resolution, color profiles, accessibility metadata, and platform-specific preflight rules for Amazon KDP, IngramSpark, Apple Books, and Kobo.
Copyediting and manuscript proofreading are out of scope. Those disciplines catch grammar, spelling, and style errors in the text itself. Typeset proofing starts after the manuscript is locked and the first formatted export exists.
One rule that trips up a lot of authors: always test the final export file, not the working document. A layout that looks clean in your formatting software can still fail preflight after export if fonts aren't properly embedded or if the PDF writer applies unexpected scaling. Version your files clearly ("title_v3_final_export.pdf") and run every check on that exact file.
A quick 3-step proofing workflow to run before every upload
Order matters here. Most platform rejections trace back to geometry first, then resource problems, then platform-specific metadata. Running checks in the wrong sequence wastes time.
- PDF geometry and print template — Confirm trim size, MediaBox/TrimBox alignment, bleed, safe margins, and spine width. If your page count changed since you last exported, recalculate the spine.
- Resource compliance — Verify fonts are embedded and subsetted, images meet 300 DPI minimum for print, and color profiles are correct (CMYK for print covers, sRGB for ebook images).
- Platform preflight and EPUB validation — Run the platform's own preflight tool or checklist, and run EPUBCheck on your EPUB file. Fix blockers before moving to warnings.
Pro Tip: Save versioned filenames at each step ("title_v3_preflight_pass.pdf") so you always know which file passed which check. Running validators on an unversioned file is how authors accidentally upload a draft.
PDF preflight checklist for print-ready files
A print-ready PDF must satisfy geometry, resource, and export requirements before KDP or IngramSpark will accept it.
Geometry checks:
- Trim size matches the platform template exactly (e.g., 6" x 9" for a standard trade paperback).
- Bleed set to the commonly recommended size for print on all sides for any element that runs to the edge.
- Live content stays inside safe margins (typically 0.5" from trim on interior pages, more on the spine side).
- Spine width recalculated from final page count and paper type whenever either changes.
- MediaBox and TrimBox defined correctly in the PDF; no extra crop marks unless the platform explicitly allows them.
Resource checks:
- All fonts embedded and subsetted — run
pdffonts filename.pdfin the terminal to confirm. - Images at 300 DPI minimum; upscaling a 72 DPI image to 300 DPI in your layout software does not fix the source resolution.
- Print covers in CMYK; interior images in the color space your platform specifies.
- Barcode and ISBN area clear of bleed and live content.
Export settings:
- Export as PDF/X-1a or PDF/X-4 where the platform requires it; check platform documentation before choosing.
- No scaling applied during export (set to 100%).
- Cover exported as a single full-wrap file for IngramSpark; KDP accepts a separate cover PDF.
Pro Tip: Run Adobe Acrobat's Preflight tool (Output Preview > Preflight) on the exported PDF before uploading. It catches TrimBox mismatches and font issues that visual inspection misses entirely.
EPUB 3 validation: running EPUBCheck and fixing the top problems
EPUB 3 conformance requires a valid package document, correct manifest entries, fallbacks for any foreign resources, and well-formed XHTML and CSS. EPUBCheck reports violations of MUST terms as errors and SHOULD terms as warnings. The industry target is zero of both.
To run EPUBCheck from the command line:
- Download the latest EPUBCheck JAR from the W3C publishing repository.
- Run:
java -jar epubcheck.jar yourbook.epub - Read the output top to bottom. Errors block distributor acceptance; fix those first.
- Address warnings next — Apple Books and Kobo are stricter than the minimum spec.
Common failures to prioritize:
- Manifest/spine errors: an item listed in the manifest but missing from the spine, or vice versa.
- Missing fallbacks for non-core media types (audio, video, SVG without an HTML fallback).
- Invalid XHTML — unclosed tags, deprecated elements, or namespace errors.
- Incorrectly packaged fonts or images (wrong MIME type in the manifest).
Pro Tip: Semantic markup and manifest integrity matter far more than visual appearance. A file that looks perfect in your reader app can still fail EPUBCheck on structural grounds. Fix the code, not just the display.
Platform-specific preflight rules and common rejection causes
Each platform has its own preflight layer on top of the general PDF/EPUB standards.
Amazon KDP:
- Trim size must match a KDP-supported size exactly.
- Bleed: 0.125" / 3.2 mm; any element touching the edge needs it.
- Spine width recalculated from KDP's own spine calculator when page count changes.
- Interior PDFs: grayscale or CMYK; KDP converts RGB interiors automatically but results vary.
- Cover: CMYK, full-wrap for print, separate high-res JPEG for ebook cover.
IngramSpark:
- Use IngramSpark's downloadable template for your exact trim size and page count.
- Cover must be a single full-wrap PDF with the barcode/ISBN quiet zone respected.
- Spine text has minimum width requirements; IngramSpark will reject a spine with text if the spine is too narrow.
- Font embedding is strictly enforced — no exceptions.
Apple Books and Kobo:
- Both expect EPUB 3 conformance; Apple enforces this at import.
- Fixed-layout EPUBs must be tagged as
pre-paginatedin the package document. - Apple Books has a 2GB guidance limit for embedded PDFs; large illustrated books need careful asset management.
- Use Safari Web Inspector on macOS to debug rendering issues in Apple Books before submitting.
Pro Tip: If you're distributing to multiple platforms, test on IngramSpark first. Its preflight is the strictest for print. Pass IngramSpark and you'll likely pass KDP with minor adjustments.
How many proof rounds to expect, and when
Proof rounds follow a standard sequence whether you're publishing a short trade paperback or an illustrated children's book.
- First-pass/layout proof — The formatter or typesetting software produces the first paginated output. The author reviews for layout breaks, widows, orphans, and pagination. No text changes after this point without re-checking pagination.
- Second-pass corrections — Fixes from the first pass are applied. A second review confirms nothing broke in the process. Pagination is frozen here for index compilation.
- Repro/contract proof — A final proof that matches the production file exactly. For offset printing, this is the color contract proof the printer matches on press.
- Press check (offset only) — Optional but recommended for illustrated or color-critical books. You or your designer reviews the first sheets off the press.
A typical trade paperback runs through rounds 1 and 2 in one to two weeks. An illustrated book with color proofing can take three to four weeks, especially if the printer is overseas.
Pro Tip: Build two extra days into your schedule for platform rejection and resubmission. KDP and IngramSpark reviews are not instant, and a geometry fix followed by re-upload can cost you a launch date.
Tools to run and what each one tells you
- EPUBCheck — Validates EPUB 3 structure, manifest, and conformance. First action when it flags an error: read the line number and element name, then open the OPF or XHTML file at that location.
- Adobe Acrobat Preflight — Checks PDF geometry (TrimBox, BleedBox), font embedding, color spaces, and image resolution. First action on a flag: open Output Preview to see which objects triggered the rule.
- pdffonts — Command-line tool that lists every font in a PDF and whether it's embedded. Run it on every export; any "no" in the Emb column is a blocker.
- Safari Web Inspector — Connect an iOS device or use macOS Books to debug fixed-layout EPUB rendering. Apple's asset guide documents the setup steps.
- Print Validation pre-upload checker — A web-based checklist tool that walks through KDP and IngramSpark geometry and resource requirements before you upload.
Pro Tip: Automate repeat checks with a shell script that runs pdffonts and EPUBCheck on every new export. A two-line script that logs results to a text file takes ten minutes to write and saves hours across a series.
Triage map: validator messages and first corrective actions
| Validator message | First corrective action | Second corrective action |
|---|---|---|
| Bleed missing or insufficient | Reopen layout, extend bleed to 0.125" on all edges | Re-export and re-run preflight |
| Fonts not embedded | Re-export with "Embed all fonts" enabled; check pdffonts output | Check for system fonts that can't be embedded; substitute licensed fonts |
| Cover dimensions incorrect | Recalculate spine from platform calculator; regenerate cover template | Re-export full-wrap cover at correct dimensions |
| EPUB manifest/spine error | Open OPF file; match every spine idref to a manifest id | Validate with EPUBCheck and confirm zero errors |
| Image resolution below 300 DPI | Replace source image with high-resolution original | If no high-res original exists, remove or redraw the element |
| TrimBox/MediaBox mismatch | Re-export PDF with correct page box settings | Verify in Acrobat Preflight > Page Boxes |
Fix blockers (errors) before warnings. A file with one geometry error and twenty warnings will be rejected; a file with zero errors and five low-priority warnings often passes.
Pro Tip: Sort your EPUBCheck output by error type, not line number. Fixing one manifest error often resolves a cascade of downstream warnings automatically.
When to DIY and when to hire a pro
Most reflowable ebooks and standard trade paperbacks are well within reach for a careful self-publisher using the right tools. Fixed-layout books, illustrated children's books, and titles with complex typography (poetry, tables, sidebars) are where DIY proofing gets expensive in time.
Signs you should hire a professional formatter or typesetter:
- Fixed-layout EPUB with precise image placement.
- Illustrated or heavily designed interior (cookbooks, art books).
- Offset print run where a press check is required.
- Tight launch deadline with no buffer for rejection cycles.
The middle path is using software like Alhora that handles the typesetting engine automatically (justification, hyphenation, widows/orphans) while giving you built-in validation checks before export. You stay in control of the creative decisions; the software handles the technical compliance layer. For a small publisher managing a series, Alhora's batch formatting and version control features reduce the per-title proofing workload significantly.
Proofing accessibility features in your ebook
Accessibility proofing is not optional if you're distributing through Apple Books or targeting EPUB 3 compliance. The checks to run:
- Confirm every image has a meaningful
altattribute in the XHTML source (not just an empty string). - Verify the reading order in the OPF spine matches the logical reading sequence of the book.
- Check that the
epub:typesemantic attributes are applied to landmarks (cover, toc, bodymatter). - Confirm the language attribute (
xml:lang) is set correctly on the package document and any foreign-language passages. - Test with a screen reader (VoiceOver on macOS or iOS) to catch reading-order issues that EPUBCheck won't flag.
Accessibility metadata in the OPF (schema:accessMode, schema:accessibilityFeature) is increasingly required by distributors and is worth adding even when not yet mandatory.
How to prepare and submit proofs to a professional
When handing files to a typesetter or proofreader for layout review, send the right version:
- Export a PDF proof (not the source file) with crop marks and color bars if the reviewer needs to check print geometry.
- Include a brief spec sheet: trim size, bleed, target platform(s), font list, and any known issues from your last preflight run.
- Use a shared folder with clear versioning ("title_v2_for_review.pdf") so neither party works on a stale file.
- Specify what kind of review you need: layout-only, accessibility check, or full preflight sign-off. A typesetter reviewing for widows and orphans doesn't need the same file as a prepress technician checking color profiles.
For EPUB submissions, send the .epub file plus your EPUBCheck report so the reviewer knows the current error count and doesn't duplicate work you've already done.
Print-on-demand vs. offset printing: proofing differences
Print-on-demand (POD) platforms like KDP and IngramSpark use digital presses and automated preflight. You upload a PDF, their system checks it, and you order a physical proof copy to review before wide release. The tolerance for color variation is higher than offset, and you can update files after publication.

Offset printing requires tighter prepress work. You'll supply a press-ready PDF to a commercial printer, who produces a contract color proof (often a Kodak Approval or similar) that you sign off on before the press run. Color profiles matter more: CMYK values need to match the printer's press profile, and any error discovered after plates are made is expensive.
The practical difference for self-publishers: POD proofing is iterative and forgiving; offset proofing is a one-shot commitment. For a first print run of a color-critical book, order a physical proof copy from your POD platform before committing to an offset run — it's the cheapest way to catch layout problems at scale.
What authors consistently get wrong about proofing
The most common mistake is running validators on a working draft instead of the final export. EPUBCheck on a draft EPUB is useful for catching structural issues early, but the file you upload must be the file you validated. Export, validate, upload — in that order, every time.
The second mistake is treating EPUBCheck warnings as optional. Apple Books and Kobo both enforce stricter conformance than the minimum spec. A file with warnings that passes KDP can still fail on Apple Books at import.
Spine recalculation is the third overlooked step. Authors finalize their interior, adjust the page count by a few pages during final edits, and forget to regenerate the cover template. The spine is now the wrong width, and IngramSpark rejects the cover.
Visual inspection alone is not a preflight. A PDF that looks correct on screen can still have unembedded fonts, an incorrect TrimBox, or RGB images in a CMYK document. Run the tools.
Alhora handles the technical layer so you can focus on the book
Getting from a finished manuscript to an upload-ready file means clearing a checklist most authors encounter only when something fails. Alhora is built to close that gap before the first rejection.

Alhora's typesetting engine handles justification, hyphenation, and widow/orphan prevention automatically. Its built-in validation checks flag geometry and resource issues before you export, so you're not discovering a missing bleed or an unembedded font after uploading to KDP. Exports target KDP, IngramSpark, Apple Books, Kobo, Draft2Digital, and Google Play from a single formatted source. The AI-assisted proofreading layer flags structural and layout issues without touching your text.
For independent authors and small publishers who want professional results without a full prepress workflow, start with Alhora and export files that are ready to upload the first time.
