https://bugs.documentfoundation.org/show_bug.cgi?id=173552
--- Comment #2 from Robert C.Abbe <[email protected]> --- Created attachment 208528 --> https://bugs.documentfoundation.org/attachment.cgi?id=208528&action=edit Demo files (before/after ODT pair) and reproduction script. Demo files and reproduction steps attached (Bug173552_Response_Package.zip), containing: - control_BEFORE.odt - unmodified source document - control_AFTER.odt - the same document after the TOC refresh operation described below - run_test.py - the Python/UNO script used to trigger it programmatically - Bug173552_Reproduction_Steps.md - full write-up IMPORTANT NOTE: I first tried building a minimal from-scratch test document (one heading, a TOC, one custom style) specifically for this report. That minimal file did NOT reproduce the bug, even after adding an extra save/reopen cycle first. Whatever triggers this requires more pre-existing document complexity than the simplest possible case. For that reason I'm attaching the real working file (control_BEFORE.odt) rather than a "minimal" one that doesn't actually reproduce. STEPS TO REPRODUCE (GUI): 1. Open control_BEFORE.odt in Writer. 2. Right-click inside the table of contents. 3. Choose "Update Index/Table". 4. Save (Ctrl+S), keeping ODF Text Document (.odt) format. 5. Close Writer completely. STEPS TO REPRODUCE (script): python3 run_test.py MYTEST control_BEFORE.odt /path/to/scratch/profile 2002 This calls DocumentIndexes.getByIndex(i).update() on every index in the document, then doc.store(). Same effect as the GUI steps above. HOW TO CONFIRM THE CORRUPTION: unzip -p control_BEFORE.odt content.xml styles.xml | grep -o 'style:font-face style:name="[^"]*"' | sort -u unzip -p control_AFTER.odt content.xml styles.xml | grep -o 'style:font-face style:name="[^"]*"' | sort -u Compare the two lists. The "after" list contains new font-face aliases not present before (e.g. an existing font gains numbered duplicates such as "Aptos1", "Aptos2", plus an unrequested "Symbol" declaration with no prior reference in the document). Also check for style renaming: unzip -p control_BEFORE.odt content.xml styles.xml | grep -c "TableHeaderText" unzip -p control_AFTER.odt content.xml styles.xml | grep -c "TableHeaderText" unzip -p control_AFTER.odt content.xml styles.xml | grep -c "Table_20_Header_20_Text" The custom-named styles "TableHeaderText" and "TableBodyText" are silently renamed to "Table_20_Header_20_Text" / "Table_20_Body_20_Text" after the operation, even though neither the GUI steps nor the script asked for any renaming. FONTS: Both attached files embed the identical set of font binaries (verified byte-for-byte identical via SHA-256 before attaching), so the corruption is in the font-face declarations and style references, not caused by a different font set being embedded at some stage. ENVIRONMENT TESTED: LibreOffice 24.2.7.2 420 (Build:2), Linux x86_64, headless, via the Python UNO bridge. Also separately observed manually via the GUI on LibreOffice 26.8.0.3, Windows 11 x86_64 (my original report). NOTE ON REPEATED OPERATIONS: My original Windows/GUI observation needed two rounds of Update Index to reach the full corruption described above. Testing on Linux via the scripted API path, a SINGLE pass already produces the full effect - there was nothing left for a second pass to change. So on Linux, one pass through either method above should be enough; you should not need to repeat the operation. I have only automated the scripted UNO path on Linux, not the literal GUI click sequence, so I can't yet confirm whether the GUI path on Linux also needs only one pass. Happy to provide anything else useful - a diff of the two files, additional test documents, or clarification on any step. -- You are receiving this mail because: You are the assignee for the bug.
