I am using Aspose Words for Java (on-premise version) to edit Word documents.
Currently, I am able to generate tracked changes successfully, but I would like to improve the UX for accepting changes.
Right now, when both a deletion and an insertion occur at the same location, the user has to:
Accept the deletion → Accept the insertion
This means it takes two steps to accept what is logically a single edit.
In contrast, in the Microsoft Word desktop application, when a deletion and insertion occur at the same location, they are treated as a single combined change, so the user can accept both with one action.
What I want to achieve is:
When opening a docx file that was modified using Aspose Words for Java in the Microsoft Word desktop application,
the deletion and insertion at the same location should be recognized as one combined tracked change,
so that the user only needs one acceptance action instead of two.
Here are the things I’ve tried so far, but they didn’t work:
- Making
w:del and w:ins completely adjacent.
- Setting the same
author for both w:del and w:ins.
- Setting the same
w:date value for both w:del and w:ins.
Are there any methods or implementation tips for generating a docx file with Aspose Words for Java that will make Microsoft Word treat a deletion and insertion at the same location as a single tracked change?
@shinya0913
Summary
- Aspose Words for Java creates separate
w:del and w:ins revision elements.
- The “single‑step” change you see in the Word UI is a move revision (
w:moveFrom / w:moveTo) that Word itself generates when a user edits a document while Track Changes is on.
- Aspose Words does not provide an API to create a combined delete‑and‑insert revision (move revision) – the
Revision objects are always of type DELETION or INSERTION and their IDs are generated internally.
Therefore, with the current Aspose Words for Java (on‑premise) you cannot make Microsoft Word treat the two revisions as one accept‑action change directly from the library.
Why the attempts you tried do not work
| What you tried |
Why it doesn’t combine the revisions |
Adjacency of <w:del> and <w:ins> |
Word groups only move revisions, not adjacent delete/insert pairs. |
| Same author |
The UI still shows two separate revisions; author is only a display attribute. |
| Same date |
Same reasoning – the grouping logic in Word ignores these attributes. |
(Not tried) Same w:id |
The id attribute is generated by Word for move revisions; Aspose does not expose a way to set it, and simply copying the same id onto separate del/ins elements does not make Word treat them as a move. |
What can be done today
-
Accept the change programmatically before the document reaches the end user.
Document doc = new Document("input.docx");
doc.getTrackRevisions().setAuthor("MyApp");
doc.startTrackRevisions();
// … make your delete/insert …
doc.stopTrackRevisions();
// Accept everything (or a subset) so the user sees a clean document
doc.acceptAllRevisions();
doc.save("output.docx");
This removes the need for the user to click Accept twice.
-
Post‑process the OOXML (outside of Aspose) if you truly need a move revision:
- Open the saved DOCX as a ZIP, locate the relevant
w:del / w:ins parts, replace them with a single <w:moveFrom> / <w:moveTo> pair and give both elements the same w:id.
- This is a manual OpenXML manipulation step; it is not supported by Aspose Words.
Note: Word may still treat a manually‑created move revision differently depending on surrounding formatting, and such hand‑crafted OOXML is fragile across Word versions.
Official documentation
Bottom line
Aspose Words for Java cannot generate a single combined delete‑plus‑insert tracked change that the Word UI will accept with one click.
The library only creates distinct Deletion and Insertion revisions. To obtain the “single‑step” experience you would need to either (a) accept the changes in code before delivering the file, or (b) perform a custom OpenXML transformation after the file is saved.
If you have any further questions or need help with programmatically accepting/rejecting revisions, feel free to ask!
Hi team, thank you for the detailed explanation.
I have a couple of concerns I’d like to confirm:
- Broken spec link
The Open XML “move revision” spec link you provided seems to be broken (404)
Could you please share the correct official link that documents w:moveFrom / w:moveTo for DOCX?
- No
w:moveFrom found in a real one-click case
I tested with a DOCX file that does allow a single-click accept in the Microsoft Word desktop UI.
After unzipping and inspecting /word/document.xml, I could not find any w:moveFrom / w:moveTo elements (including the range start/end variants).
I only found w:ins and w:del, yet Word still allowed me to accept the change in one step.
Based on this, I have the following questions:
- Is it possible that Word groups adjacent delete/insert pairs purely through its UI logic, without actually emitting move revision elements?
- If so, are there known conditions (e.g., exact adjacency, identical range boundaries, same parent run/paragraph, matching IDs/RSIDs, etc.) that trigger this behavior when generating DOCX files?
- Conversely, if
w:moveFrom / w:moveTo elements are truly required, could you please share a minimal example DOCX that uses these elements and is recognized by Word as a single combined change?
Additionally, based on this official documentation,
it appears that MoveFrom is related to moving a paragraph to another location, and may not be directly related to tracked changes themselves.
Could you please confirm if this understanding is correct?