Insert - Table of Contents and Index, then export with File - Export
as PDF, Universal Accessibility (PDF/UA) on and PDF version 2.0. The
file fails ISO 14289-2 clause 8.2.5.8 once per entry, which veraPDF
reports as:
Each TOCI in the table of contents shall identify the target of the
reference using the Ref entry, either directly on the TOCI structure
element itself or on one of its child structure elements
An item named no target at all:
<</Type/StructElem/NS 2 0 R/S/TOCI /P 8 0 R /Pg 3 0 R /K[10 0 R ]>>
It names the heading now, in the /Ref entry PDF 2.0 added:
<</Type/StructElem/NS 2 0 R/S/TOCI /P 8 0 R /Pg 3 0 R /Ref[ 15 0 R ] /K[10 0 R ]>>
Object 15 is the /S/H1 the entry links to, found from the mark its
URL names. An item that links to a table, a frame or an object, or
that has no link at all, still names nothing.
The document of testTdf173162 linked its entries to
bookmark alone now, as Writer writes them, and the document passes
the profile, so the test asks for PDF/UA instead of plain tagging
and the harness validates it.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I76e73684d2ab09f187f56cab093d13980150d737
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12750
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit ee49bf58e7d3eb3ff94677e9a51c73b76eb51a99)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211338
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Write a paragraph in Writer's built-in Index paragraph style and
export with Tagged PDF switched on. The element comes out as
/S/Index, over a role map that reads
/Index/P
so the standard Index type means a paragraph, document-wide. veraPDF,
on the PDF/UA-1 profile:
Standard tags defined in ISO 32000-1:2008, 14.8.4, shall not be
remapped
A style called Artifact went further. Its paragraph reached the
content stream beside the marker for content that is not part of the
structure at all, the two being one name:
/Artifact BMC
/Artifact<</MCID 10>>BDC
Writer names a structure element after the style that produced it,
and the role map records what that name means, one entry per name.
Styles collide there with the standard types, with each other, being
separate families for paragraphs and characters, and with the names
Writer asks for itself, Source Text writing Code literally.
A name a standard type has, or another alias asked for, is now passed
over for the first indexed name beside it that is free, so the Index
style writes /S/Index-1 over /Index-1/P. PDF 2.0 has standard names
1.7 lacks: a style called H7 gives way there, while a heading at
outline level 7, which Writer asks for by that same name, keeps it
and needs no entry at all. The synthetic Div containers ask for no
name now, and carry the Div tag as before.
The test document remapped four standard tags at PDF 1.7 and six at
2.0; now none at either.
Found while reproducing tdf#165454.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I63e9116e5db17bdb554b508a864e313a77f40bc2
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12361
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 54e0207ff6bcf937187a395912f1ed57b60d90e3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211314
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A slide with a background, its own or its master's, exported to
tagged PDF with that background as untagged content. ISO 14289-1 7.1
leaves no third state, and veraPDF says so once per background:
Content is neither marked as Artifact nor tagged as real content
Page decoration is wrapped as an artifact in
ViewObjectContact::getPrimitive2DSequence, which the background never
reached: the master page descriptor builds its own hierarchy and
emitted the fill straight into the visitor. It now takes the same
wrapper as the page decoration beside it - the machinery of commit
81ef846485 ("(related: tdf#135192) svx:
PDF/UA export: tag background as Artifact", 2022-12-01), whose author
hoped there that "anything that's not SdrObject can be tagged as
Artifact".
The wrapper has to lie to be heard: VclMetafileProcessor2D drops a
tag that is a NonStructElement, and drops a background tag that is
not an image, so page decoration goes out as a Division claiming to
be an image. That second refusal is also why a shape on a master
slide, unless it is a graphic, is untagged to this day. LATER: let the
processor emit an artifact for a plain background and stop dropping
one, and both go.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I9431c460cade3d432cb7abf76930e23f8106a7f1
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12311
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit b11283cd97e1170688a75f4229fd43bd8298e276)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211166
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The commit "tdf#163240 vcl,sw: keep one Link tag for a wrapped link"
made language, baseline shift and decoration come from the link's first
portion for the whole link, and noted subdividing by Spans as the fix:
those three are attributes of the Link tag, and there is now one tag per
hyperlink, so a change inside it had nowhere to go.
Open a Span in the Link instead. A span waits inside its link, so two
tags can be open at once, and an annotation goes to the link's own tag -
vcl takes it on a Link only, and a styled run crossing a line break
would otherwise leave that line's annotation without a StructParent.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I302d32f66fcb4e3b1eaf63b136bdcf96aaea17b7
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/11543
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 8f52d63f897aaf710dfe4cd9771f39689471abfd)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211101
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The commit "tdf#163240 vcl,sw: keep one Link tag for a wrapped link"
kept the tag across a line break. A ruby still split it, and a character
style on a ruby base pulled the following text into the Ruby element.
Tags were closed by a count, which callers decremented to leave one open
for the next portion; a count does not record which tag. Keep two stacks
instead: the tags this helper opened, and the tags left open for a
following portion. Close a deferred tag only while it is the current
element, so neither a ruby nor a fly closes a tag of another.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Icdf793f149076db2b5dfac2b7668d0c414467427
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/11542
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 1936ac2268b9e603c64a03eff6eb8b7ecb8b56de)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211090
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Regression after commit a71da3b7a8
(tdf#156565 sw: PDF/UA export: split Link SE at line break,
2023-11-01), which closed the tag at each line break so that every
annotation had a tag to nest in.
A structure element could reference one annotation only, the
LinkAnnotation attribute being a value in a std::map; give it a vector
and emit an OBJR kid and a parent tree entry per annotation, so each
StructParent resolves to that tag. A page or column break still ends
the tag.
Language, baseline shift and decoration now come from the link's first
portion, at a line break as much as within a line - splitting the tag
at a break would only make the result depend on where the line ends.
LATER: subdivide the Link by Spans, which covers both.
testTdf157816Link and testTdf142806 expected a tag per annotation.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I493439a33b2cbc0eecf1af6b300859cd78ee87ba
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/11541
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit ade287e6a4edf7476e667f48082261deeddd96d5)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211077
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Exporting a document with a table of contents to PDF/UA-2 produced a
file that fails ISO 14289-2 clause 8.2.4, once for the TOC element
and once for each entry in it. veraPDF reports
Non-standard structure type http://iso.org/pdf2/ssn:/TOC is not
mapped to a standard type
Non-standard structure type http://iso.org/pdf2/ssn:/TOCI is not
mapped to a standard type
Commit d23c5560c1 (tdf#160196 add
support for PDF/UA-2 and NS for struct. elem., 2025-01-22) declared
one namespace, PDF 2.0, and pointed every element at it. ISO 32000-2
14.8.6 leaves TOC and TOCI out of that namespace, and also Art,
BlockQuote, Index, Quote, Note, Reference, BibEntry and Code. Writer
emits all but Art and Reference, so one footnote is enough to reach
this.
The bug asks for L and LI with Lbl and LBody instead, or for a
RoleMapNS entry to a standard type. Role mapping is the smaller of
the two and does clear 8.2.4 for the TOC, but the element is then
validated as an L, so veraPDF reports ISO 32005 Table 5 per entry
<LI> contains <P>
Neither remedy reaches Note, Index, Quote, Code or BibEntry.
ISO 14289-2 8.2.4 offers a third way out: it accepts the PDF 1.7
namespace alongside the 2.0 one, and TOC and TOCI are standard types
there, so nothing needs remapping and the tree keeps its shape.
Declare both namespaces, list both on the structure tree root, and
point all ten types at the 1.7 one. The root's RoleMap is the
fallback for elements there, so RoleMapNS stays on the 2.0 namespace.
Every PDF 2.0 export now declares both, PDF/A-4 included.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Ibdf0f27afe2c7b5b5801dbe1b813afb6de95bb0f
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12200
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 92a2bfff6f47e055dd49d767a5013cbfcdafcf11)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211067
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A table cell whose first paragraph uses a style inherited from Table
Heading was tagged TD, so a screen reader announces it as data rather
than as a header; only the built-in style itself became TH.
lcl_IsHeadlineCell compared the paragraph's own style name and stopped
there. Walk the DerivedFrom() chain, the way the HTML table writer
already does.
Scope stays Column on every TH, so a row header still claims its
column; that is a defect of its own.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I9ccbd1b3837d3edc5087162a143560e8412a846d
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12168
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 270d087cad2c8327775ce204371830c34eecc0d7)
(cherry picked from commit d86b837d439355e62afcdd6b771603c260bc5949)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211049
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
A hyperlink whose text an alphabetical index entry covers exported a
link annotation with no tag around it, so PDF/UA checkers reject the
file:
Link annotation is not nested inside a Link structure element
that is ISO 14289-1 7.18.5. The same happens under a reference mark or
an RDF metadata field.
Each of the three lays its run out as its own portion type, a
SwTextPortion whose only addition is a shading that never reaches an
export. BeginInlineStructureElements listed Text, Lay and Para, so the
run matched no case and got no element at all - not even the Span
carrying its language.
Handle the three with the other text portions.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Ie38193f64923cd6a0a3afa509691fb29a007f272
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12104
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 409e0cc615e191a0392ee080717bb84eb61e4724)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211027
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Instead of converting CFF table to a Type 1 font and embedding that, we
now embed the CFF table directly without modification.
This allows us to get rid of the CFF parsing code with its security
issues.
The CFF table is embedded as FontFile3 (/Subtype/CIDFontType0C) stream
of a CIDFontType0.
This is a rework of previous attempt in:
commit d9a6a3f7f0
Author: Khaled Hosny <khaled@aliftype.com>
Date: Sun Apr 12 18:46:43 2026 +0200
vcl: embed fonts with CFF table as OpenType fonts
That tried to embed them as full OpenType fonts, which was broken for
CID-keyed fonts and got reverted in:
commit 4c3c87e79d
Author: Khaled Hosny <khaled@aliftype.com>
Date: Thu Apr 30 02:56:06 2026 +0300
tdf#171869 vcl: restore Type1 PFB conversion for CFF fonts
Next version of harfbuzz-subset library will have an option to write an
identity charset (GID == CID) for CID-keyed fonts, so embedded as CFF
table will now work equally for both name-keyed and CID-keyed fonts.
As in interim solution (until we can require that version of HarfBuzz),
we now have a small module that parses only the CFF charset to get CID
mapping.
Change-Id: I57b0f722174613b91373c972e0c8eba3efeea5f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208804
Tested-by: Jenkins
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
reproduce by exporting to tagged PDF/UA a document where an outer table
spans more than one page and its repeated header row carries a nested
table.
#4 SwTaggedPDFHelper::BeginTag (...) at engine/sw/source/core/text/EnhancedPDFExportHelper.cxx:627
#5 SwTaggedPDFHelper::BeginBlockStructureElements (...) at engine/sw/source/core/text/EnhancedPDFExportHelper.cxx:1827
#6 SwTaggedPDFHelper::SwTaggedPDFHelper (...) at engine/sw/source/core/text/EnhancedPDFExportHelper.cxx:460
#7 SwLayoutFrame::PaintSwFrame (...) at engine/sw/source/core/layout/paintfrm.cxx:3659
#8 SwTabFrame::PaintSwFrame (...) at engine/sw/source/core/layout/paintfrm.cxx:4649
the header row is laid out again on each page, so the nested table gets
a master frame per page. the follow-headline check only looked at the
innermost enclosing table, so a nested table inside an outer table's
headline was not recognised as a repeat and was tagged once per page.
tagging the same frame a second time aborts on the assert that each
frame is tagged only once, so walk every enclosing table and treat the
frame as an artifact when any of them is a repeated follow headline.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I173c229fc46b8fbf7575c6a19293f54431dbe0e9
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/5967
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
(cherry picked from commit 9c31ded970a549fac846ad4f45349c70fde114d4)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208731
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Strikeout characters are drawn over the struck-out text, always as LTR
strings positioned at the leftmost position of the text. Due to a
1-character typo, the PDF exporter was drawing the strikeout characters
as RTL rather than LTR, which made them extend to the left outside the
clipping area, rather than covering the struck-out text as intended.
Change-Id: If4ef3a745a76526c2dfb8af6133b2bf729e92fbf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205995
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Writer has a special code path for underlines that span font changes.
This special code path did not handle kashida justification, and would
draw underlines that were too short to connect to the following portion.
Change-Id: I31ff2c3a1cea0e7e4339a0533e568e421c20d52d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204604
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
Test that font-variation-settings with arbitrary axis values (wght=623,
wdth=87) produce distinct font subsets in PDF export. Tests both writer
(ODT) and editengine (ODP) paths.
The test font is a subset of Amstelvar with wdth and wght axes and
Latin-1 character range.
Change-Id: Ic2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203249
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
Tested-by: Jenkins
When exporting to PDF a document with a background image on the page.
The image would always be exported as a bitmap at a fix resolution, even
if the original data had vector form (like a pdf or svg).
This ensures that the original vector data is also exported as it is
done with regularly inserted images.
Change-Id: I7f363614ba375e01a4b076c961ce91dae8c2351b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202994
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Support saving/loading font-optical-sizing in Writer. The
font-optical-sizing property is enabled on the standard style for new
documents, and for old documents it remains unset for backward
compatibility.
Add no-op stubs to DOCX, RTF, WW8, and HTML filters.
Change-Id: I87e3de603785dbd588099bfbd72e13e4538fc420
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200536
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
Tested-by: Jenkins
Otherwise, the validator fails with
"The value of CreationDate entry from the document
Info dictionary and its matching XMP property "xmp:CreateDate"
are not equivalent
(Info /CreationDate = D:20260220154049+01'00', XMP xmp:CreateDate = 2025-12-31T11:13:40.000+01)
The call to osl_getDateTimeFromTimeValue was removed in
commit 07ac61f2c6
Author: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
Date: Mon Aug 28 11:16:34 2023 +0300
tdf#138792: PDF export: fix date of xmp:CreateDate
for no apparent reason
Change-Id: I4c6948769797a4e446239316de2857851b31565e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199886
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Manually replace GentiumBasic with NotoSans in tdf66597-3.odt
Test testTdf66597_3 still fails if
commit d337222359
Author: Khaled Hosny <khaledhosny@eglug.org>
Date: Sun Apr 29 01:00:20 2018 +0200
tdf66597: Fix a typo in detecting cluster start
is reverted with
Test name: (anonymous namespace)::testTdf66597_3::TestBody
equality assertion failed
- Expected: 4
- Actual : 0
- Number of ActualText entries does not match!
Change-Id: I6634ce703e1db81d44ea12d745464e8881fa2e7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199086
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
This change updates Writer to better conform with the ODF standard
wording for the fo:text-align attribute when used in
style:list-level-properties.
Previously, Writer interpreted list label alignments while ignoring
paragraph direction, always behaving as if the list label is always
left-to-right. This change updates Writer to instead apply label
direction correctly, treating start and end label alignment in a manner
similar to how we treat start and end paragraph alignment.
The list style dialog has been updated to reflect the new behavior as
start/end alignment, rather than left/right alignment.
This change also adds the LIST_LABEL_ALIGNMENT_IGNORES_DIRECTION
compatibility flag. In order to preserve the layout of existing
documents, this flag is enabled automatically when loading an ODF
created with earlier versions of LibreOffice.
Change-Id: I56cd37fa83487b010369b99570f7bb4750c07595
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198857
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Previously, new Writer documents defaulted to left/right paragraph
alignment, depending on application language. This change updates Writer
to instead use the language-independent start alignment by default.
Change-Id: Ic385bb8e38234d29365d21f46a11ebb115523970
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197309
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Implements support for ODF fo:text-align start and end in paragraph
styles. The new alignment options can be selected in the paragraph
dialog. Further user interface changes are tracked as separate bugs.
This change also adds START and END to css.style.ParagraphAdjust, which
is flagged as an incompatible UNO API change.
Change-Id: I2ee57f0029de7b794bc1ecd3eddbbd90af5dfdb9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192932
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Fixes an issue causing Writer to print the destination page number twice
in footnotes with continuation notices that end in non-Latin text.
This was happening due to subtle mismanagement of the m_bHasFollow flag.
Continuation notices rely on this flag being unset to indicate the field
portion responsible for printing the destination page number, but the
layout algorithm was leaving this flag unset on two different portions.
In Latin-only documents, this bug was hidden by SwLineLayout::CalcLine()
removing the second portion, but this isn't possible when a script
change is involved.
Regression since commit 6c0105307e
(sw: fix stale SwNumberPortion follow flag)
Change-Id: I94c6f7ca75a3cf844d3eff2640d63777ac026717
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192464
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
PDFs exported from Writer show/don't show tracked changes
based on what's set on the UI.
During command line conversion, there was no way to change
this setting.
Introduce a new option 'ExportTrackedChanges' to be only used
during command line conversion as a --convert-to parameter, eg.:
'pdf:writer_pdf_Export:{"ExportTrackedChanges":
{"type":"boolean","value":"false"}}'
Change-Id: I763393ee4305415b714662decf23e0e8f8e75662
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188194
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Implements a minimal functional version of ruby character layout and
rendering in Edit Engine. Many features are missing from this
implementation, and will be added in future commits.
Currently, ruby characters cannot be created via the user interface.
Ruby character styles are also currently hard-coded.
Change-Id: Ia7c18ccae6c37cd320acc214574ba3123c18ddb0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185210
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
Fixes a bug causing editeng to insert kashida glyphs in positions where
there is not enough space for them. The root cause was failing to
account for the extra space used by blanks while rejecting candidate
kashida positions.
Change-Id: I1e22f758af0a88c2070f31cca040570f3a730c08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184282
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
In ISO 14289-2:2024 the requirement was changed from "shall" to "should":
Link annotations should include a Contents entry to enrich information
available to assistive technology.
There is also now a Well-Tagged PDF (WTPDF) Version 1.0.0, which says:
8.9.2.4.2 Link
Link annotations should include a Contents entry to enrich information
available to assistive technology.
NOTE 1 Link annotations are often accessed out of context; the Contents
entry provides optional additional information. The Contents entry is also
particularly valuable in the context of link targets that are not intended
to be human-readable.
EXAMPLE — A link over the text “click here” is improved by a Contents entry
to advise the user regarding the link’s target.
So adapt PDFWriterImpl::emitLinkAnnotations() to produce "Contents" only
if there is some alt text.
The sw a11y check will already warn if the alt text/"name" is missing on
a hyperlink in a SwTextNode, and a previous commit added a warning if it
is missing on a hyperlink in a SwFlyFrameFormat.
Contents should in any case not contain the textual representation of
the hyperlinks, that was a misunderstanding, but describe the target of
the link.
This requires adapting numerous unit tests.
(regression from commit fa3f04bdd4)
Change-Id: I88a7ae83d17d781115c93152d267ddb57208c200
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182600
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
According to the PDF standard, if a table has a caption, it must be
either the first or the last child within the table tag.
Therefore, if both above and below captions are set for the table, they will be exported as the table's first child.
Change-Id: Id4ee732d469d606b6ad49f68b34500bc1174c51e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181981
Tested-by: Jenkins
Reviewed-by: Nagy Tibor <tibor.nagy.extern@allotropia.de>
If a PDF file containing artifacts is added to a document as an image,
and the document is then exported as a tagged PDF, these artifacts are
placed into a structure element (e.g., figure), which is not allowed.
This fix removes unnecessary artifact tags from the content stream.
Change-Id: I590ebec9a7aecdaa42520008824469bc8a9ff65b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180041
Reviewed-by: Nagy Tibor <tibor.nagy.extern@allotropia.de>
Tested-by: Jenkins
This adds a test that checks the attached file is correctly added
to the PDF stream when encryption is enabled.
Also add support for reading of attachments to PDFium wrapper.
The test saves a document as encrypted PDF with hybrid mode enabled,
then opens the document in PDFium and saves the attachment content
to a temporary file, which is opened again and the content checked.
Change-Id: I918f67d269c31fe7826a49473e939d52bac7fe98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178629
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178778
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
Due to formatting, grapheme clusters can possibly be split across
multiple layouts. Layouts containing split grapheme clusters are created
by laying out the complete string, and extracting only the necessary
glyphs based on source codepoint index.
This approach is good enough for most diacritic cases, but it cannot
handle certain substitution cases where glyphs with advances would be
interleaved with other layouts. Sub-layouts must be contiguous.
This change introduces code to disable grapheme cluster splitting in
these cases that cannot be handled correctly.
Change-Id: I122abbf9c3f8a5efa4c72ad47991d0ad9ff8a8c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177927
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Previously, Writer was not correctly terminating layout contexts at the
starts of small caps spans. This could cause incorrect character
placement in certain cases.
Regression since:
Commit 30d376fb7d
"tdf#61444 Correct Writer text layout across formatting changes"
and
Commit ab0a4543ca
"tdf#124116 Correct Writer text shaping across formatting changes"
Change-Id: I863b9b66356eb0a9efb5bbdc75e80b43d56aaaf0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177839
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
This change adds loext:margin-left and loext:margin-right, which
implement margins that support font-relative units.
See tdf#36709 for additional details.
Change-Id: I31b0dd2b6f98cb5b02fd4dca3608db6fdee4054c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177473
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
This change extends layout for font-relative paragraph first-line
indentation into Edit Engine.
Change-Id: I5906f493b91fbcb87ded165709fb132b33ce1906
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176487
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
This change adds an ODF font-relative first-line indent paragraph style
attribute as a LibreOffice extension. The corresponding ODF standard
change is tracked by OFFICE-4165.
This change only implements what is minimally necessary to serialize,
deserialize, and check for ODF files containing this attribute. Further
changes are necessary.
* Added cssLength to schema, which is equivalent to length but also
allows ic and em as units.
* Added loext:text-indent to schema as a paragraph style attribute. This
attribute is equivalent to fo:text-indent, but accepts cssLength
instead of length.
* Added XML_TYPE_UNIT_MEASURE to the ODF parser, which currently accepts
only the font-relative measures and forces fallback in other cases.
* Added loext:text-indent to the ODF parser. This attribute accepts
font-relative metrics, and will behave as an import-only alias for
fo:text-indent in other cases.
* Updated SvxFirstLineIndentItem to handle unit-denominated measures.
* Added proof-of-concept indentation handler to Writer. This
implementation is incomplete and temporary, and will be revised in
future changes.
Change-Id: I7eb5c7382093cb18a9b0afbf93dacb34ba1d35ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175941
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Previously, Writer and Edit Engine would skip inserting kashida in words
if the highest-priority candidate position is marked as invalid by
HarfBuzz. This would happen even if the word contained multiple
lower-ranked valid candidate positions.
This change updates Writer and Edit Engine to pass HarfBuzz kashida
position data to the selection algorithm. The algorithm has been updated
to return the highest-priority valid position, if any. The algorithm has
also been updated to use raw positions marked as valid by HarfBuzz as a
fallback, if no better positions could be found.
Change-Id: I40c6432c4607aee197e8767e5667db504469956a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173963
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tihs change updates Writer kashida justification to include some
whitespace expansion, mirroring the behavior of Edit Engine and other
word processor programs.
Each kashida and space character are given 1 unit each of extra space.
Change-Id: I8c9031a0d51844e532b9d1f7e3619c2c9ba23f6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173884
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Mike Kaganski