Comments and Revisions

Review markup comes in two shapes that share almost nothing in the file format. A comment lives in its own part of the document package, comments.xml, and is tied to the body only by a pair of range markers and a reference run, which is why adding one is not a matter of setting a property on a paragraph. A tracked change is the opposite: the w:ins or w:del element sits inline in the body, wrapping the runs it applies to.

That difference shows up in what the API supports. Comments can be created, listed, threaded, resolved and removed, because the part they live in is a first-class object UniOffice reads and writes. Tracked changes can only be created. Paragraph.AddInsertedText and Paragraph.AddDeletedText write the markup, and nothing in the document package reads it back, so there is no accept, no reject, and no listing of the revisions in a document you opened.

Comment threading is a third part again. Replies, and the resolved flag, are recorded in commentsExtended.xml keyed by paragraph ID, so a document written by a tool that only emits comments.xml has comments with no thread structure at all. Comment.Replies() and Comment.Done() read that part, which is why they can come back empty on a file whose comments plainly form a conversation.

Both kinds of markup survive independently of the text around them. Deleting a paragraph a comment points at leaves the comment behind with a broken anchor, so code that strips content should decide what happens to the review markup at the same time.

Where to look