[
https://issues.apache.org/jira/browse/TIKA-4891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18114668#comment-18114668
]
Luca Foppiano commented on TIKA-4891:
-------------------------------------
I've burned a few tokens, although is not a UA PDF, there are other information
that can be extracted, e.g. tables information. Does Tika already exploit
those?
---
Short version: the file is a tagged PDF, but it is not PDF/UA conformant, and
it doesn't claim to be. It was produced by Chrome 86's "Save as PDF" (Skia/PDF
m86) from the PSE Edge web viewer, so the tags are a straight translation of
the HTML DOM, with the usual browser-export gaps.
*What's there*
* {{{}MarkInfo /Marked true{}}}, a {{StructTreeRoot}} with a ParentTree and
IDTree, and MCIDs on all page content. All fonts embedded with ToUnicode maps,
so text extraction is clean.
* Element inventory: 1 Document, 6 Div, 1 H1, 1 H2, 2 H4, 13 P, 11 Table, 36
TR, 23 TH, 25 TD, and 110 NonStruct.
* Tables are the best part: every TH carries {{/Scope}} (Row or Column), every
TD has a {{/Headers}} array pointing at TH IDs, and RowSpan/ColSpan are set.
That's better than most authoring tools manage.
*Where it fails PDF/UA*
* No conformance identifier. There's no XMP metadata stream at all, so no
{{{}pdfuaid:part{}}}. There's also no document {{/Title}} and no
{{{}ViewerPreferences /DisplayDocTitle{}}}. Three hard requirements missing
before you even look at the tags.
* Wrong language. The Document element declares {{/Lang (ko)}} — Korean — for
an English document. Chrome presumably inherited it from the {{lang}} attribute
of the PSE page. No catalog-level {{/Lang}} either.
* Untagged content. The browser print header/footer on every page (date, page
title, URL, "2/3") is drawn outside any marked-content sequence and isn't
marked as {{{}/Artifact{}}}. Same for all the table borders and rules. PDF/UA
requires everything to be either tagged or an artifact; there is not a single
{{/Artifact}} BDC in the file.
* The AC Energy logo (a 2194×911 image XObject on page 2) is drawn outside
marked content with no Figure element and no {{{}/Alt{}}}. Straight failure.
* Heading hierarchy is broken: the order is H2 → H4 → H1 → H4. PDF/UA-1
requires headings to nest without skipping levels.
* NonStruct is doing the work of real tags. 110 of the ~230 elements are
NonStruct, and almost all leaf text sits under one. The entire SEC Form 17-C
section on page 1 ("1. Date of Report… Nov 3, 2020", etc.) is a flat run of
NonStruct siblings, so a screen reader gets no label/value relationship there.
The {{C07699-2020}} reference at the top is a table that lost its Table/TR/TD
roles (it still carries {{{}/RowSpan{}}}/{{{}/ColSpan{}}} attributes on a
NonStruct). Several Tables also have NonStruct as a direct child, which isn't
permitted (only TR, THead/TBody/TFoot, Caption).
* Semantic misuse: the layout tables are really key/value forms; several
"tables" are a single TH+TD pair. Some TDs list every TH in their table as
headers (e.g. five headers for one cell), which over-associates.
*Verdict*
Machine-readable and reasonably well-tagged for a browser export, and the table
markup would help a screen reader. But it would fail a PAC or veraPDF PDF/UA
check on metadata, language, artifacts, alt text, heading order, and
structure-type placement. Fixing it properly means remediation in Acrobat or a
re-export from a source that emits Figure/Alt, artifacts, and a correct
{{{}lang{}}}; the {{ko}} language tag is the one that would most actively hurt
an assistive-tech user, since a screen reader may switch to a Korean voice.
> Improve handling of PDF/UA structural tags/marked content
> ---------------------------------------------------------
>
> Key: TIKA-4891
> URL: https://issues.apache.org/jira/browse/TIKA-4891
> Project: Tika
> Issue Type: Task
> Reporter: Tim Allison
> Priority: Major
> Attachments: 1008690.pdf
>
>
> PDF/UA includes structural markup. We hacked out a standalone handler for
> this back in 1.x but haven't touched it in years.
>
> We should modernize our handling of structural tags and eventually consider
> turning that on by default. That decision will be based on evaluation on
> 1000s of PDFs. This is not a default switch to be taken lightly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
