https://bugs.documentfoundation.org/show_bug.cgi?id=173552
Bug ID: 173552
Summary: a TOC Refresh causes document to use system fonts
rather than embedded fonts
Product: LibreOffice
Version: 26.8.0.3 release
Hardware: All
OS: Windows (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: LibreOffice
Assignee: [email protected]
Reporter: [email protected]
Description:
TOC Refresh causess font replacement from embedded fonts to proprietary
Microsoft fonts and system fonts
Steps to Reproduce:
1.Refresh TOC
2.Save .odt
3.Open .odt
4. Refresh .odt
Actual Results:
Fonts change from embedded fonts to unwanted fonts including Microsoft licensed
fonts which are not transportable. Total number of pages can also change
Expected Results:
Embedded fonts survive repeated TOC refresh cycles, number of pages remains
unchanged
Reproducible: Always
User Profile Reset: Yes
Additional Info:
Bug report: DocumentIndexes.update() on a Table of Contents introduces
duplicate font-face aliases, renames built-in structural styles, and
synthesizes non-matching factory-default colors
Suggested component: Writer Suggested severity: Normal (data-integrity defect;
not a crash) Version tested: LibreOffice 24.2.7.2 420 (Build:2), Linux x86_64,
headless Also observed on: LibreOffice 26.8.0.3, Windows x86_64 (Writer GUI,
manual "Update Index" via right-click), and LibreOfficeDev 26.8.0.0.alpha0,
Linux x86_64 (headless conversion pipeline) — same symptom class on all three
builds/platforms.
Summary
Calling update() on a Writer document's table-of-contents index (equivalently:
right-clicking a TOC and choosing "Update Index/Table", or
.uno:UpdateAllIndexes) and then saving as ODF Text (.odt) causes LibreOffice to
silently:
Create duplicate, renamed aliases of fonts already present and correctly
declared in the document (e.g. an already-embedded Aptos becomes Aptos, Aptos1,
Aptos2, Aptos3; an already-embedded IPAexMincho becomes IPAexMincho and
IPAexMincho1), and introduces at least one font-face declaration (Symbol) that
did not exist in the source document at all.
Silently rename built-in/custom paragraph styles that the document's own
content structure depends on (a document-defined style named exactly
TableHeaderText is renamed to the display-name-derived identifier
Table_20_Header_20_Text; likewise TableBodyText → Table_20_Body_20_Text),
breaking any tooling or downstream process that resolves styles by their
original exact name.
Synthesize a new built-in character style (Internet_20_link, display name
"Internet link") using an internal factory-default color (
#000080) that has no relationship to any color used elsewhere in the document,
the first time the TOC-update operation actually creates a hyperlink run of
that kind.
None of these three effects are requested by the operation, none are reflected
in any UI dialog or warning, and none are reversible by simply repeating the
same operation (they compound: a second update on an already-affected file was
independently observed to introduce yet another distinct symptom, see
"Additional observation" below).
Why this matters
This is silent, unrequested data corruption in the ODF style layer of a
document whose visible rendering may be completely unaffected — the defect is
invisible unless the document's underlying XML is inspected or its style names
are relied upon programmatically. For any workflow that treats specific style
names as stable identifiers (accessibility tooling, document-generation
pipelines, compliance/QA tooling, template systems), or that relies on the
document's declared font set staying minimal and exact
(font-embedding-size-sensitive workflows, licensing-constrained font sets),
this is a serious defect: the mere act of refreshing a table of contents can
silently corrupt the document's structural and typographic contract with no
user-facing indication that anything happened.
Environment
Tested primarily via the Python UNO API (com.sun.star.text.DocumentIndexes),
which reproduces the identical effect as manually right-clicking a TOC in the
Writer GUI and choosing "Update Index/Table" — this is not specific to the
scripting path.
Reproduced independently on three separate LibreOffice builds across two
operating systems (see "Version tested" above), ruling out a single
build/platform-specific regression.
Reproduced on a from-scratch, freshly-verified-clean ODF 1.3 document with a
minimal, exactly-two-font approved font set (Aptos, IPAexMincho) and
EmbedOnlyUsedFonts=true — ruling out any pre-existing document corruption,
legacy-format artifacts, or an inherited Microsoft Office "theme" block as the
cause (a same-document control/experiment with the theme block present vs.
programmatically stripped produced byte-identical corruption in both cases —
see "Root-cause elimination test" below).
Steps to reproduce (minimal)
Create (or use the attached) a Writer .odt document containing:
A live table of contents (Insert > Table of Contents and Index > Table of
Contents, Index or Bibliography) built from real document headings.
At least one custom paragraph style with an exact, deliberately-chosen name
(e.g. TableHeaderText) applied to some paragraph in the body, used inside a
table.
Exactly two embedded fonts, with Tools > Options > Load/Save > General (or the
per-document File > Properties > Font tab) set to embed only used fonts.
Save the file. Record its font-face declarations (<style:font-face> elements in
content.xml/styles.xml), the exact name of the custom style, and the full list
of embedded font binaries.
Programmatically or via the GUI, update the table of contents:
UNO API: doc.DocumentIndexes.getByIndex(0).update(), then doc.store().
GUI equivalent: right-click inside the TOC → "Update Index/Table", then save
(Ctrl+S), keeping ODF format.
Re-open the saved file (or simply re-inspect the saved XML) and re-list the
font-face declarations and the custom style's name.
Expected result
The font-face declaration list is unchanged (still exactly the two
originally-declared fonts).
The custom style TableHeaderText still exists under that exact name.
No new character style is created with a color that doesn't correspond to
anything already in the document.
Actual result
New, duplicate font-face declarations appear for fonts that were already
correctly declared once, plus at least one font-face declaration for a font
(Symbol) that was never referenced or embedded in the source document at all.
Observed before: ['Aptos', 'IPAexMincho']
Observed after one update-and-save cycle: ['Aptos', 'Aptos1', 'Aptos2',
'Aptos3', 'IPAexMincho', 'IPAexMincho1', 'Symbol']
The custom style is silently renamed from its exact original name
(TableHeaderText) to a display-name-derived internal identifier
(Table_20_Header_20_Text). The original exact name no longer exists anywhere in
the saved file (verified: zero occurrences).
A new character style (Internet_20_link, display name "Internet link") is
synthesized with fo:color="#000080" — a value that does not appear anywhere
else in the document before or after the operation, and was clearly pulled from
an internal Writer factory default rather than derived from anything the
document itself specified.
Root-cause elimination test
Because the test document's lineage traced back through Microsoft Word
(confirmed via a <loext:theme loext:name="Office Theme"> block in styles.xml
carrying the exact default Office-2007 color palette), we hypothesized the
corruption might stem from that inherited Office-theme/compatibility data. We
tested this directly:
Control: ran the update-and-save cycle on the document with the <loext:theme>
block intact.
Experiment: ran the identical operation on a byte-for-byte copy of the same
document with only the <loext:theme>...</loext:theme> element removed
beforehand.
Result: the corruption was identical in both cases — the same new font-face
names (Aptos1, Aptos2, Aptos3, IPAexMincho1, Symbol) and the same style rename
(TableHeaderText → Table_20_Header_20_Text) appeared regardless of whether the
Office-theme block was present. This rules out inherited
Office-theme/compatibility data as the cause and indicates the defect is a
general property of the TOC-update code path itself, independent of document
lineage.
Additional observation (not independently isolated, reported for completeness)
On the same underlying document, a second, independent occurrence of the
update-and-save cycle (performed manually in the Writer GUI on Windows, after
the first-round font corruption above had already been corrected by hand)
reproduced the font-face aliasing symptom again but did not reproduce the exact
style-rename symptom in the same way — instead a differently-shaped defect was
observed on that occasion (page-count-affecting whitespace/pagination changes).
We have not isolated a controlled minimal repro for this second variant and
mention it only to note that the exact symptom set appears to vary between
invocations, which is itself worth flagging: whatever internal logic is
responsible does not appear to behave deterministically/idempotently across
repeated invocations on documents at different states.
Suggested area to investigate
The pattern across all observed symptoms — new automatic/built-in styles or
font-face entries being synthesized fresh from internal factory defaults at the
moment they are first actually needed by regenerated index content (rather than
being resolved against, or omitted in favor of, whatever the document already
declares) — suggests the defect lies in whatever code path lazily instantiates
built-in style definitions (Contents 1–10, Internet Link, table-role styles
referenced by a TOC's generated entries) during index regeneration, rather than
in the TOC/index-generation logic narrowly construed.
Attachments available on request
The minimal control/experiment .odt pair (theme-intact vs. theme-stripped,
before and after the update-and-save cycle) used for the root-cause elimination
test.
The Python UNO reproduction script used to drive the test deterministically.
Prepared from direct, reproducible testing; happy to provide the underlying
test files and script to a triager on request.
>From Help:
"The Document Foundation
LibreOfficeis a modern,easy-to-use,open source productivity suite for word
processing, spreadsheets. presentations and more.
This re ease was suppl ed by The Document Foundation. Copyright © 2000-2026
LibreOffice c0<1tributors.
LibreOffice was basedon OpenOffice.org.
Credits Website Release Notes
Version Information r
Version:
Buid:
Environment
26.8.03 ()(86_64)
bce0998afefdbc355585ca324 ... CPU threads:8:OS:Windows 11 X86_64 (bui d 26200)
UserInterlace: UIrender: Skia/Raster;VCL: win Locae: en·US (en_US);UI:en US
Misc Cale CL threaded
"
--
You are receiving this mail because:
You are the assignee for the bug.
