What's the point of XPS?

Question

When I read books about WPF, I saw the authors mention XPS like it was something important. Windows also includes its XPS viewer, and I've seen that listed as a "feature" of Windows.

But why? What's the point? Who the heck uses it? It's my understanding that XPS is, basically, like PDF, xhtml, or ePub (which is just xhtml)...or even Word's docx format. Many of the features are the same among those formats.

It doesn't seem to have any major benefits compared to any of those other formats. It seems to me that xhtml would be so much more useful than XPS as a way to save and load FlowDocuments from the RichTextBox. I've looked at multiple blogs about converting between the two. Most or all of the rich text on the internet is (x)html. Beyond that, I don't think anyone uses it just to publish their docs; PDF is preferred. It seems like XPS is just some random format that MS made and decided to push. I generally love MS, but they do have a habit of that kind of thing. Couldn't MS have made an api using xhtml instead? That would have been more useful in a lot of situations, I'd think.

So, is there a point to using XPS, particularly in comparison to one of the other formats I mentioned (or any I haven't)? Have you ever used XPS in your programs or otherwise?

Answer 1

As U62 already stated, WPF comes with a DocumentViewer control which enables you to view XPS documents. The DocumentViewer also has some useful fonctions like Print, Zoom, FitToPage etc... So you don't need to implement that or use a third party tool.

What I just finished an hour ago using XPS and the DocumentViewer was some kind of "Adress label print preview". Allow the user to select some contacts from a list of contacts, click "Print Preview". This opens a new XAML Window which contains a DocumentViewer control and a ListBox with the choice of different Labels (e.g. 1 sheet with 12 labels [2 columns, 6 rows], 1 sheet with a single label whose width and height can be user defined). Based on the users selection, I generate an XPS Document in the layout the user selected with the adresses of the selected contacts. If e.g. the user selected 4 contacts and wishes to print them on "SingleLabelSheet"'s, I generate 1 XPS document with 4 pages, each page containing 1 Adress. Then I display the XPS in the DocumentViewer and the user can print the labels on our Label Printer.

Once I understood how the XPS API worked (at least the Basics), it was a matter of 2 hours to get this up and running.

So, basically, I see XPS as an easy to use API to display FixedDocuments which are to be generated on the fly. But I wouldn't personnally go about saving them to my HDD or somehow modify them or whatever you generally do with documents.

Answer 2

The only actual advantage I can think of is that you have a control for viewing XPS documents in WPF applications. The other formats you mention mean you would have to bring in a 3rd party renderer (or write one yourself if you have a year to spare).

btw. I don't know much about ePub, but XPS isn't directly comparable with XHTML, it's more like PDF in that it's designed to have a fixed layout.

Answer 3

XPS to WPF is like WMF to Win32/WinForms, it's a persistent format that let you store and print native WPF graphics.

XPS is used to print from WPF (even when you print directly from the application without saving, the internal printing system is built on XPS) so what should MS do:

1. Create a new file format that exactly fit with what they are trying to do
2. Build a 100% perfect translator from WPF to a format they don't control like PDF (and hope Adobe doesn't break all WPF applications out there with the next release of Acrobat Reader).

What would you do?

Saving XPS files is just a nice bonus.

Answer 4

Look, I may be a pessimist on XPS as a report generation solution, but I gave it a go and found the initial documentation to be hard to understand, with less real world samples out there than what I would have liked. When I put it into a real world business application I found it to be frustrating, particularly in LOB apps that require tables that span over multiple pages.

Things may have changed since then but as soon as I started looking at tables that spanned over several pages and I wanted column headers to go to the top, etc. I found that the API required me to do what I would call excessive workarounds with unnecessary complexity.

So, things may have changed since then (about 8 months ago), but I went from XPS to using ITextSharp and that has been a lot less painful.

So the only advantage I would say, like everyone else, is the built in viewer in WPF - but other than that I feel the API may need to "mature" a bit more before I will attempt something again in it.

Answer 5

Actually I found a really nice reason to use XPS. I wanted to print from multiple sources, merge documents and specify duplex and stapled. Finally it should be printed as one document with duplex and stapled. I was having a difficult time doing so but found that by printing to XPS (saved to disc) I could accomplish my goal with minimum fuss. I haven't found any other method that is so easy and straightforward.

    Dim PrintServer As New SysPrint.PrintServer("\\" & My.Computer.Name)
    Dim PrintQ As New SysPrint.PrintQueue(PrintServer, "Ricoh Main")
    Dim Jobs As SysPrint.PrintJobInfoCollection = PrintQ.GetPrintJobInfoCollection
    Dim able As SysPrint.PrintCapabilities = PrintQ.GetPrintCapabilities()

    Dim CurrentTicket As SysPrint.PrintTicket = PrintQ.CurrentJobSettings.CurrentPrintTicket
    If able.StaplingCapability IsNot Nothing AndAlso able.StaplingCapability.Count > 0 Then
        If able.StaplingCapability.Contains(Printing.Stapling.StapleTopLeft) Then
            CurrentTicket.Stapling = Printing.Stapling.StapleTopLeft
        End If
    Else
        Debug.Print("no stapling capability")
    End If

    CurrentTicket.Duplexing = Printing.Duplexing.TwoSidedLongEdge

    Dim fiName As String = "S:\Temp\PS\XPS\Test.xps"

    Dim TestJob As SysPrint.PrintSystemJobInfo _
            = PrintQ.AddJob("Test job", fiName, False)