deps: Bump DocumentFormat.OpenXml from 3.2.0 to 3.3.0#4
Merged
JSv4 merged 1 commit intoNov 27, 2025
Merged
Conversation
--- updated-dependencies: - dependency-name: DocumentFormat.OpenXml dependency-version: 3.3.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Contributor
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
JSv4
deleted the
dependabot/nuget/OpenXmlPowerTools.Tests/DocumentFormat.OpenXml-3.3.0
branch
JSv4
added a commit
that referenced
this pull request
Jul 9, 2026
…n reviewer-inserted notes A reference nested inside a reviewer-INSERTED note's definition body was never rewritten from the reviewer's id space to the output id space. The body-reference rewrite (step 2) only visits body clones and the renumber sweep (step 4) keys on the output-old id, so a reviewer inserting a footnote whose text cites an endnote the same reviewer ALSO inserts — whose target becomes a fresh output id, not a base id — left the nested reference on the reviewer id and dangling on merge/accept/reject. IrCompositeMarkupRenderer.ApplyCompositeNoteDiffs now rewrites the nested references inside every reviewer-inserted note definition (all-ins, single-id-space content) through the same outputId map, before the body-order renumber carries them to their final ids. Base-matched notes already worked and are untouched. New IrCompositeCrossKindNoteTests: base cross-kind nesting survives the N-way renumber (x3 policies); inserted-fn-cites-existing-en and inserted-en-cites- existing-fn; and inserted-fn-cites-inserted-en (the previously-dangling case). Each asserts structural reference resolvability on merge/accept/reject; a schema check runs alongside (excluding Sem_MissingReferenceElement, which OpenXmlValidator false-positives on cross-part note-body refs). Non-vacuity confirmed by sabotaging the cross-kind remap. Full suite 2640/0/3. Closes the last untested corner of the note-scope Consolidate merge.
JSv4
added a commit
that referenced
this pull request
Jul 9, 2026
…ormat changes + cross-kind note fix (#261) * feat(diff): Consolidate B2 Phase 0+1 — table-shell N-way merge (tcPr/trPr/tblPr/tblGrid/tblPrEx) + byte-level verifiers Phase 0: strengthen the format-blind composite verifiers first — new Docs.ShellSection byte-level shell/section projection, asserted alongside the text projections in CompositeFuzzTests (3/4/5-way regression guard) and the new ConsolidateBlockFormatB2Tests (per-family reject=base/accept=winner). Phase 1: carve TrackTableFormatChanges (+ TrackSectionFormatChanges) slices out of the umbrella TrackBlockFormatChanges (mirrors B1's paragraph slice; public opt-out cascades to all three); the composite turns the table slice ON. Single-reviewer table shells merge via the two-way single-source render. Multi-reviewer cells stamp w:tcPrChange at the composed-table render gap (was: shell swapped with no marker -> reject != base). Multi-reviewer trPr/tblPr/tblGrid/tblPrEx compose per-element via ComposeTableAndRowShells (mirrors ComposeCellShell: 0->base/agree->consensus/>=2->conflict/non-stackable), carried on IrAuthoredRowOp.TrPr/TblPrEx + IrCompositeOp.TableShell and stamped by ApplyComposedShell. Revision surface re-gated onto the table slice. reject == base / accept == policy-winner hold at the property-byte level. B1 ceiling pins re-baselined. * feat(diff): Consolidate B2 Phase 2 — section N-way merge (w:sectPrChange, trailing + inline) Carve TrackSectionFormatChanges out of the umbrella (public opt-out cascades); the composite turns it ON. Trailing sectPr is not a body block op (Word compares it at the document level), so ComposeTrailingSection composes base vs each reviewer's trailing IrSectionBreak.FormatFingerprint (modeled + unmodeled digest), mirroring ComposeCellShell; the winner rides on IrCompositeScript.TrailingSectPr and the composite renderer stamps w:sectPrChange (inner = base, header/footer refs preserved) via ApplyComposedTrailingSectPr. Inline (in-pPr) sectPr merges by riding B1's paragraph FormatOnly path (SectionKey re-gated onto the section slice). Two-way section emission + revision surface re-gated onto the section slice (byte-identical when all slices on; 470 two-way + composite regression green). reject == base / accept == policy-winner at the property-byte level. * test(diff): Consolidate B2 Phase 3 — pin text+format as conflict-routed (v1 decision, never silent-drop) Per the ratified v1 decision, a reviewer editing a paragraph's TEXT and pPr is conflict-routed, not inline-composed. The existing ParagraphPropsUnchanged guard already implements this: a cross-reviewer text+pPr collision falls out of token-composition into a RECORDED block conflict (never a silent format drop, because RenderComposedParagraph clones base pPr and is never reached with a pPr-changed reviewer); a SINGLE reviewer's text+pPr edit tracks both (w:ins/w:del + w:pPrChange). True inline text+format compose is deferred to B3. No production change — pins only. * docs(diff): Consolidate B2 — flip the block-format ceiling in CHANGELOG/CLAUDE/ir_diff_engine Consolidate now merges the paragraph (B1) + table-shell + section (B2) block-format families with per-element attribution + native markup; competing edits conflict per policy; reject == base / accept == policy-winner at the property-byte level. text+pPr stays conflict-routed (v1 decision). The only remaining block-format ceiling is split/merge-member pPrChange (a principled decline). * fix(diff): Consolidate B2 — emit the trailing-section revision exactly once, not per-op The composite revision renderer renders each op through a two-way one-op mini-script, and the two-way renderer appends the DOCUMENT-LEVEL trailing-sectPr FormatChanged revision (it compares the two docs' final section blocks). So a section-changing reviewer with N ops emitted the section revision N times (6x in a 2-paragraph+section edit). New internal IrDiffSettings.EmitTrailingSectionRevision (default true, two-way unaffected) is set false for the composite per-op mini-scripts; the composite renderer emits the section revision EXACTLY ONCE from script.TrailingSectPr, attributed to the section winner. Pinned. * fix(diff): Consolidate B2 — anchor-aware row-shell pairing + delete-vs-shell conflict + shell revisions (adversarial review) Adversarial silent-drop review found two correctness holes in ComposeTableAndRowShells's per-row shell composition, both when a reviewer restructures rows AND another touches the table: - Finding A (HIGH): row shells paired POSITIONALLY guarded only by row count. A co-toucher's row delete/insert either dropped a trPr/tblPrEx change on a kept row (count mismatch) or, worse, mis-paired it to the wrong row and stamped a PHANTOM w:trPrChange corrupting the accept output (net-zero restructure). Fixed with ResolveRightRowForBaseRow: anchor-aware right-row resolution (a content toucher maps via its TableDiff row op; a pure-shell FormatOnly toucher is content-equal so positional is sound) — a co-toucher's restructure can never shift the pairing. - Finding B (MEDIUM): a pure-shell reformat of a row another reviewer DELETES was attached to the DeleteRow op and silently dropped. Now a delete-vs-reformat records a conflict (never silent); the delete wins. - Finding C: multi-reviewer table-shell changes (AuthoredRows path) + the trailing section were absent from GetConsolidatedRevisions. The composite revision renderer now emits Table/TableRow/TableCell shell revisions (digest-guarded for cells) attributed to each winner, matching two-way GetRevisions. Pinned by 4 new tests (row-delete+shell, delete-vs-shell conflict, multi-reviewer shell revisions). * fix(diff): Consolidate B2 — guard tblGrid composition against structural column changes (round-trip review) Adversarial round-trip review found tblGrid was composed purely on TblGridDigest inequality with no column-count guard. A structural column ADD/REMOVE also changes TblGridDigest, so B2 misclassified it as a grid-PROPERTY change and composed it independently — leaving the accepted grid's gridCol count disagreeing with the tc count (a malformed table Word would auto-repair). reject == base always held; the break was accept-side. Now tblGrid composes as a property change only for a reviewer whose COLUMN COUNT matches base (a pure gridCol-width edit); a column add/remove is left to ComposeTableDiffs (native w:cellIns/w:cellDel), which owns the grid — no spurious w:tblGridChange. Pinned by two tests (column-add emits no tblGridChange; pure width change still composes). The other 6 round-trip hunts verified SAFE. * fix(diff): Consolidate M-A #4 — rewrite cross-kind note refs nested in reviewer-inserted notes A reference nested inside a reviewer-INSERTED note's definition body was never rewritten from the reviewer's id space to the output id space. The body-reference rewrite (step 2) only visits body clones and the renumber sweep (step 4) keys on the output-old id, so a reviewer inserting a footnote whose text cites an endnote the same reviewer ALSO inserts — whose target becomes a fresh output id, not a base id — left the nested reference on the reviewer id and dangling on merge/accept/reject. IrCompositeMarkupRenderer.ApplyCompositeNoteDiffs now rewrites the nested references inside every reviewer-inserted note definition (all-ins, single-id-space content) through the same outputId map, before the body-order renumber carries them to their final ids. Base-matched notes already worked and are untouched. New IrCompositeCrossKindNoteTests: base cross-kind nesting survives the N-way renumber (x3 policies); inserted-fn-cites-existing-en and inserted-en-cites- existing-fn; and inserted-fn-cites-inserted-en (the previously-dangling case). Each asserts structural reference resolvability on merge/accept/reject; a schema check runs alongside (excluding Sem_MissingReferenceElement, which OpenXmlValidator false-positives on cross-part note-body refs). Non-vacuity confirmed by sabotaging the cross-kind remap. Full suite 2640/0/3. Closes the last untested corner of the note-scope Consolidate merge.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Updated DocumentFormat.OpenXml from 3.2.0 to 3.3.0.
Release notes
Sourced from DocumentFormat.OpenXml's releases.
3.3.0
Added
DocumentFormat.OpenXml.Office.SpreadSheetML.Y2024.WorkbookCompatibilityVersionnamespaceFixed
.ToFlatOpc(...)has been greatly improved for large parts (#1863)Thanks to the following for their contributions:
@QuocDatHoang
Commits viewable in compare view.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)