One part of our goal with XPS was to ensure that documents can be viewed and printed with high quality, great fidelity and superb performance.
The seeds of XPS delivering an amazing graphics experience began with the new Windows Presentation Foundation (WPF) development platform (It started its life as “Avalon”). WPF was built on a new Windows graphics engine that is hardware-accelerated to provide amazing graphics capability. That capability is delivered through a set of easy to use developer APIs so that anyone can build amazing looking applications – full of animations, 3D content, glowing buttons, etc. There was an equal vision of making this new platform seamless for applications that crossed the boundaries between rich user interface, media and documents. We saw a converging world where punishing developers to learn brand new technology and development skills, just to cross the boundary between application UI and say an integrated video clip – was just silly. We really wanted any person familiar with .Net programming to do the types of things that were the exclusive domain of the Direct X programmer.
So on the document side, building XPS using the same markup as XAML and integrated platform APIs inside of WPF was just natural. Why, if someone wanted to create a document, should they learn a new mark up and programming model separate from WPF?
Mixing into this Petri-dish of innovation was the Windows Printing Team. Cloistered in a dark, tree-covered corner of the Microsoft campus they faced a growing problem. Slogging through bug after bug shipping Windows XP made it clear that the more sophisticated applications became, the more bugs were cropping up in printing. The heavy and complicated translations between the graphics in these applications to the aging page description languages that drive printers were showing signs of stress fracture. It was clear that the use of sophisticated transparencies, gradients and font effects were becoming available in typical office applications and regular users – no longer created by the graphics artist and tuned specifically for Postscript print workflows. Even, more of this amazing content was going to hit the print pipeline and the print architecture in Windows Vista and the printer languages of today were not up to the task. Spool files were getting bloated and output was funky.
Office 2003 highlighted a lot of these problems and we knew that future versions of Office would become more powerful with their graphics capabilities (just look at the Office betas and you will see what I mean).
At the same time, printer manufacturers were getting more frustrated with not being able to manipulate Windows graphics processes directly to work around bugs and problems in printing. They really wanted direct access to the original content to add secret sauce (image processing) and other cool things to make printing better. We really needed to stop forcing them to ‘hack’ around the print system, and provide developers a transparent and easy way to create and process print jobs.
We realized we had an opportunity – and in fact, more of a civic duty, to fix all of this. We needed to not only express the content of a printed page in the same way we built our windows graphics engine, we needed to describe it in XML and document it so that when the print job hit the disk, it would be transparent as to its’ contents and identical to how the original application expressed the graphic intent. So – we could use XPS as the spool format. We could work together to build an integrated platform between the WPF core graphics team, the document team and the printing team. Build one format that seamlessly worked across the platform for describing a fixed, printable document. We were crazy, but just crazy enough to pull it off.
As I sit here typing this, some of our very last check-ins are happening and we are just about code-complete. It was brutally hard to do integrated innovation at this scale, but it has been worth it – and the benefits to our customers and partners will be huge.
Today, we are seeing beautiful graphics on-screen built on WPF and also as part of Office “12” – and creating XPS documents that look equally gorgeous. They are small, give users WYSIWYG and a confident way to share content whether it is viewed on screen or printed with no loss in quality or fidelity. It’s a beautiful thing.
You can experience this innovation the minute Vista ships by simply creating an XPS document and viewing it on screen. Or printing to an XPS-enabled printer (we are expecting a lot of them to hit the market by the time Vista ships). It is a touching story, but we still have a long way to go. GDI still exists – we did some work to make GDI printing better when going to an XPS device, and that code is working quite well. But, if you have an old application and an old printer, there is not much we can do to improve the experience (although we continue to fix bugs). Innovation like this does require both investments in legacy technology (like the work we are doing to make sure that we print well from WPF to existing devices) and the investments that will provide break-through experiences for customers. I think we have endeavored to do both in Vista and we’ve created a new standard for graphics quality from application-to-document sharing –to-document printing for every Vista user.
Part 4 will be called: Platform for Innovation