https://bugs.documentfoundation.org/show_bug.cgi?id=173661
Bug ID: 173661
Summary: PDF/UA: catalog /Lang is taken from the UI locale
instead of the document, in Impress, Draw and Calc
Product: LibreOffice
Version: 7.4.4.2 release
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
-----------
When Impress, Draw or Calc export to tagged PDF, the /Lang entry in the
document catalog is filled from Application::GetSettings(), i.e. the UI locale
of whoever runs the export, rather than from the document's default language.
The same file converted on differently localised installations gets a
different catalog /Lang. Writer uses the document default and is correct.
This is the sd/sc half of tdf#67866. That bug's 2013 description named Impress
explicitly and it was closed once Writer was correct; commit 0e4ff2261f3c
("tdf#67866 sc,sd: PDF/UA export: set language in Catalog", 2022-11-25) added
the UI-locale placeholder for sd and sc - the answer that comment 3 of that
same bug had argued against, using the example of a document received from a
colleague abroad and converted locally.
The other half of tdf#67866, the missing per-run /Lang on structure elements,
is a separate defect in a different module; I will file it as a follow-up and
link it here.
Steps to reproduce
------------------
Attached impress-default-uk.fodp and calc-default-uk.fods both declare a
document default language of uk-UA and contain no other markup of interest.
soffice --headless --convert-to
'pdf:impress_pdf_Export:{"UseTaggedPDF":{"type":"boolean","value":"true"},"PDFUACompliance":{"type":"boolean","value":"true"}}'
impress-default-uk.fodp
soffice --headless --convert-to
'pdf:calc_pdf_Export:{"UseTaggedPDF":{"type":"boolean","value":"true"},"PDFUACompliance":{"type":"boolean","value":"true"}}'
calc-default-uk.fods
Read the catalog /Lang with the attached check_lang.py (pikepdf), or with any
PDF inspector.
Actual results
--------------
Both files: catalog /Lang: en-US, on an installation with an en-US UI locale.
Measured on 26.8.0.3 and on master 6a83b1538cd1.
Expected results
----------------
Both files: catalog /Lang: uk-UA, independent of the UI locale.
Code pointers (master 6a83b1538cd1)
-----------------------------------
sd/source/ui/unoidl/unomodel.cxx:3543 and sc/source/ui/unoobj/docuno.cxx:2312
both call SetDocumentLocale with
Application::GetSettings().GetLanguageTag().getLocale().
Writer instead passes the document default, at
sw/source/core/text/EnhancedPDFExportHelper.cxx:2510.
The document defaults are available in both modules:
SdDrawDocument::GetLanguage(EE_CHAR_LANGUAGE) (sd/source/core/drawdoc2.cxx:994,
kept in sync with the item-pool default by SdUnoDrawPool::putAny) and
ScDocument::GetLanguage(rLatin, rCjk, rCtl) (sc/inc/document.hxx:763). In Calc,
lcl_PDFExportHelper would need the ScDocument, which is in scope at both of its
callers.
Why it matters
--------------
PDF/UA-1 requires the natural language of text to be determinable. Because a
/Lang value is present, the machine-testable Matterhorn conditions 11-001 and
11-006 pass; only 11-007 ("natural language is not appropriate") catches a
wrong value, and that one requires human verification. A checker therefore
reports these files as conforming while a screen reader applies the wrong
phonetics.
It also makes tagged PDF export non-deterministic across machines, which is a
problem for automated publishing pipelines.
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.
