Skip to content

Fix embedded OLE object IDs in subdocuments - #659

Open
aka-debug-jie wants to merge 1 commit into
elapouya:masterfrom
aka-debug-jie:fix/issue-621-embedded-ole-ids-v5
Open

Fix embedded OLE object IDs in subdocuments#659
aka-debug-jie wants to merge 1 commit into
elapouya:masterfrom
aka-debug-jie:fix/issue-621-embedded-ole-ids-v5

Conversation

@aka-debug-jie

Copy link
Copy Markdown

Why

When several subdocuments contain embedded Excel objects, the generated DOCX
reuses their VML shape, OLE object, and paragraph anchor identifiers. The
embedded packages and icons remain present, but Word only exposes the first
Worksheet Object action.

Root cause

SubdocComposer copied each subdocument's related parts without normalizing
the identifiers that must be unique in the destination document.

Change

  • reserve identifiers already used by the destination and incoming subdocument
  • renumber matching VML shape/@id and OLE ShapeID values together
  • renumber OLE ObjectID and case-normalized w14:anchorId values
  • preserve existing relationships, embedded payloads, APIs, and dependencies

Validation

  • reproduced seven duplicate OLE shape IDs with the public issue attachment on
    the unfixed baseline
  • replayed its seven exact XLSX payloads and verified their SHA-256 values,
    sheet names, relationships, ZIP integrity, and OOXML main parts after the fix
  • passed the collision regression, related subdocument and embedding scripts,
    the complete 40-script suite, flake8, wheel/sdist builds, and archive audits

Scope and risks

This change is limited to body-level OLE objects using the sibling VML layout
present in the reported attachment. It does not generalize non-OLE VML ID
deduplication or OLE objects in headers, footers, or footnotes.

Closes #621

@yangfan-yf-yf yangfan-yf-yf left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reproduced #621 from the public attachment, and the identifier fix itself looks correct. On 9bbfc87b, the seven objects receive distinct paired v:shape/@id and OLE ShapeID values, distinct ObjectID values, and case-normalized unique w14:anchorId values. All seven relationships resolve to unique internal embeddings, and each XLSX passes ZIP, XML, and relationship checks. Existing body collisions, repeated renders, and the documented non-OLE and header/footer boundaries did not reveal another issue.

One fixture prevents me from approving the current head. tests/templates/issue_621_excel_0.xlsx is not the corresponding payload from the public attachment:

  • attachment output/0.tmp_excel_0.xlsx, also stored as the first embedding in demo_doc_with_excel.docx: 4,867 bytes, SHA-256 17ce75452390fd3057db51670b37df9c9027654a9589282d0834070ab6496cf9
  • committed fixture: 4,887 bytes, SHA-256 3b7d1befbe9fe6d4dfa8bee06b3dc424774b37079a884e89427c78577516805f

The workbook content is equivalent, but docProps/app.xml and docProps/core.xml differ, showing that this fixture was regenerated. The other six XLSX files and both DOCX templates are byte-identical to the attachment. This makes the “seven exact XLSX payloads” claim and the first expected hash inaccurate.

Please replace issue_621_excel_0.xlsx with the attachment’s exact payload and update its expected size and SHA-256. I did not find another blocker in the implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Only first embedded Excel object is openable in generated Word document

2 participants