decision among driver property bag, devmode bag, PPD bag for v4 printer drivers RRS feed

  • Question

  • Hi

    I am developing a PPD based v4 printer driver and confused what guideline teaches us to choose that a property should be added to driver property bag OR devmode bag OR PPD?

    e.g which type is best suited for my below requirement:

    1) a property which is visible in UI (like a custom N-up or new property which doesn't exist in PPD files). My devmode should have this property and i should be able to set this in print ticket so that my Rendering filter can use this.

    2) a property which isn't visible in UI and i want to fetch set this into print ticket and later use in my rendering filter...

    I tried setting such property in devmode map but the convertDevModetoPrintTicket function always returns Blank value for thr property on debugging constrains js.

    devmode map sample:

    <?xml version="1.0" encoding="utf-8"?>

    <Properties xmlns="http://schemas.microsoft.com/windows/2011/08/printing/devmodemap">

      <Property Name="CustomProp">
        <String Length="32">4</String>


    function convertDevModeToPrintTicket(devModeProperties, scriptContext, printTicket) {

    if (!printTicket || !devModeProperties) {
    var nupStr = devModeProperties.getString("ADBENup");
    if (nupStr !== undefined) {
    // create a node in print ticket for the same


    Please point out the issue

    Thursday, July 19, 2012 12:53 PM


  • HJindal,

    Please see this snippet from the Developing v4 Print Drivers whitepaper (section 5.2):

    JavaScript constraints can be used to augment PrintCapabilties, validate PrintTickets and handle conversion of PrintTicket to DEVMODE and vice versa. However, JavaScript constraints have a few limitations. In particular:

    • Features/options added in using CompletePrintCapabilities, as well as constraints specified in validatePrintTicket are not shown in the desktop printer preferences dialog.
    • Features/options added in using CompletePrintCapabilities are not persisted into the public DEVMODE.
    • JavaScript constraints cannot access language resources from resource dlls to localize added features/options or parameters.

    As such, we recommend that JavaScript constraints are used only where appropriate. Features and options should be specified in the GPD or PPD where possible, and only complicated constraints should be represented in JavaScript.

    I also think its worth recapping the background on some of the technologies that are in play here.

    - PrintCapabilities documents need to represent every configurable option for a print job.

    - PrintTickets contain configured features, options and initialized parameters (ParameterInit) based on the information in the PrintCapabilities file. Metro style and XPS producers/consumers use the PrintTicket format instead of DEVMODE format, but PrintTickets need to convert losslessly to the DEVMODE in order to support legacy applications as well.

    - For any features, options or parameters that were added to the PrintCapabilities during completePrintCapabilities, these need to be persisted through DEVMODE->PT conversion and vice versa. The DEVMODE property bag is simply a container that we use to organize these items prior to persisting them in the private section of a DEVMODE structure.

    - The driver property bag is a read-only property bag, used for storing driver initialization data, for instance information about how to change PDL rendering behavior for this driver when using a custom rendering filter.



    Thursday, July 19, 2012 8:12 PM