tooldura

ISO 32000-2, the current PDF standard, describes a file as a collection of numbered objects with one of them, the document catalog, acting as the root. The catalog points at a page tree, and the leaves of that tree are the pages. Everything you see when you scroll is in those leaves: content streams with the drawing operators, references to the fonts and images each page uses, and annotations such as links.

But the catalog holds far more than the page tree. The outline that fills the bookmarks panel is a separate structure hanging off the catalog. So is the interactive form dictionary, the list of named destinations, the attachments, the document-level JavaScript, the optional content groups behind layer visibility, and the XMP metadata packet.

Merging takes pages. Each page is copied into a new document along with everything it references, which is why nothing on the page itself is lost. The structures that hang off the old catalog have no page to travel with, and the new document has a catalog of its own containing only what the merge put there. That single fact explains almost every surprise on the list below.

A common worry is that a merged PDF has been re-rendered and lost sharpness. It has not. Copying a page moves its content stream verbatim, along with the exact image data and font programs it refers to. A scan that arrived as JPEG-compressed image data leaves as the same JPEG data, at the same compression, with the same artefacts and no new ones.

Size behaves the way that implies. The merged file is close to the sum of its parts, usually slightly smaller, for two reasons. Resources that several pages of one source file share are written once rather than once per page. And the output is written using object streams, introduced in PDF 1.5, which pack many small objects into one compressed stream instead of listing them individually.

The file gets bigger than the sum only when the sources shared something the merge cannot know they shared. Ten separate exports that each embed the same 4 MB subset of a corporate font arrive as ten copies of it, because they are ten distinct font programs as far as the file is concerned. That is the case where running the result through a PDF optimiser afterwards actually pays.

Order is the part people redo most, and it is almost always the same cause: the file manager and the merging tool disagree about what alphabetical means.

A plain string sort puts chapter-10 before chapter-2, because it compares the character 1 against 2 and stops there. Windows Explorer does not do this; it uses a natural sort that reads runs of digits as numbers. Anything that sorts by name should be doing the same, and this tool does, but a script you wrote with a bare sort call will not, and neither will many older utilities. The fix that works everywhere is zero-padding at the point files are named: chapter-02 and chapter-10 sort correctly under any rule ever written.

The second habit is scanning double-sided documents. Feed the stack once face up and once face down and you get two files, odds ascending and evens descending. Merging them in order interleaves nothing useful. Take odd pages from the first file, reverse the second, and merge, or scan them again with a duplex setting. The page selection box handles the odd and even halves; the reversal is why a backwards range such as 12-1 exists.

Page sizes need no thought at all. Each page keeps its own MediaBox, so an A4 report, a US Letter appendix and a landscape A3 drawing coexist in one file. Readers handle that without complaint. Printing a mixed file is the only place it shows up, and a scale-to-fit setting solves it.

Merging is the wrong move more often than it looks. Four cases:

A document someone has to fill in and return. Keep it separate and fillable rather than merged and inert.

Anything signed, whether by a digital certificate or a signing service. Forward the original bytes.

A file that has to stay PDF/A compliant for archiving. ISO 19005 constrains fonts, colour spaces and metadata, and a merge that mixes a compliant file with a non-compliant one produces a non-compliant result while still carrying the PDF/A identifier in its metadata, which is worse than an honest failure. Validate afterwards or merge before conversion.

And files that simply have different lifetimes. A proposal and its price list want to be merged; a proposal and a contract that will be signed separately do not. The one-file instinct is strong and often costs more than the extra attachment saves.