fix: temporarily disable TOC detection until it is complete#639
Merged
Conversation
Objective: PDF/UA-2 validation fails on documents where a table of contents is detected. The detected TOC cannot become a conformant structure: each entry must point at the section it references, but the pipeline never resolves that target, so the tagged output has no valid reference and fails clause 8.2.5.8.1. On top of that the detector is triggered too eagerly (any line ending in a number looks like a TOC entry), so it can even restructure ordinary body text. Approach: Turn the feature off at its single call site until it is finished, rather than shipping a half-working table of contents. A partial TOC is worse than none — an entry that points nowhere (or to the wrong place) sends a screen reader astray, and the false positives corrupt normal content. Detection is only commented out (the processor stays in the tree) so re-enabling is a one-line change once entry-target resolution and detection precision are done. With it off, the same text is tagged as ordinary paragraphs, which validates cleanly. Evidence: Rebuilt core with detection disabled and converted a document that previously triggered TOC detection. Before: TOC/TOCI elements emitted with no target -> PDF/UA-2 clause 8.2.5.8.1 failure (each TOCI must identify its reference target). After: veraPDF 1/1 pass; struct tree contains 0 TOC and 0 TOCI elements, the same text tagged as 7 <P> paragraphs. No regression to normal documents (every text line flows through the existing paragraph path). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
bundolee
requested review from
LonelyMidoriya,
MaximPlusov,
hnc-jglee and
hyunhee-jo
as code owners
July 14, 2026 08:42
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughTable-of-contents detection is temporarily disabled in ChangesTOC processing change
Estimated code review effort: 2 (Simple) | ~5 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Objective
PDF/UA-2 validation fails on documents where a table of contents is detected. A detected TOC cannot currently become a conformant structure: PDF/UA-2 clause 8.2.5.8.1 requires each
TOCIto identify the section it references via a target, but the pipeline never resolves that target, so the tagged output carries no valid reference and fails validation. The detector is also triggered too eagerly — any line ending in a number looks like a TOC entry — so it can restructure ordinary body text.Approach
Turn TOC detection off at its single call site (
DocumentProcessor) until it is finished, rather than shipping a half-working table of contents. A partial TOC is worse than none: an entry that points nowhere (or to the wrong place) sends a screen reader astray, and the false positives corrupt normal content. Only the call is commented out —TableOfContentsProcessorstays in the tree, so re-enabling is a one-line change once entry-target resolution and detection precision are complete. With detection off, the same text is tagged as ordinary paragraphs, which validates cleanly.Some additional hardening for the detector is tracked in the internal tasks tracker and should land before re-enabling.
Evidence
Rebuilt core with detection disabled and converted a document that previously triggered TOC detection.
<P>@MaximPlusov — while checking veraPDF conformance I found that the TOC detection you added produces a struct tree that fails PDF/UA-2 (clause 8.2.5.8.1): each
TOCIneeds to identify its reference target, butTOCIInfo's destination is never populated, so there is no valid/Refto emit. Downstream I could only work around it by downgrading TOC items to plain paragraphs, which drops the TOC semantics entirely — so that isn't a real fix either.My suggestion is to disable the feature for now and re-enable it once the target/destination resolution is in place (a couple of follow-up items are tracked in the internal tasks tracker). This PR just comments out the call; the processor stays in the tree so bringing it back is trivial. Happy to collaborate on the proper implementation — I think the right end state is resolving the entry target and tagging as
L/LI(PDF/UA-2 no longer defines TOC/TOCI and expects list structures). What do you think?🤖 Generated with Claude Code
Summary by CodeRabbit