https://bugs.documentfoundation.org/show_bug.cgi?id=173662
Bug ID: 173662
Summary: PDF/UA: shape text loses per-run language, no /Lang on
any structure element (Impress, Draw, shapes in Writer
and Calc)
Product: LibreOffice
Version: Inherited From OOo
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: accessibility, filter:pdf
Severity: normal
Priority: medium
Component: Printing and PDF export
Assignee: [email protected]
Reporter: [email protected]
Blocks: 139007
Description
-----------
Text runs that carry an explicit character language produce no /Lang attribute
on any structure element when exported to tagged PDF. Writer emits it correctly
for its own text through the same PDF framework, but the shape-text path never
sets it, so Impress and Draw lose language entirely - as do drawing objects in
Writer and Calc, since they share that path.
This is the per-run half of tdf#67866, whose 2013 description named Impress
explicitly; the bug was closed once Writer was correct. The catalog-level half
is filed separately as bug 173661.
Steps to reproduce
------------------
Attached impress-repro.fodp is a one-slide presentation with a single span
marked fo:language="uk" fo:country="UA". It declares no document default
language.
soffice --headless --convert-to
'pdf:impress_pdf_Export:{"UseTaggedPDF":{"type":"boolean","value":"true"},"PDFUACompliance":{"type":"boolean","value":"true"}}'
impress-repro.fodp
List the structure elements carrying /Lang with the attached check_lang.py
(pikepdf).
Actual results
--------------
No structure element carries /Lang. Measured on 26.8.0.3 and on master
6a83b1538cd1.
Expected results
----------------
One /Span carrying /Lang uk-UA, as Writer produces for the same content.
The catalog /Lang of this particular file is en-US both before and after, and
that is correct: the file declares no document default, so the fallback
applies. Only the missing Span is the defect here.
Control: Writer
---------------
Attached writer-control.fodt holds the same content as a text document.
Exported with writer_pdf_Export and the same two filter options it yields
[('/Span', 'uk-UA')], on both versions tested.
Import is not at fault: PPTX runs with a:rPr/@lang="uk-UA" import as
fo:language="uk" fo:country="UA". The document model holds the right value;
only export drops it.
Code pointers (master 6a83b1538cd1)
-----------------------------------
grep -rn "PDFWriter::Language" sd/ svx/ drawinglayer/ editeng/ returns nothing.
Tree-wide there are exactly two references:
producer, Writer only:
sw/source/core/text/EnhancedPDFExportHelper.cxx:1299 - sets the attribute
only when the run's language differs from the document default
consumer, vcl:
vcl/source/pdf/pdfwriter_impl.cxx:10924 stores the locale, :1186 emits /Lang
on any structure element carrying one
The vcl side is complete and app-agnostic; only the producer is missing.
Shape text is tagged in
VclMetafileProcessor2D::processTextSimplePortionPrimitive2D,
drawinglayer/source/processor2d/vclmetafileprocessor2d.cxx:1631. The run locale
is already available there as rTextCandidate.getLocale(), currently used only
to drive the break iterator for the XTEXT_EO* metafile comments. It originates
from ImpEditEngine::GetLocale() and reaches the primitive via
DrawPortionInfo::mpLocale (editeng/source/editeng/StripPortionsHelper.cxx:203).
Note on ordering: this compares the run against the document default, which
bug 173661 currently fills from the UI locale. Fixing that one first avoids
emitting spurious Spans here.
Why it matters
--------------
PDF/UA-1 requires the natural language of text to be determinable; Matterhorn
checkpoint 11 covers it. A presentation in one language exported on a
differently localised installation carries no per-run language at all, so a
screen reader falls back to the catalog value and applies the wrong phonetics.
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.
