[a11y] Automatically create outline (table of contents) metadata from page's headings (<h1>, <h2>, etc.) when printing/saving a page to PDF
Categories
(Core :: Printing: Output, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox150 | --- | fixed |
People
(Reporter: nekohayo, Assigned: Jamie)
References
Details
(Keywords: access)
Attachments
(1 file)
Summary
Both for convenience and accessibility compliance reasons, in addition to the page title being preserved into the PDF title metadata (bug #1939532), when "printing" (saving) a page to PDF, the web browser engine should automatically create the dynamic table of content that gets shown in PDF readers' sidebars, which lists the headings and their corresponding page position (so that the software and the user can easily know the entire document structure and more easily navigate through it.
Here are two examples of pages that can serve as easy testcases, as they make good use of h1/h2/h3 headings:
- https://en.wikipedia.org/wiki/GNOME
- https://theconversation.com/what-canada-can-learn-from-the-european-union-about-dealing-with-chaos-and-crises-249462
Info about implementation in Skia
Searching for "pdf heading print" in Chromium's issue tracker, I found https://issues.chromium.org/issues/41387522 where we see mentions of the Skia graphics library where this feature is available, including:
- This merge request in Skia: https://skia-review.googlesource.com/c/skia/+/765519
- …merged as this resulting commit: https://skia.googlesource.com/skia/+/5075f1
Additional things I found:
- https://skia.org/docs/dev/design/pdftheory/
- https://api.skia.org/structSkPDF_1_1StructureElementNode.html ; I'm not sure if this is the right thing to use or not (through the a11y tree?)
- https://issues.chromium.org/issues/383706655 potentially related issue for headlines that have wrapped text
|
Reporter | |
Updated•1 year ago
|
|
||
Comment 1•1 year ago
|
||
This would be one aspect of Tagged PDF generation.
(Currently, our PDF output is generated via cairo, not skia; presumably the cairo_tag_{begin,end} APIs could be used to generate this.)
|
Assignee | |
Comment 2•10 months ago
|
||
With SkPDF, once we have the structure tree including headings, it should be trivial to generate the document outline. See SkPDF::Metadata::fOutline. Thus, I'm reversing the dependency relationship here, since bug 1657973 is about building the structure tree.
|
|
Assignee | |
Comment 3•10 months ago
|
||
Unfortunately, setting SkPDF::Metadata::fOutline to StructureElementHeaders isn't sufficient by itself. It seems that accumulating the text from headings relies on the SkTextBlob being constructed using text, but Gecko only provides glyph indexes.
|
|
Assignee | |
Comment 4•10 months ago
•
|
||
I got this working in my prototype, but it required a small patch to Skia and I'm not sure it will be accepted upstream. I suspect the cleaner solution (as far as Skia is concerned) of fixing Gecko to provide text instead of just glyph indexes might be a much bigger lift, but I'm not familiar enough with the graphics code to have any real clue.
|
|
Assignee | |
Comment 5•7 months ago
|
||
This is facilitated using the PDF struct tree and thus requires that tagged PDF output is enabled.
|
||
Updated•7 months ago
|
|
||
Updated•6 months ago
|
Description
•