Matterhorn 28-016 · PDF/UA-1 UA1:7.18.7-1
PDF attachment with a missing or garbled name: /F and /UF
The file specification referenced by a FileAttachment annotation must carry both /F and /UF.
The condition, as the protocol states it. “File attachment annotations do not conform to 7.11.”
Matterhorn Protocol 1.1, checkpoint 28, index 28-016, section UA1:7.18.7-1. Software can decide this one on its own.
What a screen reader actually does
The attachment is announced with a mangled or missing filename.
What is in the file
A file attached as a comment is two objects. The FileAttachment annotation is the paperclip on the page. Its /FS entry points at a file specification, which names the file and holds the embedded bytes:
21 0 obj
<< /Type /Annot /Subtype /FileAttachment
/Rect [ 500 700 520 720 ]
/Name /Paperclip
/Contents (Figures for table 2, CSV)
/FS 22 0 R
>>
endobj
22 0 obj
<< /Type /Filespec
/F (figures-q1.csv) % byte string — the name for old readers
/UF <FEFF 0066 0069 0067 …> % text string — the name in Unicode
/EF << /F 23 0 R >> % the embedded file itself
/Desc (Quarterly figures behind table 2)
>>
endobjPDF/UA-1 clause 7.18.7 says file attachment annotations shall conform to clause 7.11, and 7.11 says the file specification of an embedded file shall have both /F and /UF. This condition fires when the attachment’s specification is missing either one — or when there is no /FS at all.
Why one name is not enough
/F is the original entry, and it is a byte string. How those bytes become characters depends on the platform and the reader, and in practice a name in anything other than plain ASCII reaches different readers as different text. /UF, from PDF 1.7, is a proper text string — UTF-16 when it needs to be — and can hold דוח רבעוני.xlsx or Résumé.docx without loss.
So the two failure modes are different:
/UFmissing. A modern reader falls back to/F. An ASCII name survives. A Hebrew, Arabic or accented one may come out as a run of Latin-1 punctuation, which is what a screen reader then reads, character by character./Fmissing. An older reader, or a tool that only knows/F, finds no name at all.
The paperclip itself is announced from the annotation’s /Contents (28-004 when that is missing). The file name is what the user meets when they go to open or save the attachment — in Acrobat’s Attachments pane, for example — and it is the name the file is saved under.
Where it comes from
Older producers that predate PDF 1.7 and write only /F.
Libraries that attach files with the minimum dictionary. A specification with /EF and /F is valid PDF and opens everywhere, so nothing prompts a developer to add the second name.
How to check it free
veraPDF reports it under clause 7.11 — its PDF/UA-1 profile has no separate test for 7.18.7, because 7.18.7 is defined as “conform to 7.11”. Its test also requires both names to be non-empty, which is slightly stricter than Taggart (below).
Acrobat shows attachment names but not which entry they came from, so it cannot show you this directly. What you can do is read the name in the Attachments pane. If a name that should be in Hebrew or with accents shows as punctuation, /UF is missing or wrong.
How to fix it free, in Acrobat Pro
Re-attach the file. Adobe documents the tool as (Adobe: Add attachments as comments):
- Right-click the existing attachment on the page and select Delete.
- Select Add a comment from the Quick action toolbar, then Attach file.
- Click where the attachment should go, and select the file.
Adobe does not document which entries the new file specification gets, so check the saved file with veraPDF or Taggart before calling it done. While you are there, Adobe’s page on adding attachments documents right-clicking a file in the Attachments pane and choosing Edit Description — not what this condition asks for, but a place to tell a reader what the file is rather than what it is called. If the document is tagged, the new annotation also needs to be in the tag tree; Adobe’s page on the Content and Tags panels documents Find → Unmarked Comments → Tag Element for that, which is 28-002.
What Taggart does
The check walks every FileAttachment annotation and reads its /FS:
The file specification of a FileAttachment annotation is missing /UF, so it does not conform to 7.11.
or, where there is nothing to read:
A FileAttachment annotation has no /FS file specification.
The same specification is also an embedded file, so it is reported under 21-001 as well. Both clear together.
The repair is embedded-file-names, and it is in Fix All Safe. It copies whichever name exists into the one that does not — /F into /UF or the reverse — and the change log says exactly what it wrote: copied /F to /UF for ‘figures-q1.csv’.
Its limits:
- No name at all, no repair. When the specification has neither entry, there is nothing to copy, and the finding stays. Taggart does not make up a file name; somebody has to say what the file is called.
- It copies, it does not translate. A name that is already mangled in
/Fis copied mangled into/UF. The finding clears; the name is still wrong. Read the name in the change log. - Presence, not content. The check asks whether each entry exists. An empty
/UF ()passes it; veraPDF’s 7.11 test would not.
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 Add F and UF to embedded file specifications. 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
Why does a file need two names?
Because /F is a byte string, and how its bytes become characters depends on who is reading them — fine for ASCII, unreliable for a Hebrew, Arabic or accented name. /UF, added in PDF 1.7, is a text string that can hold any script. Old readers use /F, newer ones prefer /UF, and PDF/UA asks for both so every reader gets something.
How is this different from 21-001?
21-001 is about every embedded file specification in the document, including files attached at document level that no annotation shows. 28-016 is about the specification behind a FileAttachment annotation — the paperclip on the page. One bad specification behind a paperclip fails both, and Taggart reports both.
Can the fix go wrong?
It copies, it does not translate. If /F holds a name that was already mangled — a legacy code page read as something else — /UF receives the same mangled name, and the condition passes with a name nobody can read. Look at the name the change log reports before accepting it.
Does Acrobat write both entries when I attach a file?
Adobe's documentation of the Attach file tool does not say which entries it writes. Attach the file, then check the result with veraPDF or Taggart rather than assuming.
Where this sits in the standards
| Standard | Reference |
|---|---|
| Matterhorn Protocol 1.1 | Checkpoint 28 (Annotations), index 28-016 |
| PDF/UA-1 (ISO 14289-1) | Clause 7.18.7-1 |
| WCAG 2.1 | 1.3.1 Info and Relationships — 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
- 21-001 File specification dictionary for an embedded file does not contain F and UF entriesEmbedded attachments must carry both the byte-string filename (F) and the Unicode filename (UF).
- 28-004 An annotation has neither a Contents entry nor an alternative descriptionEvery non-widget annotation needs an accessible description, either in its own /Contents or in the /Alt of the structure element that encloses it.
- 28-002 An annotation is not a direct child of an Annot structure elementNon-widget, non-link annotations must sit inside an Annot structure element so they have a place in the reading order.
- 28-012 A link annotation does not include an alternate description in its Contents entryLink annotations need /Contents describing where the link goes.
Other conditions in checkpoint 28
Checkpoint 28 covers annotations. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.
- 28-001 An annotation is not in correct reading orderThe annotation's position in the structure tree does not match where it appears on the page.
- 28-002 An annotation is not a direct child of an Annot structure elementNon-widget, non-link annotations must sit inside an Annot structure element so they have a place in the reading order.
- 28-003 An annotation is used for visual formatting but is not tagged according to its semantic functionA Square or Line annotation used to draw a box round a callout is decoration and should be artifacted, or tagged for what it actually means.
- 28-004 An annotation has neither a Contents entry nor an alternative descriptionEvery non-widget annotation needs an accessible description, either in its own /Contents or in the /Alt of the structure element that encloses it.
- 28-005 A form field has neither a TU entry nor an alternative descriptionThe /TU tooltip is the accessible name of a PDF form field. Without it the field has no name at all — the visible label printed next to it is not connected to the control.
- 28-006 An annotation with subtype undefined in ISO 32000 does not meet 7.18.1A custom annotation subtype still has to be placed in the structure tree and described.
- 28-007 An annotation of subtype TrapNet existsTrapNet annotations are prepress artefacts and are forbidden in PDF/UA-1.
- 28-008 A page containing an annotation does not contain a Tabs entryAny page carrying annotations must declare a tab order. PDF/UA-1 requires /Tabs /S — tab order follows the structure tree.
- 28-009 A page containing an annotation has a Tabs entry with a value other than S/Tabs is present but set to /R (row order) or /C (column order) rather than /S (structure order).
- 28-010 A widget annotation is not nested within a Form tagEvery form control must sit inside a Form structure element.
- 28-011 A link annotation is not nested within a Link tagA link annotation must be a child of a Link structure element containing the link's text, joined by an object reference (/OBJR).
- 28-012 A link annotation does not include an alternate description in its Contents entryLink annotations need /Contents describing where the link goes.
- 28-013 An IsMap entry is true but the functionality is not provided in some other wayA server-side image map requires pointing at a pixel, which is not possible without a mouse.
- 28-014 CT entry is missing from the media clip data dictionaryThe media clip's content type (/CT) is required so a processor knows what it is being asked to play.
- 28-015 Alt entry is missing from the media clip data dictionaryMedia clips require an /Alt array giving a text description.
- 28-017 A PrinterMark annotation is included in the logical structureCrop marks and registration targets are production artefacts and must not appear in the structure tree.
- 28-018 The appearance stream of a PrinterMark annotation is not marked as ArtifactThe content inside a PrinterMark's appearance stream must itself be artifacted.
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 .