https://bugs.documentfoundation.org/show_bug.cgi?id=173773
Bug ID: 173773
Summary: Tagged PDF: list in a second text box of a slide has
LI without L parent
Product: LibreOffice
Version: 26.8.0.3 release
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: accessibility
Severity: normal
Priority: medium
Component: Printing and PDF export
Assignee: [email protected]
Reporter: [email protected]
Blocks: 139007
Created attachment 208813
--> https://bugs.documentfoundation.org/attachment.cgi?id=208813&action=edit
Two text boxes, each with a bulleted list (saved by LibreOffice 26.8)
Steps:
1. Open attachment two-lists.odp (one slide, two text boxes, each a bulleted
list).
2. File > Export as PDF, check "Universal Accessibility (PDF/UA)" or "Tagged
PDF".
3. Inspect the structure tree (e.g. PAC, or pikepdf).
Actual: the first text box gives L > LI > Lbl + LBody. The second gives its LI
elements directly under Div, with no L.
Expected: each list is an L whose children are LI (ISO 32000-1, 14.8.4.3.3,
Table 336).
The same happens with a numbered list, with the numbered list first, and for
PPTX input. When the second list starts at level 2, only one L is opened for
two levels. A text box without a list between the two list boxes hides the bug.
Cause: VclMetafileProcessor2D::processTextHierarchyBlockPrimitive2D() closes
the open list elements at the end of a text block but does not reset
mnCurrentOutlineLevel, so the first paragraph of the next block takes the "same
list level" branch and opens only an LI. The closing loop came with
05f5c18959cb (2019); before it, the second list was put into the L of the first
one.
Tested on 26.8.0.3 and master (8b00664342af), macOS.
Referenced Bugs:
https://bugs.documentfoundation.org/show_bug.cgi?id=139007
[Bug 139007] [META] PDF accessibility
--
You are receiving this mail because:
You are the assignee for the bug.
