Click here to Skip to main content
15,884,298 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
Hello, having an issue with a V4 printer driver, and not finding what I need in the Microsoft docs. Hoping someone here can shed some light on this.

I'm using VS2019 (16.11.12) with WDK 10 (10.0.19041). My task is to create a 64-bit V4 PostScript printer driver. I started with the "Printer Driver V4" project template (configured as Debug x64). I made the necessary updates to the default PPD, and INF, and driver properties, and built my driver. Build was fine. I installed it. I printed the Windows Test Page and ran it through my PostScript interpreter. All seems normal. My PPD feature additions (*OpenUI) show up under "Printer Features" in the driver UI tree view as expected. In other words, it all appears good.

I then tried printing a test image from Illustrator CS5. The test image is one I created; it's a CMYK image. What I discovered, when I attempted to print it, was that Illustrator would not allow me to select "Let PostScript printer determine colors" and would only allow me to select an RGB ICC profile for the Printer Profile. In other words, Illustrator sees the driver as only supporting RGB, which is odd because my PPD includes the line "*DefaultColorSpace: CMYK"

So, I went back to my project and, on a whim, changed the "ClassVer=" line in the INF from 4.0 to 3.0. I rebuilt the driver, uninstalled the previous one, reinstalled the new build, and tested it again. This time, Illustrator allowed me to select "printer determines color" and allowed me to select a CMYK printer profile. Illustrator sees the V3 driver as CMYK, but the V4 driver as RGB. Other than that, the UI, the list of PostScript features, all appear the same.

The only thing I changed in my project was the driver version in the INF, from 4 to 3. I tried it again, switching back to "ClassVer=4.0" and, as before Illustrator saw the driver as an RGB device. Switched to "ClassVer=3.0" and Illustrator saw it as CMYK. What the heck?

In both cases, my PPD includes the line "*MSIsXPSDriver: True" and, as I said, "*DefaultColorSpace: CMYK" and, in my PipelineConfig file is the filter reference to MSxpsPS.dll (and nothing else).

So my question is two-fold: first, why is V4 defaulting to an RGB workflow? That makes no sense to me. XPS supports RGB and CMYK (as well as N-color and spot colors). PostScript as well. My understanding is that MSxpsPS.dll simply translates between XPS and PostScript, so why ignore the DefaultColorSpace line in the PPD and default to RGB? And, more important, how do I change this default behavior?

Clearly, my PPD is being parsed because my other *OpenUI settings are showing up in the driver UI. But *DefaultColorSpace is not affecting the behavior of MSxpsPS. Is there some other way to configure MSxpsPS, if not in the PPD? Or, are there other MSxpsPS-specific keywords for the PPD (such as *MSIsXPSDriver and *MSXPSMaxCopies)?

As an aside, there is also something else I noticed. The V4 Windows test page was 122K in size, whereas the V3 Windows test page was 4,486K (I'm talking about the test print you print at the end of the Windows driver install wizard). I tested both in Acrobat Distiller, and both produced nearly identical results. The V4 file claims to have been made by MSxpsPS, whereas the V3 file claims to have been made by PScript5 ver. 5.2.2. But, I'm unsure how to account for the significant size difference. Downloaded fonts, maybe?

Anyway, this forced RGB workflow issue appears to be specific to MSxpsPS.dll, and clearly something I'm doing wrong or missing in terms of configuring the behavior of MSxpsPS. So my question is, how do I alter this default behavior? And, are there other MSxpsPS behaviors that can be controlled?

What I have tried:

I've read through Microsoft's V4 printer driver-related documentation for WDK 10, and I've gone through all the sample code on GitHub related to printer drivers, specifically the sample V4 code and anything (V3 and V4) related to PostScript drivers. The entire project consists of the INF, the PPD, the manifest, and the PipelineConfig. There are no build warnings or messages coming up, so I can only assume I'm missing something in configuring the behavior of MSxpsPS. Any suggestions would be most appreciated. Thanks!
Updated 1-Sep-22 13:59pm
[no name] 31-Aug-22 16:03pm    
Are you sure that your issue isn't being caused by Adobe Illustrator CS5? Have you tried to reproduce the issue with a test printing application?
CassinianSoftware 31-Aug-22 16:41pm    
Good question. The "Windows Printer Test Page" that is printed when the "Print Test Page" button is clicked at the end of the driver install wizard (or from the driver properties dialog) generates a PostScript file that appears to have its color encoding as RGB. As far as Illustrator being the problem, I'm not sure how I would verify that. Photoshop exhibits exactly the same behavior. If the driver is built with ClassVer=3.0 (V3), it's seen as a CMYK device in Illustrator (and Photoshop). If it's built with ClassVer=4.0 (V4), it's seen as an RGB device. The only difference I can see is that, as a V3 driver, PScript5 is generating the PostScript output. Whereas, as a V4 driver, MSxpsPS is generating the PostScript. The project template upon which this project is based is the "Printer Driver V4" template from VS2019 (with WDK 10). I'm not sure how I can fault Illustrator (or Photoshop) since they both work as expected with the V3 variant, but not the V4 variant. To me, this seems to suggest the issue is specific to MSxpsPS.
[no name] 31-Aug-22 17:20pm    

Adobe Illustrator CS5 was released back in 2010, I'm just suggesting that you use one of the Microsoft samples to debug the issue and eliminate third-party code.

I don't know what would cause the issue you are describing. Are you using the correct manifest?
CassinianSoftware 31-Aug-22 17:58pm    
Yes, that is the manifest I'm using.

With respect to using "one of the Microsoft samples to debug the issue," I'm not sure what you're referring to. The V4 driver template is from Microsoft; I've not added any third-party code. I could acquire a current version of Adobe Illustrator for testing, but I'm not sure what you mean by using a Microsoft sample to debug. Can you elaborate?

I'm using CS5 for testing because I have it available, and because it supports a CMYK workflow for printing. I've not encountered an issue before with CS5 in terms of driver incompatibility, but I suppose I cannot rule it out. I could write my own testbed, but then that opens an interesting question with respect to application compatibility with a V4 driver. Your assertion is that an older application, such as CS5, could be incompatible with the V4 driver framework. That would be worth knowing.

In the meantime, I will test further with the latest Adobe product to see if I can isolate this to a driver incompatibility issue. Thanks.
[no name] 1-Sep-22 12:59pm    

Took a fresh look at your problem this morning and I think I know what the problem is. I think you are missing the v4 Print Capabilities XML document.

For your v4 driver you will need to add the following Capability:

1 solution

I don't think the QA comments supports XML so I'll put it down here. As far as I can tell your Print Capabilities needs something like this:

	<PwgRasterDocumentType psf2:PageOutputColor="psk:Color">black_8</PwgRasterDocumentType>
	<PwgRasterDocumentType psf2:PageOutputColor="psk:Color">Srgb_8</PwgRasterDocumentType>
	<PwgRasterDocumentType psf2:PageOutputColor="psk:Color">cmyk_8</PwgRasterDocumentType>
	<PwgRasterDocumentType psf2:PageOutputColor="psk:Color">adobe-rgb_8</PwgRasterDocumentType>

Just wanted to mention that these are sample values. Since you are the one writing the device driver you will need to populate the capabilities based on your hardware.

As you already know the Printer Working Group[^] maintains those. The IANA maintains[^] the IPP values.

Update 2:
There is a sample v4 printer driver manifest at the bottom of this page: V4 Driver Manifest[^] which shows how to package the capabilities xml with your driver.
Share this answer

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900