Supporting Metro for Printing Devices - 2

Supporting Metro for Printing Devices

Adrian Ford, CTO - Global Graphics

WinHEC 2005

Abstract

This paper provides information about supporting direct printing of Metro within the new printing architecture for Microsoft® Windows® with Microsoft WinFX™. Benefits of Metro printing are summarized and implementation options presented. Specific implementation routes are recommended along with examples of specific implementations using Global Graphics technology.

Contents

Introduction 3

Metro Benefits 3

Supporting Metro Printing 4

Device Native Consumption 4

Device Driver Native Consumption 4

Device Driver PDL Conversion 5

Metro as a PDL 5

Benefits of Metro as a PDL 5

Requirements for Device Native Consumption 5

Challenges of Supporting Metro Printing 6

Another PDL 6

Resource Usage 6

Core Technology 7

Global Graphics Metro Support 7

Windows Toolset 7

Global Graphics Products 7

About Global Graphics 8

Call to Action 8

Resources 8


Windows Hardware Engineering Conference

WinHEC Sponsors’ Disclaimer: The contents of this document have not been authored or confirmed by Microsoft or the WinHEC conference co-sponsors (hereinafter “WinHEC Sponsors”). Accordingly, the information contained in this document does not necessarily represent the views of the WinHEC Sponsors and the WinHEC Sponsors cannot make any representation concerning its accuracy. THE WinHEC SPONSORS MAKE NO WARRANTIES, EXPRESS OR IMPLIED, WITH RESPECT TO THIS INFORMATION.

Microsoft, Windows, and Windows NT are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners.

© 2005 Global Graphics Software Ltd. All rights reserved.

Introduction

This paper provides information for vendors looking to support the new Microsoft® Windows® printing system and the Metro format in their printing products. In particular, how the benefits that the new print architecture provides can be realized in product implementations.

Metro Benefits

Microsoft is introducing significant advances in the Windows printing system for Microsoft Windows codenamed “Longhorn,” including:

·  New print paths from the application to the printer.

·  An advanced print format.

·  Enhancements to the printer driver architecture.

The changes in the Windows printing subsystem are necessary to maintain complete compatibility and the highest print quality from new Microsoft WinFX™-based applications. In addition, these improvements are designed to improve the printing experience for users and create opportunities for Independent Hardware vendors (IHVs) to add value to their product offerings.

Among the benefits that the new architecture is expected to provide are:

·  Improved performance—aspects of the new print format and the efficiency in which job content is represented can provide improved printing performance.

·  Support for extended color spaces—the ability to support extended color information beyond the limited RGB support of the GDI-based print pipeline will provide enhanced color reproduction, particularly benefiting photo-printing applications.

·  Improved fidelity—providing an efficient printing pipeline for handling advanced graphics, such as transparency and smooth gradients.

·  Integrated document security—incorporating support for digital signatures that can be used in wider enterprise workflows.

·  Enhanced user experience—providing a new architecture to communicate print job intent and device capabilities to simplify the users interaction with the printing process.

The Metro format and the system built around the new spool file format comprise the foundation that enables these benefits. IHVs can use these technologies to develop innovative products that offer significant added value over existing devices. This will include:

·  Simplification of the printing process by utilizing PrintTicket/PrintCapabilities, based on the new Print Schema introduced in Longhorn, combined with native Metro consuming devices.

·  Advanced document capabilities by enabling printing devices to participate in wider document workflows.

·  Improved print quality when printing content authored in WinFX and Microsoft Win32® applications.

·  Improved performance by ensuring that the print pipeline can maintain the required throughput for the latest generation device.

Supporting Metro Printing

Currently, print devices do not support Metro. For end users to benefit from the advantages and enhanced features that Metro provides, vendors will need to enable support for Metro in their products. There are a number of routes that an IHV can use that vary in terms of ease of implementation and degree of improved printing experience. Generally, easier to implement options, although providing potentially faster and cheaper routes to market, do not enable the full range of user benefits.

The options to consider are:

·  Device Native Consumption

·  Device Driver Native Consumption

·  Device Driver PDL Conversion

The optimal implementation route will vary according to the device and the target market. For this reason, details of each option are outline in the following sections.

Device Native Consumption

Wherever possible, the recommended route for implementing support for Metro and the new print architecture is to implement native support for consuming Metro in the device. This is because the best printing experience is provided when information is retained in Metro format for as long as possible, without converting to an intermediate or device dependent form.

Ideally, direct native consumption is achieved by implementing support for Metro directly in the device using a raster image processor (RIP) to provide Metro native interpretation and rendering as part of a print controller. As described later in this paper; this route allows the benefits of the Metro format to be retained down to the device and ensures that the device can fully participate in wider Metro-based workflows.

Device Driver Native Consumption

The current printing architecture provides driver developers with the ability to rasterize the print stream. This is a widely used capability for driving devices where cost and performance are suitable for transmitting compressed raster data from the host to the device. Such devices have no need for an on-board controller necessary to interpret a page description language (PDL).

Conversion of the Metro print stream to raster data within a print driver is an obvious route to support raster driven devices. The print driver can interpret and render the Metro print stream and generate raster data optimized for the device. The limiting factor to host-based implementation is the bandwidth down to the device. Compression of the print data plays an important role in determining the types of devices for which host-based rasterization is suitable.

Device Driver Native Consumption may also be a suitable route for supporting Metro on existing devices that currently support alternative PDLs. Rather than updating the device controller immediately, an IHV may decide to provide a new print driver that sends wrapped raster to the device, either to provide a rapid implementation of Metro support or to specifically achieve higher quality on an existing installed base.

There are no operating system services to use in performing host-based rasterization. A vendor interested in this implementation option can either provide their own rendering engine or work in partnership with third parties such as Global Graphics for this functionality.

In addition to providing embedded RIPs capable of interpreting Metro, Global Graphics is working in partnership with other vendors, to provide industry with advanced Metro rendering technology that brings added flexibility and performance to the driver.

Device Driver PDL Conversion

Conversion of Metro content to an alternative PDL stream from within the Metro-based print driver, MetroDrv, is an option for devices that support an existing PDL. It has the disadvantage that, depending on the PDL, advanced Metro features such as improved print quality, may not be converted correctly. Often there may not be an equivalent capability within the target PDL.

Conversion to alternative PDLs is therefore not an optimal implementation route. In some specialized cases there may be a benefit in taking this approach, and IHVs should weigh the costs of performing the work themselves or through technology provided by third parties such as Global Graphics.

Metro as a PDL

Benefits of Metro as a PDL

Key benefits of treating Metro as a PDL include:

·  Richer printing from native applications with minimal developer effort. Applications written in WinFX will benefit from rich print capabilities without application developers needing to resort to pass-through mechanisms with the associated development overhead of directly writing out the print stream.

·  Richer graphical content and higher quality on the output device. By maintaining the print stream in Metro format right down to the device, the enhanced graphics model of Metro is maintained. For example, based on assumptions about the characteristics of the output device, conversion to an existing PDL will result in transparency information being flattened.

·  Maximum flexibility. Maintaining the Metro format means that late changes in the output device can be accommodated easily. The content of a Metro print stream is the same irrespective of the device, enabling changes between devices and clustering of multiple devices without the overheads associated with existing approaches. The combination of the Metro format and the PrintTicket capabilities, when combined with a native-Metro RIP means that you don't have to perform functions such as imposition for multiple (or N-UP) printing in the driver. An application can just add an N-UP flag in the PrintTicket and have the RIP impose content on the fly. This means you can make a late decision on how you want the content printed but, more importantly, you can make post publication changes to the document print options without having to revert to the originating application.

·  Greater efficiency. Maintaining data in the Metro format maintains efficiency in the print path and can boost performance.

Requirements for Device Native Consumption

To support Device Native Consumption and to therefore treat Metro as a full PDL, vendors need to architect printing systems that maintain information in the Metro format for as long as possible. This architecture minimizes conversion operations between formats and ensures that rendering to raster for the print engine is performed late in the workflow where it can be optimized for the device.

To implement Device Native Consumption architecture and maximize the benefits of a native Metro workflow, a vendor needs:

·  A Metro-based driver (MetroDrv) to advertise printer availability to the operating system and to applications.

·  Consume Metro natively in the device, using a native Metro RIP.

·  Make best use of implementation specific optimizations that Metro enables.

Challenges of Supporting Metro Printing

Both Metro and the print subsystem provide extension capabilities for vendors to add value to their products. To realize these benefits IHVs will need to provide devices that support Metro and can interoperate with the new print system. In providing devices with these capabilities there are a number of challenges that need to be addressed.

Another PDL

In the printing space, Metro can be consumed directly on a printer and thus represents another PDL that vendors support. Metro will not replace existing PDLs or the workflows that rely on them. Although Metro has significant advantages in many areas, there will continue to be a demand for, and in some areas advantages in using, existing PDLs.

Vendors will need solutions that provide broad support across PDL formats and that maximize the performance and functionality within their implementation. Within print devices, vendors will also need efficient implementations which maximize the sharing of resources between PDLs without compromising on performance or functionality.

Resource Usage

Metro provides support for a rich set of graphics primitives, including advanced graphics that other common PDLs do not support. A consequence is that devices that provide native support for Metro consumption may require additional local resources to process jobs, including more memory, increased processing power and in some cases access to mass storage.

For example, while the support for transparency within Metro enables richer content to be printed it also means that the consuming device needs additional resources to handle that transparency information. The implementation of transparency support may result in jobs that cannot be processed on the equivalent of today’s low end or entry level devices because they would lack sufficient resources to cope with complex transparency effects.

In addition it is expected that the use of transparencies in WinFX-based applications will become common because Avalon integrates transparencies and gradients as attributes on all graphics primitives, including text. The Metro format used within the print system is derived from the new Avalon graphics model and will natively convey these graphics effects to the printer. Metro printers will need to deal with more jobs containing richer job content than is currently the norm.

A key requirement for robust implementations will be the ability to support collaborative processing, where vendors can select from a scalable architecture that allows them to balance processing of complex graphical content and other advanced Metro features between a resource-rich host and an on-device controller.

Core Technology

IHVs often rely on strategic partners to provide core technology. This includes provision of PDL RIP technology. With a new format to support, vendors will need to decide whether to partner for new technology or to develop support for the format in house.

Increasingly, vendors are looking to assign resources to areas where they can add differentiation from competitive products. By partnering with a core provider of open technology, they can concentrate on developing product value rather than on re-implementing basic functionality. By working with key partners, IHVs can reduce their time to market and can implement strategies that ensure they have the correct product for the right market at the right time.

Global Graphics Metro Support

Global Graphics has been working with Microsoft and has been developing core technology to support the Metro format since 2003. As part of the project, Global Graphics has provided feedback into the Metro specification and has developed technology for the interpretation and rendering of Metro print streams. This technology will be provided, both as part of a print reference implementation to be used for evaluation and benchmarking in Microsoft-provided developer tools, and, in products for integration in solutions from Global Graphics partners.

Windows Toolset

Microsoft is committed to the widespread adoption of the Metro format, both on the Windows platform and beyond. The Metro format specification will be published and third party implementations of products for Metro creation, manipulation and consumption will emerge.