Metro Print Path FAQ

Metro Print Path FAQ - 1

WinHEC 2005 Version - April 20, 2005

Abstract

This paper answers some frequently-asked questions about the Metro print path for the next version of the Microsoft® Windows® operating system, codenamed “Longhorn.” It provides guidelines for printer driver developers to better understand the Metro print path.

This information applies for the following operating systems:
Microsoft Windows codenamed “Longhorn”
Microsoft Windows Server™ 2003
Microsoft Windows XP

Future versions of this preview information will be provided in the Windows Driver Kit (WDK).

The current version of this paper is maintained on the Web at:

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

Contents

Definitions

Version Support

Longhorn Printing

Developer Tools

MetroDrv

PrintTicket

Hardware

Next Steps

Resources

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.

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

All other trademarks are property of their respective owners.

Definitions

What is the Metro Print Path?

The Metro print path is the print path in the next client version of Microsoft Windows, codenamed “Longhorn,” that supports the new Metro document format and the Avalon graphics engine. The operation of the print spooler is essentially the same as in previous versions of Microsoft Windows; however, it has been enhanced to support the Metro print path as well as the existing GDI print path. The new print path natively consumes a Metro spool file. Although user-mode printer drivers written for previous versions of Microsoft Windows will run in Longhorn, a MetroDrv printer driver is required to use the Metro print path.

What happened to the concept of the Next Generation Print Path?

At WinHEC 2004, Microsoft introduced the concept of the Next Generation Print Path. This concept still exists and has been renamed the Metro print path, which better describes the basis for the change over the existing GDI print path.

The Metro print path has undergone some fundamental design changes since WinHEC 2004 as well. The Metro print path in Windows Longhorn will support unmanaged NextGen print drivers that consume the Metro spool file.

What is a MetroDrv driver?

The MetroDrv driver was previously called the Next Generation Print Path (NGPP) driver. The significant change from WinHEC 2004 is that the Metro print path will support only the unmanaged filter pipeline and therefore, only MetroDrv drivers.

Vendors wishing to take advantage of the benefits of the Metro print path must provide a MetroDrv driver. A MetroDrv driver is a vendor-provided filter pipeline that provides driver features such as host-based N-up, watermark, and rendering functions. The new MetroDrv driver includes a Unidrv-based or PScript5-based or IHV monolithic configuration module. The driver must implement PrintTicket/PrintCapabilities to communicate with devices and applications.

What happened to the concept of a dual-mode printer driver?

At WinHEC 2004 and Driver DevCon 2003, Microsoft discussed the concept of a dual–mode printer driver. This concept is no longer in Microsoft’s plan of record for Longhorn, and as such, will not be implemented. References to a dual-mode driver are obsolete. For devices that support both Metro and existing PDLs, a separate driver and print queue will be required for each PDL.

Is there a difference between the Metro Reach document and spool file formats?

There is no difference. Metro is an electronic document format, a spool file format and a page description language. Each instantiation conforms to the same specification.

Version Support

Will non-MetroDrv drivers run in Longhorn?

Yes. User-mode GDI/DDI-based print drivers written for Windows XP and Windows Server 2003 will operate on Longhorn. Most drivers will work without modification, but some print drivers might require minor changes to function correctly. You should test your print driver thoroughly under Longhorn to ensure correct operation.

Kernel mode print drivers are not supported in Windows Longhorn.

Will a MetroDrv driver work on earlier versions of Windows?

Yes. Metro is a new data type to the spooler. Although the spooler on downlevel OSes will not change, Microsoft will supply a Metro-based print processor that understands the new data type to enable Metro-based printing on previous versions of Windows. This new print processor will host MetroDrv and communicate with the Windows XP and Windows Server 2003 spooler. The hosting process provides the same environment for filters. Be aware that some Metro functionality is not available on downlevel OSes, so the MetroDrv driver should be able to gracefully degrade capabilities.

Will PrintCapabilities/PrintTicket work on earlier versions of Windows?

The PrintTicket/PrintCapabilities APIs is planned to ship in both WinFX as a managed API and in Longhorn as an unmanaged API. Additionally, an unmanaged PT/PC API is planned for Windows XP.

Unmanaged access to the Print Schema API is planned for Longhorn, so that updated Win32 applications can communicate with devices supporting PrintCapabilities/ PrintTicket. PrintCapabilities/PrintTicket are also planned to be made available to UNIDRV and PScript driver plug-ins down to Windows XP.

Will the Metro print path support Windows v4 print drivers?

Version4 drivers do not exist and are not planned at this time.

The Metro print path in Longhorn supports both the next generation of devices as well as the installed base of printers currently using the Windows v3 print driver architecture.

What versions of Windows must the config module support?

The UI plug-in or config module must support Windows XP and later versions of Windows, including Windows Longhorn.

The details of the user interface design and requirements are being finalized, but they will be consistent with the MetroDrv driver architecture. The Longhorn-only features of a MetroDrv driver should degrade gracefully on earlier versions of Windows.

Which print paths introduced in Longhorn will work on earlier versions of Windows?

All print paths are planned to work on Windows XP and Server 2003. However, the Metro spooler services will not be available. The paths include the Metro-to-GDI-Conversion (MGC) path, GDI-to-Metro-Conversion (GMC) path, and the Metro print path. These will work alongside the existing GDI print path.

What functions available on Longhorn are not available on earlier versions of Windows?

The spooler is unchanged on earlier versions of Windows. The spooler would see Metro content as RAW format and would be incapable of performing certain actions on the data. In particular, Async Notification support in Windows Longhorn cannot be used by the spooler on earlier versions of Windows.

Will Point and Print work with MetroDrv drivers?

Yes. MetroDrv drivers use the existing Point and Print infrastructure. Specific requirements to enable this functionality will be available in the future.

Longhorn Printing

What are the options for printer driver support in Longhorn?

There are three options for printer driver support in Longhorn:

Develop a MetroDrv driver.
Take full advantage of Longhorn printing features including the configuration module changes and the additional rendering module support. The operating system provides the necessary conversion from GDI to Metro for any print job sent to a MetroDrv driver. The MetroDrv driver also supports the PrintTicket and PrintCapabilities configuration module functions.
Update a v3 driver to support a subset of Longhorn innovations.
For example, support for the Bidi infrastructure, Autoconfiguration, PrintTicket and PrintCapabilities is not dependent on the support of the Metro print path.
Use an existing printer driver.
Existing v3 drivers are expected to work on Longhorn, but will not be able to take full advantage of the Longhorn innovations. Vendors should test their drivers thoroughly under Longhorn to ensure correct operation.

If you choose either of the first two options, you will need to redesign your existing driver to use the new technology. You should keep in mind that while the driver will work on previous versions of Windows starting with Windows XP, some Longhorn innovations will only work on Longhorn.

What driver services will Microsoft provide for MetroDrv drivers?

At this time, Microsoft does not plan to provide driver services comparable to UNIDRV or PScript5 driver services for the Metro print path.

Is the Metro print path dependent on the existing printing architecture?

No. Longhorn supports two distinct print paths, the Metro print path and the GDI print path. One is not a superset of the other. The two paths have no interdependencies, but they do share some common components such as the spooler.

What about performance in a shared-printer environment?

In Longhorn, the impact of printing over the network is addressed by implementing client-side rendering (CSR). Client-side rendering distributes the rendering workload in a shared-printer environment.

Will there be a forms database in Longhorn?

The forms database will work in both the Metro print path and the GDI print path.

Is Microsoft considering a generic print preview using the Metro spool format?

No. Microsoft has no plans to develop a generic print preview using the Metro spool format.

Was this architecture developed with hardware vendor cooperation?

Yes. Microsoft worked with many vendors to refine the Metro specification and the Metro print path design. Microsoft will continue to publish information about the Longhorn print subsystem architecture and will remain open for feedback as long as possible.

How will clustering be affected?

The spooler infrastructure components must be on all the members of the cluster. The driver aspects would be similar to driver aspects for clustering today.

Developer Tools

Is there sample MetroDrv driver code?

Sample MetroDrv driver code is planned for Longhorn Beta 2.

When will Microsoft publish the new Metro format specification?

A draft version of the Metro format specification is planned for publication early in 2Q2005.

MetroDrv

Where does rendering occur in a MetroDrv driver?

A MetroDrv driver depends on a rendering engine capable of interpreting Metro. An unmanaged MetroDrv driver must either provide rendering services as part of its driver or call a third-party Metro interpreter.

Can I reuse my existing rendering code?

You might be able to reuse existing rendering code, especially if you use it to render to different PDLs, However, Metro has a new set of rendering primitives and will require new development.

How does an application know whether it's printing to a MetroDrv driver?

A mechanism is planned for applications to query this data. However, the print system will automatically route application print data through the appropriate print path depending on the targeted print queue and driver. It is not necessary for an application to query the driver to determine if it is a MetroDrv driver in order to print.

Do Microsoft-provided filters generate page description language (PDL)?

No. Microsoft is planning to provide some sample filters similar to print processor features such as n-up and watermark. PDL emitters are the responsibility of the vendor.

How do PrintTicket and the filter pipeline work together?

PrintTickets are associated with content in the Metro spool file. A PrintTicket must be processed by filters in the filter pipeline. Although the configuration of the pipeline is static, the operation of a given filter can be activated or deactivated based on the settings of the PrintTicket.

Can you access the Windows Color System from within the filter pipeline?

Yes. ICM provides interfaces to enable color processing and conversions to the filter pipeline. Color manipulation using the new Windows Color System (WCS) and extended color spaces such as scRGB is only available on Longhorn. Because MetroDrv drivers must function on earlier versions of Windows, filters that use the Windows Color System must check the operating system version before making WCS calls. On downlevel OS platforms, drivers must not suffer from major functionality problems (that is, they must not crash the system or expose a non-functional user interface).

Are the filters compatible across different versions of Windows?

They can be, depending on the implementation.

An IHV can develop a filter that can work in a pipeline, whether it is hosted by the spooler or the print processor. However, if the filter takes advantage of capabilities of a given version of the OS, then it would be version-dependent.

Does the new Metro print path support Postscript passthrough?

No. PS passthrough is not supported for MetroDrv-based drivers for two primary reasons:

MDDC (the DDI to Metro converter module) is currently designed to handle Metro graphical objects only; it builds an in memory tree of the GDI/DDI graphics primitives per page and then serializes them to Metro markup.
The inclusion of foreign content (PS or any other PDL pass-through) would have non-deterministic results on the output.

Within the MetroDrv model, raster and/or PDL generation is no longer a strictly sequential translation process as it is within the PSCRIPT driver. This means that a simplistic escape mechanism that relies on a fixed PS generation sequence is no longer viable. Within the new context, Metro and PostScript primitives and operations each rely on their own graphics state, and merging the two graphic states would be extremely difficult. Unless an application generates Metro markup directly, including the PS escapes, the complex interplay of graphical operations would make it nearly impossible to obtain the correct output.

Accomplishing PS passthrough differs for Win32 and WinFX applications:

PS passthrough for Win32 applications. Win32 applications that wish to inject PS should target existing Version 3 PostScript drivers.
PS passthrough for WinFX applications. Within the existing (Windows XP – Windows Server 2003) print infrastructure an atomic sequence of GDI drawing commands is captured within an intermediary EMF spool file which allows playback of the commands and sequential conversion into raster or PDL. Within the PSCRIPT driver this sequential nature allows interleaving of “escaped” PostScript commands with commands generated from the self-contained GDI drawing instructions.

Is there a filter communication API?

Yes. A filter communication API is planned for availability in Longhorn Beta 1 and will provide basic services to access the Metro spool file via a stream. Additional services are planned for Longhorn Beta 2 to provide richer access to the spool file content.

PrintTicket

Is PrintTicket the same as JobTicket?

Yes, with respect to Microsoft terminology. The Microsoft term JobTicket was changed to PrintTicket to avoid confusion with the term “Job Ticket” as used in the publishing industry.

Can the PrintTicket be modified on a page by page basis?

Yes. PrintTickets have a hierarchical structure that allows a flexible application of settings to pages and documents.

Does Microsoft provide a framework for applications to access or share private printer settings?

Yes. The Print Schema provides the framework for describing print capabilities in a XML-based format. Vendor extensions or private extensions to this public schema must conform to the Print Schema framework.

The Print Schema is published in the Microsoft WinFX™ Software Development Kit (SDK). Information about Print Schema is currently available at The Print Schema content is expected to be updated periodically, to facilitate publication of public extensions defined by Microsoft.