Microsoft XPS Document Converter (MXDC) is the core component for performing conversion of GDI primitives to equivalent XPS mark-up. MXDC is used for generating XPS documents in Microsoft XPS Document Writer (MXDW) and XPS printing using XPSDrv based printers when the application being used does not support XPS directly. In Windows 7 we have made investments in MXDC to improve output fidelity of the XPS documents and improve its performance. In this blog post, I will provide an overview of the improvements we have made in MXDC.a. Enhancing GDI ROP (Raster Operations) SupportXPS is generally a superset of GDI. XPS supports many graphical primitives that go beyond what is possible in GDI, but in one case XPS doesn't support a GDI concept: that case is ROPs. ROPs are binary bitwise operations (AND, OR, XOR and NOT) performed on a source-surface, destination-surface and a pattern object. ROPs have been historically used to support transparency and masking in GDI applications because GDI did not have the concept of transparency and alpha channel. GDI+ support transparency and does not require ROPs. Nevertheless applications like IE, Word, PowerPoint and many third-party applications continue to use ROPs.MXDC generates equivalent XPS markup for regions containing ROP patterns when it converts GDI data to XPS content. For example, ROP patterns that generate transparent effects are converted to transparent XPS elements using the opacity attribute. In the previous release, MXDC supported a subset of ROP operations, hence documents converted using MXDC could have fidelity problems when certain kind of ROPs, or combinations of ROPs were used. Some examples of the fidelity problems are illustrated by comparing Fig 1 and Fig 2.
In Windows 7, we have made enhancements to MXDC to address these fidelity problems and provide support for the full set of GDI ROPs. Fig 3 shows an image taken from XPS document generated in Windows 7.As mentioned above, MXDC detects the areas where ROP commands are applied and converts them into equivalent XPS markup. For certain cases where we don't have direct support, MXDC can now fall back on rasterizing content. This ensures the fidelity of the document during conversion. The flip side of rasterization is that it increases the size of the output. However, tests on thousands of documents have shown that the average increase in size of the output file is small and a reasonable tradeoff for preserving the fidelity of the document.b. DiscardControlThe DiscardControl part, defined in Sec 10.1.4.1 of v1.0 of the XPS Specification, enables consumers with limited resources to more efficiently manage how they process complex XPS content. The DiscardControl part specifies to the XPS consumer which shared resources may be discarded because they are no longer used in later pages of the document. Content created by MXDC in Windows7 includes the DiscardControl part with information on subsetted fonts that are embedded in the output XPS Package. This will improve performance because XPS consumers can selectively discard resources and free up memory.c. Additional property for rotation in MXDCGetPdevAdjustmentMXDCGetPDEVAdjustment is a function implemented by a Printer Interface DLL and supplies printer configuration data for the MXDC. This configuration data comes in the form of a property bag that contains imageable area, image compression type and dots per inch (dpi) resolution. In Win7 we have extended this property bag to include information about landscape rotation. This allows printer drivers to specify the type of rotation (counterclockwise-90, counterclockwise-270 etc) to MXDC.d. Reducing file size by embedding single copy of non-subsettable fontsMXDC subsets fonts to keep the size of XPS content to a minimum. In some cases, when font licensing restrictions prohibit subsetting, MXDC embeds the entire font in the XPS Package. In previous version of MXDC, when interleaving is enabled and the font cannot be subset, multiple copies of font were embedded in the package. In Windows-7 we have changed this to embed non-subsettable fonts only once, thereby reducing the spool file size.With these enhancements, MXDC provides full fidelity for XPSDrv-based devices and improved performance, resulting in a high fidelity, efficient experience for users.
Any chance these enhancements in the Windows 7 MXDC are in Server2008's implementation? If not, will there be an update or is there a way to get it to use that version?
Same question as Jason, I need the improvements in the MXDC supplied with Windows 7 on XP machines. I have tried XPS Essentials Pack version 1.1 but it doesn't seem to have these improvements. Are there any plans to bring these improvements to XP.
I have a simple pass through XPSDrv printer driver that prints to a FILE port. There are no filters. On Windows 7, when I print the same text file from notepad to the the Microsoft XPS Document Writer I get an XPS file that is half the size of the file I get when I print to my driver. My driver has no code. I installed it by creating a .gpd and .inf file only. the .gpd file is the same as that of the Microsoft XPS Document Writer, mxdwdui.gpd. Mine is called xdsmpl.gpd. After comparing the resulting XPS packages, I notice that the doubling in size is mostly from the the extra fonts that are present in the package that is generated by my driver. Both the MS XPS Document Writer and mine have the Document Options, Interleaving set to Off - Best for Viewing.
I learned that because of the improvements added to the Windows 7 MXDC, namely the one described in section, "b. DiscardControl" in the blog post, the size of the XPSDrv spool generated is larger than it would be when DiscardControl is not used. This is because of the many font subsets that are added to the package... DiscardControl is very helpful the consumer application has memory constraints. However, in my case, I am developing an XPSDrv print driver filter that uses the IPrintReadStream interface. My XPSDrv print driver has to run as fast as possible.
Is there a way to disable the MXDC from generating the DiscardControl part in the XPSDrv spool file? This would certainly result in both a faster and smaller spool file size and that would be fine for my filter which has no memory or resource constraints.