Aspose.Words for Java 18.9 Release Notes

Major Features

There are 85 improvements and fixes in this regular monthly release. The most notable are:

• Animated GIF is fully supported now
• MANIFEST.MF updated to support new OSGI versions
• TIFF colors accuracy improved
• Java10&11 compatibility improved: reflection for safe using of optional external libraries is removed.
• Bookmarks are allowed on block, cell, row level 
• Added load option to treat Shapes with math XML as Shapes in the model 
• Provided option to choose between Old and New Mail Merge behaviors 
• Improved PDF encryption in case when owner password is not specified 
• Metafile rendering improved: fixed drawing records processing when path bracket is opened, fixed processing of EMR_SETBKMODE record when incorrect values specified
• Improved output image quality when rendering metafiles with raster operations set
• Fixed handling of glyphs without outlines when parsing glyph data while rendering
• Fixed a bug with a glow effect, if the specified glow size is less than 10
• Fixed several problems in DrawingML Charts rendering: incorrect default axis color, bug with the date format for axis values, bug with rendering of the trend line with unsorted x-values
• Improved rendering of the mathematical element “Apostrophe” of the MathML object 
• Improved justification of Asian texts
• Improved rendering of revisions in balloons
• Improved text placement around floating shapes
• Fixed issue with paragraph spacing in footnotes
• Fixed issue with line wrapping when it has single glyph wider than the line followed by page break
• Fixed issue with table row height calculation when cells in vertical merge have horizontal borders

Full List of Issues Covering all Changes in this Release

Public API and Backward Incompatible Changes

This section lists public API changes that were introduced in Aspose.Words 18.9. It includes not only new and obsoleted public methods, but also a description of any changes in the behavior behind the scenes in Aspose. Words which may affect existing code. Any behavior introduced that could be seen as a regression and modifies existing behavior is especially important and is documented here.

Bookmarks are Allowed on Block, Cell, Row Levels

WORDSNET-721 has now been resolved.

The bookmark nodes are allowed to be placed on the block, cell and row levels now. In the previous versions bookmarks were moved into the next nearest paragraph on document loading. So, now on reading/saving DOCX, DOC, WML documents, bookmarks preserve their positions in document node structure. The following public properties have been added into the LoadOptions class to control the mentioned behavior.

/// <summary>
/// Gets or sets a flag indicating whether cross structure annotation nodes can be added at block/cell/row level (<see cref="Node.NodeLevel"/>).
/// </summary>
/// <remarks>
/// Currently only bookmarks are affected by this option.
/// </remarks>
public boolean AnnotationsAtBlockLevel { get; set; }
/// <summary>
/// Gets or sets a default value for the <see cref="AnnotationsAtBlockLevel"/> property.
/// </summary>
/// <remarks>
/// Allows defining necessary behaviour when an instance of <see cref="LoadOptions"/> is not specified on opening a document.
/// </remarks>
public static boolean AnnotationsAtBlockLevelAsDefault { get; set; }

Now code that uses Aspose.Words should consider that not only composite nodes may appear on the block/cell/row level, for example, as children of the Body, Table, Row, Cell nodes. Setting the AnnotationsAtBlockLevelAsDefault property to false allows temporarily prevent possible issues with the existing code. But please note that the property may become obsolete in the further versions of the software.

UC to open a document in the inline-bookmarks mode

LoadOptions options = new LoadOptions();
options.setAnnotationsAtBlockLevel(false);
Document doc = new Document("Document1.docx", options);

UC to set the “old” mode as default

LoadOptions.setAnnotationsAtBlockLevelAsDefault(false);

Added LoadOption to Treat Shapes with Math XML as Shapes in Model

WORDSNET-16540 has now been resolved.

The “ConvertShapeToOfficeMath” property has been added to “LoadOptions” class.

/// <summary>
/// Gets or sets whether to convert shapes with EquationXML to Office Math objects.
/// </summary>
public boolean ConvertShapeToOfficeMath
{
    get { return mConvertShapeToOfficeMath; }
    set { mConvertShapeToOfficeMath = value; }
}

Default value corresponds to MS Word behaviour i.e. shapes with equation XML are not converted to Office math objects.

Use case:

LoadOptions lo = new LoadOptions();
lo.setConvertShapeToOfficeMath(true);

// Specify load option to use previous default behaviour i.e. convert math shapes to office math ojects on loading stage.
Document doc = new Document("SrcFile.docx", lo);

Option to Choose Between Old and New Mail Merge Behaviors Added

WORDSNET-17313 has now been resolved.

We had a customer (issue: WORDSNET-17259) who was not happy with the current Aspose.Words behavior related to the IF fields evaluation during mail merge. They were relying on the fact that the merge fields and regions located in the “false” argument of the IF field (“false” meaning the argument that does not match the condition) were merged in the past along with the “true” argument. This behavior was changed over time to mimic MS Word and at the moment it matches MS Word (the “false” argument is not merged); however the customer considered it a regression and wanted the old behavior back. To satisfy them, we decided to introduce an option controlling the behavior.

/// <summary>
/// Gets or sets a value indicating whether merge fields and merge regions are merged regardless of the parent IF field's condition.
/// </summary>
/// <remarks>
/// The default value is <b>false</b>.
/// </remarks>
public boolean UnconditionalMergeFieldsAndRegions

Use case:

document.getMailMerge().setUnconditionalMergeFieldsAndRegions(true);
document.getMailMerge().execute(dataSource);

Improved PDF encryption in Case when Owner Password is not Specified

WORDSNET-17316 has now been resolved.

Previously Aspose.Words created random owner password in the produced PDF document when PdfEncryptionDetails.OwnerPassword was not set by the user. This behavior was described in XML comments:

If you do not specify an owner password, then the system will generate a random password when generating the PDF document.

Now Aspose.Words properly sets the empty owner password when saving to PDF.