By Alain Thibodeau – Consultant

Printing in Flex is the source of frustration for many people. Native Flex printing is good for simple print jobs, but the frustrations start when the layout becomes complex and the output becomes unpredictable. In any case, the native print API in Flex doesn’t deserve all the bad press it has been getting. We will see what can be accomplished with it and when it is time to start considering alternatives. In the first part of this series, we will first look at the native API. In the second part we will look at one of the alternatives for printing in Flex called AlivePDF.

Giving the users the ability to print from any application does not mean that they will print what is currently on the screen. It is best to not print certain areas of the application like the UI for example. It is for this reason that we normally just print the data needed in a print friendly version. Flex’s native API allows us to do that very well. It allows us to generate a printer friendly output by allowing us to select specific areas to print, create new objects for print or print the data directly. Flex actually has specific components for print that helps you achieve this. These components are the PrintDataGrid, PrintAdvancedDataGrid, PrintOLAPDataGrid.

Simple Example:

When printing in flex we want to use the classes in the mx.printing package. The main class for printing is the FlexPrintJob which is actually a wrapper of the Flash PrintJob class. The idea is to instantiate this class, start a print job, add the objects you want to add and send it to the printer. For a basic print job, the code looks like this:

Explanation:

1. We create an object of type FlexPrintJob
2. We set its property of printAsBitmap to false. This will make sure that it will print as vector. The default is true which creates a bitmap image of your object. I always set this to false; I find it gives better print quality.
3. The PrintJob’s method start will invoke the users print dialog box to open. The method returns false if the user selects cancel. If the user selects print, the method returns true and the FlexJob’s properties pageHeight and pageWidth are assigned values from the printer settings. At this point we can use these values for layout calculations if we want.
4. Next, we need to add objects to the print job. The addObject method takes care of that. The second parameter specifies the scale type. You should use the class FlexPrintJobScaleType and its constants to specify scaling. The values are FILL_PAGE, MATCH_HEIGHT, MATCH_WIDTH, NONE, SHOW_ALL . Each call to the addObject starts a new page; this is important and becomes a little tricky if you want to add more than one object to a print page. This is discussed further below.
5. Once the objects are added to the PrintJob, we need to send it to the printer, which is what the send method does.

Multi-object print pages

The above code demonstrated a simple example of printing in Flex that works well. Now, we move on a bit deeper and show how to add more than one object to a print page. Earlier, we added one object to the print page with the PrintJob’s addObject method, this added one object to one print page. If you want to add more than one object to one print page you need to create custom components that contain the objects you want to print. You can achieve this dynamically with ActionScript or create custom MXML components that will be instantiated and added to the display list and then to the print job. Custom components need to be on the display list in order to be added to a print job. Let’s start by creating a custom component.

Now, we have our custom component. In our printing code of the main application file we need to adjust a few things.

Explanation:

In this case we have adjusted the code by:

1. Instantiating our custom component.
2. Adding our custom component to the display list.
3. Removing it from the display list to clear the memory after adding it to the print job.

This example will allow us to add more than one object to one print page and could be the start of creating a multi-page print job of several images in a database for example. I’ve always had good outcomes with the native Flex printing and this type of print job. That is, when you know the position, dimensions and number of items that will be on the page.

Printing Data

As mentioned before there are three built-in components that help print data. These components are the PrintDataGrid, PrintAdvancedDataGrid, PrintOLAPDataGrid. They come with built-in pagination and the base functionality that you need to print data grids. I will not show an example of these as it involves a lot of code and this post is meant to be kept brief. You can look at the documentation on how to use them and take time to investigate the possibilities.

Conclusion

When printing simple pages like the examples above, flex is actually quite good. Where I’ve ran into problems and bugs is when trying to create a print job that can span multiple pages and has no reoccurring layout. In more advanced printing, I’ve also used the PrintDataGrid. This component worked great for me until I had to have variable row heights which seem to break the pagination. The point I am trying to make is the same as many developer will say about flex printing; it is good for simple print jobs. Once you need to print complex reports that span multiple pages, the problems start.

There are a few other simple things that the native print API does not do which is worth mentioning. For instance, the orientation is read only. This means that you cannot specify one page to be landscape and the next to be portrait. You also do not have the option of portability, unless you have a PDF writer you can “print” too.

For these reasons, other printing options have been made available by way of third party libraries. In the next part we will look at one of the alternatives for printing in Flex. This library helps address some of the Flex printing shortcomings and is called AlivePDF. See you then!