Organising a long document without losing your place

Assembling a bundle from a dozen sources is not difficult, but it is easy to do in a sequence that creates work. A few habits make it quick.

Decide the order before you merge

Renaming files so they sort correctly takes a minute and saves fighting with a reordering interface later. Numbered prefixes work: 01-cover, 02-report, 03-appendix.

Most tools merge in the order files are listed, and most file pickers list alphabetically. Making those two agree removes a whole class of mistake.

Merge first, then number

Page numbers added before merging will restart at each section. Add them once, at the end, when the document is in its final order.

The same applies to headers and footers. Anything that refers to the document as a whole should be applied to the document as a whole.

Standardise page size at the merge

A bundle assembled from an exported report, a scanned signature page and a spreadsheet printout will contain at least two page sizes. This is invisible on screen, where each page displays at its own size, and obvious the moment anyone prints it.

If the document will be printed, set every page to one size when merging.

Extract rather than delete

When you want a subset, name the pages to keep rather than the pages to remove. Both get you there, but the failure modes differ: forgetting to delete a page leaves confidential content in a document, while forgetting to include one produces an obvious gap that someone will notice.

Make the default exclusion.

Work on a copy of the original

Every operation here produces a new file. Keep the source until the result has been checked, because the check sometimes reveals that the wrong version went in three steps ago.

Check the joins

When you have finished, scroll the whole document once, paying attention to the boundaries between sections. That is where duplicated pages, missing pages and upside-down scans show up, and it takes a minute.

A note on bookmarks

Merging generally discards bookmarks and the document outline. If a long bundle needs navigable structure, that has to be added after assembly, in a tool that supports it. Worth knowing before you build a two-hundred-page document and discover the contents page does not link to anything.

Deciding the structure before you start

The order to assemble in is: get the content right, then the order, then the numbering, then the navigation. Doing them out of sequence creates rework at every step.

Content first means resolving which version of each source file is current. This sounds trivial and is where most bundle errors originate: a schedule that was superseded, an unsigned copy of something that was later signed, a draft that looks identical to the final.

Name the files so they sort correctly before you touch a merge tool. Numbered prefixes do this reliably, and they double as a checklist.

Handling a bundle that changes

Long documents rarely get assembled once. Something is added, a section is replaced, a page is found to be missing.

Keep the source files rather than editing the merged output. Re-merging from corrected sources takes a minute; surgically patching a two-hundred-page bundle takes an afternoon and introduces mistakes.

Keep the assembly order written down, even if only as filenames. Six weeks later, when someone asks why the appendix is where it is, you will want it.

Numbering that survives revision

Add page numbers last, after the document is final. Numbers added before a change become wrong the moment anything moves.

For bundles that will be referred to in correspondence, sequential numbering across the whole document matters more than per-section numbering, because a reference to "page 84" needs to mean one thing.

If the document is going into a legal or regulatory process, use a numbering scheme with a prefix so that references remain unambiguous when several bundles are in play at once.

Navigation for anything long

Past about thirty pages, a reader needs a way to move around that is not scrolling.

Bookmarks give a reader a contents panel that jumps to sections. They are separate from any printed contents page, and merging discards them, which is why they are built last.

Build them from the final structure, one per major section, nested one level for subsections. More than two levels is rarely read.

The final pass

Scroll the whole document once, at a zoom where you can read headings. Look at the joins between sections, which is where duplicate and missing pages appear.

Check the first page, the last page, and the page after each section boundary. That covers the great majority of assembly errors in a fraction of the time a full read takes.

Working with someone else's bundle

If you are handed an assembled document rather than its sources, resist editing it in place.

Split it back into sections, correct what needs correcting, and reassemble. That gives you the same working method as if you had built it, and it produces a document whose structure you understand well enough to fix again next month.