Skip to main content
Device.Imaging Requirements

Updated: September 4, 2013

Device.Imaging.Printer.Base

 

Related Requirements

Device.Imaging.Printer.Base.applicationVerifier

Device.Imaging.Printer.Base.autoConfiguration

Device.Imaging.Printer.Base.configurationFiles

Device.Imaging.Printer.Base.connectionRecovery

Device.Imaging.Printer.Base.connectivityRobustness

Device.Imaging.Printer.Base.deviceCapabilities

Device.Imaging.Printer.Base.DocumentProperties

Device.Imaging.Printer.Base.driverCategory

Device.Imaging.Printer.Base.DriverEventFiles

Device.Imaging.Printer.Base.driverIsolation

Device.Imaging.Printer.Base.driverPackage

Device.Imaging.Printer.Base.driverStability

Device.Imaging.Printer.Base.faxModem

Device.Imaging.Printer.Base.faxTIA592

Device.Imaging.Printer.Base.faxV34

Device.Imaging.Printer.Base.GDLFile

Device.Imaging.Printer.Base.infFile

Device.Imaging.Printer.Base.jobCancellation

Device.Imaging.Printer.Base.metadata

Device.Imaging.Printer.Base.portMonitors

Device.Imaging.Printer.Base.PrinterExtension

Device.Imaging.Printer.Base.printerInterfaces

Device.Imaging.Printer.Base.printProcessor

Device.Imaging.Printer.Base.printRegions

Device.Imaging.Printer.Base.printTicket

Device.Imaging.Printer.Base.rendering

Device.Imaging.Printer.Base.TCPMon

Device.Imaging.Printer.Base.applicationVerifier

Printer driver components must comply with Application Verifier test criteria

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

All user-mode modules (.dll or .exe files) that are part of a printer driver must satisfy the criteria for Application Verifier tests. During driver testing, Application Verifier must be turned on for processes in which the driver modules execute. Application Verifier causes a break when Application Verifier detects an error.For printer drivers, common applications that must have Application Verifier turned on during testing are the following:

Splwow64.exe.

Spoolsv.exe. The process loads the rendering and UI portions of the driver during print testing.

Printfilterpipelinesvc.exe. The process loads the XPS rendering filters.

Any vendor-supplied applications that are part of the driver package, such as a custom status monitor. All portions of the driver package that is being signed must be robust.

Any tests that load driver modules for rendering or UI purposes. The tests commonly load UI and rendering modules

The following Application Verifier tests must be turned on for these processes during testing:

Heap

Locks

Handles

FilePaths

HighVersionLie

DFWChecksNonSetup

SecurityChecks

Printing

Design Notes: For information about Application Verifier, see http://go.microsoft.com/fwlink/?LinkId=58371.

Additional Information

 

Enforcement Date

Jul. 11, 2008

Device.Imaging.Printer.Base.autoConfiguration

Printers must support autoconfiguration

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

If the print device supports installable hardware options, such as memory, duplex units, or finisher units, the print driver must support the automatic update of the device configuration that is registered in the system. Device configuration includes print UIs that are associated with the driver and the result of platform APIs that report device configuration. Automatic updates must not require end-user intervention. A device that does not support installable hardware options automatically satisfies this requirement.Design Notes: The next version of Windows supports print driver autoconfiguration as defined in the Windows Driver Kit documentation. Although this requirement does not require autoconfiguration as defined in the Windows Driver Kit documentation, it is recommended.

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Printer.Base.configurationFiles

Version 4 print drivers provide valid configuration files.

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2012 x64

Description

Version 4 print drivers must provide valid configuration files.

These files must be syntactically valid according to the WDK.

When supported by the hardware, the configuration files must support the following features:

Orientation

Duplexing

Collate

N-Up

Paper Size

Paper Type

Tray

Quality

Color

Stapling

Hole-punches

Binding

GPD or PPD files should define the majority of the features and constraints represented in the driver's PrintCapabilities. JavaScript implementations should supplement these capabilities as needed.

JavaScript files must be syntactically valid according to the WDK.

They must be included in the driver package and cannot be in a subdirectory in the package.

They may be included only with version 4 print drivers

They should be designed securely and validate any untrusted data that will be parsed; this includes PrintCapabilities, PrintTicket, XPS Documents and Property Bags.

Additional Information

 

Enforcement Date

Jun. 01, 2009

Device.Imaging.Printer.Base.connectionRecovery

A printer must continue to operate normally if a computer becomes unavailable during a print job

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

If a computer becomes unavailable during a print job (for example, if the computer enters a sleep state or a network failure or other event interrupts the connection between the computer and printer), the printer must recover so that normal print operations can continue without user interaction.Design Notes: Specifically, the printer must not fail into a state in which the end user must manually power cycle the printer or clear a paper jam.The printer does not have to complete or continue the failed print job when the computer becomes available again. However, when computer-to-printer communication is restored, new print jobs must be able to spool and complete normally.

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Printer.Base.connectivityRobustness

A printer must recover from a surprise disconnect or reconnect

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

Printers must be able to recover from a surprise disconnect or reconnect from the host or the network, regardless of what the printer is doing at the time. The disconnect or reconnect must leave the system in a consistent state. The host must be able to submit the next print job. It is not acceptable to require a reboot of the host or the printer to re-establish communications. The existing job does not have to complete after the reconnect occurs.Design Notes: The printer does not have to finish or resume the current print job or any print jobs already in the printer's memory. The printer must behave normally after the computer reconnects. All print jobs must print normally after communication is restored.

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Printer.Base.deviceCapabilities

A printer must correctly support the DeviceCapabilities and GetDeviceCaps application programming interfaces (APIs) based on the guidelines in the Windows Driver Kit

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

This requirement clarifies the use of existing WLK tests. The Print Driver Device Capabilities test determines whether the printer driver returns the correct information for the DeviceCapabilities and GetDeviceCaps API calls.For more information, see http://msdn.microsoft.com/en-us/library/dd183552(v=vs.85).aspxand http://msdn.microsoft.com/en-us/library/ff566075(v=VS.85).aspx.

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Printer.Base.DocumentProperties

A driver must implement the DocumentProperty API according to the guidelines in the Windows Driver Kit

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

This test clarifies the use of existing WLK tests. The Document Properties test exercises a printer driver's user interface (UI). The test calls the DocumentProperties API by using various well-formed and malformed parameters. The test then validates the results. For more information, see http://msdn.microsoft.com/en-us/library/ff562200(v=vs.85).aspx.

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Printer.Base.driverCategory

Version 4 printer drivers must declare a valid printer category

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2012 x64

Description

All V4 printer drivers must declare a valid DriverCategory in their driver manifest.  V3 drivers are not required to declare a category.  If a V3 driver does declare a DriverCategory, it must be valid value.The DriverCategory must be one of the following values:

PrintFax.Printer

PrintFax.Fax

PrintFax.Printer.File

PrintFax.Printer.Virtual

PrintFax.Printer.Service

Additional Information

 

Enforcement Date

Jul. 10, 2008

Device.Imaging.Printer.Base.DriverEventFiles

Driver Event files are implemented according to the guidance in the WDK

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2012 x64

Description

Driver Event files are implemented according to the guidance in the WDK

Driver Event files are syntactically valid

Additional Information

 

Enforcement Date

Jun. 01, 2009

Device.Imaging.Printer.Base.driverIsolation

A printer driver that supports driver isolation must do so as defined in Windows Driver Kit

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

Print drivers must support driver isolation as defined in the Windows Driver Kit. With driver isolation, the printer executes print-related plug-ins such as drivers and print processors out of the spooler process. This increases print system stability.Design Notes: The Print Driver Sandboxing technical whitepaper is planned for a future date. Please send requests to prninfo@microsoft.com.

Additional Information

 

Enforcement Date

Jun. 01, 2009

Device.Imaging.Printer.Base.driverPackage

Print device drivers must support package installation infrastructure

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

 A driver that depends on other driver packages must declare that it is package-aware and use the new dependency definition keywords.Design Notes: Vendors must use the package installation infrastructure as defined in the Windows Driver Kit.

Additional Information

 

Enforcement Date

Jun. 01, 2007

Device.Imaging.Printer.Base.driverStability

Printer driver components do not cause a break in any process in which they are loaded

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

A driver must not cause a break in the spooler service (spoolsv.exe) or in any other process in which the driver's components are loaded. Breaks must not occur in the driver modules themselves or indirectly through leaving the process in an inconsistent state, such as by corrupting process memory.

Additional Information

 

Enforcement Date

Jun. 01, 2007

Device.Imaging.Printer.Base.faxModem

Fax modem successfully sets up a connection and transmits pages

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Description

A fax modem must meet the following requirements:The modem must be able to send and receive five faxes of 10 pages in various document formats. When a service shutdown or hibernate is requested, the modem must abort all ongoing calls (both send and receive).

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Printer.Base.faxTIA592

Fax Class 2.0 implementations must comply with the TIA-592 command set

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Description

If the device supports Fax Class 2.0, the fax must comply with the TIA-592 standard.

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Printer.Base.faxV34

Any Fax V.34 implementation must comply with ITU-T recommendation V.34

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Description

A fax that supports V.34 must adhere to International Telecommunications Union Telecommunication Standardization Sector (ITU-T) recommendation V.34: "A modem operating at data signaling rates of up to 33,600 bit/s for use on the general switched telephone network and on leased point-to-point 2-wire telephone-type circuits".

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Printer.Base.GDLFile

GDL files must use correct syntax according to the guidelines in the Windows Driver Kit

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

This requirement clarifies the use of existing WLK tests. The Generic Description Language (GDL) Correctness Test determines whether GDL files use correct syntax according to the WDK.For more information, see http://msdn.microsoft.com/en-us/library/ff549787(v=VS.85).aspx and http://msdn.microsoft.com/en-us/library/ff563355(v=VS.85).aspx.

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Printer.Base.infFile

INF files must use the correct syntax according to the guidelines in the Windows Driver Kit

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

This requirement clarifies the use of existing WLK tests.INFGate determines whether INF files and v4 manifest use correct syntax according to the WDK. Version 4 print drivers use version 4 INFs and manifest files. V4 driver INF must:

Define a PrinterDriverID for each driver in the INF to indicate when drivers are compatible for the sake of printer sharing

PrinterDriverID must be GUID

Set a DataFile as a GPD or PPD file

Use only the following DestinationDirs: DriverStore, 66000; or Color directory, 66003

Must specify a filter xml pipeline config file named *-pipelineconfig.xml, OR specify RequiredClass  in the v4 driver manifest

V4 driver manifest files must:

Define a PrinterDriverID for each driver in the manifest to indicate when drivers are compatible for the sake of printer sharing.

PrinterDriverID must be GUID

Set a DataFile as a GPD or PPD file

 V4 drivers must not:

Utilize any of the following INF directives ClassInstall32, ClassInstall32.Services, DDInstall.Services, DDInstall.HW, DDInstall.CoInstallers, DDInstall.FactDef, DDInstall.LogConfigOverride, DDInstall.Interfaces, InterfaceInstall32, DefaultInstall, DefaultInstall.Services, AddReg, DelReg, DelFiles, RenFiles, AddService, DelService, AddInterface, BitReg, LogConfig, UpdateInis, UpdateIniFields, or Ini2Reg.

Version 3 INF files must use correct syntax according to the WDK.For more information on v3 INF files, see http://msdn.microsoft.com/en-us/library/ff560902(v=VS.85).aspx and http://msdn.microsoft.com/en-us/library/ff563414(v=VS.85).aspx. 

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Printer.Base.jobCancellation

A printer must handle software problems or print job cancellations gracefully

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

If a driver encounters a software-related problem when the driver spools or de-spools a print job, the driver must ensure that jobs can successfully print in the future.Printers also must be able to handle a job being canceled at any time without wasting consumables, such as print media, or entering a state that requires human intervention to print.

Additional Information

 

Enforcement Date

Jul. 10, 2008

Device.Imaging.Printer.Base.metadata

Printer and MFP driver components must include an authored device metadata document

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

Devices that provide DeviceStage metadata that includes a photorealistic image of the device, company logo, and basic task information must do so correctly. Tasks must only appear when the tasks are available. For example, scanner tasks must not appear on a printer-only connection, and Internet tasks must not appear if the Internet is unavailable. Design Notes: More information available in the Windows SDK and in the WDK. Please send questions to prninfo@microsoft.com.

Additional Information

 

Enforcement Date

Jun. 01, 2009

Device.Imaging.Printer.Base.portMonitors

A v4 print driver must use an inbox provided port monitor.

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2012 x64

Description

Custom port monitors are not allowed for v4 printer drivers.  They must use an inbox provided port monitor. 

V3 printer driver, print processor, or language monitor may use a custom port monitor, but must be able to de-spool print jobs when the device is configured in a queue that uses any port monitor

Additional Information

 

Enforcement Date

Jun. 01, 2007

Device.Imaging.Printer.Base.PrinterExtension

Printer extensions are implemented according to the guidance in the WDK

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2012 x64

Description

Printer extensions are implemented according to the guidance in the WDK

They must run in the appropriate integrity level

They should be designed securely and validate any untrusted data that will be parsed; this includes PrintCapabilities, PrintTicket, XPS Documents and Property Bags.

They must not register system services on installation

They must register with the print system for any events they should be invoked for

They must communicate with the print system using the prescribed interfaces

Additional Information

 

Enforcement Date

Jun. 01, 2009

Device.Imaging.Printer.Base.printerInterfaces

A printer device must support at least one non-legacy interface

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

Printers and multi-function print (MFP) devices must be able to connect to the computer through a non-legacy interface such as Ethernet, USB, IEEE 1394, or Bluetooth. Printing devices may offer IEEE 1284 (parallel) ports in addition to a non-legacy connector.

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Printer.Base.printProcessor

Print processors must be implemented based on the guidelines in the Windows Driver Kit

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

This requirement clarifies the use of existing WLK tests. The Print Processor API test helps ensure that print processors are implemented based on WDK guidelines.All print processors must support the following endpoints:

OpenPrintProcessor

ClosePrintProcessor

ControlPrintProcessor

EnumPrintProcessorDatatypesW

PrintDocumentOnPrintProcessor

GetPrintProcessorCapabilities

For more information, seehttp://msdn.microsoft.com/en-us/library/ff566084(v=VS.85).aspx.

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Printer.Base.printRegions

A printer must support printable regions accurately

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

The printer must be able to print output for the entire area that appears in the printable region that the user can select in the Windows UI.Design Notes: Note that if the printer supports a "borderless" printing feature, this restriction may be relaxed to allow for devices whose printable region extends beyond the dimensions of the physical media sheet. In these cases, the printer must be able to print output to the extent of the page dimension.This test applies to all paper sizes that the printer physically supports. If the printer supports auto-scaling and the UI exposes additional paper sizes to the user that cannot be physically loaded into the printer, the printer must maintain correct aspect ratios during resizing. In this context, "auto-scaling" is any feature in the hardware or driver that changes the print job to fit on an available paper size without user interaction or warning.If the printer does not support printing on a physical medium that is at least 4" x 4" in size, the printer is exempt from this requirement.

Additional Information

 

Enforcement Date

Jun. 01, 2007

Device.Imaging.Printer.Base.printTicket

Printer driver supports PrintTicket/PrintCapabilities

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

Print devices must fully support the PrintTicket and PrintCapabilities objects. Depending on your print driver implementation, this may or may not require implementing certain PrintTicket or PrintCapabilities interfaces. For more information, see the WDK documentation. Printer drivers must support the public Print Schema element types for each keyword if the printer driver or print device includes the specified functionality. Printer drivers must also support the public Print Schema element types for each keyword if the appropriate functionality is present but non-configurable. The element types that the printer driver must support for each keyword include all such Features, Options, ParameterDef, ParameterRef, Property, and ScoredProperty that the public Print Schema definition contains. Printer drivers do not have to support public Print Schema keywords if the printer driver or print device does not include the specified functionality.Printer drivers must support the following basic Print Schema element types:

DocumentCollate

JobCopiesAllDocuments

JobDuplexAllDocumentsContiguously

PageColorManagement

PageImageableSize

PageMediaSize

PageMediaType

PageOrientation

PageOutputColor

PageResolution

PageICMRenderingIntent

One of the following: JobInputBin, DocumentInputBin, or PageInputBin

Additional Information

 

Enforcement Date

Jul. 12, 2008

Device.Imaging.Printer.Base.rendering

A printer must correctly render print jobs

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64, ARM (Windows RT)

Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

This requirement clarifies the use of the following existing WLK tests to ensure that printers correctly render print jobs:

Pgremlin/Pgremlin2

This test produces numerous pages of output that include shapes, gradient fills, alpha blends and some complex fonts. The test checks Device Driver Interface (DDI) calls that a driver can make.

WinFX Markup Content Rendering Test

The WinFX Markup Content Rendering test loads eight WinFX XAML files and produces output on the specified printer.

Photo Print Test

The Photo Print Test prints landscape- and portrait-oriented photos to exercise printer functionality.For more information about Pgremlin, seehttp://msdn.microsoft.com/en-us/library/ff566081(v=VS.85).aspx.For more information about Pgremlin2, seehttp://msdn.microsoft.com/en-us/library/ff566079(v=VS.85).aspx.For more information about the WinFX Markup Content Rendering Test,seehttp://msdn.microsoft.com/en-us/library/ff569275(v=VS.85).aspx.For more information about the Photo Print Test, see http://msdn.microsoft.com/en-us/library/ff565234(v=VS.85).aspx.

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Printer.Base.TCPMon

Network-connected printers that support Port 9100 printing with the Microsoft Standard Port Monitor (TCPMon) must provide rich status for the device

 

Target Feature

Device.Imaging.Printer.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

If the printer uses a network interface port connection and supports Port 9100 printing (raw printing) with the Microsoft Standard Port Monitor (TCPmon), it must also support Simple Network Management Protocol (SNMP), Host Resource Management Information Base (MIB), and Common Printer MIB, and Printer Port Monitor MIB 1.0 (IEEE-ISTO5107.1-2005) so that the operating system can provide rich status for the device.

Additional Information

 

Enforcement Date

Jun. 27, 2008

Device.Imaging.Printer.Cluster

 

Related Requirements

Device.Imaging.Printer.Cluster.cluster

Device.Imaging.Printer.Cluster.cluster

Print driver implements cluster requirements

 

Target Feature

Device.Imaging.Printer.Cluster

Applies to

Windows Server 2008 Release 2 x64

Description

Many printers may be hosted on clustered print servers. To work properly on a cluster, print drivers must:

Use only one print processor binary, defined in the INF

Implement InitializePrintMonitor2 on any custom port monitors used and access the registry only through the provided interface.

 Design Notes:  Print ProcessorPrint processor binaries must be a single file and be defined in the driver INF using the PrintProcessor directive.  Other print processor binaries may not migrate or work properly in cluster failover. Print processors may call into other DLLs if they are:

A system DLL

In the print processor's directory

A print driver file in the driver's directory

AND it gracefully handles cases where a print driver file no longer exists.

Port MonitorsThe InitializePrintMonitor2 interface provides the port monitor with rich information about the system environment (local-only, cluster-only, or both). It helps isolate the port monitor from potential compatibility or migration issues. Port monitors should not attempt to access the registry outside this interface.

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Printer.OXPS

 

Related Requirements

Device.Imaging.Printer.OXPS.OXPS

Device.Imaging.Printer.OXPS.OXPS

V4 drivers that support OpenXPS must be implemented according to the rules specified in the WDK.

 

Target Feature

Device.Imaging.Printer.OXPS

Applies to

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2012 x64

Description

For Windows 8, a correctly implemented version 4 print driver will satisfy the XPS requirements.  The v4 driver can support either MSXPS or Open XPS.V4 print drivers that support OpenXPS, either exclusively or in dual-format support mode with XPS , must satisfy the following requirements:

Driver manifest must specify either "XpsFormat=OpenXPS", "XpsFormat=OpenXPS, XPS" or "XpsFormat=XPS, OpenXPS" in the DriverRender section

The first filter must be able to consume OpenXPS document format when provided such by the print filter pipeline manager

All filters must conform to the rendering rules in the ECMA Open XML Paper Specification v. 1.0 (Ecma 388)

All filters must conform to the PrintTicket processing rules in the PrintSchema Specification 1.0.

The v4 driver filter pipeline must produce a PDL that the target print device can interpret.

Filters in the v4 driver pipeline supporting OpenXPS must NOT do the following:

Call into the Common Language Runtime (CLR) or the WinFX run-time components for any functionality.

Display user interface (UI) content.

OpenXPS supporting drivers must adhere to all other v4 rules.  Dual-format drivers must adhere to both OpenXPS and MSXPS requirements and successfully handle either format.

Additional Information

 

Enforcement Date

Jul. 12, 2008

Device.Imaging.Printer.USB

 

Related Requirements

Device.Imaging.Printer.USB.CompatID

Device.Imaging.Printer.USB.JSBidiExtender

Device.Imaging.Printer.USB.CompatID

Printers must implement a Compatible ID in their IEEE1284 string according to the rules specified in the WDK.

 

Target Feature

Device.Imaging.Printer.USB

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

Printers must implement a Compatible ID in their IEEE1284 string for devices that connect over USB and WSD using the Port Monitor MIB.The Compatible ID must indicate:

Manufacturer Name or Code

Device Class Description

Recommended:

Include PDL

any other relevant device class information

Example: Fabrikam_XPS_A3_laser

Devices that receive the Windows 7 logo before June 1,2012 are exempt from this requirement.Link to Compatible ID Whitepaper: http://msdn.microsoft.com/en-us/windows/hardware/gg463313.aspx

Additional Information

 

Enforcement Date

Jun. 01, 2012

Device.Imaging.Printer.USB.JSBidiExtender

USB JavaScript Bidi Extenders are implemented according to the guidance in the WDK

 

Target Feature

Device.Imaging.Printer.USB

Applies to

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2012 x64

Description

USB JavaScript Bidi Extenders are implemented according to the guidance in the WDK

They must be included in the driver package and cannot be in a subdirectory in the package.

They may only be included with version 4 print drivers.

They should be designed securely and validate any untrusted data that will be parsed.

They must be referenced in the v4 manifest files.

They must use syntactically valid JavaScript, implemented according to the WDK.

Additional Information

 

Enforcement Date

Jun. 01, 2009

Device.Imaging.Printer.WSD

 

Related Requirements

Device.Imaging.Printer.WSD.CompatID

Device.Imaging.Printer.WSD.Rally

Device.Imaging.Printer.WSD.WSPrint

Device.Imaging.Printer.WSD.CompatID

Printers must implement a Compatible ID in their IEEE1284 string according to the rules specified in the WDK.

 

Target Feature

Device.Imaging.Printer.WSD

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

Printers must implement a Compatible ID in their IEEE1284 string for devices that connect over USB and WSD using the Port Monitor MIB.The Compatible ID must indicate:

Manufacturer Name or Code

Device Class Description

Recommended:

Include PDL

any other relevant device class information

Example: Fabrikam_XPS_A3_laser

Devices that receive the Windows 7 logo before June 1,2012 are exempt from this requirement.Link to Compatible ID Whitepaper: http://msdn.microsoft.com/en-us/windows/hardware/gg463313.aspx

Additional Information

 

Enforcement Date

Jun. 01, 2012

Device.Imaging.Printer.WSD.Rally

Network-attached printers and MFPs must implement the Windows Rally Technologies

 

Target Feature

Device.Imaging.Printer.WSD

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

Network-connected printers, scanners, and MFPs that implement any of the following Windows Rally requirements must comply completely with the implemented requirement:

Connect-0098 (optional): Devices that implement 802.3 or 802.11 may implement the Link Layer Topology Discovery (LLTD) protocol. This requirement applies only if the device implements LLTD. LLTD implementation is not required.

Connect-0099 (required): A 802.11 network-enabled device that operates as a station must implement WCN-NET and meet basic 802.11 requirements.

Connect-0100 (required): A network-enabled device that implements Plug and Play Extensions (PnP-X) must comply with the specification.

IMAGING-0004 (required): A network-connected device must implement Windows network-connected Web Services for Devices (WSD) correctly for the device type.

Design Notes: For more information, see the PnP-X: Plug and Play Extensions for Windows specification at http://go.microsoft.com/fwlink/?LinkID=123172,

Additional Information

 

Enforcement Date

Jun. 01, 2008

Device.Imaging.Printer.WSD.WSPrint

Network-connected printers must implement Windows network-connected Web Services for Devices

 

Target Feature

Device.Imaging.Printer.WSD

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64, ARM (Windows RT)

Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

Printers or MFP devices must support the Device Profile for Web Services and the Print Web Development Partnership (WDP) by using the Microsoft WSD Port Monitor (WSDMon). The printer or MFP device must support the following events that the Print Service Definition includes:

PrinterElementsChangeEvent

PrinterStatusSummaryEvent

PrinterStatusConditionEvent

PrinterStatusConditionClearedEvent

JobStatusEvent

JobEndStateEvent

In addition, the printer or MFP device must support all required operations that Section 5, Table 2 of the Print Service Definition outlines. Design Notes: For more information, see the Print Service Definition 1.0 at  http://go.microsoft.com/fwlink/?LinkId=109841.

Additional Information

 

Enforcement Date

Jul. 12, 2008

Device.Imaging.Printer.XPS

 

Related Requirements

Device.Imaging.Printer.XPS.XPS

Device.Imaging.Printer.XPS.XPS

A printer must have a driver that correctly implements XPSDrv printer driver architecture

 

Target Feature

Device.Imaging.Printer.XPS

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

For Windows 8, a correctly implemented version 4 print driver will satisfy this requirement.  The v4 driver can support either MSXPS or Open XPS.V4 print drivers that support MSXPS, either exclusively or in dual-format support mode with Open XPS , must satisfy the following requirements:

Driver manifest must specify either "XpsFormat=OpenXPS", "XpsFormat=OpenXPS, XPS" or "XpsFormat=XPS, OpenXPS" in the DriverRender section

The first filter must be able to consume XPS document format when provided such by the print filter pipeline manager

All filters must conform to the rendering rules in the XML Paper Specification

All filters must conform to the PrintTicket processing rules in the PrintSchema Specification 1.0?

The v4 driver filter pipeline must produce a PDL that the target print device can interpret.

Filters in the v4 driver pipeline supporting XPS must NOT do the following:

Call into the Common Language Runtime (CLR) or the WinFX run-time components for any functionality.

Display user interface (UI) content.

XPS supporting drivers must adhere to all other v4 rules.  Dual-format drivers must adhere to both OpenXPS and MSXPS requirements and successfully handle either format.

For Windows 7, Windows Server 2008 R2 and later, a printer must have a driver that correctly implements XPSDrv printer driver architecture.  An XPSDrv driver is not required for Windows Vista Basic, and Windows Server 2008 and earlier. A v3 driver that implements the XPSDrv printer driver architecture must do the following:

Implement a Version 3 driver architecture configuration module. The configuration module must support PrintTicket and PrintCapabilities objects for all functionality.

Include a valid filter pipeline configuration file.

A driver that implements the XPSDrv printer driver architecture must not do the following:

Implement a GDI rendering module. Is this what we used to say?

Implement a print processor.

If the XPSDrv driver supports a print device that can consume the XPS Document format as a printer description language (PDL), no filters are required. Otherwise, or if the driver supplies filters, the driver must satisfy the following requirements:

The first filter in the XPSDrv driver filter pipeline must consume the XPS Document format.

The XPSDrv driver filter pipeline must produce a PDL that the target print device can interpret.

Filters in the XPSDrv driver filter pipeline must do the following:

Conform to the rendering rules in the XML Paper Specification.

Conform to the PrintTicket processing rules in the XML Paper Specification.

Filters in the XPSDrv driver filter pipeline must not do the following:

Call into the Common Language Runtime (CLR) or the WinFX run-time components for any functionality.

Display user interface (UI) content.

XPSDrv must fully support the PrintTicket and PrintCapabilities objects. XPSDrv drivers must also support the following additional keywords in the described under the printTicket requirement.

PageScaling

JobDigitalSignatureProcessing

PagePhotoPrintingIntent

PageOutputQuality

 

Additional Information

 

Enforcement Date

Jul. 12, 2008

Device.Imaging.Scanner.Base

 

Related Requirements

Device.Imaging.Scanner.Base.dataTransfer

Device.Imaging.Scanner.Base.driverInstallation

Device.Imaging.Scanner.Base.errorHandling

Device.Imaging.Scanner.Base.metadata

Device.Imaging.Scanner.Base.MFPmultiplePorts

Device.Imaging.Scanner.Base.RawFileFormat

Device.Imaging.Scanner.Base.scannerInterfaces

Device.Imaging.Scanner.Base.statusMessages

Device.Imaging.Scanner.Base.wia20

Device.Imaging.Scanner.Base.WIAArchitecture

Device.Imaging.Scanner.Base.WIAProperties

Device.Imaging.Scanner.Base.dataTransfer

WIA drivers must support specific data transfer implementations

 

Target Feature

Device.Imaging.Scanner.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64, ARM (Windows RT)

Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

Windows Image Acquisition (WIA) drivers must do the following:

Use only the Write, Seek, and SetSizeIStream methods during downloads.

Use only the Read, Seek, and StatIStream methods during uploads.

Send valid lPercentComplete values during calls to the IWiaMiniDrvTransferCallback::SendMessage<element>.  lPercentComplete must be between 0 and 100 inclusive.

Send correct ulTransferredBytes values during calls to IWiaMiniDrvTransferCallback::SendMessage.

Append new data to the end of streams that the IWiaMiniDrvTransferCallback::GetNextStream<element> receives if the streams are not empty.

Return success values from the IWia( SYLVIA PEARCE: Should this be IWia (as it is in other instances)?)  MiniDrv::drvAcquireItemData method ( SYLVIA PEARCE: If this isn't correct, please replace it with the correct element.)  when the driver calls IWiaMiniDrv::drvAcquireItemData by using good parameters in all supported formats.

Release their references to the application's IStream object before their IWiaMiniDrv::drvAcquireItemData methods return or call IWiaMiniDrvTransferCallback::GetNextStream.

Send one stream that contains a multi-page file during downloads by using all supported TYMED_MULTIPAGE_FILE formats.

Send one stream for each item during downloads by using all supported TYMED_FILE formats.

Return S_FALSE from IWiaMiniDrv::drvAcquireItemData if IWiaMiniDrvTransferCallback::SendMessage returns S_FALSE.

Continue to transfer any subsequent items during multi-item downloads after IWiaMiniDrvTransferCallback::GetNextStream returns WIA_STATUS_SKIP_ITEM.

Return S_OK from IWiaMiniDrv::drvAcquireItemData during single-item and multi-item downloads after the IWiaMiniDrvTransferCallback::GetNextStream returns WIA_STATUS_SKIP_ITEM for any item.

Abort transfer of all items after IWiaMiniDrvTransferCallback::GetNextStream returns S_FALSE.

Return from IWiaMiniDrv::drvAcquireItemData calls during canceled transfers in less time than during completed transfers.

Return a failure code from IWiaMiniDrv::drvAcquireItemData if IWiaMiniDrvTransferCallback::GetNextStream fails.

Return a standard COM failure code from IWiaMiniDrv::drvAcquireItemData if IWiaMiniDrvTransferCallback::GetNextStream returns a NULL stream pointer.

Return a failure code from IWiaMiniDrv::drvAcquireItemData if IWiaMiniDrvTransferCallback::SendMessage fails.

Successfully transfer items when an identical device is installed and when the identical device transfers an item simultaneously.

Return a failure code from IWiaMiniDrv::drvAcquireItemData if an IStream method fails.

Seek to the correct stream position after the driver begins the transfer or calls IWiaMiniDrvTransferCallback::GetNextStream or IWiaMiniDrvTransferCallback::SendMessage.

Function correctly if the WIA service terminates during a transfer and is then restarted, and a new transfer is requested.

Ignore calls to the drvNotifyPnPEvent<element> that contain WIA_EVENT_CANCEL_IO if a transfer is not occurring, and not crash or hang.

Successfully transfer items after a valid WIA_IPA_TYMED property value is written by using a signed or unsigned variant type.

WIA drivers must not do the following:

Call a method of an application's IStream object other than the IUnknown::Release method after an application's transfer callback returns S_FALSE, WIA_STATUS_SKIP_ITEM, or an error.

Call a method of an application's IStream object other than the IUnknown::Release method after the driver's IWiaMiniDrv::drvAcquireItemData method returns or calls IWiaMiniDrvTransferCallback::GetNextStream during a multi-item transfer.

Call IWiaMiniDrvTransferCallback::SendMessage by using WIA_TRANSFER_MSG_END_OF_STREAM and WIA_TRANSFER_MSG_END_OF_TRANSFER messages.

Call IWiaMiniDrvTransferCallback::SendMessage or IWiaMiniDrvTransferCallback::GetNextStream after IWiaMiniDrvTransferCallback::SendMessage returns S_FALSE or an error.

Crash or hang if a device requests an upload by using an invalid or empty stream.

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Scanner.Base.driverInstallation

A WIA driver must be installed for scanners and MFPs

 

Target Feature

Device.Imaging.Scanner.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

In cases in which a scanner or MFP that has scanning functionality initiates a plug and play installation event, a WIA driver must be installed. On a software-first installation for this device, a WIA driver must be staged to the driver store so that plug and play installations are successful. This requirement does not prevent the manufacturer from installing other software, such as a TWAIN data source.

Additional Information

 

Enforcement Date

Jun. 01, 2009

Device.Imaging.Scanner.Base.errorHandling

WIA drivers that support error handling must comply with specified error handling implementations

 

Target Feature

Device.Imaging.Scanner.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

Error handling in WIA drivers must comply with the following requirements:

IWiaErrorHandler::GetStatusDescription methods must return S_OK or WIA_STATUS_NOT_HANDLED when the driver calls the methods by using good parameters.

IWiaErrorHandler::ReportStatus and IWiaErrorHandler::GetStatusDescription methods must return a standard COM failure code if the driver calls the methods by using a NULL pWiaItem2 parameter.

WIA drivers must:

Cancel transfers and return S_FALSE when IWiaErrorHandler::ReportStatus is called by using a device status message and returns S_FALSE.

Cancel transfers and return a standard COM failure code when IWiaErrorHandler::ReportStatus is called by using a device status message and returns a failure code.

WIA drivers must not:

Call IWiaMiniDrvTransferCallback::SendMessage by using WIA_STATUS_CLEAR messages.

Call ReportStatus by using failure device status messages when the driver calls IWiaMiniDrv::drvAcquireItemData by using good parameters.

IWiaErrorHandler::ReportStatus methods must:

Return only S_OK or WIA_STATUS_NOT_HANDLED when called by using good parameters and without user input.

Return S_OK when called by using good parameters and without user input when a device status message is sent that is identical to a message that an active modeless window handles.

Return a standard COM failure code when called by using good parameters and without user input when a modeless error handler window is open and a device status message is sent that is not identical to the message that the existing window handles.

Return S_OK when called by using a WIA_STATUS_CLEAR message while an error handler is either active or inactive.

IWiaErrorHandler::ReportStatus methods must not:

Create or remove any windows when called by using good parameters and without user input when a device status message is sent that is identical to a message that an active modeless window handles.

IWIA driver error handlers must:

Return without user input when IWiaErrorHandler::ReportStatus is called by using a success device status message.

Consistently choose whether to handle specific device status messages for each item category. For example, a flatbed item may not only sometimes handle the WIA_STATUS_WARMING_UP message.

Create modeless windows when IWiaErrorHandler::ReportStatus returns S_OK after IWiaErrorHandler::ReportStatus is called by using a success device status message.

Remove their active modeless windows when IWiaErrorHandler::ReportStatus is called by using a WIA_STATUS_CLEAR message.

Create modal windows when IWiaErrorHandler::ReportStatus returns S_OK after IWiaErrorHandler::ReportStatus is called by using a failure device status message.

Return a valid pbstrDescription value when IWiaErrorHandler::GetStatusDescription succeeds and does not return WIA_STATUS_NOT_HANDLED.

Return S_OK and a valid pbstrDescription value when IWiaErrorHandler::GetStatusDescription is called by using good parameters and a custom device status message that the driver sent during a transfer.

Return a standard COM failure code when IWiaErrorHandler::GetStatusDescription is called by using a NULL pbstrDescription parameter.

IWIA driver error handlers must not:

Return without user input when IWiaErrorHandler::ReportStatus is called by using a failure device status message and does not return WIA_STATUS_NOT_HANDLED.

Create windows when IWiaErrorHandler::ReportStatus returns WIA_STATUS_NOT_HANDLED.

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Scanner.Base.metadata

Scanner and MFP driver components must include an authored device metadata document

 

Target Feature

Device.Imaging.Scanner.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

Devices that provide DeviceStage metadata must do so correctly. The metadata must include a photorealistic image of the device, the company logo, and basic task information.Tasks must only appear when the tasks are available. For example, scanner tasks must not appear on a printer-only connection. Internet tasks must not appear if the Internet is unavailable.

Additional Information

 

Enforcement Date

Jun. 01, 2009

Device.Imaging.Scanner.Base.MFPmultiplePorts

MFP devices that have multiple identical ports must expose the same functionality on all ports

 

Target Feature

Device.Imaging.Scanner.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

If an MFP device has identical multiple ports, the device must expose identical functionality on each port. For example, if one USB port supports print and scan functionality, all other USB ports must support print and scan functionality. This requirement does not extend to bandwidth concerns (that is, a device can have a USB 1.1 port and a USB 2.0 port). All other functionality must be exposed on both ports.Telephone jacks for fax functionality can behave differently to support line-in and line-out telephony connections.

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Scanner.Base.RawFileFormat

A scanning device that supports the WIA Raw Transfer Image file format must implement it correctly

 

Target Feature

Device.Imaging.Scanner.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

Devices that support WIA Raw Transfer Image File must support transferring data in all supported WIA_IPA_DATATYPE, WIA_IPA_DEPTH and WIA_COMPRESSION_NONE modes in the WIA Raw Format (WIA_IPA_FORMAT set to WiaImgFmt_RAW, WIA_IPA_TYMED set to TYMED_FILE). In other words the uncompressed variant (WIA_RAW_HEADER::Compression set to WIA_COMPRESSION_NONE) is required. 

Additional Information

 

Enforcement Date

Jun. 26, 2013

Device.Imaging.Scanner.Base.scannerInterfaces

A scanning device must support at least one non-legacy interface

 

Target Feature

Device.Imaging.Scanner.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

Scanners and MFP devices must be able to connect to the computer through a non-legacy interface such as Ethernet, USB, IEEE 1394, or Bluetooth.

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Scanner.Base.statusMessages

Scanning device sends device status messages correctly

 

Target Feature

Device.Imaging.Scanner.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

A scanning device that sends device status messages must do so correctly. The device must also implement the error handler correctly if the device implements an error handler.Design Notes: For more information, see the Windows Driver Kit content on IWiaErrorHandler at http://msdn.microsoft.com/en-us/library/ff543907.aspAlternatively, send an e-mail message to wiainfo@microsoft.com.

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Scanner.Base.wia20

Scanners and multi-function printers that have scanning ability must implement the WIA 2.0 driver architecture according to the Windows Driver Kit guidelines

 

Target Feature

Device.Imaging.Scanner.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

Scanners and multi-function printers that have scanning ability must implement the WIA 2.0 driver architecture according to the guidelines in the Windows Driver Kit. Scanners support stream-based image transfers. In stream-based transfers, the application gives WIA the stream to use, and then the driver reads or writes to the stream. The stream may be a file stream, a memory stream, or any other type of stream. The stream is transparent to the driver. Using streams also provides easy integration with the image processing filter. This helps prevent complications that occur because of the destination type (memory or file).Scanners need to correctly implement the Windows WIA Scanner Item Architecture for flatbed, ADF, and film scanners and scanners that have storage. The Windows Driver Kit reference documents and tools outline the WIA scanner item architecture. Device manufacturers must implement WIA support as described in the Windows Driver Kit.Design Notes: WIA 2.0 enables new stream-based transfer models and certain extensions that include an image-processing filter, a segmentation filter, and error handling. For more information about WIA 2.0, see "Introduction to WIA 2.0" at http://www.microsoft.com/whdc/device/stillimage/WIA20-intro.mspx and "What's new in WIA 2.0" at http://msdn.microsoft.com/en-us/library/ms630379(VS.85).aspx.

Additional Information

 

Enforcement Date

Jun. 01, 2010

Device.Imaging.Scanner.Base.WIAArchitecture

A scanner device driver must implement WIA driver architecture

 

Target Feature

Device.Imaging.Scanner.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

Scanner device drivers must support still image devices under WIA architecture or ISO/PRF (formerly PIMA) 15740. The scanner vendor must provide a WIA driver. A WIA driver is required for all local busses on which a scanner enumerates to Windows. If the device supports network-based scanning using WS-Scan or Distributed Scan Management, the device must do so as outlined in those requirements.Design Notes: An optimal user experience is seamless integration of the imaging peripheral with the Windows environment. The operating system detects hot-pluggable WIA devices such as digital cameras, providing a seamless interface with the device. For persistent-connection devices, such as scanners, implementation of device events through buttons and sensors delivers this functionality after initial installation. In addition to WIA, scanners can optionally support TWAIN.See the Windows Driver Kit, "Still Image Drivers."

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Scanner.Base.WIAProperties

Scanners must implement support for all required WIA properties and property values

 

Target Feature

Device.Imaging.Scanner.Base

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

The Windows Driver Kit (WDK) reference documents and tools outline the properties and property values for WIA. Scanners must implement WIA as described in the WDK.

Additional Information

 

Enforcement Date

Jun. 01, 2006

Device.Imaging.Scanner.DistributedScanManagement

 

Related Requirements

Device.Imaging.Scanner.DistributedScanManagement.DistributedScanManagement

Device.Imaging.Scanner.DistributedScanManagement.DistributedScanManagement

A scanner that supports the Distributed Scan Management protocols must implement the protocols correctly

 

Target Feature

Device.Imaging.Scanner.DistributedScanManagement

Applies to

Windows Server 2012 R2 x64

Windows Server 2008 Release 2 x64

Windows Server 2012 x64

Description

Any device that interacts with Windows Server Active Directory and a Windows Server scan server that implements the Distributed Scan Management Web service protocols must do so correctly.

Additional Information

 

Enforcement Date

Jun. 01, 2009

Device.Imaging.Scanner.WSD

 

Related Requirements

Device.Imaging.Scanner.WSD.Rally

Device.Imaging.Scanner.WSD.WSScan

Device.Imaging.Scanner.WSD.Rally

Network-attached scanners and MFPs must implement the Windows Rally Technologies

 

Target Feature

Device.Imaging.Scanner.WSD

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64

Windows 8.1 Client x86, x64

Description

Network-connected scanners and MFPs that implement any of the following Windows Rally requirements must comply with the implemented requirement completely.

Connect-0098 (optional): Devices that implement 802.3 or 802.11 may implement the Link Layer Topology Discovery (LLTD) protocol. This applies only if the device implements LLTD. LLTD implementation is not required.

Connect-0099 (required): An 802.11 network-enabled device that operates as a station must implement WCN-NET and meet basic 802.11 requirements.

Connect-0100 (required): A network-enabled device that implements Plug and Play Extensions (PnP-X) must comply with the specification.

IMAGING-0004 (required): Network-connected devices must implement Windows network-connected Web Services for Devices (WSD) correctly for their device type.

Design Notes: For more information, see the PnP-X: Plug and Play Extensions for Windows Specification at http://go.microsoft.com/fwlink/?LinkID=123172

Additional Information

 

Enforcement Date

Jun. 01, 2008

Device.Imaging.Scanner.WSD.WSScan

Scanners that have a network connection must implement WS-Scan protocol

 

Target Feature

Device.Imaging.Scanner.WSD

Applies to

Windows 7 Client x86, x64

Windows 8 Client x86, x64, ARM (Windows RT)

Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)

Description

This requirement applies to scanners or multifunction printers that have scanning ability, connect to the network, and have a physical scan button on the device. These scanners or multifunction printers must implement the following WS-Scan protocol requirements as outlined in the WS-Scan specification v1.0:

The device must correctly implement all events and operations that the specification defines.

The device must support the ScanAvailableEvent so that users can initiate a scan from the scanner and push the document to a scanning application.

The device must support the Microsoft WSD scan class driver for all device features that WS-Scan exposes.

If the device has ADF and plate scanning, the device must support those media over WS-Scan.

For more information, see "Implementing Web Services on Devices for Printing and Scanning" at http://www.microsoft.com/whdc/connect/rally/wsdspecs.mspx.

Additional Information

 

Enforcement Date

Jun. 01, 2011