Make a TV Bible PDF With a Working Contents Page and Bookmarks

A contents page works when its entries land on the sections they name.

That is the whole test, and it is stricter than it sounds, because a generated contents page actually produces three separate things that fail separately:

The visible list. Entries, indents, page numbers. This is the part you look at. The links. Each entry's hyperlink, which carries its own idea of where "Characters" begins. The bookmark panel. A second, independent navigation tree, and the one a producer skimming on a tablet will probably use.

All three derive from the same headings in your source document, and all three can disagree with each other. A list can show the right number and link to the wrong page. A bookmark can land correctly and sit at the wrong level. A section can move, and only two of the three outputs will notice.

On paper, a page number in a contents list is a promise the reader tests by turning to the page. In a PDF the promise is machine-checkable: the entry either arrives or it doesn't. The number stops being the navigation and becomes a label attached to it — which means the number can be right while the navigation is wrong. That is the failure worth engineering against, and it is why printed page numbers alone will never carry a reader through a forty-page bible.

What follows is the order I would build it in, using an invented bible so the decisions stay concrete.

The invented bible we'll build against

I haven't built or exported this file. The numbers below follow from the section lengths I chose, so you can check the arithmetic, but they are not measurements of anything. Treat the walkthrough as a plan to run rather than a record of something that happened.

The show is called Ashgrove. The bible runs to 45 pages, with eight sections and two heading levels. Before revision it looks like this:

Two features of this bible matter for the lesson. Under Characters there is a subsection heading that runs long — "3.1 Mira Vance — a forensic auditor who finds the discrepancy that unravels the family firm" — and it will test your contents layout harder than anything else in the document. And one section, Tone and Visual Language, is going to move to a different position later, which will break things quietly.

Turn the headings into generated entries

Give the eight section headings a paragraph style called Section Head. Give the subsections a second style called Subsection Head. Then don't touch either one by hand again.

The reason is that a generated contents list is built from styles, not from text that looks like a heading. A heading you bolded and enlarged manually is invisible to the generator, so it produces no entry, and then someone retypes the entry into the contents list, and now you have navigation that is maintained by hand — which is where the whole thing starts to rot.

In InDesign, open Layout > Table of Contents. You are answering two separate questions in that dialog: which styles supply entries, and which styles format them. Answer them differently. If your contents entries wear the very heading styles the generator is hunting for, they are candidate headings themselves, and the next update may pick them up as sources. Give the contents entries their own styles — Contents Section, Contents Subsection — and that question disappears.

Set the level nesting here too: Contents Subsection sits under Contents Section, indented, one level down. Adobe's documentation on generating and maintaining tables of contents covers generating the list and updating it, and the important thing it establishes for our purposes is that an update replaces the contents story — including anything you typed into it by hand. Hold that thought; it decides a whole maintenance argument later.

Keep the contents in its own story

A story in InDesign is a connected run of text frames. If you thread your contents frames into the bible's body text, then flowing text, adding a page, or moving a section can shove the contents around, and updating the contents replaces the whole connected run. Threading them is convenient once and expensive repeatedly.

Keep the contents as an unthreaded story on its own page, ideally right after the title page. When you update, you replace exactly one story and nothing else moves.

The long entry

Now the Mira Vance problem. In a narrow contents column, an approved subsection heading of that length will run to two or three lines, or clip, or push its page number into a second line that reads as a separate entry.

The tempting fix is to shorten the entry text. Don't. The entry is generated from the heading, so a shorter entry is a lie about what is on the page — and it will be overwritten the next time you update the contents anyway. You would be making a permanent editorial compromise to solve a temporary layout problem, and it wouldn't even survive.

The fixes that hold are layout fixes. Widen the contents frame, or reduce the size of the Contents Subsection style, or set a hanging indent so a wrapped line aligns under the entry rather than under the number. If the heading genuinely is too long for the bible, change it in the source, where it will change everywhere at once. That is the only route that produces one version of the truth.

Export, then look in the panel

The Table of Contents dialog has an option to create PDF bookmarks. Turn it on. The levels you include in the contents become the levels of the bookmark tree, which is why you decided the hierarchy back when you set up the styles rather than afterwards.

Export through the interactive PDF route for this walkthrough, because that is the path built to carry links. If you export with a different preset, don't assume the same result — open the file and look. Exported links behave differently depending on the preset and the export options, and the preset name is a label, not a guarantee.

Then open the exported PDF and look at the bookmark panel before you look at anything else. You are checking two things at once: does a tree exist, and does its shape match the two levels you designed.

Hierarchy is not destination

These two ideas sit together in one panel and get confused constantly.

A bookmark's hierarchy is where it sits in the list. A bookmark's destination is where it takes you. Adobe's help page on page thumbnails and bookmarks covers creating a bookmark, editing it, and building a hierarchy, and notes that a bookmark can target a particular page view — which is how you know these are independent properties.

So: drag a subsection bookmark under its parent. Nothing in the document moves. No page reflows, no section relocates, no content changes at all. You have reordered the panel and nothing else. It is worth doing once deliberately, just to feel the distinction in your hands, because everything downstream depends on keeping it straight.

When a bookmark lands in the wrong place, select the page and the view you actually want, then retarget the bookmark to that destination. Acrobat provides a command for this — the label varies between versions and platforms, so match on the function rather than hunting for exact wording. What you want is the control that redefines where the selected bookmark goes.

Then decide honestly which kind of fix you just made. An export-only correction is a patch. If a bookmark is wrong because a heading is missing its style, or because the heading sits outside the story the generator reads, retargeting the bookmark hides the symptom and the next export restores the fault. Fix the source, note in your own records if you also patched the PDF, and expect that patch to be undone the next time you export. A silently patched file that gets regenerated six weeks later is worse than a known-broken one.

Move a section and regenerate

The producer reads the bible and wants tone and visual language earlier — before the characters, not after the episode guide. So Tone and Visual Language moves from position six to position three. Nothing else changes.

Work out what that does to the arithmetic before you open the file:

The three sections that came after the insertion point shift by four pages — exactly the length of the section that was inserted ahead of them. The two sections that came after the moved section's old position don't move at all. The document is the same length; the change redistributes it internally, and the tail absorbs it.

Which sets a trap. If you spot-check the end of the contents, you find 38 and 42 sitting exactly where they were, and you conclude the export is fine. The damage is in the middle: Characters, Season One Arc, and Episode Guide now have entries pointing at pages that no longer hold what they claim.

In InDesign, update the contents after the move, then export a fresh PDF. Don't retype the numbers. An update replaces the generated story wholesale, so retyped numbers are work you will do again and again — and the one time you forget, they will be wrong instead of merely typed. Then re-check the long Mira Vance entry, the bookmark nesting, and every destination that changed. Page-number order on its own tells you nothing: three entries can show a perfectly ascending sequence of numbers and still land in the wrong three places.

Check the routes, not the screenshot

A screenshot of a handsome contents page is not evidence. Build a small route table instead — entry, intended destination, actual result, return route — and work through it.

Follow every contents entry. Not a sample. Eight sections and something like twenty subsections is under thirty clicks on a bible this size, and the clicks you skip are always the ones that broke.

Follow every bookmark, and check the level. A subsection sitting at the top level isn't a broken link, but it is a broken hierarchy, and it makes a long panel useless.

Check the return route. Your reader will land in Season One Arc and want to get back. Two designs work: a single bookmark at the top of the tree that returns to the contents, or a link at the foot of each section. The bookmark costs you one thing to maintain and lives in the panel the reader is already using; the footer link is visible on the page and survives a closed bookmarks panel. Pick one deliberately, check the one you picked, and if you build both, maintain both.

Read the pages in order, without touching any navigation. Navigation cannot tell you the reading order is wrong, because navigation exists precisely to let a reader skip the order. A bible can have flawless bookmarks and still present the world before the logline. Read it straight through once.

Check the numbers against the folios. The number printed in the contents is a claim about the number printed on the page; a viewer's page counter is an index. If the file was assembled from several exports, or has a cover that doesn't count, the two can drift apart.

Write down what you checked it with. Version of InDesign, version of Acrobat, platform. A route that works in Acrobat is a verified route in Acrobat and nothing more. If this bible is going to a producer who opens it in a browser's built-in viewer or on a phone, that is a separate check and should be labelled as one rather than assumed.

And keep the scope honest in your own head: this is a navigation check. Tagged reading order, alt text, contrast and heading semantics are a different audit with different tools. A PDF can navigate beautifully and be miserable to listen to.

What you're handing over

The deliverable is not a list of features. It is the revised PDF alongside a checked route table and a note of the versions you verified it in — plus one specific proof: after the section moved, every entry that should have changed did, every bookmark still lands where it says, and a reader can still get back.

Keep the InDesign source as the maintenance path. The next revision will arrive, and the only thing that will make it cheap is that the navigation regenerates from the headings rather than being rebuilt by hand. Any repair you made directly in Acrobat should be written down somewhere, because regenerating will quietly reverse it — and the failure will look like a mystery rather than a known cost.

The contents page is a promise. The destinations are the delivery. The page numbers are neither, and a bible whose entries land every time is worth more than one with a prettier list.

Frequently asked questions

What three things does a generated contents page produce, and why can they disagree?

It produces a visible list with entries and page numbers, hyperlinks for each entry, and a bookmark panel. All three derive from the same headings, but they fail separately. The list can show the right page number and link to the wrong page. A bookmark can land correctly and sit at the wrong level. A section can move and only some of the three outputs may notice.

Why use paragraph styles for headings and separate styles for contents entries?

A generated contents list is built from styles, not from text that merely looks like a heading. Give section headings one style and subsections a second style. Give contents entries their own styles, so they are not mistaken for source headings on the next update. Set the nesting there too, with subsection entries indented under section entries. A manually bolded heading produces no generated entry, and retyped entries become hand-maintained navigation that starts to rot.

Why not shorten a long subsection entry to fit the contents column?

The entry is generated from the heading, so a shorter entry is a lie about what is on the page, and it will be overwritten the next time the contents are updated. Use layout fixes instead: widen the contents frame, reduce the size of the contents subsection style, or set a hanging indent so a wrapped line aligns under the entry rather than under the number. If the heading genuinely is too long for the document, change it in the source so one version of the truth changes everywhere at once.

What happens when a section moves, and what should be regenerated?

In the example, moving Tone and Visual Language from position six to position three shifts the three sections after the insertion point by four pages, exactly the length of the inserted section. The sections after the moved section's old position do not move, so checking only the end of the contents can miss damage in the middle. Update the contents in InDesign, export a fresh PDF, and re-check the long entry, bookmark nesting, and every changed destination. Do not retype the numbers; an update replaces the generated story wholesale.

How should the finished PDF be checked before handover?

Build a route table and follow every contents entry, not just a sample, then follow every bookmark and check its level. Check the return route to the contents, read the pages in order without using navigation, and compare contents numbers with the folios. Record the versions of InDesign, Acrobat, and the platform used, because a route verified in Acrobat is verified only there; browser or phone viewers are separate checks. This is a navigation check, not an accessibility audit of tagged reading order, alt text, contrast, or heading semantics.

Further reading

• One TV Bible File or an InDesign Book? Coordinate Chapters Without Breaking Their Layouts — When one bible file becomes unwieldy, this works through splitting it into chapters and coordinating order, page numbering and a regenerated contents list across them.
• Add a Working Index to a Long Series Bible — If collaborators arrive with a name or term rather than a section number, this shows how an index supplements a contents page and regenerates after reflow.