introductiondownload.microsoft.com/.../xpsdrv_filterpipe.docx · web viewthis capability can be...

XPSDrv Filter Pipeline

Implementation and Best Practices

February 7, 2008

Abstract

This paper provides information about XPSDrv printer drivers and the filter pipeline that hosts them in the Windows® family of operating systems. It provides guidelines and best practices for printer driver developers and hardware vendors to use when they develop XPSDrv printer drivers.

Independent hardware vendors (IHVs) and independent software vendors (ISVs) who have existing printers or printer drivers can use this paper to help plan their strategy for migrating their existing code to the new print architecture. IHVs and ISVs who are developing new printer drivers can use this paper to understand the details of the filter pipeline and how to develop an efficient XPSDrv printer driver.

This information applies for the following operating systems:Windows Vista®Windows XPWindows Server® 2003

References and resources discussed here are listed at the end of this paper.

For the latest information, see: http://www.microsoft.com/whdc/device/print/XPSDrv_FilterPipe.mspx

http://www.microsoft.com/whdc/device/print/XPSDrv_FilterPipe.mspx

XPSDrv Filter Pipeline - 2

Disclaimer: This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred.

© 2007–2008 Microsoft Corporation. All rights reserved.

Microsoft, Win32, Windows, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Document HistoryDate Change

2/7/2008 Changed IXpsReadStream and IXpsWriteStream to the correct names, IPrintReadStream and IPrintWriteStream.

4/11/2007 First publication

ContentsIntroduction...................................................................................................................4Windows Vista Print Path Overview..............................................................................5

XPSDrv Printer Driver................................................................................................5XPS-Enabled Printers.................................................................................................6Windows Vista Print Paths........................................................................................6

GDI-to-XPS Conversion Path..................................................................................7XPS-to-GDI Conversion Path..................................................................................9

XPS Print Path Processing........................................................................................10XPS_PASS Datatype.................................................................................................11

XPS Print Path Components.........................................................................................13XPS Spool File..........................................................................................................13XPSDrv Printer Driver..............................................................................................14

XPSDrv Filter........................................................................................................14Filter Configuration File.......................................................................................14Configuration Module.........................................................................................15

Filter Pipeline Manager...........................................................................................15

February 7, 2008© 2007–2008 Microsoft Corporation. All rights reserved.


Filter Pipeline......................................................................................................16Interfilter Communicator....................................................................................16Print Pipeline Property Bag.................................................................................17

Printer and Driver Migration Strategies.......................................................................17Adapting the Printer to Consume XPS Data.............................................................17

Advantages..........................................................................................................18Challenges...........................................................................................................18Development Details...........................................................................................18Conclusions.........................................................................................................18

Porting Existing Driver to XPSDrv Driver..................................................................18Advantages..........................................................................................................19Challenges...........................................................................................................19Development Details...........................................................................................19Conclusions.........................................................................................................20

XPS Print Path Functional Design Examples.................................................................20Passthrough Printer Driver Example........................................................................20Printer Driver with Filters Example..........................................................................21

Filter Pipeline......................................................................................................21Filter Interfaces...................................................................................................22Color Management Filter Example......................................................................24N-up Filter...........................................................................................................25Render Filter Example.........................................................................................26

Best Practices for XPSDrv Printer Drivers.....................................................................27Considerations for Filters that Use XPS Document Interfaces.................................28Considerations for Filters that Use Stream Interfaces.............................................28Filter Sequence in the Filter Pipeline.......................................................................29Interleaving Mode for the Output Device...............................................................29Asynchronous Notification Support.........................................................................30

Debugging Filters in the Filter Pipeline........................................................................30Next Steps....................................................................................................................31Resources....................................................................................................................31



IntroductionThe Windows Vista® operating system includes the XPS print path as part of a new print architecture that is designed to improve support for printers and document processing. The XPS print path can also be added to earlier versions of Windows® by installing the XPS Essentials Pack or .NET Framework 3.0. An important part of these advancements is the modular, filter-based XPSDrv printer driver that uses a more flexible printer driver design than the graphics device interface (GDI)-based printer driver.

The XPS print path is designed around the XML Paper Specification and documents are spooled in the XPS spool file format. The XML Paper Specification describes the XPS document format, which is identical to the XPS spool file format. The term XPS document is used in the XML Paper Specification to describe the fixed document that is used in document viewing and sharing scenarios. The term XPS spool file is used to indicate that the file is queued for printing. Because both formats are identical—no data is lost to transformations or translations when an XPS document is sent to a printer that has an XPSDrv printer driver.

The XML Paper Specification is used by XPS technologies such as:

The XPS Viewer. A Microsoft Internet Explorer version 7 plug-in that can be used to view, manage, and print XPS documents.

The Microsoft XPS Document Writer. A printer driver that enables users to generate XPS documents from any application.

.NET Framework 3.0. A new set of features that includes the Windows Presentation Foundation (WPF) and contains APIs that make it easy for applications to use XPS document features.

The Microsoft XPS Document Converter (MXDC). A feature in the print spooler that makes it possible for Microsoft Win32®-based applications to also take advantage of the new features that the XPS print path and the XPSDrv driver architecture provide.

This paper describes the processing component of the XPS print path in Windows Vista and includes technical details about how to implement several different types of filters for XPSDrv printer drivers. The configuration functions of an XPSDrv printer driver are also an essential part of a complete XPSDrv printer driver. For more information on designing and building an XPSDrv printer driver, see the Windows Driver Kit (WDK).

This paper helps printer driver developers and decision-makers plan the migration or porting strategy for their XPSDrv printer driver. It also describes the best practices for the design and implementation of an XPSDrv printer driver and provides information about the following topics: A high-level overview of the XPS print path components to familiarize readers

with the technology that is used in the XPS print path. Detailed technical descriptions of the different components that make up the XPS

print path.



Implementation alternatives and best practices for designers and decision-makers to consider when planning their support for XPS.

Technical details about several types of XPSDrv printer driver filter designs.

Windows Vista Print Path OverviewWindows Vista uses two print paths for processing print jobs: the XPS print path and the GDI print path. Both print paths are present in the Windows Vista print subsystem, and both share a common print spooler. The Windows Vista print subsystem includes conversion routines that convert print jobs from one print path to the other. The XPS print path can also be added to earlier versions of Windows by installing the XPS Essentials Pack or the .NET Framework 3.0.

WPF—Microsoft's unified presentation subsystem—is part of .NET Framework 3.0 and is standard with Windows Vista. This presentation subsystem consists of a display engine and a managed-code framework. It unifies the way in which Windows creates, displays, and manipulates documents, media, and user interface (UI) so that developers and designers can create visually stunning and differentiated user experiences. These features can also be added to earlier versions of Windows by installing .NET Framework 3.0.

The advantages of the XPSDrv print path are available to both WPF and Win32 applications. WPF applications can use the XPS print path to provide a richer user experience with better print fidelity and performance than was possible with the GDI print path. Win32 applications can use the escape codes that the conversion modules support and write their own XPS document data in the RAW datatype to take advantage of the additional features that the XPS print path offers.

XPSDrv Printer DriverAt the heart of the XPS print path is the XPSDrv printer driver. An XPSDrv printer driver contains a set of print processing modules that are called filters and a configuration file that describes how the filters of the printer driver are loaded, how they are called, and how data is passed between each filter and the interfilter communicator (IFC).

The specific function or functions that each filter in a printer driver performs depends on the printer driver implementation and the printer requirements. A filter might perform only a single function, such as applying a watermark to a page or color management to a document, or a single filter might perform all of the required processing to convert the contents of an XPS spool file to the page description language (PDL) that the printer requires.

The filter configuration file describes which filters a printer driver uses and the order in which the filters process the print job. Because of the modular nature of this design, a filter that performs a specific print processing task can be used in more than one printer driver.



Manufacturers of printers that are not XPS enabled must include a filter that converts the print job data from the XPS spool file format to the PDL that the printer supports. The point in the print path where the conversion to the printer’s PDL takes place is not defined by the XPSDrv printer driver design and can vary from one implementation to the next.

XPS-Enabled PrintersThe XPS print path supports XPS-enabled printers—printers that use XPS as the PDL. When printing to an XPS-enabled printer, the print job can remain in the original XPS spool file format throughout the entire print path from the application to the printer. A printer that consumes the XPS document output of the application is also referred to as a direct-consumption printer. In the XPS print path, XPSDrv printer drivers for XPS-enabled printers can maintain the original XPS document format throughout the print path and eliminate the loss of document and image fidelity that results from data translations and transformations that can occur in the print path.

Note:To support printers that are not XPS-enabled printers, printer vendors and printer driver developers must provide the capability to convert print job data from the XPS spool file format to the PDL, including the raster image processing (RIP) functions because Windows does not offer any graphics support to XPSDrv printer driver filters. This capability can be provided in the XPSDrv printer driver as an individual filter or as a component of a filter.

Manufacturers that are developing new printers might also consider the scalable consumption that the XPSDrv printer driver architecture offers. The scalable consumption model allows print processing functions to be divided between the printer driver and the printer firmware. This capability can be factored into the design of the printer firmware and the printer driver to optimize the processing power that is available throughout the print path in the print server and the printer hardware.

Windows Vista Print PathsThe type of printer driver in the print queue determines which print path is used to print the document in Windows Vista. The same print spooler is used to process print jobs through both print paths.

Figure 1 illustrates at a high level how the spooler processes documents. Documents that are sent to a print queue with an XPSDrv printer driver are spooled in the XPS spool file format and processed in the XPS print path by an XPSDrv printer driver. Documents that are sent to a print queue with a GDI-based, Version-3 printer driver are processed in the GDI print path. Both Win32 and WPF applications can print to either type of printer driver.

The two print paths are not as separate and distinct as Figure 1 might imply. Microsoft provides conversion routines so that Win32 applications can print to printers with XPSDrv printer drivers and WPF applications can print to printers with GDI-based printer drivers.



Figure 1. Side-by-Side Comparison of the XPS Print Path and the GDI Print Path

Although the printer driver of the target print queue determines which print path is taken, the presentation system of the application determines whether the print job from the application must be converted before spooling. If the application’s presentation technology differs from that of the print path, the print job format must be converted by the conversion modules that convert between the XPS and the GDI print paths.

GDI-to-XPS Conversion PathWin32 applications can take advantage of the improved features that an XPSDrv printer driver provides. When a Win32 application sends a document to a printer with an XPSDrv printer driver, the spooler uses the GDI-to-XPS conversion (GXC) module to create an XPS spool file for the XPS print path from the GDI functions called by the application. This is the simplest way for a Win32 application to use the XPS print path because no changes to the Win32 application are required.

Figure 2 shows the GXC path. Although not shown specifically in Figure 2, a Win32 application can use the printer escape function to send XPS document content to the printer while it calls GDI printing functions to spool the print job. This feature causes the XPS document content to pass, unchanged, through the GXC module and be spooled in the XPS spool file so it can be processed directly by the XPSDrv printer driver. After the document has been spooled in an XPS spool file, it is processed in the same manner as any other XPS spool file.



A Win32 application can also write XPS document content directly to a print queue that has an XPSDrv printer driver by using the RAW datatype and calling the StartDocPrinter, the WritePrinter (as needed), and then the EndDocPrinter Win32 functions. When using these functions, the Win32 application must format the XPS document content and document parts according to the XML Paper Specification.

Figure 2. GDI-to-XPS Conversion Path



XPS-to-GDI Conversion PathXPS documents that are sent to a printer with a GDI-based printer driver are converted by the XPS-to-GDI conversion (XGC) module that is part of the WPF print support. Figure 3 shows how the WPF print support processes documents for printers based on the type of printer driver. The application prints the document by using the WPF print support and, when printing to a GDI-based printer driver, the XGC simulates a Win32-based application and makes the calls to the GDI functions that are necessary to spool the document for the GDI-based print path.

Figure 3. XPS-to-GDI Conversion Path



XPS Print Path ProcessingPrint jobs that are processed through the XPS print path are processed by a filter-based, XPSDrv printer driver. Figure 4 illustrates the major components of the XPS print path, including the filters of an XPSDrv printer driver and how they are managed by the filter pipeline. The documents that are processed by the XPSDrv printer driver can come from either a WPF application or a Win32 application. After the print job has been spooled as an XPS spool file, the print job is processed the same way regardless of the type of application that spooled the job.

Figure 4. Detailed View of Filter Pipeline Components in the XPS Print Path

The print spooler spools documents for the XPS print path in the XPS spool file format. Documents from a Win32 application are spooled in the XPS spool file format by the MXDC, whereas the WPF applications use WPF print support to spool the document in the XPS spool file format. When the job is ready to print, the scheduler signals the filter pipeline manager to begin processing.

The filter pipeline manager starts processing the job by reading the filter configuration file of the printer driver. The filter pipeline manager creates the filter pipeline for this printer by loading the filters that are listed in the filter configuration file. After the filter pipeline has been created and initialized, the filter pipeline



manager starts the filter pipeline and the first filter in the filter pipeline reads the contents of the XPS spool file.

The first filter reads the document parts and XML PrintTickets and processes the document accordingly. The filter sends the processed document parts to the next filter by using the interface that the IFC provided. The IFC maintains the intermediate processing results until the next filter is ready to process them.

The print filter pipeline also stores information about the printer and the print job in the print pipeline property bag for filters to use. Filters can access this data and can use the print pipeline property bag to share proprietary data.

When the next filter in the filter pipeline is available to process the print job, the filter reads the data from the previous IFC, processes the data, and writes the processed data back through the IFC interface. This process repeats for each filter in the filter pipeline, and the results from the last filter go to the port that the printer driver defined. In this example, the output from the last filter is sent to the printer port.

The internal processing of an XPSDrv printer driver is described in more detail in “XPS Print Path Functional Design Examples” later in this paper.

XPS_PASS DatatypeA print queue with an XPSDrv printer driver accepts two types of data: RAW and XPS_PASS. Content that is sent to the print queue in the RAW datatype must be formatted as an XPS document, whereas content that is sent in the XPS_PASS datatype must not be formatted as an XPS document. The XPS_PASS datatype is reserved for printer control and maintenance commands. When the application selects the RAW datatype, the print subsystem processes the print job by using the printer driver’s filters in the filter pipeline. When the application selects the XPS_PASS datatype, the print subsystem sends the print data directly to the printer port, bypassing the filter pipeline. This feature is designed for maintenance applications so that they can send low-level and maintenance commands to the printer. Do not use the XPS_PASS datatype for sending XPS document content to printers.



Figure 5 illustrates the two paths that print job data can take through the XPS print path, depending on the datatype.

Figure 5. Data Flow through the XPS Print Path for XPS_PASS and RAW Data

An application can set the datatype when it opens the printer for printing as shown in the following example:PRINTER_DEFAULTS PrtrDefaults;

PrtrDefaults.pDatatype = "XPS_PASS";PrtrDefaults.pDevMode = &MyLocalDevmode;PrtrDefaults.DesiredAccess = PRINTER_ACCESS_USE;

bStatus = OpenPrinter (PrinterName, &hPrinter, PrtrDefaults);Or it can set the data type when it calls SetDocPrinter as shown in the following example:DOC_INFO1 DocInfo;

DocInfo1.pDocName="PrinterTestDoc";DocInfo1.pOutputFile=NULL;DocInfo1.pDatatype="XPS_PASS";

dwPrtJob = StartDocPrinter (hPrinter, 1, // indicates DOC_INFO1 structure (LPBYTE)DocInfo1;



XPS Print Path ComponentsThis section describes the components that make up the XPS print path.

XPS Spool FileMuch of the XPS print path’s flexibility comes from the modular nature of the XPS spool file format. The XPS spool file format is identical to the XPS document format and is documented as the XPS document format in the XML Paper Specification.

An XPS document is composed of modular parts and resources that are organized in a logical hierarchy. The format of the content and the organization of these parts and resources are specified in the XML Paper Specification. Figure 6 shows an example of an XPS spool file and how the internal format consists of a hierarchical set of document parts that describe different aspects of the document’s content.

Figure 6. The Logical Organization of the XPS Spool File

In addition to the logical hierarchy of document parts, the package can contain a thumbnail image that the operating system and applications use as a visually summarized representation of the document. Although the XML Paper Specification describes the format for the content and the logical organization of the parts in an XPS document, the Open Packaging Conventions specify the actual physical storage and organization of the document parts.

At the top of the logical part hierarchy in an XPS spool file is the Fixed Document Sequence object. The Fixed Document Sequence object contains the references to the Fixed Document objects in the package, each of which represents individual documents, chapters, or other document-defined groups of pages in the package. Each Fixed Document object contains the references to the Fixed Page objects that contain the content of the individual pages in the document. A Fixed Page object contains the markup that describes the page and references to the images, fonts, and custom resources that are used on that page.



The filters in an XPSDrv printer driver can act on the document parts individually or collectively. For example, a filter that applies a watermark to each page in a document might alter only the contents of the Fixed Page objects in the document without altering any of the other elements in the document hierarchy. Conversely, a filter that adds a separator page between each document in the print job might alter the Fixed Document objects in each document by adding a new Fixed Page object for the separator page.

XPS spool files can also include XML PrintTicket objects that contain additional characteristics of the print job that the printer driver, and possibly the printer, can use to modify how they process the print job. XML PrintTicket processing in XPSDrv printer driver filters is described in the WDK.

XPSDrv Printer DriverAn XPSDrv printer driver package includes: XPSDrv filters

A filter configuration file A configuration module

The filters in an XPSDrv printer driver process the print job in the sequence that the printer driver’s filter configuration file describes.

XPSDrv FilterThe filter is the basic processing element of an XPSDrv printer driver. An XPSDrv printer driver can contain as many filters as it needs to process a print job. The filter pipeline manager, which manages the filters of an XPSDrv printer driver, is described later in this section.

When the printer driver processes a document for printing, the filter pipeline manager loads the filters that the filter configuration file describes. The print job data is then passed from one filter to the next through the IFC interface that is managed by the filter pipeline manager.

For maximum flexibility and the ability to reuse filters in other printer drivers, each filter should perform a specific print processing function. XPSDrv printer driver design also allows a filter to perform a range of functions such as the complete image processing that is required to convert the XPS data format to the raster or PDL that is necessary for the printer.

Filter Configuration FileThe filter configuration file is an XML file that contains the configuration information that the filter pipeline manager uses to load the filter modules of the driver and to create the filter pipeline for the printer. The following code sample shows the contents of a sample filter configuration file:



<Filters> <Filter name = "Watermark filter" clsid = "{Filter GUID}" dll = "MsWatermark.dll"> <input guid="{b8cf8530-5562-47c4-ab67-b1f69ecf961e}" comment="IID_IXpsDocumentProvider" /> <output guid="{4368d8a2-4181-4a9f-b295-3d9a38bb9ba0}" comment="IID_IXpsDocumentConsumer" /> </Filter>

<Filter name = "Render filter" clsid = "{Filter GUID}" dll = "MsRender.dll"> <input guid="{b8cf8530-5562-47c4-ab67-b1f69ecf961e}" comment="IID_IXpsDocumentProvider" /> <output guid="{65bb7f1b-371e-4571-8ac7-912f510c1a38}" comment="IID_IPrintWriteStream" /> </Filter></Filters>

Configuration ModuleThe XPSDrv printer driver includes a configuration module that supports the GDI-based, Version-3 printer driver interfaces. The configuration module also includes support for the PrintTicket document and the PrintCapabilites document that XPSDrv printer drivers must support. PrintTicket Document. The PrintTicket document is an XML PrintTicket object

that can be associated with each document part in an XPS spool file. The XML PrintTicket is the standard way of describing print job settings for XPSDrv printer drivers. Printer driver filters in the filter pipeline should use this information when processing a document.

PrintCapabilities Document. The PrintCapabilities document publishes configurable device capabilities, such as user settings and finishing and page-layout options, to applications in a well-defined, XML-based format. Printers can use the XML PrintCapabilities document to describe device capabilities, user-configurable attributes of the device, and allowable settings for each attribute. Applications can use printer features more effectively when printers describe those features by using the Print Schema framework and the keywords that are described in the Print Schema specification.

Filter Pipeline ManagerThe filter pipeline manager is part of the PrintFilterPipeline service that is a component of the print spooler. The filter pipeline manager performs the following tasks: Loading and initializing filters as described by the filter configuration file to create

the filter pipeline. Managing the data between filters as the print job is processed.

Unloading filters when the print job is finished. Initializing the print pipeline property bag



Filter PipelineThe filter pipeline for a printer driver is the logical collection of printer driver filters that are specified in the filter configuration file and configured to process the print job for the printer. The filter pipeline manager reads the printer driver’s filter configuration file and then loads and initializes each filter that is listed in the file. After the filters have been loaded and initialized, the filter pipeline is started and the first filter in the pipeline reads the document.

When the print job is finished, the filters exit and are unloaded by the filter pipeline manager. This destroys the filter pipeline; however, the hosting process might remain active to host another pipeline or might be terminated, depending on how it is configured.

Interfilter CommunicatorThe IFC is the part of the filter pipeline manager that handles the communication between filters in the filter pipeline. When the filter pipeline manager initializes a filter, an IFC interface—IInterFilterCommunicator—is passed to each filter so that the filter can obtain the read and write interfaces that are defined for that filter.

XPSDrv printer driver design requires only that the last filter in the printer driver produces the raster data or PDL that the printer requires. Although the filter interfaces can be mixed in theory, in practice filter processing is much more efficient when the consumer interface of one filter is the same type as the producer interface of the filter that follows it in the pipeline. For example, if the output of one filter is the IXpsDocumentConsumer interface, the input of the filter that follows it in the filter pipeline should use the IXpsDocumentProvider interface. The IFC converts the data, if necessary, but unnecessary conversions can greatly reduce the throughput of the filter pipeline.

Microsoft provides the XPS document and stream interfaces, and vendors can also create their own IFC interfaces when they implement their printer driver filters.

XPS document interface. This Microsoft interface reads from and writes to the different parts of an XPS spool file by using the XPS document object model. The filter uses these interfaces to access the document parts in an XPS spool file for processing and then to write the parts of the processed document back in the XPS spool file format. The actual interfaces are: IXpsDocumentProvider

IXpsDocumentConsumer Stream interface. This Microsoft interface reads and writes a serial stream of

data. This interface would be used, for example, to write the PDL from a filter to a printer that does not use XPS as a PDL or to process the XPS spool file as a stream without the XPS document object model. The actual interfaces are: IPrintReadStream

IPrintWriteStream



Custom filter provider/consumer interfaces. Hardware vendors and printer driver developers can define application-specific or document-specific IFC interfaces if the Microsoft-provided interfaces do not meet their requirements. Discussion of that development is outside the scope of this paper.

Print Pipeline Property BagThe print pipeline property bag is an interface that the PrintFilterPipelineSvc service implements for the filters of an XPSDrv printer driver to use to share data. The filter pipeline provides some common properties that the filters can access and filters can also create and store proprietary properties in the property bag.

The IPrintPipelinePropertyBag interface is documented in the WDK and includes the following predefined properties: PrinterName: The printer name.

ProgressReport: A reference to the IPrintPipelineProgressReport interface. PrinterHandle: The printer handle.

PerUserPrintTicket: A reference to the Per-User Print Ticket. UserSecurityToken: A handle the filter can use to impersonate the user.

PrintJobId: The print job identification number. PrintClassFactory: A reference to the IPrintClassObjectFactory interface.

IPrintCoreHelper: A reference to the IPrintCoreHelper interface if the unidrvui.dll is included as a FilterServiceProvider in the filter configuration file.

Printer and Driver Migration StrategiesThis section reviews some possible approaches to upgrading existing printers and printer drivers to support the XPS print path.

Adapting the Printer to Consume XPS DataA printer that can directly consume an XPS document is referred to as an XPS-enabled or direct-consumption printer. Having the printer use XPS as its PDL eliminates the required format conversions between the application and the printer when printing from a WPF application.

Many printers support more than one PDL and are called multipersonality printers. Some printers support only one PDL and are called single-personality printers. Often, multipersonality printers can implement XPS as one PDL and also support another PDL such as PostScript or printer control language (PCL).

The XPSDrv printer driver for a direct-consumption printer could be implemented as a passthrough driver and have no processing filters. The printer driver would simply provide a configuration module as shown in the passthrough driver example in “XPS Print Path Functional Design Examples” later in this paper.



AdvantagesAn XPS-enabled printer can require very little print job processing on the print server.

Having very little host software minimizes the host software maintenance requirements, which can be an advantage in enterprises that have many printers as well as those that have print servers that are deployed across a large area. Often, the XPS spool file is smaller than the corresponding enhanced metafile (EMF) or RAW spool file and requires less server storage space to spool the print job from the client computer and less network bandwidth to move the file from the client computer to the server and from the server to the printer.

Processing XPS documents in the XPS print path and sending them to an XPS-enabled printer eliminates the transformations and translations that are commonly found in host-based image processing software. For example, GDI-based printer drivers must transform image data to the 8-bit-per-channel, red-green-blue (RGB) color space that GDI supports. XPSDrv printer drivers, conversely, can support up to 32 bits per channel by using the Windows Media Photo image format and can provide a direct path to the device for device color support.

XPS-enabled printers can also use different native color spaces, such as the printer-oriented, cyan-yellow-magenta-black (CYMK) color space and n-channel image representation. Applications that create images for printing can work in a color space that is more suitable for the task and can send this image data to the printer, where it can be processed in the same color space and sent directly to the printer for greater image fidelity.

ChallengesPrinter hardware and firmware must be engineered to process an XPS document directly. In some cases, this might also require additional processing speed, power consumption, and memory, all of which could limit this option to only the higher end products of the product line.

Development DetailsAs noted above, most of the development for this option is in the printer’s hardware and firmware, so a detailed discussion of this is outside the scope of this paper.

ConclusionsDirect consumption is a good option for printers that have the resources to consume an XPS document. Fortunately, printers that already support several PDLs can probably also support XPS as a PDL. Processing the document directly in the printer not only takes advantage of the device’s hardware acceleration and embedded firmware capabilities, but might also make possible new print scenarios such as walk-up or kiosk-like applications that are not currently possible with other PDLs.

Porting Existing Driver to XPSDrv DriverNot all printers have the processing resources that are required to process a PDL. Many consumer-level inkjet printers, for example, are typically raster devices that require the printer driver on the host to perform all the print processing and rasterization for the printer.



The XPSDrv printer driver architecture offers a scalable consumption model that enables printer driver designers to balance the print processing load between the driver and the printer. Because the XPSDrv printer driver design does not define where in the print path any particular aspect of print processing must occur, printer vendors have considerable flexibility in their printer and printer driver design.

For example, if printer vendors want to keep the majority of print processing on the host, they can port their current printer drivers to XPSDrv drivers that process the XPS spool file format data and produce the same output to the printer that their current printer drivers produce.

Printer vendors can also take this opportunity to restructure their printer driver design into modular, reusable filters that consume XPS as input and generate XPS on output. Of course, one filter in the filter pipeline must generate the PDL or rasterized data that the printer requires.

AdvantagesThe main advantage to this approach from a design perspective is that very little, if any, additional development is required on the printer hardware. Developing XPSDrv printer drivers for existing printers can provide improved image fidelity, support for extended color spaces, and reduced spool file sizes by supporting the XPS print path without requiring any changes to the printer devices.

New XPSDrv printer drivers can give end users the advantages of the XPS print path on their existing printers. At the same time, printer vendors can build on their installed base and customer loyalty by incrementally moving their product line to support XPS printing, by using either a host-based driver solution or a direct-consumption solution.

ChallengesExisting printer drivers must be ported and adapted to support the XPS spool file and the filter-based nature of the XPS print path.

When considering this option, it is important to remember that an XPS spool file is quite different from an EMF spool file. An XPS spool file contains an XML-based representation of the page content and includes additional data such as the XML PrintTicket. In contrast, an EMF spool file contains a series of GDI calls. An XPSDrv printer driver must perform the required image processing to render an XML-based markup, so porting from a GDI-based driver is likely to require significant engineering, the use of a raster imaging processor module, or both.

Development DetailsExisting printer driver functionality must be divided and ported into XPSDrv driver filters. It might be necessary to add RIP functions to accurately convert the XPS spool file content to the raster data or PDL that the printer requires. When designing the XPSDrv filters for a printer driver, properly partitioning the printer driver functionality is critical to realizing the long-term, cost-saving benefits of filter reuse.



The configuration module is an important part of the XPS print path and must be included in the design of an XPSDrv printer driver. Applications use the configuration module to communicate job, document, and page layout intent to the printer driver filters as the job progresses through the filter pipeline.

ConclusionsFor vendors that have a wide range of existing printers or a large installed base, this might be the most practical option to provide customers with the improved document fidelity that is available by using the XPS print path. The modular, filter-based design of the XPSDrv printer driver allows all printers that use the same PDL to share the same XPS to PDL render filter. Other features can be included in separate filters and then configured into the printer drivers as needed by each printer.

Porting a printer driver to XPSDrv is an investment in the future. With a sound design, printer driver filters can be reused in future printers, making it easier to bring new printers to market.

XPS Print Path Functional Design ExamplesTo provide some examples of possible printer driver implementations, this section describes the functional design of different types of XPSDrv printer drivers.

Passthrough Printer Driver ExampleThe simplest XPSDrv printer driver is a passthrough printer driver. A passthrough printer driver passes the XPS spool file directly to an XPS-enabled, direct-consumption printer. The following PassthroughConfig.XML shows the filter configuration file for this printer and how it only contains an empty Filters element:

PassthroughConfig.XML<Filters></Filters>Figure 7 shows the filter pipeline for a passthrough printer driver after it has been configured by the filter pipeline manager.

Figure 7. Filter Pipeline for a Passthrough XPSDrv Printer Driver



Printer Driver with Filters ExampleThe passthrough printer driver represents a very minimalist printer driver option that can be used only by an XPS-enabled printer. A more complex and more realistic printer driver requires some document processing features especially if the target printer does not use XPS as a PDL.

This example describes a printer driver with three filters to illustrate how the filters are designed and how they process print jobs. The printer driver in this example uses one filter to apply color management to the document, another filter to perform N-up printing, and the final filter in the filter pipeline to converts the XPS spool file to a stream of PDL for the destination printer. Note that the functions that the filters perform in this example were selected more to illustrate different ways to implement filters than to illustrate an ideal XPSDrv printer driver.

Printer drivers can have as many filters as they need to process the print job. The filter configuration file describes how the filters are configured to make up the printer driver. For more information on how to organize the filters in the pipeline for the best performance, see ”Best Practices for XPSDrv Printer Drivers” later in this paper.

Filter PipelineWhen a document is ready to print, the filter pipeline manager creates a filter pipeline for the print queue and begins to process the print job. The filter pipeline manager first reads the filter configuration file and then loads and initializes the filters as described in the file to create the filter pipeline for the printer driver.

ThreeFilterConfig.XML is the filter configuration file for the following printer driver example:

ThreeFilterConfig.XML<Filters> <Filter name="Color Management Filter" clsid="{Color Management GUID}" dll="ColMgmt.dll" /> <input guid="{b8cf8530-5562-47c4-ab67-b1f69ecf961e}" comment="IID_IXpsDocumentProvider" /> <output guid="{4368d8a2-4181-4a9f-b295-3d9a38bb9ba0}" comment="IID_IXpsDocumentConsumer" /> </Filter>

<Filter name="N-up Filter" clsid="{NUP Filter GUID}" dll="NUP.dll" /> <input guid="{b8cf8530-5562-47c4-ab67-b1f69ecf961e}" comment="IID_IXpsDocumentProvider" /> <output guid="{4368d8a2-4181-4a9f-b295-3d9a38bb9ba0}" comment="IID_IXpsDocumentConsumer" /> </Filter>



<Filter name="Render Filter" " clsid="{Render Filter GUID}" dll="RenderJob.dll /> <input guid="{b8cf8530-5562-47c4-ab67-b1f69ecf961e}" comment="IID_IXpsDocumentProvider" /> <output guid="{65bb7f1b-371e-4571-8ac7-912f510c1a38}" comment="IID_IPrintWriteStream" /> </Filter></Filters>The filter pipeline manager instantiates each of the filters that is specified in the filter configuration file and then calls the InitializeFilter method of each filter’s IPrintPipelineFilter interface to initialize the IFC interfaces. The IPrintPipelineFilter interface is shown in the following example:interface IPrintPipelineFilter : IUnknown{ HRESULT InitializeFilter( IInterFilterCommunicator *pICommunicator, IPrintPipelinePropertyBag *pIPropertyBag, IPrintPipelineManagerControl *pIPipelineControl );...In the InitializeFilter method, the filter:

Caches the pointer to the IPrintPipelineManagerControl interface. Reads any required properties from the IPrintPipelinePropertyBag interface.

Calls the RequestReader and RequestWriter methods of the IInterFilterCommunicator interface that was passed by pICommunicator to initialize the provider and consumer interfaces for this filter.

Filter InterfacesThe IInterFilterCommunicator interface contains the methods that enable the filter to obtain the provider and consumer interfaces for each filter. The following sample shows the methods of the IInterFilterCommunicator interface:interface IInterFilterCommunicator : IUnknown{ HRESULT RequestReader(void **ppIReader);

HRESULT RequestWriter(void **ppIWriter);}The filters in the filter pipeline communicate print job data with the other filters in the pipeline by using the interfaces obtained from the IInterFilterCommunicator interface. This decoupling makes the filters more independent and allows the IFC to optimize the scheduling of the filters and improve the performance of interfilter communications.

When designing filters for an XPSDrv printer driver, it is important to consider the IFC interfaces that each filter uses. The provider or reader interface of one filter must be able to read and process the data from the consumer or writer interface of the previous filter. The IFC does not perform any data-format conversions, but it will



prepare the data so that adjacent filters can use different Microsoft-provided interfaces. The conversion from a stream to an XPS document, however, can incur a performance penalty because the stream data must be interpreted into the XPS document object model. Conversely, serializing data from the XPS document object model to a stream still requires some processing, but much less than the conversion from a stream to the XPS document object model.

Figure 8 shows the initialized filter pipeline for this printer driver. Note that the provider and consumer interfaces are illustrated in the XPS printer driver. The color management filter uses the XPS provider interface—IXpsDocumentProvider—as the reader interface so that it can read the XPS spool file from the spooler. It writes data back to the IFC in the XPS spool file format by using the XPS document consumer interface—IXpsDocumentConsumer. The next filter in the pipeline, the N-up filter in this example, also uses an XPS provider interface so that it can read the data written by the color management filter without incurring any data conversion. The render filter creates the PDL for the printer by using the content of the XPS document parts so it uses the IXpsDocumentProvider interface to read in the document content and uses the stream writer interface—IPrintWriteStream—to send the PDL data to the printer port through the IFC.

The filter pipeline in Figure 8 is indicated by the line from the XPS spool file, through the filters, ending in the printer.

After the filters have been loaded and initialized, the filter pipeline for this driver begins to process the print job. The filter pipeline manager starts by calling the filter’s StartOperation method in a separate thread. The StartOperation method, which is described in the next section, runs until that filter has completely processed the document or the filter pipeline manager calls the ShutdownOperation method.

A filter should not create additional threads. However, if a filter must create an additional thread, it must also manage the thread resources properly during the thread’s lifetime and then terminate and close those threads when the filter is shut down by the filter pipeline manager.



Figure 8. Filter Pipeline for a Three-Filter XPSDrv Printer Driver

Normally, the processing loop in the StartOperation method exits when the document has been completely processed. However, the StartOperation method must also exit when the filer pipeline manager issues a termination request.

To detect an early termination request and allow the filter to exit properly, the processing loop of the StartOperation method that is described in the following section monitors the m_bShutdown value. To issue the termination request, the filter pipeline manager calls the ShutdownOperation method of each filter, as shown in the following example:

STDMETHODIMPIPrintPipelineFilter::ShutdownOperation(void){

m_bShutdown = true;return S_OK;

}

Color Management Filter ExampleThe first filter in the filter pipeline for this printer driver example applies color management to the FixedPage parts in the XPS document. The filter performs this task as each FixedPage part in the XPS document is processed and passes all the other document parts through the filter unchanged.



Processing the XPS Document PartsThis filter is an example of a serial processing filter that acts on the document parts as they are read from the provider. Figure 9 shows the internal processing that the filter performs after it has been initialized.

Figure 9. Block Diagram of Color Management Filter Processing

This filter consumes data from the IFC interface by using the Microsoft-provided XPS document provider interface—IXpsDocumentProvider. The filter provides data to the IFC interface by using the Microsoft-provided XPS document consumer interface—IXpsDocumentConsumer—which contains the methods that are used to write each of the document parts back to the IFC. Other filters might also use other IFC interfaces, depending on the nature of the filter.

Note:All document parts that are read from the provider interface must be passed on to the next filter in the correct order by using the appropriate consumer interface, even if they are not modified by the filter.

Processing the XML PrintTicketPrintTicket DocumentEach document part in an XPS spool file can have an XML PrintTicket document part that contains information from the application for use by the printer driver filters. The filter can use this information to modify the print job processing. Each document part interface contains a method to set and get the PrintTicket for that document part. For more information about parsing and processing the content of an XML PrintTicket, see the WDK.

N-up FilterThe color management filter in the previous section processed the XPS document as individual parts and passed them on to the next filter as they were processed. This was possible in the color management filter because it did not require any more document context to perform its processing than was available in the current document part.



The N-up filter illustrates another processing option that can be used when a more comprehensive document context is required to process the print job. In this example, the filter must cache some or all of the document parts as they are read before it can process them.

Filters that must cache document parts should cache only the document parts that are required for processing and should send the processed parts to the next filter as soon as possible. This enables the document to be processed through the filter pipeline as efficiently as possible.

The N-up feature lays out multiple document pages on a single printed sheet. To do this, it must read in several pages from the original document before it can create the output pages for the printer that contains that set of document pages.

Figure 10 shows a block diagram of this type of filter.

Figure 10. Block Diagram of n-Up Filter Processing

When a filter is processing a document in this way, it must cache the incoming pages and write the new pages in the correct sequence so that the next filter in the pipeline can access and process them correctly.

Render Filter ExampleThe render filter in this printer driver example reads the XPS spool file data from the IFC and creates the data to send to the printer. This data can be either the raster output or the PDL that the printer requires. As in the N-up filter, the render filter must also cache some of the document parts and resources to render the text and graphics that the page markup describes. When the filter has enough information, it can render the page and create the byte stream to send to the printer. This section discusses only the interfaces to the spooler and filter pipeline manager because the specific details of how the render filter processes the print job depend on the implementation of the RIP and the printer interface and are outside the scope of this paper.



To communicate with the IFC, the render filter in this example uses the XPS provider interface—IXpsDocumentProvider—and the stream writer interface—IPrintWriteStream—that it obtained during initialization. It calls the GetXpsPart method of the IXpsDocumentProvider interface to read the document parts from the IFC and caches them as required to render the document and generate the output for the printer.

Figure 11 shows the overall processing that the render filter provides.

Figure 11. Block Diagram of Render Filter Processing

The design illustrated in Figure 11 assumes that the document parts must be cached before the page can be rendered. This might not always be true, depending on the type of processing that is required to render the pages and create the PDL for the printer.

The resulting stream of PDL that is created by the filter is sent to the printer by using the stream interface, and the spooler sends it on to the printer.

Best Practices for XPSDrv Printer DriversThis section describes some details of XPSDrv printer driver design to help you create the most efficient XPSDrv printer driver.

The spool file data enters the filter pipeline as a stream in the format that was defined by the document-part interleaving that was used when the application created the XPS spool file. Before that data can be passed to a filter that uses the XPS document interfaces, the IFC must convert the stream into the XPS document object model. The IFC must also convert data that is in the XPS document object model back into a stream to be read by a filter that uses the stream interface. Minimizing the number of these conversions improves the overall throughput of the filter pipeline. The type of interface that a filter uses is determined by how the filter will process the data. Some processing functions are applied to the document parts whereas others might be applied to the data as a stream.



After the print job data has been converted to a format other than an XPS document format (such as the PDL that the printer uses), then all subsequent filters, if any, should use the stream or a customer-defined interface that supports the resulting data format.

Considerations for Filters that Use XPS Document InterfacesIf your filters process the parts of an XPS document, they should use the Microsoft-provided XPS document interfaces. These interfaces provide the XPS document to the filter as individual document parts, which means that the filters are not required to interpret the data stream as components of an XPS document file. When designing these filters, consider the following:

Very little overhead is incurred when a filter with an IXpsDocumentConsumer interface is followed by a filter with an IXpsDocumentProvider interface. To avoid the cost of a Stream interface to an XPS document interface, it is better to keep the filters that use XPS document interfaces together, sequentially, in the filter pipeline.

The low overhead of a filter with an IXpsDocumentConsumer interface that is followed by a filter with an IXpsDocumentProvider interface might make it beneficial for your printer driver to use several discrete filters with XPS document interfaces rather than one filter that performs more than one operation. Having discrete functions in separate filters might make it easier to share filters with other printer drivers while adding very little overhead.

If the printer is an XPS-enabled printer, that is, if the printer uses XPS as its PDL, and you have at least one filter that uses XPS document interfaces, you'll get the best performance if the last filter in the filter pipeline uses the IXpsDocumentProvider interface. For more information about how to optimize the interleaving of the document for the printer when using the IXpsDocumentProvider interface in the last filter in the filter pipeline, see ”Interleaving Mode for the Output Device” later in this paper. The advantage of this interface as compared to the stream interface is that the IFC formats the stream as configured in the configuration file, thereby simplifying the filter design.

Considerations for Filters that Use Stream InterfacesStream interfaces are used by filters that process the data as a stream instead of as a series of XPS document objects. This data stream can be the XPS document passed as a stream or another data format such as the printer-specific PDL. In any case, the filters should be ordered so that they receive the data in the format that they expect. In other words, a stream filter that expects data as an XPS document formatted stream should not follow a filter that outputs a stream of non-XPS PDL. The IFC converts only between XPS document data and XPS document formatted streams.

Filters that use stream interfaces should use buffers that are 32 K-bytes or larger when reading and writing data to the IFC.

If the printer is not an XPS-enabled printer and some filters use the XPS document interfaces, you will probably get better performance if the last filter in the filter pipeline uses the IXpsDocumentConsumer interface as its input,



converts the XPS document information to the PDL of the printer, and then writes the stream by using the IPrintWriteStream interface. If the last filter is configured to use the stream input, the IFC must first reformat the XPS document data as a stream before it is passed into the last filter.

Filter Sequence in the Filter PipelineThe interfilter pipeline can convert the print job data so that a filter that uses the XPS document interfaces can be followed by a filter that uses a stream interface and vice versa. These conversions, however, come with some cost. The filters of a printer driver should be sequenced so they minimize these conversions. For example, if your XPSDrv printer driver has filters that use the XPS document interfaces, those filters should be grouped together in the filter pipeline. Grouping the filters with XPS document interfaces together minimizes the additional processing that is required when the IFC converts the XPS document model data to a stream format and vice versa.

Consider the following when you design an XPSDrv printer driver with filters that have XPS document interfaces and filters that have stream interfaces:

The Stream-to-XPS interface conversion is more costly than the XPS-to-Stream interface conversion

Although a filter with stream interfaces has the lowest interface overhead, if the filter must use the XPS document object model to process the document, it would probably be better for the filter to use XPS document interfaces and let the IFC manage the document object model.

When mixing filters that use different interfaces: If you have any filters with stream interfaces (S) they should either precede or

follow filters with XPS document interfaces (X). They should not be between filters with XPS document interfaces. For example:

X-S is OK. This filter pipeline incurs only one conversion from the Stream-to-XPS document interface.

X-X-S is also OK. This filter pipeline incurs only one conversion from the Stream-to-XPS document interface, and very little additional interface overhead is introduced by the second filter with an XPS document interface.

X-S-X is less than ideal because this design involves two Stream-to-XPS document interface conversions: one before the first filter with an XPS document interface and another before the second filter with an XPS document interface (the third filter in this filter pipeline).

S-X-S is better than the X-S-X example because it requires only one Stream-to-XPS document interface conversion.

Interleaving Mode for the Output DeviceInterleaving refers to how the individual resource parts of an XPS document are streamed along with the FixedPage document parts. When the filter pipeline creates the XPS document object model for the first filter with XPS document interfaces in the pipeline, the interleaving order of the XPS spool file is no longer followed. The last filter in the pipeline that uses the XPS document interface can, however, specify an



interleaving order in the filter configuration file for the pipeline to use when it serializes the XPS content. Selecting an interleaving order that is most compatible with the output device or file can improve performance for subsequent document processing.

The following excerpt from the filter configuration file that was used earlier in this paper shows how this option could be applied. Note that while both Interleaving options are shown in this example, a real filter configuration file will have only one Interleaving element in the filter definition:<Filter dll="NUP.dll" clsid="{NUP Filter GUID}" name="N-up Filter" /> <input guid="{b8cf8530-5562-47c4-ab67-b1f69ecf961e}" comment="IID_IXpsDocumentProvider" /> <output guid="{4368d8a2-4181-4a9f-b295-3d9a38bb9ba0}" comment="IID_IXpsDocumentConsumer" /> <Interleaving mode="MarkupFirst"/> <Interleaving mode="ResourcesFirst"/></Filter>The filter pipeline supports the following interleaving orders:

ResourcesFirst. The ResourcesFirst interleaving order streams each dependent resource before the FixedPage to which it depends. This interleaving order is good for direct-consumption printers because it provides the font and image resources that the printer requires to render the text and page content.

MarkupFirst. The MarkupFirst interleaving order streams the document text and markup and the information about how a resource will be used before it streams the actual resource. This interleaving order is best for archive file destinations and applications that will view the document online.

Asynchronous Notification SupportWhere possible, printer driver filters should support the asynchronous notification feature that Windows Vista supports when the printer driver must interact with the application or the end user who submitted the job for features such as print preview or processing status. The WDK describes this feature and how to add it to your printer driver filters.

Debugging Filters in the Filter PipelineThe filter pipeline hosts the filters of an XPSDrv printer driver. Although the filter pipeline is part of the spooler, it runs as its own process and runs only when necessary. As a result, attaching a debugger to the filter pipeline to troubleshoot the filters of an XPSDrv printer driver is not as straightforward as attaching the debugger to the spooler service (spoolsv.exe). For a description of how to attach the debugger to the filter pipeline service (printfilterpipelinesvc.exe), see ”Debugging XPSDrv Printer Drivers” in the MSDN library online.

For additional tips on how to test and debug the print subsystem, see ”Debugging Printer Drivers” and ”Testing and Troubleshooting the Print Subsystem.” For debugging tools and documentation, see ”Debugging Tools for Windows.”



Next StepsDevelopers and vendors of printer and document processing products are encouraged to review the advantages and requirements of supporting the XPS print path and how applying this technology best fits with their immediate and strategic product plans. Microsoft encourages vendors to pursue these advances by taking the following steps: Read the XML Paper Specification to understand the XPS document format.

Review the Print Schema to understand the structure of the XML PrintTicket and PrintCapabilities documents as well as the keywords that are used to describe the printer's capabilities, features, options, and current settings.

Review all technical documentation about the XPS print path to better understand printer consumption challenges and opportunities.

Consider implementation opportunities to take advantage of scalable and direct consumption, which can maximize software development resources across product lines.

Consider providing updated drivers for the installed base to take advantage of improved printing capabilities that are enabled through XPSDrv drivers.

Become familiar with areas of extensibility to host value-added functions. Design support for the Microsoft XML PrintTicket and XML PrintCapabilities

interfaces into GDI-based drivers for Windows Vista and later versions of Windows.

ResourcesXML Paper Specification

http://go.microsoft.com/fwlink/?LinkId=86040Open Packaging Conventions (part of the Office Open XML document interchange specification)

http://go.microsoft.com/fwlink/?LinkId=86615

Print Schema Specificationhttp://go.microsoft.com/fwlink/?LinkId=86042

Reference Raster Image Processor (RIP)http://go.microsoft.com/fwlink/?LinkId=86614

Windows Driver Kit (WDK) http://go.microsoft.com/fwlink/?LinkId=86043

Windows Hardware and Device Central http://go.microsoft.com/fwlink/?LinkId=86044

XML Paper Specification home page Information about XPS and related topics as well as links for end users, IT professionals, ISVs, and IHVs.


XPSDrv Configuration Module Implementation http://go.microsoft.com/fwlink/?LinkId=86046











Debugging Printer Drivers http://go.microsoft.com/fwlink/?LinkId=86047

Testing and Troubleshooting the Print Subsystem http://go.microsoft.com/fwlink/?LinkId=86048

Debugging Tools for Windows http://go.microsoft.com/fwlink/?LinkId=86050

Debugging Printer Drivers and Spooler Componentshttp://go.microsoft.com/fwlink/?LinkId=87626

If you have questions about XPS or this white paper, send an e-mail to: [email protected]


mailto:[email protected]



