8th Day of Silverlight : Vector Printing

On the home stretch.  I’ve had some great feedback from everyone and I do appreciate it.  Going to be close to bring the series to an end before the 25th, but it will get there.  So…

On the eighth day of Silverlight, the team delivered to me… vector printing.

Printing, printing, printing.  Prior to SL4, I couldn’t even begin to tell you how many times I had clients “absolutely have to have" printing support.  Over the last year and a half I written more demos about printing than I have implementations.  Seems that everyone decided PDF exports worked just fine.  Go figure.

However, vector printing is a great new feature for folks needing printing support.  It offers several improvements over the SL4 bitmap printing and is worth discussing.

Let’s take a closer look at some of those benefits.  The first thing to mention is that, from an API standpoint, printing is still backwards compatible with SL4.  So it has the same PrintDocument class and it’s events are still the same.  However, the Print() method now defaults to vector printing when available.  You don’t have to make any changes to get the benefits of vector printing.

It is worth noting that the vector printing added to SL5 only supports PostScript vector printing.  So if your printer, or more accurately your print driver, does not support PostScript Silverlight will print using the original bitmap printing.  This is a subtle thing that is being over looked quite frequently.

Another time when that Silverlight will revert to bitmap printing is if you have any elements on your screen that Silverlight cannot convert to PostScript.  Just a few things to keep in mind.  However, if Silverlight does revert back to bitmap printing, it does so silently and without error.

The printing API has been extended slightly to give the developer a little more control.  The first is a new method PrintBitmap().  I bet you can’t guess what this does.  Yep, it starts the SL4 version of bitmap printing.

The next change is a new Print() method.  The original Print(string documentName) method is still there, however, SL5 adds a new signature that gives you a little more flexibility.  The new method is:

Print(string name, PrinterFallbackSettings settings, bool useDefaultPrinter)

The first parameter is the document name and is treated the same as the other method.  The next parameter exposes a new class PrinterFallbackSettings.

The PrinterFallbackSettings class only contains two properties.  The first, ForceVector, is simply a bool value that determines whether Silverlight is forced to print in the vector format or not. 

The second property, OpacityThreshold, is a bit more complicated.  By default, if the XAML that you send to the print API contains any elements with the opacity set lower than 1.0, Silverlight will use bitmap printing.  The OpacityThreshold allows you to adjust that value.  The value you set, which should be between 0.0 and 1.0, tells Silverlight what is the cut-off opacity value.  For instance, if you set the value to 0.5 any element that has an opacity set lower than 0.5 you bump you to printing in bitmap mode.  One thing to remember is that if you lower the threshold any element whose opacity is still in range will print with the opacity set to 1.0.  So if your element has a 0.5 opacity in our above example it will print, but the results just might not be what you are expecting.

The last property is a bool the lets you skip the Printer dialog box and go straight to the default printer.  This only works when you have elevated trust enabled in your application. Otherwise an exception will bet thrown. Believe it or not, this little bool is a big deal for this release. There were several COM hacks written to allow this in SL4, especially for point-of-sale systems. 

Wrapping up this post, you will probably notice there isn’t any code on this post.  Since the API hasn’t changed all that much, there really wasn’t much to demo here. 

The biggest complaint I here about printing in Silverlight is the minimalist API.  It leaves a lot of work for you to do on your own.  The plus side of this is that you can make it do exactly want you want.  The down side is you have to write the code to make it do exactly what you want.  There have been some great report writer projects kicked off on CodePlex and that is a great place to start when building out an API that is better suited to your needs.

Only four most posts in my 12 Days of Silverlight series.  And if you are wondering, yes, the next post will have code. Smile

One response

Leave a Reply

Your email address will not be published. Required fields are marked *

.NET development is constantly changing and expanding. With over 20 years in the industry, I have had the opportunity to see this the technology and the community grow and shift. To get weekly updates and insights into the world of .NET, development, and career advancement click the subscribe button.