After doing a Compare sometimes the revisions are in a different font from the original document. We have some code that tries to fix this. And in general it works. But sometimes it doesn’t work. Our code chains down to something similar to below. Using reflection to set the font property by property. But in some cases it just does not “stick” and for example the revision are in Calibri Light even though we set the font.Name to “Times New Roman”.
Is there a better way to set the “destination run” below to look exactly like the “source run” maybe without reflection?
private static void SetFont(Run source, Run destination)
{
var myObjectProperties = typeof(Font).GetProperties();
foreach (PropertyInfo pi in myObjectProperties)
{
var sourceValue = pi.GetValue(source.Font, null);
if (sourceValue.Equals(pi.GetValue(destination.Font, null)))
{
continue;
}
if (pi.PropertyType == typeof(StyleIdentifier))
{
continue;
}
if (pi.CanWrite)
{
try
{
pi.SetValue(destination.Font, sourceValue, null);
}
catch (Exception ex)
{
throw error;
}
}
}
}
@ResearchSquare If both source and destination runs are in the same document, I would use clone operation. Something like this:
private static Run SetFont(Run source, Run destination)
{
Run result = (Run)source.Clone(true);
result.Text = destination.Text;
destination.ParentNode.InsertAfter(result, destination);
destination.Remove();
return result;
}
The code replaces the destination run with clone of source run with destination run’s text.
Our destination Runs have IsInsertRevision set to true. So if we clone a Run from the source, it will no longer have that set. And IsInsertRevision is read only.
I could do what you are saying and then now that we have a before and after document that are both formatted the same, we do a 2nd Compare. That is the only thing I can think of really. If we could just assign the source Font to the destination Font, and that worked, that seems like it would work. But you can’t assign a Font wholesale. Which is a bit surprising.
Our “first compare” is between the original document, and sort of a stripped down document we construct from a text file. When we Compare those we get this mis-match where the fonts are different.
But if we constructed a fully formatted version of the edited document, with your suggested code, then ran Compare with the fully formatted one against the original, then we shouldn’t have to do any fix up of fonts. The revisions should all match the original formatting. An extra Compare but maybe it would work.
@ResearchSquare Could you please attach your input documents here for our reference? Also it would be great if you provide sample code that will demonstrate how you reconstruct the document. Probably it will be easier to fix the reconstruction code to use the same fonts as source document. For example you can use original document as template for reconstructing the document.
The code is spread out over a lot of files, and it’s not easy to extract it.
We do somewhat use the original document as a template. We start by loading the original document. Then we step through its paragraphs. But for each paragraph we wipe out the runs, then insert new run(s) with the new text. We “start over” like this because we have no way to figure out which previous run matches which new text. They could be quite different.
Now that’s what Compare does. It figures out what the “inserted” runs are. And then we can go run-by-run looking at the inserted runs, and trying to make them match the previous run. But we can’t seem to do that fully, can’t get the styles to fully match.
For instance I see if we set the Theme it can change the font Name. But if we set the Name it can change the Theme. I don’t see a way to say “Make this run’s font/style identical the run that came before it”.
@ResearchSquare Thank you for additional information. We will consider adding a method Font.CopyFormatting method to make it possible to copy formatting from one Font object to another.
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): WORDSNET-26633
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.
Thanks for filing that feature request.
I did a test of a “double Compare” and it seemed to work. I did it like this:
We have an originalWord document and an editedText version of that same document, with potentially lots of changes. We create a Word version of editedText, somewhat using originalWord as a template, but we don’t have a way to get all the runs to be perfectly formatting with correct styles.
Next we Compare(originalWord, editedWord). This leaves a document with the correct revisions, but the insert revisions might be in the wrong format/style, since they are from editedWord. We used to run through and “fix” the INSERT run fonts, but that seems impossible to do perfectly. So now we do a “manual merge” pushing the run.Text from the inserted runs into neighboring runs. All runs now have the correct formatting, since they are all original runs.
Finally we Compare(originalWord, mergedWord). This is our final result: the insert revisions are all perfectly formatted with the surrounding runs.
I just did this for a simple case. I suspect finding the “adjacent runs” will get complicated in some cases we’ll have to work through. Like single-run paragraphs and tables and things.
@ResearchSquare It is perfect that you managed to font a workaround. We will keep you updated and let you know once coping font formatting feature is available.