Test Publishing Software With a Difficult Nonfiction Chapter

Test a publishing app with a small but difficult chapter from your own project. Include the elements most likely to break during editing or export, define what a usable result looks like, and repeat the test after one realistic correction. Save the evidence so you can compare tools by their outputs rather than their feature descriptions.

Build a test fixture from real material

Choose a short chapter containing a four-column comparison table, a note, two diagrams, a numbered procedure, and a captioned image. If your manuscript does not contain those elements, substitute the ones it actually needs. The point is to represent your production problem, not to construct an artificial torture test. Use material you own and remove private information before trying unfamiliar services.

Keep an unchanged reference copy outside the app. Give every element a clear identifier, such as Table A, Figure B, and Procedure C, and record the expected relationships. A caption must remain with the correct image, a note must lead to the right explanation, and procedure numbering must remain coherent. These expectations make it easier to distinguish a genuine defect from a visual preference about spacing or type size.

Check the editing behavior before export

Import or recreate the chapter using the workflow the app recommends. Record any cleanup needed before ordinary editing can begin. Inspect heading levels, table cells, image captions, and paragraph styles. A chapter that looks acceptable at first glance may have lost its underlying structure, leaving every later revision dependent on manual formatting. Note whether you can select and edit the actual content rather than only a flattened visual object.

Make one deliberately realistic change. Add a row to the table, insert a new step in the procedure, and replace a diagram with a corrected version. Check whether references, numbering, and placement still make sense. Undo and redo the change if the app supports those actions, then save and reopen the project. The test should include a normal correction cycle, because nonfiction files rarely remain unchanged after the first export.

Inspect each exported format independently

Export the formats you actually intend to deliver. Open the results outside the publishing app using suitable readers or preview tools. For print, inspect page breaks, table readability, image placement, and the relationship between captions and figures. For an ebook, follow navigation and notes and check how the content behaves at different reading sizes. A successful print export does not establish that the ebook version is usable.

Compare the exported chapter against your reference expectations element by element. Record a screenshot or a concise description of each defect with the file version and location. Do not settle for "the PDF looked fine" when the table headings became separated from their values. Distinguish issues you can fix reliably in the source from issues that require repeated manual repair after every export, since the latter create ongoing production work.

Test what happens when you leave the app

Find out what source material you can retrieve in a form that remains useful elsewhere. Export the editable manuscript, images, and any supported project archive. Open the retrieved files and check whether the essential structure and content survive. A download button proves that a file exists; it does not prove that another application can use the file or that all linked assets were included.

Document the practical limits without assuming a particular business policy. Some services may offer different export paths or account controls, and those details can change. Inspect the current behavior and terms that apply to your trial. Keep the test narrowly focused on your needs: can you preserve the manuscript, rebuild the output, and recover the assets needed for a correction if you decide to move the project later?

Turn the results into a repeatable decision

Create a comparison sheet with the test, expected behavior, observed result, workaround, and consequence. Use meaningful outcomes such as "table remains editable" or "note links survive export." Avoid averaging a serious failure into a reassuring overall score. If the app cannot produce a required deliverable, that issue deserves a clear decision even if several convenience features work well.

Repeat the same fixture and correction in any alternative app you compare. Keep the source material and acceptance criteria consistent so differences are interpretable. Select a tool only after you understand the remaining repair work and the current KDP requirements for the intended format. Preserve the fixture as a regression example: it can help check an important software update or a new export method before the full manuscript depends on it.