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

Here is a look at some of the biggest features in this month’s release:

Added Support for Signature Line

A signature line is a special object found in Microsoft Word documents in the drawing layer.  The signature line can be interacted with and provides an easy way for the end user to add a digital signature to the document. This feature can be thought in the same way as how one would add a written signature to a printed document.

Starting with the release of Aspose.Words 10.3.0, signature lines are now supported in the model and this feature is retained when converting between flow formats such as DOCX, RTF, and WML with the exception of DOC format which will follow shortly.

At the moment signature lines are only partially rendered to fixed formats such as PDF with full support planned within a few releases.

Support of MathML in OpenOffice Format

MathML is the language used to describe mathematical and scientific equations in OpenOffice documents. Aspose.Words now supports import and export of MathML in ODT format and preserves almost all equations during round-trip.

Aspose.Words now boasts wide support for Math content in all types of Word documents. Nearly all types of math content are preserved during open and save using Aspose.Words. In this release we also have further improvements to math content in OOXML which is described next.

OfficeMath Equations are now Preserved when Saving to Non-OOXML formats.

We are glad to announce that Aspose.Words now supports OfficeMath when saving to almost all formats.

OfficeMath is the main feature used to represent math equations in OOXML documents. Aspose.Words already supports round-trip of OfficeMath when loading and saving back to OOXML formats. However, in earlier versions this feature was lost if the target format did not natively support OfficeMath, for example OfficeMath disappear if the document was converted to DOC or HTML format.

Starting in Aspose.Words 11.3.0, we now mimic Microsoft Word’s behavior and convert OfficeMath to image when saving to any format that does not natively support it. This accurately preserves the appearance of this feature for all formats.

OfficeMath Supported Features

This is the first version of OfficeMath rendering and we are proud to say that most features are supported. However, there are few limitations which we will be working to support in the next releases. Here is a detailed list of what features are supported or unsupported when rendering OfficeMath.

• ‘Cambria Math’ font should be installed and accessible in order to properly render equations.
• Vertical alignment of equation elements is not supported. Elements are always rendered as vertically centered.
• Not all equation constructions are supported, below is the detailed list of supported elements:

USA, Texas – May 3, 2012

We are particularly proud to find ourselves in the top ten of the Best Selling Publisher Award. Since this award is based on our sales through ComponentSource, it is unbiased proof of how popular our products are. Our customers are voting with their pockets and there is no better endorsement. We want to thank all of our customers for their confidence in us and look forward to supporting them throughout 2012-2013.

In the Bestselling Product Awards, Top 10 Product Awards, Aspose.Total for .NET placed 8th. Aspose.Total is Aspose’s flag-ship product and brings together all our components into one complete and competitive package. It’s up seven places from last year.

The Top 50 Product Award saw Aspose.Words for .NET in 26th place and Aspose.Cells for .NET in 45th place.

In the Top 100 Product Awards, Aspose.Total for Java appeared in 68th place and Aspose.Words for Java in 77th. We’re delighted to see our Java products enter the lists and wish them well for the year to come.

Read the full list of awards on ComponentSource’s website.

About Aspose

Aspose offers a powerful set of file management components with which developers can create applications which can open, edit, create and save some of the most popular business file formats. Supported formats include Word documents, Excel spreadsheets, PowerPoint presentations, PDF documents, and Microsoft Project files. Tools allow developers to perform OCR, work with images, create and read barcodes and perform many other document conversion and management tasks. Aspose produce components for .NET, Java and SharePoint, as well as rendering extensions for SQL Server Reporting Services and JasperReports exporters.

Aspose was founded in 2002, in Sydney, Australia. In 2012, we celebrate our 10th birthday.

Press Contact

Email: press@aspose.com
Web: www.aspose.com

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

Here’s a closer look at some of the bigger features in this month’s release:

Performance Enhancements

This particular improvement started as a fix to speed up the conversion of large documents consisting of only a single section, however we did not stop there,  we went on to make numerous speed improvements in other parts of Aspose.Words.

The latest release can now see up to 50% conversion speed improvements during document conversion. We are pleased with these performance improvements.

Supported Features Lists for both Import and Export Now Available for All Formats

Aspose.Words is built primarily to work with Microsoft Word documents. These formats are complex and contain numerous numbers of features. Aspose.Words is renowned for its high level of support for Word document features and now we have the lists to prove it.

These lists which are available for both .NET and Java, describe the support for the most common features that you, the customer, look for during conversion of documents from one format to another. It describes any limitations (if there are any) during conversion either due to the document format not supporting the particular feature or any limitations to do with Aspose.Words.

You can find the full lists in our online documentation section:

• What Document Features are Supported in Aspose.Words for .NET
• What Document Features are Supported in Aspose.Words for Java

Here’s a look at the supported features section in the documentation:

Detailed Descriptions and Helpful Links for Each Feature

Not only do we describe the current level of support for each feature, we go one further and provide you with helpful information in the form of overview and tips for each feature.

You will find that most features on the import pages come with detailed information about how the feature is imported into Aspose.Words and how it is represented in the Aspose.Words Document Object Model. We also provide handy hyperlinks for features in the documentation for further reading. This allows you to gain more information on the features you are interested in.

Find out what HTML Tag Corresponds to What Document Feature

We are often asked what HTML tags are loaded as what document features. We have listened and understand that users who work with HTML formats often want extra information such as this.

We now provide a list of what tags are loaded during HTML import and what feature they correspond to. There is also a list which describes the HTML tags that are written for a particular document feature during export to HTML. We have made these lists as accurate as possible and are continually improving them.

Stay tuned to see further improvements to these pages as we add further information and restructure some parts to make it even easier to use.

Introduction of the “Mustache” Template Syntax for Mail Merge

This new syntax allows you to create templates for use with mail merge that use plain text markers instead of merge fields. These markers look like this:

{{FieldName}}

You can enable mail merging into plain text fields by enabling the MailMerge.UseNonMergeFields property and can freely mix them in your template with the Microsoft Word fields such as IF or Formula fields.

There is also some additional syntax you can use with these new fields:

Object.Attribute

You can now easily merge attributes of a field using the following syntax

{{Address.Street}}

This will merge the street name from an address when you have XML which looks like this:

<Order> // <-- Current context is here.
   <Number>23</Number>
   <Address>
     <Street>Nelson Street</Street>
     <Suburb>Howick</Suburb>
     <City>Auckland</City>
   </Address>
   <PhoneNumber>543 1234</PhoneNumber>
</Order>

Note that the notation works for regular merge fields as well, simply structure the merge field name in the same way, for example “MERGEFIELD Address.Street”.

Foreach Blocks

You can merge data from multiple records using the foreach tag. This is similar to mail merge regions with conventional merge fields. You can also nest foreach blocks just like nested mail merge.

{{#foreach Order}} 
   {{Number}}
   {{Address.Street}}
   {{#foreach Item}}
        {{Description}} {{Cost}} {{Total}}
   {{/foreach Item}}
{{/foreach Order}}

We regularly produce a new release at the end of each month and this month’s release contains 102 various features and fixes.

As usual, you can download Aspose.Words from:

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

Let’s take a look at a few of the prominent features included in the Aspose.Words 11.1.0 release:

Save in the SVG Vector Image Format

We now provide export of any document to SVG format. This adds to the collection of image formats you can already save a document to using Aspose.Words. These include the raster types BMP, JPG, PNG, TIFF and the vector format EMF.

The code to achieve the conversion is simple, one line to load the document into Aspose.Words, the other to save it to SVG at the desired location.

Document doc = new Document("Rendering.doc");
doc.Save("Rendering Out.svg");

This format is newly introduced but it is already supported with high fidelity. Just take a look at the sample conversion below.

First is the input Word document as seen in Microsoft Word, as you can see it contains plenty of formatting and different features.

Now the output produced by Aspose.Words converting the document to SVG image format. The output is viewed in Chrome. Clipping of bottom border does not appear in the source image.

Also, here is a part of the source of the SVG image above produced by Aspose.Words. You can see the SVG markup of the image:

Lastly, we have introduced a new save options class to along with this save format. The SvgSaveOptions class provides you further control over how the SVG files are produced. A few of the features included in these save options are:

• Saving images embedded into the SVG as base64 format.
• Selecting how text is exported, you can choose to embed the text as static glyphs, use SVG fonts, or rely on the fonts of the target machine.
• The selected page range of the document to save to image.

Specify the Default Font used during Rendering

In previous versions, during rendering if a required font was not found on the machine or embedded in the document then in most cases Aspose.Words would fall back on the free “Gentium” font. Now, starting with this release you can specify the default to use during rendering if a font is missing.

Simply use the DefaultFontName property before rendering to set the default font:

FontSettings.DefaultFontName = "Arial";

Different Options for passing Fonts to Aspose.Words

It’s understandable that each user has their requirements when it comes to specifying where fonts come from. Not all users store their fonts on disk, however Aspose.Words needs access to them one way or another to render documents correctly. We have listened to your requests on this subject and to help solve this issue have provided a brand new interface to make passing fonts to Aspose.Words even easier.

Now, you can pass any TrueType fonts to the Aspose.Words engine in a variety of different ways:

• Using the FileFontSource class to load a font from file.
• Using the MemoryFontSource to pass a font in from an array of bytes.
• Using FolderFontSource to load fonts from a folder or sub folders.

Here’s a quick example of this code in action:

// Create font sources from different locations.
FileFontSource fileFont = new FileFontSource(MyDir + "apr11.ttf");
MemoryFontSource memoryFont = new MemoryFontSource(GetFontBytes());
FolderFontSource folderFonts = new FolderFontSource("C:\\MyFonts\\", true);

// Pass these fonts to Aspose.Words
FontSettings.SetFontsSources(new FontSourceBase[] {fileFont, memoryFont, folderFonts});

As before all of the existing functionality still exists, you can still set font folders using the existing SetFontFolder method. Additionally Aspose.Words still searches for fonts in the expected font locations, such as “C:\Windows\Fonts\” on a Windows machine.

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.