Device.Imaging Requirements
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 https://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 https://msdn.microsoft.com/library/dd183552(v=vs.85).aspxand https://msdn.microsoft.com/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 https://msdn.microsoft.com/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 https://msdn.microsoft.com/library/ff549787(v=VS.85).aspx and https://msdn.microsoft.com/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 https://msdn.microsoft.com/library/ff560902(v=VS.85).aspx and https://msdn.microsoft.com/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, seehttps://msdn.microsoft.com/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, seehttps://msdn.microsoft.com/library/ff566081(v=VS.85).aspx.For more information about Pgremlin2, seehttps://msdn.microsoft.com/library/ff566079(v=VS.85).aspx.For more information about the WinFX Markup Content Rendering Test,seehttps://msdn.microsoft.com/library/ff569275(v=VS.85).aspx.For more information about the Photo Print Test, see https://msdn.microsoft.com/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: https://msdn.microsoft.com/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: https://msdn.microsoft.com/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 https://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 https://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 https://msdn.microsoft.com/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 https://www.microsoft.com/whdc/device/stillimage/WIA20-intro.mspx and "What's new in WIA 2.0" at https://msdn.microsoft.com/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 https://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 https://www.microsoft.com/whdc/connect/rally/wsdspecs.mspx.
Additional Information
| Enforcement Date |
Jun. 01, 2011 |