WPF <> XPS

  • Article

A favorite question I get asked is “When will [insert some application name] be ported to WPF?” WPF is a fantastic technology and there’s lots of interesting stuff happening on top of the WPF platform, but I’m wondering why people are asking me about it and [insert some application name]. It turns out that there’s a widely held assumption that to take full advantage of the XPS Print Path an application needs to be built on WPF. The logic follows that an app that isn’t based on WPF is some how a second class citizen in the XPS world. That’s a misplaced assumption, but because of the way XPS and WPF do relate to each other it’s perhaps not surprising that people have fallen into this particular trap.

WPF and XPS

There *is* a close relationship between XPS and WPF, but that relationship does not extend to the point where the only way to use XPS is from WPF (although WPF may well be the easiest way for developers to take advantage of the benefits of XPS, that’s a different point :-).

Here’s three important things to remember when thinking about how XPS and WPF relate:

  • XAML. XAML is the markup language used in WPF. To quote Sells & Griffiths “XAML is an XML-based language for creating and initializing .Net objects. It’s used in WPF as a human-authorable way of describing the UI”. XPS uses a subset of WPF XAML to describe the markup of graphic elements within fixed pages. But XAML is not just used by WPF and XPS, for example Silverlight also makes use of it.
  • Graphics Model. XPS and WPF share the same graphics model. This means that the rules that determine how graphical elements (text, paths, fills, images) are drawn onto a surface are defined in the same way. This also means that XPS can represent the 2D static content supported by WPF without loss of fidelity.
  • API Support. WPF provides a rich framework for working with graphic elements and UI. That framework includes APIs for supporting XPS so, for example, a WPF Visual Tree can be easily serialized to an XPS Document by a developer working with WPF.

These abilities make XPS a great document and print format for WPF-based applications and also make WPF a great platform for applications that work closely with XPS files.

If not only WPF, what else?image

Now let’s circle back on what other options Windows applications have for working with XPS. (I’ve highlighted Windows because I’m talking here about Windows, other options exist for other platforms.) The diagram on the right shows the stack rank of how I typically think about the various options. Top is most feature-rich and, typically, easiest from a development perspective. Bottom is greatest flexibility but, typically, most development effort.

At the top is Office. Office? Yup, Office as well as everything else it does, also provides a platform that many developers build applications (often company-specific line-of-business applications) with. In Office 2007 save as XPS is exposed in the Object Model, for example Document.ExportAsFixedFormat in Word 2007.

WPF comes second. It provides a rich API surface and supports XPS and the underlying OPC formats making it an ideal environment for working with XPS Documents. In addition, WPF provides broad document support with things like flow documents and the document viewer control. All great stuff.

Next on the list is using .Net without WPF. Although WPF makes working with XPS super-easy, you can also use .Net to work with XPS at a lower level which can be useful if you’re using .Net but not WPF.

If you’re not using .Net, then there are a number of choices. Next in my list comes the increasing number of third party libraries that provide both support for working with XPS content directly, and conversion capabilities between formats.

From the print perspective, Win32 provides some support for the XPS Print Path (although less than that provided by WPF). This enables applications to generate XPS fixed page markup directly and to pass this, with associated resources, to the print system via an escape mechanism for XPS drivers.

Finally, and for the hard-core, the XML Paper Specification is fully documented and available for download. The spec contains all the information needed to implement your own solution should you find that there isn’t already something suitable (or just like having fun with things like that!).

You can see that we provide a comprehensive stack for working with XPS. This enables the developer to choose from a range of options with the best combination of developer productivity and technology flexibility for their application. We do aim to please.

The follow-up question: Photo Gallery

Getting back to questions, a frequent follow-up question to my “you don’t have to be WPF to use XPS” response is to be asked what WPF applications ship in Windows apart from Photo Gallery. Now the assumption is that Photo Gallery (or rather the printing wizard used by Windows Explorer and Photo Gallery) are WPF-based because… yup, because they print natively to the XPS Print Path. As you now know, that’s not necessarily a safe assumption since Win32 apps can also print to XPS. Can yours?