New XPS Features in Windows 7

We’ve been busy.

Last week at PDC we unveiled Windows 7 and provided developers with a first look at the bits. This week at WinHEC we’re providing further details about Windows 7 for the hardware community. The big Windows 7 news for XPS is that we’ve extended the developer surface to include applications built on Win32. With Windows Vista (and back to XP) we have a great developer story for managed code development with XPS support in .Net 3.0 (and later). With Windows 7 we now have great support for developers working with Win32 (aka native) code.

New Win32 APIs in Windows 7 that we covered at PDC last week:

  • XPS API provides creation, manipulation, reading, writing and other services for XPS documents and print streams
  • OPC API provides creation, manipulation, reading, writing and other services for Open Packaging Conventions-based file formats, including XPS, OOXML and an increasing number of industrial strength third party file formats
  • XPS Print API provides a new entry point for applications to benefit from the enhanced XPS Print Path, irrespective of whether the final output device supports XPS

There’s also enhancements to the user experience and components for driver developers. More details on all of this in the coming weeks and months. In the meantime, you can catch up on the content presented at PDC on Channel9.

Comments (6)
  1. RuslanUrban says:

    XPS Essentials Feature Request

    While the intent of the XPS document writer seems to be only "printing" into an XPS file instead of a printer. In my opinion, it is missing lots of functionality that a first-class Windows system citizen should have. Can the driver be extended easily, or, should it be completely re-written if certain functionality should be added by a third party?

    Here are a few things that can be added to the XPS Essentials:

    XPS Document Writer (printer driver):

    1. Add a optional dialog to assign additional document properties; e.g. specify metadata attributes like author, title, etc., sign the document, secure document with a with password.
    2. Use title of the window of the application that initiated printing or title metadata attribute as the default file name for the XPS file, or leave file name blank. I find "*.xps" in the file name annoying to edit at times. The .xps extension is added to the name of the file automatically.

    3. Add send option to allow sending the document by e-mail without storing it to the file system.

    4. Add ability to queue multiple print jobs into a single XPS file. It is useful when you want to save multiple steps of a wizard, for example saving a log of a an online purchase.

    5. Add ability to add watermarks.

    XPS Viewer

    1. Add Send option to allow sending the document by e-mail

    2. Add ability to append contents of other XPS files.

    3. Add ability to delete pages. Sometimes, when you print a web page, a few lines of text are printed on a separate page that is often thrown away. Deleting such pages would reduce the size of the document, which is often very important.

  2. adrian ford says:

    Thanks for the input – I’ve passed it on to the team.

    "Can the driver be extended easily"

    Yes – see for links to the WDK which includes example code and documentation for building your own ‘Save as XPS’ driver ontop of the core components provided by Windows.

  3. HLeuze says:


    we are using XPS in our .net app and the biggest problem for us with the current xps version is that there is no way to send output to the microsoft xps document writer and redirect the output to a specific file (print to file). Problem is that there is no way to specify the output filename.

    A lot of developers are asking for this feature in the the XPS MSDN forum.

    Thanks in advance for some comment about this.

  4. adrian ford says:

    If you’re using WPF in .Net then there’s no need to use the document writer, you can serialize direct to XPS and output wherever you want (see

    If you’re using Winforms in .Net than check out the PrinterSettings class in System.Drawing.Printing, specifically PrintToFile and PrintFileName (see


  5. Walter says:

    We have been waiting a long time for an XPS renderer in SQL Reporting Services. In fact we were very disappointed to see that neither SQL 2008 nor SQL 2005 SP3 had one. Hopefully it will support native rendering to XPS in the not too distant future.

    In the mean time however, is it possible to use the System.Drawing.Printing to programatically print SSRS output to the Microsoft XPS Document Writer without user intervention? That might give us a great option to use in the mean time.

  6. adrian ford says:

    Hi Walter, I don’t know what plans SQL Reporting Services have, but I can ask…

Comments are closed.

Skip to main content