So, I’m reading through the documentation on Windows printing, trying to learn what this is all about. My team writes stuff that sits between the Windows Spooler (spoolsrv.exe) and the Kernel-model communications pieces.
Anyway, so I come to a great fork in the road: GDI and XPS. GDI (Graphical Device Interface) is the way that earlier windows programs (Win32) talk to the display and printing subsystem. Essentially, everything in GDI is a bitmap. This is “the old way of doing things”.
XPS is a whole ’nother ball of wax. XPS stands for Xml Paper Specification, and it offers a way to describe, render, and print information. It can function as an XML-based Page Description Language (PDL).
At first XPS and the new XPS-based print subsystem sounds like a great idea: The application stores its documents in XPS format, sends the documents to the screen via the Windows Presentation Framework (WPF), which natively speaks in XPS, and then the printing subsystem is even more snazzy.
See, they got this great ideas: Why not have the driver implement a series of stages (filters) that you can set-up using a file instead of using code? That way, you can have these cool filters that you can reuse in different drivers. Modular. Smart.
Yeah…here’s the catch.
THIS WHOLE FREAKING CONCEPT IS STOLEN FROM APPLE and UNIX.
In the Unix world, they came-up with the concept of CUPS, the Common Unix Printing System, which is the filter-chain concept described above. Print “drivers” in cups become a series of stateless filters, chained together by a PostScript Printer Definition (PPD) file.
It gets better. In Mac OS X, they use the same unified document concept, only instead of some hokey solution, they use the industry standard for document interoperatbility–Adobe’s PDF files.
I can’t tell if the whole XPS/Metro concept is just a massive case of Not-invented-here (NIH) or if Microsoft genuinely thinks it can do better by reinventing 2 wheels. No wonder Vista was years late!