Docx4j 6.0.1 released
Posted: Fri Aug 03, 2018 7:31 pm
Docx4j 6.0.1 is now available.
This is a replacement for 6.0.0, which in many cases writes <?xml version="1.0" ?> omitting encoding "UTF-8". Although UTF-8 is supposed to be the default encoding for XML, it is possible that some consumers may behave incorrectly.
This release makes the encoding explicit, and is recommended to anyone who may be working with 6.0.0.
For Maven users, 6.0.1 is in the Central Repository at http://search.maven.org/#search%7Cga%7C1%7Cdocx4j
Otherwise, see https://www.docx4java.org/downloads.html
Docx4j 6.0.0 release notes
Rather than calling it 3.4.0, it is called 6.0.0 since it still supports Java 6. (The plan is that docx4j 7.x, when released, will require Java 7+, and so on. Easy to remember.)
This release contains the following notable changes:
- support for Java 9 and 10
- preserve mc:AlternateContent in a run
New dependency commons-compress used for zip/unzip. Most other deps updated to last version supporting Java 6.
API breaking changes have largely been avoided, so it should be easy to get your code running against this.
Notable Changes in Version 6.0.0
Support for Java 9 and 10 (see notes in README for use in Eclipse)
- Maven profiles for java 9 and 10
- Maven pom now specifies source & target 1.6 (previously 1.5)
Preserve mc:AlternateContent in a run. Previously, this would have caused mc-preprocessor
to be invoked, selecting one of the pieces of content.
Object model for wps http://schemas.microsoft.com/office/wordprocessingShape
Content Control databinding (and OpenDoPE)
- UpdateXmlFromDocumentSurface: Copy content control content back to the custom XML part, like Microsoft Word does for a content control which has a w:databinding element
- improvements to migration (from eg VariableReplace)
- better support for binding standardised Answers format
- various other improvement
Write docx4j version as XML comment in MainDocument part.
New properties docx4j.openpackaging.parts.MAX_BYTES.unzip.error and docx4j.openpackaging.parts.MAX_BYTES.unmarshal.error which can be set to positive values to have docx4j throw a PartTooLarge exception if a part is larger than the set value.
This is a replacement for 6.0.0, which in many cases writes <?xml version="1.0" ?> omitting encoding "UTF-8". Although UTF-8 is supposed to be the default encoding for XML, it is possible that some consumers may behave incorrectly.
This release makes the encoding explicit, and is recommended to anyone who may be working with 6.0.0.
For Maven users, 6.0.1 is in the Central Repository at http://search.maven.org/#search%7Cga%7C1%7Cdocx4j
Otherwise, see https://www.docx4java.org/downloads.html
Docx4j 6.0.0 release notes
Rather than calling it 3.4.0, it is called 6.0.0 since it still supports Java 6. (The plan is that docx4j 7.x, when released, will require Java 7+, and so on. Easy to remember.)
This release contains the following notable changes:
- support for Java 9 and 10
- preserve mc:AlternateContent in a run
New dependency commons-compress used for zip/unzip. Most other deps updated to last version supporting Java 6.
API breaking changes have largely been avoided, so it should be easy to get your code running against this.
Notable Changes in Version 6.0.0
Support for Java 9 and 10 (see notes in README for use in Eclipse)
- Maven profiles for java 9 and 10
- Maven pom now specifies source & target 1.6 (previously 1.5)
Preserve mc:AlternateContent in a run. Previously, this would have caused mc-preprocessor
to be invoked, selecting one of the pieces of content.
Object model for wps http://schemas.microsoft.com/office/wordprocessingShape
Content Control databinding (and OpenDoPE)
- UpdateXmlFromDocumentSurface: Copy content control content back to the custom XML part, like Microsoft Word does for a content control which has a w:databinding element
- improvements to migration (from eg VariableReplace)
- better support for binding standardised Answers format
- various other improvement
Write docx4j version as XML comment in MainDocument part.
New properties docx4j.openpackaging.parts.MAX_BYTES.unzip.error and docx4j.openpackaging.parts.MAX_BYTES.unmarshal.error which can be set to positive values to have docx4j throw a PartTooLarge exception if a part is larger than the set value.