TOC generated using heading levels have incorrect page#

Our use case is to generate a word doc from HTML’s and also to include a few more information such as header, footer & TOC using IReplacingCallBack implementation. We are using Aspose.Words 21.7 version with valid license in environments.

The inserted TOC fields generate entries using heading levels with incorrect page numbers in a few cases on certain page and cascades to the rest of the pages following. See Incorrect Page Number in TOC.png (16.1 KB) for example.

We do ensure to call all the below listed Api’s to get the page numbers right, but they all didn’t help. But manually updating TOC in the Word app refreshes and corrects the right page numbers.

  1. doc.UpdateFields() & doc.UpdatePageLayout() in this order
  2. fieldToc.UpdatePageNumbers() &
  3. fieldToc.Update()

Attaching the sample project and generated document which mimics our exact problem for your perusal. Please do confirm us if we are missing any to get it right or it is something your team can help with a fix.
Sampe doc which has issue.docx (39.4 KB)
Sample App.7z (3.0 KB)

@earr,
The problem is caused by Evaluation version limitations. Aspose.Words injects a watermark into the header and footer of each section in your document. The resulting document has a slightly different formatting, and some content of the second page is pushed to the next page.

You can request a 30 days temporary license to test Aspose.Words without evaluation version limitations.
Here is DOCX document produced by licensed version on my side output.docx (9.5 KB)

@sergey.lobanov, Thanks for responding to this ask.

Took a peek on the doc you shared, which was produced by licensed version. I could still see the incorrect page# exists in the TOC even without the evaluation version footer being present. Refer the screenshot.png (7.8 KB) took from the shared doc, where I’ve highlighted the page numbers being wrong in red & the expected page numbers in green.

I’ve also tried by applying a valid license file in the shared sample project, still able to reproduce the problem without a footer injected from my side. In our real use cases, we do inject a footer & the resulting output is exactly same as the doc generated by the shared sample project. So, I’m able to mimic this problematic behavior with/without footer and with/without a valid license being applied.

Please let me know is there a way to resolve this.

@earr,
Unfortunately, we were unable to reproduce the same issue on our side. On my side, there are only 4 pages in the output document, and the TOC contents are correct when opened using MS Word 2016:

Could you please verify that you are using Aspose.Words 21.7 version in your app? On my side, the issue does not appear starting from 21.6 version. Also, we suggest you please upgrade to the latest 22.1 version of Aspose.Words for .NET.

@sergey.lobanov,

Took a peek at the shared image, it seems the page number in TOC is right at your end. Also good to know that you were using MS Word 2016. That’s the only & concerning difference I could think of. We use MS Word 2019 (Office 365).

Due to this difference, there may be a different page layout that could have given you the right numbers. As this issue is happening in a very edge case, I managed to update the previously shared sample project to explicitly reflect the page layout, margins & footer requirements which mimics our production output.

Also, a previously shared sample project used Aspose.Words for .Net 21.7 version. Since you stated, I also updated the package to the latest 22.1 version and tested using a valid license. I still managed to reproduce the same issue. Attaching the updated sample project and the reproduced output file for your perusal.

Reproduced Output with Aspose Words 22.1.docx (11.2 KB)
TocPageNumberIncorrect.7z (5.7 KB)

@earr,
Thank you for reporting this problem to us. For the sake of correction, we have logged this problem in our issue tracking system as WORDSNET - 23345. You will be notified via this forum thread once this issue is resolved.

We apologize for your inconvenience.

1 Like

@sergey.lobanov,

Thank you for considering this to give a resolution. Greatly appreciated!

Have one more request, could you please make this thread public? Somehow it’s been marked as private, couldn’t make it public of my own.

@Jagan2021

@earr I have made the thread public.