Matterhorn 07-002 · PDF/UA-1 UA1:7.1-9
DisplayDocTitle false: the PDF asks for its filename
The entry is present and explicitly instructs the viewer to show the filename rather than the title.
The condition, as the protocol states it. “ViewerPreferences dictionary of the Catalog dictionary contains a DisplayDocTitle entry with a value of false.”
Matterhorn Protocol 1.1, checkpoint 07, index 07-002, section UA1:7.1-9. Software can decide this one on its own.
What a screen reader actually does
The window/tab title announced on open is the filename, not the document name.
What is in the file
The catalog carries a viewer-preferences dictionary, and in it one flag decides what goes in the window’s title bar:
1 0 obj
<< /Type /Catalog
/Pages 2 0 R
/Metadata 5 0 R
/ViewerPreferences << /HideToolbar false
/HideMenubar false
/FitWindow false
/DisplayDocTitle false >>
>>
endobjThe PDF specification describes DisplayDocTitle as a choice between the document’s title and the name of the file, and makes false the default. PDF/UA-1 overrides that default: the entry has to be present, and it has to be true. When it is absent the condition is 07-001. This one is the entry present and false, which is not an omission but an instruction.
What the user hears
The filename, first, on open:
Q3_board_pack_v7_FINAL.pdf
and again in every window list, tab and “which document is this” query for as long as the file is open.
What makes this one frustrating is that it defeats work that was done properly. The author set a title; Document properties → Description shows it; 06-003 passes; and the screen reader still says the filename, because the file has told the viewer not to use the title. People check the title, find it, and stop looking.
Where it comes from
Something has to write false; it never comes from leaving a field blank.
A viewer-preferences dictionary written out in full. A library or template that writes every preference flag with its default value writes this one as false, because false is the default. The other false entries in the example above are harmless. This one is not.
Acrobat’s Initial View tab. Window Options → Show offers the file name or the document title, and it is the same instruction in interface form. Somebody tidying the window for a presentation can set it without a screen reader crossing their mind.
A batch. Adobe notes that in Acrobat Pro, Action wizards can change initial-view settings across many documents. If that action shows the file name, every file it processes leaves with this condition, and it arrives a whole folder at a time.
LaTeX. hyperref’s pdfdisplaydoctitle option controls the entry; it needs to be true.
How to check it free
Acrobat Pro. Document properties → Initial View → Window Options → Show. If it does not say Document Title, the file is not asking for its title.
The Accessibility Checker’s Title rule is described by Adobe as reporting whether there is a title in the Acrobat title bar, which is the thing this flag controls.
veraPDF tests that the viewer-preferences dictionary contains DisplayDocTitle with the value true. Missing and false fail the same test, so its report does not tell you which of 07-001 and 07-002 you have; the catalog does.
From a terminal, with pikepdf (free):
python3 -c "import pikepdf, sys; pdf = pikepdf.open(sys.argv[1]); print(pdf.Root.get('/ViewerPreferences'))" report.pdfgrep -a DisplayDocTitle report.pdf also works when the catalog is stored as plain text. From PDF 1.5 on it can sit inside a compressed object stream, and then grep finds nothing and proves nothing.
How to fix it free, in Acrobat Pro
From Adobe’s guide to checking accessibility:
- The hamburger menu (Windows) or the File menu (macOS) → Document properties.
- Initial View → Show → Document Title.
- OK, and save.
Or run the Accessibility Checker, select Title, and choose Fix from the options menu. That route also prompts for the title itself, which is worth having: a file that shows its title needs one worth showing (06-004).
Then find what wrote false. If it was a template, a batch action or a library default, fixing one file leaves the cause in place, and the next export arrives the same way.
What Taggart does
Taggart reads the catalog’s /ViewerPreferences. A missing dictionary or a missing entry is reported as 07-001; an entry that is present and false is reported as 07-002, once per document, as a blocker:
/ViewerPreferences /DisplayDocTitle is false, which tells the viewer to display the filename rather than the document title.
The repair is display-doc-title. It is mechanical, so it runs in Fix All Safe without being asked. It sets the existing entry to true and leaves the dictionary’s other entries as they were. The change log says exactly that:
set /ViewerPreferences /DisplayDocTitle to true
No content stream is touched, so the pages render as they did.
The fix does not judge the title it now puts on display. If there is none, that is reported as 06-003 and needs a title from you; if there is one and it looks like a placeholder, Taggart’s heuristic reports it as 06-004.
One thing to know when reading Taggart’s screen-reader preview of a file with this condition: near the top it announces Document: and the title whenever the file has a title, whatever this flag says. It does not model the filename a viewer shows instead, so on this condition the preview is kinder than a real reader. The finding is the one to believe.
How Taggart handles it
Taggart checks for this condition automatically and reports it as a blocker, with where in the file it found it.
The fix is Set DisplayDocTitle to true. It is mechanical, so “Fix All Safe” applies it along with the others in one pass and lists what it changed. Your original file is never modified.
Whatever Taggart changes, the page still looks identical. Fixes edit the PDF object model, not the content streams, and every remediation is re-rendered and compared against the original at structural similarity ≥ 0.999 before you get the file back. A tool that quietly reflows your document is worse than no tool.
Frequently asked questions
If false is the default anyway, why is it a separate condition from a missing entry?
Because PDF/UA asks for the entry to be present and true, and there are two ways not to be. 07-001 is a file that says nothing, so the viewer falls back to the default, which the PDF specification sets to false. 07-002 is a file that says false. The reader hears the same filename either way and the repair is the same, but a file that says false was told to by something — a template, a batch action, a library — and that thing will do it again.
Which title does the viewer show once it is true?
The PDF specification describes the flag as showing the Title entry of the document information dictionary, while PDF/UA requires the title in XMP as dc:title. A file needs both, with the same string. Taggart's title fix writes both at once.
Can a reader still choose to see filenames?
Yes. Acrobat has a preference, Always use filename as document title, under Documents, off by default. A reader who wants filenames can have them. The file should not make that choice for everybody.
Is it safe to change automatically?
Yes. It is one entry in the catalog. Nothing on any page changes and nothing about what the document says changes. That is why Taggart applies it in Fix All Safe, unlike the title itself, which has to come from a person.
Where this sits in the standards
| Standard | Reference |
|---|---|
| Matterhorn Protocol 1.1 | Checkpoint 07 (Dictionary), index 07-002 |
| PDF/UA-1 (ISO 14289-1) | Clause 7.1-9 |
| WCAG 2.1 | 2.4.2 Page Titled — Level A |
| EN 301 549 / Section 508 / ADA Title II | All three point at WCAG 2.1 Level AA for non-web documents, so a Level A or AA criterion here is in scope for each of them. |
Related conditions
- 07-001 ViewerPreferences does not contain DisplayDocTitleWithout /DisplayDocTitle the viewer is free to show the filename in the window title instead of the document title.
- 06-003 XMP metadata stream does not contain dc:titleThe Dublin Core title property is missing from the XMP packet.
- 06-004 dc:title does not clearly identify the documentA title is present but useless: the filename, "Microsoft Word - Document1", "untitled", or the template name.
- 11-006 Natural language for document metadata cannot be determinedThe XMP dc:title (and other metadata) has no xml:lang and the catalog has no /Lang.
Other conditions in checkpoint 07
Checkpoint 07 covers dictionary. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.
Check your own file. Taggart’s validator is free and unlimited — 75 of the 87 Matterhorn conditions software can decide, with the other 12 listed for you to confirm; no watermark, no expiry, and no account needed up to 60 pages.
Checked with Taggart on a generated file that fails this condition on . The Acrobat steps follow Adobe’s documentation and were not walked through by hand. Last updated .