TOC / Styles Issue after Append

Hello, we are having an issue with a Table of Contents (TOC) item in bold font, that should not be bolded. We think this is due to the styles being dropped in only one section of a table (on a page referenced in the TOC).

See attached zip file for example documents mentioned below and screen snips.

When a new document is being created, before we start appending, we attach the DSTNormalTemplate.dot template. This holds some custom styles.

Code to create new document:

m_oAsposeDoc = new Document(myDocStylesFile.ToString());

object oTemplateName = this.m_sDocStylesFile;
m_oAsposeDoc.AttachedTemplate = oTemplateName.ToString();
m_oAsposeDoc.CopyStylesFromTemplate(oTemplateName.ToString());
m_oAsposeDoc.AutomaticallyUpdateStyles = false;

Then the following documents are appended to the m_oAsposeDoc:

DST TOC.DOC
SCHED BEN2 20231113c.DOC
HC-PRA1V5c2.DOC

Before the m_oAsposeDoc is saved to a file, the Document.UpdateFields() is executed to update the TOC. The results are in “Aspose18320.doc”

Now, if you look at the document with the screen snips, it shows the parts of the source document, “SCHED BEN2 20231113c.DOC”, with the custom styles there, and then it shows the same parts on the “Aspose18320.doc” without the custom styles, until a point where the custom styles match again between the source doc and the results.

I also included the results from the Word Interop assembly with the same source docs, “Word18320.doc”, and the styles are not dropped.

We believe this is what is causing the bold font issue in the TOC.

This is hard to explain, but the screen snips document in the zip file makes it easy to see what our issue is. Thank you!!

ForAsposeSupport.zip (734.6 KB)

@Egwene It looks like you are using ImportFormatMode.KeepSourceFormatting import format mode. If it is required to use the styles from the destination document, you should use ImportFormatMode.UseDestinationStyles. I have tested with the following simple code and styles are handled properly:

// Start from the template, it already contains the definition of the styles
// so it is not require to link to template or copy styles.
Document doc = new Document(@"C:\Temp\DSTNormalTemplate.dot");
// Clear the document.
doc.RemoveAllChildren();

// Append documents using the destination file styles.
doc.AppendDocument(new Document(@"C:\Temp\DST TOC.DOC"), ImportFormatMode.UseDestinationStyles);
doc.AppendDocument(new Document(@"C:\Temp\SCHED BEN2 20231113c.DOC"), ImportFormatMode.UseDestinationStyles);
doc.AppendDocument(new Document(@"C:\Temp\HC-PRA1V5c2.DOC"), ImportFormatMode.UseDestinationStyles);

// Update fields and save the output.
doc.UpdateFields();
doc.Save(@"C:\Temp\out.doc");

Thank you, this did work for us, however, we have a test case where it is not working. See attached zip file for word docs and screen snips.

the order of the docs for assembly are:

COVER-ETC.1.DOC
ET-TOC.DOC
HC-ETRDRc.DOC
HC-ETCARDRc.DOC
HC-ETDERDRc.DOC

The assembled doc shows the state names on the TOC in bold font. This is not expected, and the styles look off as well. The screen snips doc shows the difference between the styles on the Word Interop assembly vs Aspose Assembly.

18326.zip (612.1 KB)

@Egwene
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-26333

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.

FYI - It could be the UpdateFields that is somehow causing this issue.

When I open the assembled document, and right click on the TOC and Update it, the bolded part goes away, and the styles looks good.

Then I save the document, and run the code to generate the PDF. This code does the UpdateFields before saving the document as PDF. The bold issue then shows up on the TOC in the PDF even though the document no longer has the issue.

When I comment out the UpdateFields in the code, the PDF looks good.

@Egwene Thank you for additional information. Yes, we have also noticed that the problem occurs after updating fields in the document. We will keep you updated and let you know once the problem is resolved.