We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

Wrong Font information returned when there are Tracked Formatting Changes

I am working with a document which has Tracked Changes. My program has to relate to the “final” text; however, I am not at liberty to just accept all changes, but rather I must preserve all Tracked Changes as they are.

With regard to text changes, there is no problem. As I process the Runs within the document, I first check IsDeleteRevision(), and I ignore any text which is marked as a Delete Revision.

However, with regard to Font formatting, I can’t find anyway to retrieve the “final” state of the text.

For instance: I have a document in which the first word was bold in the original text, but then it was changed to non-bold. This change is a tracked change - not a deletion/insertion, but rather a formatting change.
When I look at the relevant Run with Aspose, however, the Font.Bold property is marked as True, even though the text is currently non-bold!

Why is Aspose only providing the “original” state of the Font, before the change? How can I access the “final” state? (This capability is absolutely critical for our application!)

Hi Avi,

Thanks for your inquiry. Perhaps, you’re using an older version of Aspose.Words; as with Aspose.Words v11.9.0, I am unable to reproduce this problem on my side. I would suggest you please upgrade to the latest version of Aspose.Words i.e. v11.9.0 and let us know how it goes on your side. I hope, this will help.

I have tried this again with many versions of Aspose.Words, including the latest (13.8), and the problem still persists.

Reproducing the problem is simple:
1] Create a Word document with one sentence in it, without any bold.
2] In Microsoft Word, with Track Changes on, highlight the first word and change it to bold, and save.
3] Now, with Aspose, load the document, and look at the first run. The first run will be marked as “bold=false”, even though it is set to bold in the Word document!

In short, what I find is when a tracked formatting change has been made within a Word document (that is, a change that affects only formatting, without any insertion of deletion of text), Aspose will report the formatting of the original document, and there will be no way to retrieve the formatting of the current state of the document.

I’ve enclosed a sample Word file which demonstrates this. When viewing it in MS Word, the first word is bold. However, when opening this up with Aspose, the first run, which contains the first word, reports that bold is “false”.

This is a critical issue affecting our productivity with Aspose.Words.

Hi there,

Thanks for your inquiry. I have managed to reproduce the same issue at my side. I have logged this issue as WORDSNET-8977 in our issue tracking system. I have linked this forum thread to the same issue and you will be notified via this forum thread once this issue is resolved.

We apologize for your inconvenience.

Hi there,

It is to inform you that our development team has completed the work on the issue (WORDSNET-8977)
and has come to a conclusion that this issue and the
undesired behavior you’re observing is actually not a bug in
Aspose.Words. So, we have closed this issue as ‘Not a Bug’.

Please note that when a document is loaded into Aspose.Words DOM and it has any tracked changes, Aspose.Words shows the text formatting before the track changes and just after Document.AcceptAllRevisions you will get final text formatting.


To insist that users must first “Accept all revisions” before accessing the current content of a document, is completely debilitating. It also largely defeats the purpose of the entire TrackChanges API that you labored so hard to introduce, and which you advertise with so much fanfare.

In my case, my program receives as input documents which our clients have marked up with various revisions. My program needs to process the documents in various ways, and to then return the document to the regular chain of command - but without eliminating the tracked changes! The point of the tracked changes is so that there will always be accountability to determine who added what to the document. By requiring that your users always AcceptAllChanges before being able to properly edit the document, you are essentially FORCING our clients to LOSE ALL THEIR TRACKED CHANGES - and to lose all the accountability that the tracked changes provide. So for the many many clients who rely on tracked changes, Aspose no longer provides a viable solution whatsoever.

In fact, it was precisely the ability to work with Tracked Changes that placed Aspose on a much higher pedestal than the standard free WordProcessingMP tools. When I pitch Aspose to my associates, who wonder why they should pay so much for Aspose when the WordProcessingML are free, I point them to the Microsoft MVP website which notes that in order to effectively work with WordProcessingML, all revisions must first be accepted. Then I show them how Aspose contains a full TrackChanges API. This, I find, is generally the most compelling argument, because nobody wants to eliminate all the valuable information contained within the tracked changes.

However, at this point you are essentially saying that you are not in fact able to provide a solution for clients to edit documents while preserving tracked changes.

At the end of the day, the ability to edit documents, while preserving the valuable tracked changes within the documents, is critical. It is critical in our line of business, and in many other companies that I associate with. To simply dismiss this as “not a bug”, and to simply say “just accept all changes”, is to ignore the needs of real-world users.

Hi Avi,

Thanks for your inquiry. I am in communication with the development team about shared scenario and will update you as soon as I have information on this.

Hi Avi,

Thanks for your inquiry. I have received response from our development team and like to share with you that Aspose.Words mimics the same behavior as MS Word VBA does. It always returns before-changes i.e original formatting and returns just textual representation (simple string) of after-changes i.e final formatting. So, we have closed this issue as ‘Not a Bug’.

Hope this answers your query. Please let us know if you have any more queries.

This is incorrect.

Word’s VBA interface actually provides complete flexibility for formatting changes, allowing the user to access BOTH the final as well as the original formatting, based on whether the Review setting of the active view is set for “Final” or for “Original”.

I posted a test file above (test12.docx). If you open the file, and select “Final” on the review tab, and then run the following VBA subroutine on the file, you will see that it returns the bold state of the FINAL formatting:

Sub GetStyle()
IsBold = ActiveDocument.Characters(2).Font.Bold
MsgBox “BoldState:” + Str(IsBold)
End Sub

And, conversely, if you select “Original” on the review tab, and then run the routine, it will return the bold state of the original formatting.

In light of this demonstration, I ask that you reopen this issue and address it properly, providing access to the final formatting, just as Word does in its VBA interface.

In fact, this can all be done programmatically. In order to demonstrate the capabilities of VBA for this issue, just load up the sample file I sent above (test12.doc), and run this function:

Sub GetStyleBoth()

ActiveDocument.ActiveWindow.View.RevisionsView = wdRevisionsViewFinal
ActiveDocument.TrackRevisions = True
IsBoldFinal = ActiveDocument.Characters(2).Font.Bold

ActiveDocument.ActiveWindow.View.RevisionsView = wdRevisionsViewOriginal
ActiveDocument.TrackRevisions = True
IsBoldOrig = ActiveDocument.Characters(2).Font.Bold

MsgBox “BoldState Final:” + Str(IsBoldFinal) + " BoldState Original:" + Str(IsBoldOrig)

End Sub

This function shows that VBA code can freely access both the original formatting as well as the final formatting. This is in contrast with the Aspose Word module, which can only access the original formatting.

Hi there,

Thanks for sharing the detail. Regarding VBA issue, I am in communication with the development team and will update you as soon as I have information on this.

Moreover, when you modify a document using Aspose.Words, these modifications are done to the document directly and will not appear as tracked changes. We had already logged this feature request as WORDSNET-754 in our issue tracking system. You will be notified via this forum thread once this feature is available.

We apologize for your inconvenience.

Thank you Tahir.

Please note: I am not asking here for the changes to be marked as “Track Changes” (even though that would be a great feature).

In this thread I am asking about something far more basic and critical: the ability to read and edit a document accurately according to its current “final” formatting, without destroying the “track changes” data already stored in the file.

It would be absurd if this basic ability, available for free in Word’s VBA interoperability module, would not be available in Aspose’s very costly Word component.

Hi there,

Thanks for sharing the detail. I am waiting for response from our development team about your query.

However, I have logged a new feature request as WORDSNET-9123 in our issue tracking system to get Run.Font properties according to display view (Final and Original). I will update you via this forum thread once I get response from our development team about your query and this feature request.

We apologize for your inconvenience.

Hi there,

Thanks for your patience. I have received response from our development team about WORDSNET-9123 issue. This issue has now been postponed till a later date due to some other important issues and new features. We will inform you as soon as there are any further developments. We apologize for your inconvenience.

As a workaround, please do a clone of your document and perform the accept changes on cloned document. In this way, you will get the correct value of Font.Bold property. Hope this helps you.

Hello Tahir,

Please update us regarding the status of the issue discussed within this thread (WORDSNET-9123). Has there been any progress here?

In your post from 11-18-2013, you suggest making a clone of the document and accepting changes within the clone, in order to determine the final formatting of the runs within the document. However, that solution only helps for cases where we make any significant modifications to the original document. Once we start modifying the original document - adding, splitting and deleting both paragraphs and runs - it becomes almost impossible to keep track of where the parallel runs are within the cloned document.

Hi there,

Thanks for your patience. I am afraid WORDSNET-9123 is still postponed due to some other important issues and new features. We will inform you as soon as there are any further developments.

We apologize for your inconvenience.

The issues you have found earlier (filed as WORDSNET-754) have been fixed in this .NET update and this Java update.

This message was posted using Notification2Forum from Downloads module by aspose.notifier.