Repair a Treatment PDF’s Reading Structure—or Rebuild Its Source?
Repair a Treatment PDF’s Reading Structure—or Rebuild Its Source?
The approval meeting covered the pages: the still on page 6, the schedule on 9 and 10, the act breaks. Everyone agreed the treatment looked right. Nothing in that meeting covered the file, because nothing in that meeting could see the file. A visually approved treatment can still hand a reader a caption before its image, an act title that announces itself as ordinary prose, and a schedule in which every date sounds equally firm. Those are not cosmetic differences. They change what the document says.
So: patch the PDF, or go back and rebuild the source? Three questions decide it. Can you get the source, and can you actually change it? Is the fault a slip or a construction? Is another export coming?
The third question is the one teams skip, and it settles more than the other two. A repair made inside the PDF lives only inside that PDF. A later export replaces the whole structure tree, not just the pages that changed. A PDF repair is therefore a per-version artifact rather than a durable fix. That is not an argument against it. It is an argument for knowing which one you just performed, and writing down what has to be done again.
Appearance and structure are separate approvals
Visual approval certifies ink: the right still, the copy in the right place, the spread holding together. It cannot certify sequence, role, or relationship, because none of those have a visible form. The file carries a second structure alongside the rendered page. That structure says which passages are headings and at what level, what order content is read in, which images are figures and what they contribute, which table cells are headers for which columns, and what is decoration — the rule above the act title, the running footer, the page number.
Every one of these can be wrong in a file that looks perfect on screen. A caption sitting under a photograph is a visual relationship; a caption attached to a photograph is a structural one, and layout software will happily give you the first without the second. A row of dates under a "Dates" heading looks organized whether or not the heading reaches the cells beneath it.
This is why the sentence "it looks fine" is not evidence, including when you are the one saying it. Inspect the passage twice: once as a page, once through its structure. Then work on a copy. Adobe's documentation on editing document structure with the Content and Tags panels makes three relevant points — visible position and tag structure are separate things; detailed tag editing can damage the structure you meant to improve; and Reading Order operations are not all undoable. Random experimentation on the only approved file is not a repair method. It is a way to spend an afternoon creating a second defect.
Name the defect before you choose the route
The kind of fault predicts the route, so classify it before you argue about tools. In a treatment, the recurring families are these.
Role. An act title set as body text, or body text promoted to a heading because someone bolded it. The reader gets a wall of prose where a section break should be, or a heading that announces itself in the middle of a sentence.
Sequence. The caption read before its image. A sidebar dropped into the middle of a paragraph it was meant to sit beside. A pull quote inserted mid-sentence.
Alternative. An image with no description at all, or a description that repeats the caption instead of saying what the image is doing in the proposed film. Those are different failures, and the second is the more common one.
Relationship. A table whose header ancestry is missing, whose merged cells no longer announce what they span, or whose header does not reappear when the table breaks across a page. Nothing about the table's appearance has to change for any of this to be missing.
Artifact. Rules, bleeds, page numbers, and running footers tagged as content, so they land in the reading sequence where they interrupt whatever is actually being said.
Role and artifact defects are usually per-instance, and a structure editor handles them directly: retag a paragraph, mark a footer as decoration. Relationship defects are the ones that bite. Adobe's own guidance on this material suggests that complex table correction may be better done in the source than in the tag tree — a useful admission, because the table is where visual repair tempts you most and rewards you least.
Before you choose, find out where the tags came from. Ask the designer whether the export produced them or whether someone ran a remediation pass afterward. Open the source and look at whether the act titles use paragraph styles that map to headings or local formatting applied by hand. Export a copy to a scratch file and compare its structure with the delivered one. If an earlier remediation pass built part of the current structure, the source is not a clean slate — it is a different starting point, and some of what you're seeing may exist only downstream.
Three questions, one of which is about time
Can you get the source, and can you change it? "Available" and "editable by whoever is asking" are different facts. If an outside designer holds the file under a change-request arrangement, the source route has a real cost and a real schedule. Note that cost honestly. What you may not do is treat an unavailable source as evidence that the PDF is acceptable. Those are two separate questions, and the first does not settle the second.
A slip or a construction? A slip is one instance with one local cause. A construction is the way the document was built, and it will produce the same defect on every export until someone changes the building. Two act titles set in local formatting are not two slips; they are one construction with two visible symptoms, and the next act title will be a third.
Is another export coming? For a treatment, the answer is nearly always yes, because a treatment exists to be revised. That single fact re-frames the whole decision. Correcting the PDF gives you a good file for this delivery and queues every correction for re-application on the next one. Correcting the source costs more today and means the next revision starts from a document that exports correctly.
Put roughly: the cost of the PDF route scales with how many revisions follow. The cost of the source route is a fixed piece of construction work, plus re-verification, plus the risk that the approved look shifts. Compare those, not the merit of one application over another. Neither route is universally right, and an article that crowns one has stopped answering the question.
A constructed case
The following treatment is invented, and the inspection below is a plan rather than a record — no PDF was built and no assistive technology was run for this piece. Its purpose is to hold the decision variables still long enough to compare them.
A fourteen-page treatment for a fictional sixty-second film, built in a page-layout application by one designer, exported once, approved visually, and readied for client delivery. Five defects turn up, from four constructions.
The heading "Act Two — The Long Room" on page 4 is tagged as body text, and so is "Act Three — What the Room Keeps" on page 8. Both were composed as locally formatted text rather than a mapped heading style: two instances, one construction.
On page 6, a full-page still carries a two-line caption. In the structure, the caption sits before the image, and the image has no description. The cause is constructional: the caption is a separate text frame placed beneath the photograph, and no relationship between them was ever expressed.
Pages 9 and 10 hold the shoot schedule: six columns, nine body rows, split across the page break. The header has two rows — Block, Scene, Location, Call — plus "Dates," which spans two columns labeled Est. and Locked. That span is the table's reason for existing. A locked date was committed to a location; an estimated date is a wish. In the structure, the span is gone, the header cells are not attached to the columns beneath them, and nothing repeats the header where the table breaks, so both kinds of date become the same kind of fact. The footer on all fourteen pages is ordinary text, so "Haldane Supply — The Long Room — Treatment — 4/14" enters the reading sequence at the end of every page's content.
One revision is already scheduled: the client will cut the rooftop location, removing two rows from the schedule and one sentence from Act Three. Each page is composed by hand, so the cut does not reflow pages outside the schedule table.
Now the two routes.
Repair the PDF. On a copy, retag the two headings as headings, move the caption after the figure and add a description, mark fourteen footers as decoration, and rebuild the table's header relationships by hand. The heading and footer work is quick. The table work is detailed, hard to verify by eye, and exactly what Adobe's guidance says may go better in the source. The result is a correct file for this delivery, and nothing survives the next export.
Correct the source and re-export. Define a heading style that reproduces the current local formatting exactly and apply it to both act titles. Move the footer into a running element kept out of the content flow. Anchor the caption to the still so the relationship exists in the file, not just the page, and describe the image at the image level. Rebuild the table header so the span and the header ancestry are real, and set the header to repeat at the break.
Choose the second, and not because source work is nobler. Choose it because four constructions produced this damage, three of them recur across the document, and a revision is already on the calendar. The next act title and the next footer would arrive broken under the PDF route, and the client's cut forces a re-export that erases everything patched. Corrected in the source, the cut becomes a normal edit: remove two rows, cut one sentence, export, verify.
That recommendation holds only while its conditions hold. If the source had been genuinely unobtainable, or if this were a final file with no further revisions and no further exports, the bounded repair would be the right answer — with the qualification that a broken table cannot be waved through, and that a tag edit too risky to complete safely is a documented limitation rather than a hidden one.
Follow the table through either route
The table deserves its own pass, because it is where the routes diverge most and where looking at the result proves least.
In the PDF, you can attach header roles to cells by hand and can add headers to the page-10 continuation. The file can end up correct. But you are reconstructing relationships that were never recorded, across nine rows and a span, and the work has to be redone after any export. In the source, you are deciding how the table is built: how the span is created, which cells are headers, whether the header repeats.
Either way, the check is not "does the table read in order." It is whether the distinctions survive. Reading the schedule, a person should be able to tell that the date belongs to Block 2 and scene 14, and to tell whether that date is estimated or locked. If the ancestry is missing, those two dates collapse into one another and the schedule becomes less reliable than it looks — a table that appears tidy while communicating the wrong thing.
Two dependencies in this example are worth watching. Rebuilding the table can change its height, which can move the row that currently ends page 9 onto page 10; the continuation header was necessary already, and it has to be correct wherever the break now falls. And the client's cut removes two rows, which can pull a page-10 row upward. Both changes land on the same two pages, so pages 9 and 10 need visual re-approval after the source fix and again after the revision. Budget for both, or the second one will arrive as a surprise.
Recheck the file you are actually handing over
"The treatment PDF" names a family, not a file. Identify the delivered version — a version marker, a date, a named delivery folder — and check that copy rather than a working file. If a later export replaced it, the check applies to what shipped, not to what you verified.
Recheck reading order on the pages whose structure changed, and sample pages where nothing should have changed. Confirm heading roles and levels. Confirm each figure has a description and its caption attached, and read the description against the image's job in the proposal rather than against its caption. Confirm the table, including the estimated-versus-locked distinction and the header at the break. Confirm the footers no longer interrupt the sequence. Check navigation if the document has it, and compare the rendered pages against the approved proofs so the repaired file is still the approved document.
Two kinds of checking, not one. Structure tools tell you what the file says about itself; assistive technology, used by someone qualified to interpret it, tells you what the experience is. A saved file with no warnings is not a checked file, and neither kind of check substitutes for the other. Neither one produces a conformance claim, and neither is needed to justify the work — they are simply the only way to see the structure you just changed.
Finally, record it: the version, the corrections made, what remains unresolved, and who owns preserving or re-applying those corrections at the next export. Without that line, the next revision quietly converts a repaired document back into an unrepaired one, and everyone involved will believe the problem was solved.
The choice, in the end, is not between two tools. It is about where the correction lives — in one exported file or in the construction that produces it — and who keeps it alive through the next round. Decide that deliberately, check the file that actually leaves the building, and do not mistake a quiet report for a document someone can understand.
Frequently asked questions
Why doesn't visual approval of a treatment PDF settle its reading structure?
Visual approval certifies the rendered page: the right still, the copy in the right place, the spread holding together. It does not certify sequence, role, or relationship, because those have no visible form. A caption can sit under a photograph without being attached to it; a row of dates can look organized while its headers are not attached to the cells beneath.
What three questions decide whether to patch the PDF or rebuild the source?
Can you get the source, and can you change it? Is the fault a slip or a construction? Is another export coming? The third is often decisive for a treatment, because a PDF repair lives only in that PDF and a later export replaces the whole structure tree.
In the constructed case, what defects appeared, and which were constructional?
Two act titles were locally formatted and tagged as body text, two instances of one construction. A full-page still had its caption before the image and no image description, because the caption and photograph were separate frames with no expressed relationship. The schedule table lost its estimated-versus-locked span, its header ancestry, and its repeated header at the page break. Every footer was ordinary text and entered the reading sequence. The heading, caption, table, and footer problems came from four constructions; three recur across the document.
Why choose source correction in that case, and when would PDF repair still be right?
Because four constructions produced the damage, three recur, and a revision was already scheduled. The next act title and footer would arrive broken under the PDF route, and the client's cut forces a re-export that erases patched structure. Source correction makes the cut a normal edit. If the source were genuinely unobtainable, or this were a final file with no further revisions or exports, a bounded PDF repair could be the right answer, though a broken table cannot be waved through, and a tag edit too risky to complete safely is a documented limitation, not a hidden one.
How should the table and final file be checked after a repair or rebuild?
The test is not just whether the table reads in order but whether the distinctions survive: a date should still belong to its block and scene, and a reader should be able to tell whether it is estimated or locked. Rebuilding can change table height and move rows across pages 9 and 10, so those pages need visual re-approval after the source fix and again after the revision. Check the file that actually shipped, not a working copy; confirm heading roles, figure descriptions and attached captions, the table's estimated-locked distinction and repeated header, and footers that no longer interrupt. Record the version, corrections, unresolved items, and who owns re-applying them at the next export. Structure tools and assistive technology are different checks, and neither produces a conformance claim.