MXDW and Image Content


A question was asked recently on an internal list about why the image content in XPS files generated by MXDW (that’s the Microsoft XPS Document Writer) can differ — sometimes images are stored as JPEGs and other times as PNGs (and, although not asked on this occasion, you can get TIFF and WM Photo/HD Photo too).

So, why’s that then?

As with many interesting questions, they turn out to be interesting less because of the question and more because the answer is more complex than you would assume. In this case there’s possibly three four different mechanisms at work.

  1. Like real printers MXDW has a properties dialog that can be accessed from the print dialog or from the printers control panel. One of the properties that can be set is the image compression option (it’s under Document Options in the Advanced Options dialog). There are four options, JPEG with three levels of compression, and PNG, and depending on how this is configured (IIRC the default is JPEG medium) you’ll get different image formats in the output XPS file, except that…
  2. Like other printer drivers, MXDW supports an application-level capability to pass through JPEG or PNG image data. By default, a driver receives GDI bitmap image data from an application, but if the original content is JPEG or PNG, and if the driver supports this capability, an application can pass-through the JPEG or PNG encoded image data. This can have benefits in terms of a more efficient spool file (and resulting PDL stream) and, depending on the destination, can also provide slightly better quality by avoiding re-encoding of JPEG compressed images. Drivers that support this capability implement the CHECKJPEGFORMAT and CHECKPNGFORMAT escapes, and applications that are aware of these escapes can query the driver for their support and then send JPEG and PNG data directly. In the case of MXDW, an application that passes through JPEG or PNG data in this way will override options set in (1).
  3. Applications can also override the same MXDW image settings exposed in the MXDW UI and explained in (1) above. This is done using the Print Ticket and Print Capabilities part of Print Schema (Print Schema? No time to explain now, but head over to Ben’s blog for the scoop) which can be used to set a private MXDW keyword — JobImageType — to control image format and compression.
  4. MXDW also enables applications to generate XPS mark-up directly. In normal operation, MXDW operates by converting GDI/DDI calls that the application makes through to the print subsystem into XPS mark-up and resources. However, an XPS-aware application can generate XPS mark-up directly, bypassing the conversion step. This is done using the MXDC_ESCAPE to pass through XPS mark-up for each fixed page, image, font, thumbnail and profile resources, and print tickets. The application can use GETTECHNOLOGY to query for whether the driver is an XPSDrv driver. This mechanism enables applications to have full control over the XPS content, and, as an example, is the mechanism that Windows Photo Gallery uses to pass WM Photo/HD Photo image data through to MXDW and other XPSDrv-based drivers.

Clear?

I hope so 🙂

Footnote: MXDW is part of Windows Vista (just take a look in the printers control panel) and is also included in .Net Framework 3.0 and the XPS Essentials Pack which you can install on Windows XP and Windows Server 2003.

Comments (1)

  1. Adrian Ford says:

    In a previous post I wrote about controlling compression for the Microsoft XPS Document Writer. Brian

Skip to main content