https://bugs.documentfoundation.org/show_bug.cgi?id=174221

            Bug ID: 174221
           Summary: DOC export: sprm 0xD670 (table cell shading) written
                    twice in every table-row property set; strict readers
                    show the document as empty
           Product: LibreOffice
           Version: 26.8.1.1 release
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Writer
          Assignee: [email protected]
          Reporter: [email protected]

Description:
When a Writer document containing a table is saved as “Word 97–2003 (.doc)”,
the binary file contains the sprm 0xD670 twice in a row, with an identical
operand, in the property set of every table-row terminating paragraph.
Microsoft Word and LibreOffice itself open such files without any problem.
However, at least one strict third-party .doc parser (the document viewer of a
Ukrainian electronic document management system, name and version unknown)
rejects the whole document and shows it as empty. Removing the duplicate
(nothing else) makes the file display correctly there.

Steps to Reproduce:
1. In Writer create a new document, insert a table (rows and cells with text).
2. Save as “Word 97–2003 (.doc)”.
3. Inspect the PAPX FKP entries of the table-row end paragraphs (those
containing sprmPFInTable 0x2416, sprmPFTtp 0x2417, sprmTDefTable 0xD608).

Actual Results:
In each such entry the sequence contains sprm 0xD670 two times in a row, same
value. Example grpprl of a row from my document (sprm opcodes in order):
0x2416, 0x2417, 0x6649, 0xD608, 0x9407, 0xD609, 0xD612, 0xD670, 0xD670, 0xD634,
0xD634, 0xD634, 0xD634, 0x3466, 0x3403

Expected Results:
Each property appears at most once in a grpprl, as in files written by
LibreOffice 6.4.7.2 and by Word:
0x2416, 0x2417, 0x6649, 0xD608, 0x9407, 0xD609, 0xD612, 0xD670, 0xD634, 0xD634,
0xD634, 0xD634, 0x3466, 0x3403


Reproducible: Always


User Profile Reset: No

Additional Info:
Regression: the same document saved with LibreOffice 6.4.7.2 contains 0xD670
once and displays correctly in the affected system. Saved with 24.2 and 26.8.1
it contains it twice and displays as empty.
A file saved by Word (Office 2021) does not contain the duplicate.
Workaround confirmed: removing only the second 0xD670 from each of the 3
table-row entries (the PAPX entries were rewritten without the duplicate, file
otherwise untouched) makes the document display correctly in the affected
system.
The document itself is valid: it opens correctly in LibreOffice and Word, the
text, tables and the embedded object are intact.
The exact SPRM name should be confirmed against [MS-DOC] (I identified it by
opcode: it is a table cell shading property). I have not looked at the source,
but the cause is probably in the table background export code of the DOC filter
(sw/source/filter/ww8/, e.g. the table-backgrounds export in ww8atr.cxx) that
now emits the same property twice, possibly from two code paths.
Attachments: (1) minimal sample saved in 26.8.1 (duplicate present), (2) the
same saved in 6.4.7.2 (no duplicate), (3) the same with the duplicate removed
(accepted by the affected system).

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to