Hello Team,
I am converting a Word document using GroupDocs.Conversion with version 25.3.1.
In the source Word document, the table of contents are not updated with correct page numbers. However, during conversion, the Table of Contents gets updated automatically in the output document.
This happens even without explicitly setting the WordProcessingLoadOptions.UpdateFields property
Could you please confirm:
- Is Table of Contents always updated by default during conversion?
- If yes, what is the functional purpose of WordProcessingLoadOptions.UpdateFields?
Please clarify whether this behavior is expected or a defect.
cc: @pankajgupta
TocTest.docx (20.0 KB)
TocTest.pdf (75.1 KB)
@ravi1994
You reported that Table of Contents fields in a Word document are being updated during conversion with GroupDocs.Conversion 25.3.1, even though WordProcessingLoadOptions.UpdateFields is not explicitly set to true. You’re asking whether this behavior is expected or a defect, and seeking clarification on the purpose of the UpdateFields property.
-
Based on the available information, it is unclear whether Table of Contents fields are always updated by default during conversion in GroupDocs.Conversion 25.3.1. The behavior you describe — where fields are updated without explicitly setting UpdateFields to true — is a user-reported observation and requires confirmation from official documentation or source code analysis . This could be either an intended behavior or a potential defect.
-
According to the GroupDocs.Conversion for Java documentation, the WordProcessingLoadOptions.UpdateFields property is designed to control whether fields in the loaded document are updated during the conversion process. When set to false (which is the default), fields should not be updated . Therefore, if fields are being updated despite this property being unset or set to false, it suggests an inconsistency or unexpected behavior.
If you’d like further investigation into this behavior, please consider providing a minimal reproducible example or sample code that demonstrates the issue. A support engineer will follow up in this thread if needed.
Hello @ravi1994 ,
Thank you for contacting us. As you described, I was able to reproduce the same behavior with the resulting document on my side and have forwarded it to our developers for analysis. As soon as I receive feedback from them, I will get back to you and address your questions.
Sure @evgen.efimov, Please let us know once you have any update
hey @evgen.efimov : Can you please get us confirmed it sooner, since we are blocked on development.
Hello @pankajgupta ,
I apologize for the delay. I have asked our development team to expedite the investigation of your issue if possible. Please rest assured that I will notify you as soon as I receive an update from them.
Hello @ravi1994 , @pankajgupta ,
Our development team has confirmed that this was an issue related to the UpdateFields parameter. They have fixed its behavior, and this fix will be included in GroupDocs.Conversion for Java version 26.1. The release of this version is expected by the end of this month.
Thanks for confirming @evgen.efimov . Can you cconfirm on behavior with this fix?
@pankajgupta ,
By default, WordProcessingLoadOptions.UpdateFields was initially set to false. However, unfortunately, at the stage of saving the resulting document, this parameter was being overridden due to our third-party library, and field updates were applied regardless. After this fix, the parameter will now work as originally intended: if you need to update document fields, you should explicitly set it to true; if you do not need to update fields, you do not need to set it at all, since its default value is already false.
If you have any further questions, please feel free to contact us.
Thanks for the detailed functionality @evgen.efimov. Can you also clarify if this works well after the fix for both generating the docx with updated fields using WordProcessingConvertOptions and converting to pdf using PdfConvertOptions?
@ravi1994 ,
Sorry, but I’m not sure I fully understand your question. You mentioned an issue during DOCX to PDF conversion where the UpdateFields functionality did not work correctly — this issue will be fixed in the next release. Could you please clarify which second case you are referring to?
@evgen.efimov,
Apologies for the confusion caused. Just to restate my question more clearly:
What I meant was:
You have clarified if we do Docx to PDF conversion using PdfConvertOptions with UpdateFields = true, the TOC will be updated correctly in the PDF but we also wanted to know if we do Docx to Docx generation using WordProcessingConvertOptions with UpdateFields = true, will the TOC be updated in the newly generated Word document?
I want to confirm whether enabling UpdateFields ensures consistent TOC updates for both Word and PDF outputs, or if the behavior differs depending on the target format.
@ravi1994 ,
Let me quote our developer’s response to your question verbatim:
Yes, this will work the same way both for DOCX-to-DOCX conversion and for conversions from DOCX to other formats.
The key point is that if WordProcessingLoadOptions.UpdateFields = true, the fields in the DOCX document will be updated after loading.
After that, conversion to any target format will proceed with the updated fields.
Thanks @evgen.efimov for the confirmation. Will be waiting for the fix in the coming release.
The issues you have found earlier (filed as CONVERSIONNET-8170) have been fixed in this update. This message was posted using Bugs notification tool by nikola.yankov
hey @evgen.efimov , @aspose.notifier : Can you confirm when will this fix be available in java sdk?
Hello @pankajgupta ,
We apologize if this notification may have caused any confusion. We indeed created two separate tickets for the .NET and Java platforms (I have attached the corresponding ticket CONVERSIONJAVA-3055 to this forum thread). At this point, it is not yet clear whether this fix will be included in the upcoming 26.1 Java release. Our developers will try to add it to this version; however, if they are unable to do so in time, it will most likely be available in version 26.2. We will notify you as soon as it becomes available.
@evgen.efimov : Can you please help getting it prioritised in 26.1 for java as this is primarily reported and needed fo it only.
@pankajgupta ,
Our developer has just confirmed that this fix will be included in the 26.1 release for Java. I will notify you as soon as this version is officially released.