How to control OOXML compliance for WordProcessing documents
How to control OOXML compliance for WordProcessing documents
Leave feedback
On this page
Some downstream OOXML tooling supports only specific compliance levels. For example, Docx4j does not read ISO/IEC 29500:2008 Strict output, so consumers that rely on such libraries need the signed document produced in Transitional (or ECMA-376) form instead.
Starting with GroupDocs.Signature for Java 26.10, the Signature class preserves the OOXML compliance level of the source WordProcessing document on save, and lets you override it through WordProcessingSaveOptions.
How OOXML compliance is handled
The source OOXML compliance is detected when the document is loaded and preserved on save by default.
WordProcessingSaveOptions has the getOoxmlCompliance and setOoxmlCompliance methods. The value is an Integer:
null (default) — keep the loaded document’s compliance.
set — override the source value with the specified compliance level.
Only honoured for OOXML output formats: Docx, Docm, Dotx, Dotm and their FlatOpc variants.
It can be combined with a password set on the save options.
Supported compliance levels
The OoxmlCompliance class of the com.groupdocs.signature.domain.enums package defines the levels you can request on save as int constants:
Constant
Compliance level
OoxmlCompliance.Ecma
ECMA-376 1st Edition
OoxmlCompliance.Transitional
ISO/IEC 29500:2008 Transitional
OoxmlCompliance.Strict
ISO/IEC 29500:2008 Strict
Steps to override OOXML compliance on save
Create a new instance of Signature class and pass source document path or stream as a constructor parameter.
Instantiate required signature options (for example TextSignOptions).
Instantiate WordProcessingSaveOptions and call its setOoxmlCompliance method with the required level (OoxmlCompliance.Ecma, OoxmlCompliance.Transitional, or OoxmlCompliance.Strict).
Call the sign method of Signature class instance and pass signature options and WordProcessingSaveOptions object to it.
Example — force ISO/IEC 29500:2008 Strict on save
Signaturesignature=newSignature(filePath);try{TextSignOptionssignOptions=newTextSignOptions("John Smith");signOptions.setLeft(100);signOptions.setTop(100);signOptions.setWidth(200);signOptions.setHeight(60);// Force ISO 29500:2008 Strict on save regardless of the source's compliance.
// Other allowed values: OoxmlCompliance.Ecma, OoxmlCompliance.Transitional.
WordProcessingSaveOptionssaveOptions=newWordProcessingSaveOptions(WordProcessingSaveFileFormat.Docx);saveOptions.setOoxmlCompliance(OoxmlCompliance.Strict);SignResultresult=signature.sign(outputFilePath,signOptions,saveOptions);}finally{signature.dispose();}
Example — save as Transitional for downstream compatibility
Use OoxmlCompliance.Transitional when the consumer of the signed document only reads ISO/IEC 29500:2008 Transitional (or ECMA-376) DOCX — for example when the file will be post-processed by a library that does not support Strict.
Do not call setOoxmlCompliance (or call it with null) to preserve whatever compliance level the loaded document was authored in.
Signaturesignature=newSignature(filePath);try{TextSignOptionssignOptions=newTextSignOptions("John Smith");signOptions.setLeft(100);signOptions.setTop(100);signOptions.setWidth(200);signOptions.setHeight(60);// OoxmlCompliance not set => source compliance is preserved on save.
WordProcessingSaveOptionssaveOptions=newWordProcessingSaveOptions(WordProcessingSaveFileFormat.Docx);signature.sign(outputFilePath,signOptions,saveOptions);}finally{signature.dispose();}
The SaveWordProcessingWithOoxmlCompliance class of the Java examples runs the first example.
More resources
GitHub Examples
You may easily run the code above and see the feature in action in our GitHub examples: