Aspose.Words for SharePoint 2.4.0 has been released. This release includes the latest improvements made in Aspose.Words.

To download the release, please visit the download area.

As usual, we can answer any questions you have in the product forum .

Enjoy!

• Aspose.Words for .NET 11.0
• Aspose.Words for Java 11.0

This release contains 74 great new improvements and fixes to Aspose.Words. Here is a look at some of the most notable improvements:

Comments are now Rendered to Fixed-Page Formats

The new version of Aspose.Words introduces support for rendering of comments in Microsoft Word to fixed-page formats such as PDF. The output is similar to how Microsoft Word renders comments to formats like PDF.

This is only the first version of comment rendering, so there are some limitations which we have detailed below:

• There’s no automatic coloring and numbering  - all the comments are rendered in red for the time being.
• Comments are rendered one by one from top to bottom without any special distribution rule applied.
• Long comments which are too large for the comment bubble are not clipped.

We will be constantly improving this feature with each release so these limitations will eventually be removed.

Here’s an example of the output produced by Aspose.Words. The comments are now properly rendered to PDF. Also note how the page size is preserved by scaling the document content and comments pane to fit the page size.

Options to Export PDF using Core Fonts or System Installed Fonts

There were a large number of requests from our customers to find a way to decrease the size of rendered PDF documents. The number one reason for a larger PDF size compared to the PDFs produced by Microsoft was because Aspose.Words always embedded fonts in the PDF. Microsoft Word by default does not embed core fonts, such as Arial.

The latest version of Aspose.Words introduces new options which allow you to choose how fonts are exported to PDF, either by using standard core PDF fonts or system installed fonts instead of embedding them into the document.

Using either one of these options results in significant reduction in the file size of PDFs generated using Aspose.Words. Note that these options are mutually exclusive so you should choose only one at a time to use for your particular needs.

Core Fonts Mode

This option can be set by using PdfSaveOptions.UseCoreFonts property. In this mode four of the most popular “True Type” fonts are replaced in the output PDF document with corresponding core “Type 1” fonts. These fonts are:

• Arial
• Times New Roman
• Courier New
• Symbol

This setting works only for the text in ANSI (Windows-1252) encoding. Writing non-ANSI text to PDF will always require the corresponding font to be embedded.

This option is also useful if you want a greater document portability since PDF viewer provides core fonts on any supported platform. One drawback is that the appearance of core fonts may be different from system fonts.

System Fonts Mode

This option can be set by using the PdfSaveOptions.EmbedStandardWindowsFonts property. When this property is set to false, true type “Arial” and “Times New Roman” fonts are not embedded into PDF so the client viewer is forced to rely upon the fonts which are installed on client operating system. This setting works only for the text in ANSI (Windows-1252) encoding. Writing non-ANSI text to PDF requires the corresponding font to be embedded.

This mode is most useful if you’re looking to view documents on the same platform and you also want to preserve the exact appearance of fonts in the output PDF.

Compound Lines Rendering

Previous versions of Aspose.Words use standard GDI+ objects for rendering compound (multiline) lines. This worked well when rendering directly to image, but such document formats as PDF and XPS have no explicit support for compound lines. The only way to render such lines types to these formats is to draw them as a set of normal lines.

This technique has been implemented and is now available in the latest version of Aspose.Words.

In Aspose.Words,  line styles of shapes are specified using Shape.Stroke.LineStyle property. Take a look below at how Aspose.Words now properly renders compound lines to PDF.

In Aspose.Words, we strive to make working with tables through our API powerful but also as simple to use as possible. In recent versions for both Aspose.Words for .NET and Aspose.Words for Java we have:

• Improved the table API to allow greater access to table features such as auto fitting a table to window or to contents.
• Added complete documentation for working with tables, full of useful information and detailed code examples for many scenarios when working with tables.
• Starting in Aspose.Words 10.5, changed some defaults used when creating tables so they are more similar to the defaults used when creating a table in Microsoft Word.

An Improved API for Tables in Aspose.Words

Just recently, we further improved our table API to allow great features such as setting the preferred widths of a table cells or applying autofit on a table. Starting in Aspose.Words 10.5 you can apply the following Microsoft Word standard autofit to any table in the document:

• Autofit to Window
• Autofit to Contents
• Fixed Column Widths

Further details on these new features can be found in our previous post here.

New Documentation for Working with Tables

We have also been hard at work working on the related documentation and we are proud to announce a brand new section in the documentation dedicated to working with tables in Aspose.Words.

This section is packed full of handy information and plenty of code examples for almost any common task that you might need to achieve when generating or modifying tables using Aspose.Words.

You can find the new section in the documentation under the Programmer’s Guide at:

• Working with Tables in Aspose.Words for .NET
• Working with Tables in Aspose.Words for Java

This documentation provides both useful information and example code for common tasks, such as:

• An overview of tables in Microsoft Word and Aspose.Words.
• Creating tables and applying different types of formatting.
• Specifying cell width and height
• Working with table styles
• Extracting or replacing plain text from a table or cell
• Working with Columns
• Working with Merged Cells
• Using Header Rows and Keep with Next
• Joining and Splitting Tables
• And more.

Automatically Building a Table in a Word Document from a Data Source

In addition to the Working with Tables section, we also provide a new “How-to” article with example code which demonstrates how to build a richly formatted table in a document by simply passing data from a chosen data source.

• For .NET this input data comes from any data source that returns data in the form of a DataTable
• For Java this input comes from any data source which returns data in the form of a ResultSet.

For example, we have this input data loaded in our application running Aspose.Words:

We can run the simple example code in the following article on this data. By calling the given method and few lines of code we can import this data into a fully formatted table in a new document:

• How-to: Build a Table from a DataTable in Aspose.Words for .NET
• How-to: Build a Table from a ResultSet in Aspose.Words for Java
  
  

And the following output below is generated by running the code. A table style was applied to the table to effortlessly apply great formatting to the table with just two lines of code:

Changes to Table Defaults comes with a Handy Migration Guide

Lastly, with the introduction of the new table API, we also made a few changes to the defaults used when creating new tables using Aspose.Words. We did this so creating a new table in Aspose.Words more closely follows the formatting defaults used in Microsoft Word when performing the same task. We believe this behavior will be more intuitive and much easier for new users to work with.

If you have any existing code which generates tables you may find that after upgrading to Aspose.Words 10.5 they have started to look different because of these changes.  Of course, we provide a handy migration article for you to port your code over. There are only a few changes and they are very simple.

This article explains all of the changes made to defaults in the new version of Aspose.Words and provides quick code changes to be made to revert to the old behavior.

You can find the migration article for your appropriate platform here:

• How-to: Migrate to Aspose.Words for .NET 10.5 or higher
• How-to: Migrate to Aspose.Words for Java 10.5 or higher

In Aspose.Words 10.8, released a few days ago, we introduced some new options that allow removing various items from the document while a mail merge is performed. Until this release two properties controlled whether empty paragraphs and regions were removed - MailMerge.RemoveEmptyParagraphs and MailMerge.RemoveEmptyRegions, respectively. These properties are still there, but have been marked obsolete, so there is a new way to instruct the mail merge engine how to perform a cleanup.

We have introduced a MailMergeCleanupOptions enumeration whose members are flags, so that different options may be used simultaneously. The options are specified via the MailMerge.CleanupOptions property which should be used instead of the obsolete properties.

MailMergeCleanupOptions Members

The new property takes a number of enumeration members, each described below.

None

This is the default value. Nothing interesting here.

RemoveParentParagraphs

This option is generally similar to the RemoveParentParagraphs property which is now obsolete. However, the option is slightly improved in comparison to the property. The property only treated a paragraph as empty if it had no child nodes at all, while the new option removes a paragraph even if it contains whitespace characters like spaces or tabs. Previously, a paragraph with a space character in it would not be removed. Now, it will.

RemoveUnusedRegions

This option is almost identical to the obsolete RemoveEmptyRegions property, but, again, is slightly improved. First, as you may note, the name is changed a bit. “Unused” is more correct than “empty” because there are, in reality, no empty merge regions. However, mail merge regions that are ignored by the mail merge engine for some reason, are unused. Second, unlike the property, the option removes all unused merge regions regardless of why they were skipped. The RemoveEmptyRegions property only removed regions which had a corresponding data source (like a data table) that was empty, that is, contained no records. The RemoveUnusedRegions option removes such regions too, and also removes regions that have no corresponding data source.

RemoveUnusedFields

This is a new option for removing merge fields that are left in the document after mail merge, for example, if a corresponding value was not found.

RemoveContainingFields

This is a new and very useful option for removing not only the merge fields themselves, but also all containing fields when the merge field is nested. Merge fields are often designed as child fields of the IF fields or similar in order to perform conditional merge. While merge fields are always replaced with their values during mail merge, the containing (parent) fields stay intact unless the new RemoveContainingFields option is enabled.

Note that RemoveContainingFields also works in conjunction with RemoveUnusedFields. It removes fields that contain unused merge fields, when the latter ones are removed thanks to RemoveUnusedFields being enabled.

Combining Cleanup Options

So, since the new cleanup options are flags, you can combine any of them to fit different cleanup scenarios. For example, if you want to see no merge regions or fields in the resulting document (and no containing fields as well, if present), you can combine the following three options together:

Document doc = new Document("CleanupOptions.docx");
doc.MailMerge.CleanupOptions = MailMergeCleanupOptions.RemoveUnusedRegions |
MailMergeCleanupOptions.RemoveUnusedFields |
MailMergeCleanupOptions.RemoveContainingFields;
doc.MailMerge.ExecuteWithRegions(dataSet);

Or, if you wish to get rid of empty paragraphs that are left after merging, regardless of the reason:

Document doc = new Document("CleanupOptions.docx");
doc.MailMerge.CleanupOptions = MailMergeCleanupOptions.RemoveEmptyParagraphs |
MailMergeCleanupOptions.RemoveContainingFields;
doc.MailMerge.ExecuteWithRegions(dataSet);

Downloads

• Aspose.Words for .NET
• Aspose.Words for Java

The Aspose.Words for Java API provides the handy Document.Print method whose overloads allow you to print a document using various different options with just one line of code. You can choose to print using default settings, print to a specific printer by name and even printing options such as page range to print.

Pass Any Document Loaded into Aspose.Words to Standard Java Printing Devices

Aspose.Words provides the AsposeWordsPrintDocument class which allows any document loaded into Aspose.Words to be printed with the standard Java printing API. This class provides the “typical” one document page per physical page printing.

The AsposeWordsPrintDocument class implements the following print interfaces:

• Pageable
• Printable

This class can be passed directly to standard Java print classes such as PrinterJob using PrinterJob.setPageable or PrinterJob.setPrintable and allows you to easily print the document with dialogs such as the standard print dialog.

Previewing a Document before Printing

The standard Java API doesn’t provide any existing functions to print preview any Java on its own. With Aspose.Words, not only do we provide the facilities to print documents, we also provide sample code to preview documents before printing in the DocumentPreviewAndPrint sample. The preview provided by the print preview dialog is the same as what is expected when the document it printed to a real printer. Check out the images below for a small demonstration.

The input document to be printed.

Additionally, the full source document in DOC format is available for download from this link.

Next, the print preview of the above document generated using Aspose.Words for Java.

Finally the physical output printed on a local printer using Aspose.Words for Java. As you can see Aspose.Words prints this document with high fidelity.

Print Multiple Document Pages onto a Single Sheet of Paper

You can utilize Aspose.Words for Java to fully customise how documents are printed. An example of this is printing multiple document pages onto a physical page by implementing your own print document class. Achieving this using Aspose.Words is a straight forward task. We have already provided the sample code ready for use in the MultiplePagesOnSheet sample.

The output of running this sample code on the same document as previous with settings of four pages on one sheet:

Again, but this time with the grid lines enabled:

Implementing Custom Printing Logic

Finally, it’s worth mentioning you can use the built-in methods in the Aspose.Words API to implement your own printing classes based on your own logic. Without going into too much detail, this is the basis of how the previous sample of printing multiple pages on one sheet is implemented. Using such methods as Document.renderToSize, Document.getPageInfo you can use Aspose.Words to integrate with Java’s printing framework, customize the print process to your liking and custom print documents loaded into Aspose.Words.

You can check out an example of this in action by taking a look at the code for the previous sample. The full code for this sample can be downloaded from here: Program.java

Find out More

You can test out all these great features for yourself by downloading the latest version of Aspose.Words for Java from the Aspose.Words Downloads page. The samples pack can be downloaded separately from here.

Aspose.Words’ support of Microsoft Word fields is being improved all the time. At the moment, Aspose.Words updates around 3/4 of all  Microsoft Word fields that can be updated. We’re hoping to support all ‘updateable’ fields before long. In the meantime, I’d like to share what progress we have made recently and what fields we have added to the supported list. I will use the same categorization offered by Word and OOXML specs.

Date and Time

While updating DATE and TIME fields was supported from the very beginning (due to the simplicity of implementation), the remaining fields in this category stayed unsupported for a significant time. The fields are:

• CREATEDATE
• EDITTIME
• PRINTDATE
• SAVEDATE

Recently we filled this gap so that Aspose.Words can now update all Date and Time fields.

Document Automation

Aspose.Words supports all Document Automation fields that it makes sense to update. Two of them, GOTOBUTTON and MACROBUTTON, are not updateable, but were improperly displayed when rendering to PDF or image or saving to a format like HTML. The latest release of Aspose.Words fixes this issue.

Document Information

Like for the Date and Time category, we supported the evaluation of all Document Information fields that were overlooked earlier. So the following fields are updated in the latest release:

• AUTHOR
• COMMENTS
• FILENAME
• FILESIZE
• KEYWORDS
• LASTSAVEDBY
• NUMCHARS
• NUMPAGES
• NUMWORDS
• SUBJECT
• TEMPLATE
• TITLE

Index and Tables

We have been working hard on one of the most popular Microsoft Word fields – table of contents (TOC). At the moment, Document.UpdateFields() (or Field.Update()) produces identical or very close result to how it looks after pressing F9 in Microsoft Word. In particular, we have fine-tuned tab stop positions generated for TOC entries in the latest release. Still, there is much work to do for this field because it is probably the most complex one.

There are a few fields in this category whose update is not supported yet, but they are on our TODO list and will be handled in the near future.

Mail Merge

We have added support for two complex mail merge fields – ADDRESSBLOCK and GREETINGLINE. These two behave like compound MERGEFIELDs, allowing you to compose (surprise!) an address block or greeting line, respectively:

Also, the SET field is now supported, which means you can use it to define bookmark values.

Numbering

The SEQ field is now fully supported.

You can immediately download our next regular Aspose.Words release from the following links:

• Aspose.Words for .NET 10.7
• Aspose.Words for Java 10.7

The rest of this topic mentions some of the features that we have delivered in this release:

ActiveX Controls in DOCX Documents

Support for OLE objects embedded in Word documents has been available in Aspose.Words for long time. ActiveX controls is a technology related to OLE. ActiveX controls are stored in the same way as OLE objects in the binary .DOC documents and they have been already supported by Aspose.Words. But ActiveX controls stored in OOXML documents are stored differently to OLE objects and they were not supported by Aspose.Words during DOCX open/save cycles.

Although ActiveX controls inside wordprocessing documents is not a mainstream thing these days, the lack of this feature in Aspose.Words was causing grief to some of our key customers. Starting from this release ActiveX controls stored in OOXML documents are preserved by Aspose.Words during open/save cycles.

Conversion of ActiveX controls between the binary .DOC and OOXML formats is still not available (an ActiveX control is converted to a picture), but this will be our next feature.

Custom Footnote Marks Rendering

Footnotes and endnotes in Word documents always have a reference mark. Most of the time, the reference mark is an auto-generated number, such as i, ii, iii etc. But it turns our many customers actually use custom characters as reference mark for footnotes and endnotes, for example “*”.

This Aspose.Words release addresses a long-standing feature request to support proper rendering of footnotes and endnotes with reference marks to PDF and other formats.

We have our regular monthly Aspose.Words release ready and you can download it from:

• Aspose.Words for .NET 10.6 (66 fixes and improvements)
• Aspose.Words for Java 10.6 (77 fixes and improvements)

In the rest of this post I am going to briefly talk about what’s new.

Page Layout Performance and Memory Optimizations

We have done some optimizations that reduce memory usage and increase speed when converting large documents to PDF, XPS or images. You should be able to convert bigger documents now. Our tests show 10-30% improvements. We are interested in your feedback too.

More Load and Save Warnings for Fidelity Loss

In the earlier versions we introduced a mechanism for the user to receive warnings from Aspose.Words during loading, converting and saving documents. Aspose.Words issues warnings whenever a minor or major formatting or data loss occurs when converting a document. The warnings are sent to the IWarningCallback interface. In this release Aspose.Words issues a significantly more complete set of warnings for several conversion formats.

Documentation: Working with Tables

In the previous release we have improved the public API for working with tables in Aspose.Words. This release follows up with a new section in the documentation and many new code examples.

As usual, the documentation is available online and also as part of the product download:

• Aspose.Words for .NET – Working with Tables
• Aspose.Words for Java – Working with Tables

Other Fixes

There is a good number of other fixes and enhancements that resolve exceptions for particular documents, support some really weird custom footnote reference marks, display images better and so on. You can check the full listing on the release download page.

We have released Aspose.Words for SharePoint 2.3.0.

This release includes the latest improvements made in Aspose.Words.

To download the release, please visit the download area.

As usual at our forum we are glad to answer any questions you might have.

Enjoy!

This post is about our latest Aspose.Words 10.5 release. We regularly produce a new release at the end of each month and each release contains around one hundred of improvements and fixes.

As usual, you can download Aspose.Words from:

• Aspose.Words for .NET 10.5.0
• Aspose.Words for Java 10.5.0

Improvements in the Public API for Tables

Earlier versions of Aspose.Words had some in the area of formatting tables, rows and cells programmatically. It is sufficient to mention that “table formatting” was not directly available on the Table object, instead you had to apply it to every row using Row.RowFormat object. Also, it was not possible to specify cell width in percent (a.k.a preferred width). These limitations also manifested themselves in behaviors that some customers considered as defects.

I am happy to announce that we’ve given the table formatting API a significant face lift. New code examples were added to the API Reference and to the Samples projects. The documentation will reflect the new features soon. Here is the list of what’s new:

• PreferredWidth class and PreferredWidthType enum added that allow to specify cell or table width in points or percent.
• CellFormat.PreferredWidth and Table.PreferredWidth properties added.
• Table.Style, Table.StyleName and Table.StyleOptions properties added that allow you to apply table styles to a table. Also see the new TableStyleOptionsenum.
• Table formatting properties such as Alignment, AllowAutoFit, Bidi, LeftIndent, CellSpacing, Padding were added to the Tableobject. The same properties were marked obsolete on the RowFormat object.
• The new Table.AutoFit method was added to allow you easily format an entire table using one of the “standard Microsoft Word options”: Auto Fit to Contents, Auto Fit to Window and Fixed Column Widths.
• Convenience methods to work shading and borders Table.SetBorders, Table.SetShading and Table.ClearBorders, Table.ClearShading have been added.

Chinese and Japanese Improvements

We have made a number of improvements in Aspose.Words to support these languages. Most notable points are:

• Line breaking for Chinese and Japanese documents when rendering to PDF, XPS and printing works according to the language rules and also settings stored in the document.
• Japanese formats for dates are now supported by the field update engine.

Control how Images and CSS are Loaded

When you load an HTML document into Aspose.Words and the document contains links to images, then by default, Aspose.Words tries to download those images and embed them into the document. We thought this is the “normal” use case because sometimes image dimensions are not known from HTML, but they are requried for a shape in a Word document, but several customers have requested that provide some options to customize this behavior.

Finally Aspose.Words allows you to take control over how images and CSS stylesheets are loaded. You can even completely circumvent where the data comes from. This for example, makes certain “Aspose.Words in the cloud” scenarios easier to implement.

Here is what’s been added:

• LoadOptions.ResourceLoadingCallback property
• IResourceLoadingCallback interface, ResourceLoadingActionenum, ResourceLoadingArgs class.

Print Word Documents in Java

In the previous blog I hinted this feature is coming. Now I am happy to let you know the family of Document.Printmethods are available for you. You can now easily print all or only specified pages of a document. Aspose.Words integrates with the Java’s printing framework and this means you can customize the print process to your liking. Aspose.Words implements AsposeWordsPrintDocument class that provides the “typical” one document page per physical page printing. But it is easy (and we will provide code examples) to print multiple document pages onto a physical page by implementing your own print document class.