Dear Aspose,
I am trying to delete a numbering style from a .dotx (see inside SDWEB-4981_style_delete_fail.zip (19.0 KB)), however getting a ‘ConcurrentModificationException’ while saving the document.
Following code reproduces the issue with Aspose Words (Java) 21.4
InputStream docxInputStream = getDocument("SDWEB-4981_style_delete_fail.dotx");
Document docx = new Document(docxInputStream);
StyleCollection styles = docx.getStyles();
Style wshList = styles.get("PRK list style Aai_1");
wshList.remove();
docx.save("ListStyleRemoval_done.dotx");
java.util.ConcurrentModificationException
at java.base/java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1042)
at java.base/java.util.ArrayList$Itr.next(ArrayList.java:996)
at com.aspose.words.zzZCH.zzZ0F(Unknown Source)
at com.aspose.words.zzZCH.zzi3(Unknown Source)
at com.aspose.words.zz3I.zzM(Unknown Source)
at com.aspose.words.zz3I.visitDocumentEnd(Unknown Source)
at com.aspose.words.Document.zzY(Unknown Source)
at com.aspose.words.CompositeNode.acceptCore(Unknown Source)
at com.aspose.words.Document.accept(Unknown Source)
at com.aspose.words.zz3I.zzX(Unknown Source)
at com.aspose.words.Document.zzZ(Unknown Source)
at com.aspose.words.Document.save(Unknown Source)
at com.aspose.words.Document.save(Unknown Source)
@avandenhoogen
We have tested the scenario and have managed to reproduce the same issue at our side. For the sake of correction, we have logged this problem in our issue tracking system as WORDSNET-22201. You will be notified via this forum thread once this issue is resolved.
We apologize for your inconvenience.
Dear Tahir,
Thanks for the reply. Do you maybe have a workaround or can indicate what causes the exception so we can find a workaround?
So what we want to achieve is to either remap styles to other styles (i.e. all content using certain style should use another style) and/or removal of certain styles from the document.
I noticed that I am able to rename other types of styles, however calling .rename() on the list type styles still leaves the old name style in the document. Is this also a bug or should I do this in another way?
regards,
Waruzjan
@avandenhoogen
You can save your document to DOCX as a workaround of this issue. Unfortunately, for DOTX the problem still remains. You need to wait for the fix of this issue.
Document docx = new Document(MyDir + "SDWEB-4981_style_delete_fail.dotx");
StyleCollection styles = docx.getStyles();
Style wshList = styles.get("PRK list style Aai_1");
wshList.remove();
OoxmlSaveOptions options = new OoxmlSaveOptions();
options.setCompliance(OoxmlCompliance.ISO_29500_2008_STRICT);
options.setSaveFormat(SaveFormat.DOCX);
docx.save(MyDir + "ListStyleRemoval_done.docx", options);
You can use Document.Cleanup method (CleanupOptions) to clean unused styles and lists from the document depending on given CleanupOptions. Hope this helps you.
Thanks for the quick response and the example code.
I tried with the compliance set, but with the .DOTX format and it works fine.
options.setCompliance(OoxmlCompliance.ISO_29500_2008_STRICT);
options.setSaveFormat(SaveFormat.DOTX);
I assume this combination is valid? What does the compliance exactly do ? does it have downsides?
I used to save with doc.save(output, SaveFormat.DOTX); I assume it then uses another compliance that triggers the error? just to be sure whether using certain compliance can have negative side effects.
@avandenhoogen
Aspose.Words does not throw exception for your document when it is saved to DOTX. However, MS Word does not open output document at our end.
There is no side effects of using this compliance level. The OoxmlSaveOptions.Compliance property specifies the OOXML version for the output document. The ISO_29500_2008_STRICT is Strict compliance level.
Our tools have issues opening the .dotx saved with Strict compliancy as well.
However, I have found a workaround. In order to prevent the ConcurrentModificationException, I save the document first as strict ISO compliant, then as ECMA_376 (which seem to be the default compliancy, right?)
LoadOptions loadOptions = new LoadOptions();
loadOptions.setLoadFormat(LoadFormat.DOTX);
InputStream document = getDocument("DocxTableCompliance.dotx");
Document docx = new Document(document);
OoxmlSaveOptions saveOptions = new OoxmlSaveOptions(SaveFormat.DOTX);
saveOptions.setCompliance(OoxmlCompliance.ISO_29500_2008_STRICT);
docx.save(new ByteArrayOutputStream(), saveOptions);
saveOptions.setCompliance(OoxmlCompliance.ECMA_376_2006);
docx.save("DocxTableCompliance_iso_strict_then_ecma.dotx", saveOptions);
Unfortunately I have noticed that STRICT compliancy changes the content of the document.
<w:tblGrid>
<w:gridCol w:w="4788"/>
<w:gridCol w:w="4788"/>
</w:tblGrid>
becomes
<w:tblGrid>
<w:gridCol w:w="4675"/>
<w:gridCol w:w="4675"/>
</w:tblGrid>
which changes the width/positioning of my table when saved to PDF/HTML with Aspose.
Is this by design or a bug? Attached you can find .zip with in it 
- DocxTableCompliance.dotx: the original .dotx created with Word
- DocxTableCompliance_def.dotx is the result of saving with doc.save(output, SaveFormat.DOTX)
- DocxTableCompliance_ecma.dotx is the result of ecma save option (interessting to know why the namespaces declarations in document.xml differ from _def.dotx, since ecma seems to be used by SaveFormat.DOTX)
- DocxTableCompliance_iso_strict.dotx is the result of strict iso save option
- DocxTableCompliance_iso_strict_then_ecma.dotx is the result of the code above
DocxTableCompliance.zip (62.0 KB)
@avandenhoogen
It is nice to hear from you that you have found the workaround of your issue.
Please note that Aspose.Words mimics the behavior of MS Word. If you perform the same scenario using MS Word, you will get the same output.
The issues you have found earlier (filed as WORDSNET-22201) have been fixed in this Aspose.Words for .NET 21.6 update and this Aspose.Words for Java 21.6 update.