Feng Yuan (袁峰) : XPS, Printing

Anatomy of Radial Gradient Brush

fyuan — Wed, 10 May 2006 02:09:00 GMT

WPF(Windows Presentation Foundation) and XPS (Open XML Paper Specification) supports five types of brushes. They are solid color brush, linear gradient brush, radial gradient brush, image brush, and visual brush. This posting will discuss the 'shape' of radial gradient brushes.

The shape of a WPF/XPS radial gradient brush is defined by three attributes:

Center
GradientOrigin
Radius

Here is a simple radial gradient brush in XAML:

The best way to understand a radial gradient brush is to look it using a series of paramterized ellipses, with parameter t.

The brush originates at GradientOrigin, with t= 0, color from GradientStopCollection at offset 0, and radius (0, 0).

When t = 1, it complets its first cycle. The ellipses is centered around Center, with t = 1, color from GradientStopCollections at offset 1, and radisu (RadiusX, RadiusY).

Here is the generic formulas for a radial gradient brush's ellipses:

Center: GradientOrigin (1 - t) + Center * t

Radius: (RadiusX * t, RadiusY * t)

Color: GradientStopCollection[t mod 1]

The centers for these ellipses move along the straight line from GradientOrigin to Center. After the first cycle is completed, they continue to move along the line.

Radii are simply increasing proportionally with t.

Color is a periodical function of t. But you also need to consider SpreadMethod to make it right.

GradientOrigin

Normally, center and origin are the same point. These ellipses are then cocentric curves. But when origin is moving away from center, they can become quite interesting.

If we move GradientOrigin from (0.5, 0.5) to (0.4, 0.5), this is what we get:

If we further move GradientOrigin from (0.4, 0.5) to (0.3, 0.5), something drastic happens:

Instead of having gradual changing ellipses filling the whole plane, only half of the plane is filled with ellipses; the other is filled with color at gradient stop 1. This breaking change happens when the distance between center and origin points equals radius.

If we move the origin further away, the ellipses fill an even smaller (triangular) shape:

The angle of the triangle can be calculated using:

2* arctan(radius / distance(center,origin))

Zoran announces XPS rendering support for printers

fyuan — Thu, 19 Jan 2006 22:07:00 GMT

Sunnyvale, Calif. - January 17, 2005 - Zoran Corporation (Nasdaq: ZRAN) announced that its IPS/XPS interpreter for Microsoft’s new XPS Document format will be available to printer and multifunction peripheral (MFP) manufacturers through an Early Adopter Program..

http://www.zoran.com/Zoran-Announces-Enhanced

Optimize XPS markup

fyuan — Wed, 18 Jan 2006 22:10:00 GMT

XPS is hot, so naturally more and more applications will be generating XPS. If your application has access to the XPS Document Writer, then the easiest way to generate XPS is just print to it. But there are cases you may want to generate XPS on your own, either because you can't use the XPS Document Writer, or you want a better solution.

In case you want to generate XPS on your own, here are a few tips on how to generate better XPS markup:

Read the XPS spec. Understand what is really supported and what is not.
Play with the XPS Document Writer, just to see what kind of markup is generated by it. Remember the XPS Document Writer is also improving.
Play with XPS markup using XamlPad. XPS is a subset of XAML, so you can edit a little piece of XPS markup in XamlPad and see how is it rendered.
Check default values. If an attribute has a default value and the current value matches it, it does not need to be written down.
Use Canvas element. If a group of primitives share the same transformation, clipping, opacity, opacity mask, group them in a Canvas, set those attributes only once. But do not use Canvas to group a single primitive.
Use shorthand form for Path geometry, avoid using the Element from of Path if possible.
Use ResourceDictionary, if a gradient brush, image brush, or visual brush is used multiple times, put it into Resource Dictionary and reference to it.
Use integers. By default, coordinates in XPS is in 96-dpi, so to specify coordinates in higher resolution, you need to use floating point numbers. If you have lots of vector data, it will reduce markup size if you introduce a transformation at the top to increase the resolution to say, 600-dpi, and then use integers underneath. If you use floating point, your data would most likely to be in the form of xxx.yy; if you use integers, it could be zzzz, saving 2 bytes per number.
Optimize images: check image dimension, check image pixel format, check image compression, reuse image within the whole document.
Optimize fonts: use font subsetting.
Optimize input to your XPS generator:
- Remove anything with opacity <= 0
- Remove things with null brush
- Remove things which are fully clipped.
- Remve things which are overlapped fully on the top with an opaque object.
- If OpacityMask is always opaque, remove it.
- If OpacityMask is solid color brush, just extract the opacity out and mutiply to Opacity attribute.
- Change degenerated gradient brush to solid color brush.
- Remove primitives which are out of page boundary.
- Merge simple primitives with the same brush, pen, font into a single primitive when possible.
- Merge images adjacent to each other into single image when possible.

If you have issues and concerns about XPS, talk to us (xpsinfo @ microsoft . com)

Native Office Support for XPS Annouced

fyuan — Sat, 29 Oct 2005 21:33:00 GMT

Office just annouced native/direct support for XPS document in Office 12. Read more about it:

Jeff Bell's blog: http://blogs.msdn.com/jeff_bell/archive/2005/10/27/485937.aspx

Andy Simonds's blog: http://blogs.msdn.com/andy_simonds/archive/2005/10/28/486211.aspx

The XPS (XML Paper Specification) Depot

fyuan — Wed, 21 Sep 2005 08:29:00 GMT

One stop shop for XPS information...(read more)

Printing to Microsoft XPS Document Writer without showing File Save Dialog Box

fyuan — Fri, 16 Sep 2005 20:27:00 GMT

If you want to use the Microsoft XPS Writer to generate a large amount of XPS Documents, or use it in a server environment, you do not want the File Save dialog box to show up. Solution: specify output file name in DOCINFO passed to StartDoc....(read more)

DIY generation of XPS Documents

fyuan — Fri, 16 Sep 2005 02:39:00 GMT

Although Microsoft has already provided two ways to generate XPS Documents, there are benefits to generate them on your own. Here is some sample Win32 code for generating XPS Fixedpage markup....(read more)

Printing to legacy devices in Windows Presentation Foundation

fyuan — Tue, 13 Sep 2005 10:13:00 GMT

In the two previous postings, we discussed about two different ways of generating XPS (XML Paper Specification) Documents, one being printing to XPS Document Writer from Win32 applications, and the other being using the new WPF (Windows Presentation Foundation) API. In this article, we will discuss how to print to printers in WPF.

There are two different printing paths under WPF, although the printing API is completely the same. If a printer device supports XPS Document directly, the print sub-system can just generate an XPS Document and sent to the printer; otherwise, the print sub-system will convert WPF contents to GDI commands and send them to GDI/DDI-based printer drivers (also known as legacy devices). The two printing paths approach isolates application from implementation details, encourages printer manufacturers to innovate to provide customer which better printing quality and performance, while at the same time make all existing printers work seamlessly.

In the WIN32 world, GDI-based printing API is centered around DEVMODE for printing settings, GeDeviceCapabilities for device capability queries, HPRINTER for printer handler, and HDC for passing graphics primitives to GDI and then to printer driver. In the WPF world, DEVMODE has been replaced by PrintTicket class, GetDeviceCapabilities has been turned to PrinterCapabilities class, HPRINTER morphs into PrintQueue class, and HDC’s role is now played by Visual and UIElement.

In the XPS Document generation code, we used a very simple Visual. This time, let’s try something little bit more complicated. We would like to generate Visual which reflects the size of the paper it’s going to be printed on, and we want to use more complicated brushes to illustrate internal printing implementation. Here is the Visual generation code we are using:

static Visual CreateVisual(PrintTicket ticket)

{

double width = ticket.PageMediaSize.MediaSizeX;

double height = ticket.PageMediaSize.MediaSizeY;

if (ticket.PageOrientation.Value == PrintSchema.OrientationValue.Landscape)

{

double t = width; width = height; height = t;

}

const double Inch = 96;

DrawingVisual visual = new DrawingVisual();

DrawingContext dc = visual.RenderOpen();

Pen dotPen = new Pen(Brushes.Black, 0.5);

dotPen.DashStyle = DashStyles.Dot;

dc.DrawRectangle(null, dotPen, new Rect(Inch / 4, Inch / 4, width - Inch / 2, height - Inch / 2));

LinearGradientBrush vertical = new LinearGradientBrush(Colors.Yellow, Colors.Blue, 90);

dc.DrawRectangle(vertical, null, new Rect(Inch / 2, Inch / 2, Inch * 1.5, Inch * 1.5));

LinearGradientBrush horizontal = new LinearGradientBrush(Colors.Red, Colors.Green, 0);

horizontal.Opacity = 0.6;

dc.DrawEllipse(horizontal, null, new Point(Inch * 2.25, Inch * 2), Inch * 1.25, Inch);

dc.Close();

return visual;

}

Here is what the code is doing:

It queries current paper size, and switches width and height if it’s printing landscape mode. So now width and height define the drawing area.
It then draws a dotted rectangle ¼ inch from all four sides. Notice that in WPF, point (0, 0) is aligned to the top left corner of the paper, not the top-left corner of the printable area as in GDI.
The rectangle following it uses a vertical linear gradient brush.
The last graphics primitive is an ellipse with a 60% transparent horizontal linear gradient brush.

To print a Visual, first we need to get a PrintQueue (replacement for HPRINT). The code to get the default printer queue and default PrintTicket (replacement for DEVMODE) is quite simple:

static PrintQueue GetDefaultPrintQueue(out PrintTicket ticket)

{

LocalPrintServer server = new LocalPrintServer();

PrintQueue queue = server.DefaultPrintQueue;

ticket = queue.DefaultPrintTicket;

return queue;

}

Once a Visual and a PrintQueue is generated, printing the Visual as a single page is very easy:

PrintTicket ticket;

PrintQueue queue = GetDefaultPrintQueue(out ticket);

XpsDocumentWriter writer = PrintQueue.CreateXpsDocumentWriter(queue);

writer.Write(CreateVisual(ticket), ticket);

With a few more lines of code, we can print multiple pages:

PrintTicket ticket;

PrintQueue queue = GetDefaultPrintQueue(out ticket);

XpsDocumentWriter writer = PrintQueue.CreateXpsDocumentWriter(queue);

VisualsToXpsDocument vtoxpsd = writer.CreateVisualsCollator();

vtoxpsd.Write(CreateVisual(ticket), ticket);

ticket.PageOrientation.Value = PrintSchema.OrientationValue.Landscape;

vtoxpsd.Write(CreateVisual(ticket), ticket);

vtoxpsd.EndBatchWrite();

The code above prints the first page in default orientation (normally portrait) and then switches to landscape mode for the second page. Being a developer in the Windows printing system, I normally prefer paperless printer for my endless printing needs. One of my favorite is Microsoft Office Document Image Writer. It will display the two pages as:

Notice that the dotted rectangles are somehow not displayed perfectly in small scale.

The most interesting thing in this test case is the transparency handling on a legacy device like Microsoft Office Document Image Writer. We mentioned before that for legacy devices, we will convert WPF contents into GDI representation. One of the most difficulty conversions is removing, implementing or simulating transparency. GDI+, which is used by WinForm and Microsoft Office applications, has the same issue for printing. GDI+ solves the issue using by using GDI raster operations and Postscript image masks to approximate transparency, both of them has fidelity problem. Now let’s zoom in to exam WPF’s implementation of transparency on legacy printers.

Transparency is almost as good as WPF rendering of the Visual on screen. The main difference you see is WPF’s anti-aliasing rendering vs. GDI’s aliasing rendering. What WPF legacy printing path code does is removing transparency in vector space as much as possible.

Creating XPS Documents from Visual, plus an insider look at an XPS Document

fyuan — Mon, 12 Sep 2005 10:09:00 GMT

In the last article blogs.msdn.com/fyuan/archive/2005/09/11/463708, we discussed how to generate XPS Documents from Win32 applications using the XPS Document Writer. The procedure is very simple, can you simply print whatever contents you have using GDI API. Now let’s try to generate XPS Documents from WPF (Windows Presentation Foundation) using its new API.

As lots of stuff is new, we will build a simple console application, but build step by step to illustrate what exact is involved. Starting by creating a blank C# console application using Visual Studio, here is what we will get:

using System;

using System.Collections.Generic;

using System.Text;

namespace BasicXps

{

class Program

{

static void Main(string[] args)

{

}

There are a few ways to create XPS Documents using XPF API, you can access the XPS Document container at stream level and build thing piece by piece, you can convert from a WPF Visual object, or your can convert from a WPF UIElement object. We will focus on the conversion from Visual approach. Let’s try to create a Visual which has a yellow rectangle and a pink ellipse as in the last example. The WPF code would be:

static Visual CreateVisual()

{

const double Inch = 96;

DrawingVisual visual = new DrawingVisual();

DrawingContext dc = visual.RenderOpen();

Pen bluePen = new Pen(Brushes.Blue, 1);

dc.DrawRectangle(Brushes.Yellow, bluePen, new Rect(Inch / 2, Inch / 2, Inch * 1.5, Inch * 1.5));

Brush pinkBrush = new SolidColorBrush(Color.FromArgb(128, 255, 0, 255));

Pen blackPen = new Pen(Brushes.Black, 1);

dc.DrawEllipse(pinkBrush, blackPen, new Point(Inch * 2.25, Inch * 2), Inch * 1.25, Inch);

dc.Close();

return visual;

}

DrawingVisual is one main type of Visual supported by WPF. From a DrawingVisual, you can open a DrawingContext and draw graphics primitives into it. DrawingContext is much richer than XPS in terms of graphics primitives supported, but yet every Visual, either generated through DrawingContext or otherwise can be converted to XPS, in certain form. Here the code draws a rectangle and an ellipse. Note that the pink brush is created using Color.FromArgb(128, 255, 0, 255), 50% pink to be exact.

Classes like DrawingVisual, Pen, Brush, etc., are defined in PresentationCore assembly, which depends on WindowsBase assembly. So we need to add references to them, together with the necessary namespaces:

// Needed by CreateVisual, from WindowsBase, PresentationCore.

using System.Windows;

using System.Windows.Media;

The functionality to generate XPS Document resides in ReachFramework assembly, which depends on System.Printing assembly. So we need to add two more assembly references, together with a few more namespaces:

// Needed by VisualToXps

using System.IO.Packaging;

using System.IO;

// Need by VisualToXps, from ReachFramework, which needs System.Printing and PresentationFramework

using System.Windows.Xps.Packaging;

using System.Printing.PrintSubSystem;

The code to generate an XPS Document from a Visual is shown below:

static void VisualToXps(string fileName, Visual visual)

{

Package package = Package.Open(fileName, FileMode.Create);

{

XpsDocument doc = new XpsDocument(package);

{

XpsDocumentWriter writer = XpsDocument.CreateXpsDocumentWriter(doc);

writer.Write(CreateVisual());

}

doc.Close();

}

package.Close();

}

The code above first creates a container (in ZIP format). A container can contain multiple XpsDocument, only one is used here. An XpsDocument can have multiple pages. A single page is generated here because we only call XpsDocumentWriter once with a single Visual.

With two new helper functions, we can change the Main function to call both of them to finish our project:

static void Main(string[] args)

{

VisualToXps("BasicXps.container", CreateVisual());

}

Visually the container generated by this code is very similar to the one generated by the XPS Document Writer. The difference can be explained by the two different creation methods, one dragging using mouse, and the other specifying by inches in C# code.

The XPS Document generated by this code is much smaller than the one created by the XPS Document Writer, it’s only 2,496 bytes in size. The difference is mainly caused by font embedding, PrintTicket, splitting of stroking and filling, and clipping. The container is small enough that we can show everything here. Here is the list of components in the container:

[Content_Types].xml, 543 bytes
FixedDocumentSequence/FixedDocumentSequeuce_1.xaml, 168 bytes
FixedDocuments/FixedDocument_1.xaml, 138 bytes
FixedPages/FixedPage_1.xaml,
_rels/.rels, 308 bytes.

[Context_Types].xml specifies the syntax of the container:

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

<Override PartName="/FIXEDDOCUMENTS/FIXEDDOCUMENT_1.XAML"

ContentType="application/vnd.ms-package.xps-fixeddocument+xml" />

<Override PartName="/FIXEDPAGES/FIXEDPAGE_1.XAML"

ContentType="application/vnd.ms-package.xps-fixedpage+xml" />

</Types>

FixedDocumentdSequence_1.xaml says it only has FixedDocument_1.xaml as its only document:

</FixedDocumentSequence>

FixedDocumentd_1.xaml says it only has FixedPage_1.xaml as its only page:

</FixedDocument>

FixedPage_1.xaml contains the XPS representation of the Visual we are writing:

<FixedPage xmlns="http://schemas.microsoft.com/xps/2005/06"

xmlns:x="http://schemas.microsoft.com/xps/2005/06/resourcedictionary-key"

xml:lang="en-us" Width="816" Height="1056">

<FixedPage.Resources>

</FixedPage.Resources>

<Path Stroke="#FF0000FF" StrokeThickness="1" StrokeMiterLimit="10" Fill="#FFFFFF00"

Data="F0 M 48, 48 L 192, 48 192, 192 48, 192Z" />

<Path Stroke="#FF000000" StrokeThickness="1" StrokeMiterLimit="10" Fill="#80FF00FF"

Data="F0 M 336, 192 C 336, 245.02 282.27, 288 216, 288 C 149.73, 288 96, 245.02 96, 192

C 96, 138.98 149.73, 96 216, 96 C 282.27, 96 336, 138.98 336, 192Z" />

</FixedPage>

The FixedPage element is quite similar, but much simpler than the version generated by the XPS Document Writer. The major new addition is the ResourceDictionary. Common elements can be put into the resource dictionary, given a name, and then reused. In this simple case, the resource dictionary happens to be empty.

Finally, the .rels binds everything together:

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

<Relationship Type="http://schemas.microsoft.com/xps/2005/06/fixedrepresentation"

Target="/FixedDocumentSequences/FixedDocumentSequence_1.xaml" Id="RFBE031A033A8834A" />

</Relationships>

Generating XPS Document from Win32 Applications: the XPS Document Writer

fyuan — Mon, 12 Sep 2005 00:08:00 GMT

At Winhec 2005, Microsoft announced a new file format code named Metro (Modular Content Framework and Document Format). The name Metro has since been retired and replaced with the official name XPS which stands for XML Paper Specification.

XPS is a set of conventions for the use of XML and other widely available technologies to describe the content and appearance of paginated documents. For details about XPS, check the following:

If you’re writing a WPF (Windows Presentation Foundation, previously known as Avalon) application, generating XPS Document is already supported by the new API. If you’re using or writing Win32 based applications, or non WPF-based .Net applications, there is an easy way to generate XPS Documents too, as long as your applications support printing.

With Windows Vista and WPF, Microsoft has provided a GDI/DDI based printer driver which can capture GDI/DDI command sequence and generate a XPS Document from it. The name of the printer driver is Microsoft XPS Document Writer (previously known as MDDW driver). The XPS Documents generated can then be viewed by XpsViewer or other XPS-aware applications and devices.

So let’s try out the XPS Document Writer. First let’s create a simple Microsoft Word document with two shapes overlapping each other, a pink ellipse on top of a yellow rectangle, with the ellipse set to be 50% transparent.

Now we can print it to the XPS Document Writer, hit ‘Print’, select ‘XPS Document Writer’ as your printer, and hit ‘Ok’. A file save dialog box will appear for you to select the file name. XPS Documents uses “.container” as file extension. If you set your printer option to be ‘Open the new XPS Document automatically”, an IE window will pop up showing the new container generated. Otherwise, you can locate the file and double check to open it.

For the document, the WPF rendering is almost exactly the same as Microsoft Word rendering, but they are using two totally different rendering engines. WPF is using a new hardware-accelerated rendering engine based on D3D, while Microsoft Word is using software-based rendering engine known as GDI+.

As XPS Document is packaged in ZIP format and its contents are XML-based, we can easily crack open a XPS Document and see what’s inside. Rename your container to use the zip file extension, double click to open it using WinZip. There are a bunch of files in the zip container. You can find XML files for PrintTicket, image files, font files, XML files for defining the relationship between those files. The file we are interested in here is named FixedPage_1.fpage. This is the XPS representation of the first page of our print job.

Open it up using your favorite XML viewer/editor, mine being the ever-powerful Microsoft Visual Studio.

<FixedPage Width="816" Height="1056"

xmlns="http://schemas.microsoft.com/xps/2005/06" xml:lang="en-US">

<Glyphs Fill="#ff000000" FontUri="/font_0.TTF"

FontRenderingEmSize="16"

StyleSimulations="None" OriginX="576" OriginY="336.16"

Indices="3" UnicodeString=" " />

<Path Data="F1 M 48,36 L 48,192 192,192 192,36 z"

Stroke="#ff0000ff" StrokeThickness="0.96" StrokeLineJoin="Miter"

StrokeStartLineCap="Round" StrokeEndLineCap="Round"

StrokeMiterLimit="8" Clip="M 0,0 L 0,1056 816,1056 816,0 z" />

<Path Data="F0 M 216,84 C 149.76,84 96,124.32 96,173.92 96,223.68

149.76,264 216,264 282.24,264 336,223.68 336,173.92 336,124.32

282.24,84 216,84 z" Opacity="0.5"

Clip="M 0,0 L 0,1056 816,1056 816,0 z" Fill="#ffff00ff" />

<Path Data="F1 M 216,84 C 149.76,84 96,124.32 96,173.92 96,223.68

149.76,264 216,264 282.24,264 336,223.68 336,173.92 336,124.32

282.24,84 216,84" Stroke="#ff000000" StrokeThickness="0.96"

StrokeLineJoin="Round" StrokeStartLineCap="Round"

StrokeEndLineCap="Round" Clip="M 0,0 L 0,1056 816,1056 816,0 z" />

</FixedPage>

For the official XPS specification, check http://www.microsoft.com/whdc/xps/default.mspx

Here is a crash course on XPS syntax:

A page in XPS is stored in FixedPage element.
XPS base unit is 96-dpi, so 816 x 1056 is just 8.5 inch x 11 inch.
XPS uses http://schemas.microsoft.com/xps/2005/06 schema.
All text is represented using Glyphs element, unless it has been converted to vector graphic or image.
All vector graphic and image is represented using Path element. Images are represented using image brushes.
Brush is specified using Fill attribute, which can solid color brush, linear gradient brush, radial gradient brush, image brush, or visual brush.
Pen is represented using a few attributes which start with “Stroke”. The “Stroke” attribute itself specifies the brush for stroking, StrokeTickness is for width, and other attributes control the shape of stroking.
Transparency (opacity, alpha channel) can be in lots of places in XPS. It can be in colors, images, on a single element, or on a bunch of elements grouped in a Canvas element. Transparency can be also used as opacity mask. The only place with transparency in this example is on the 3^rd path, the pink ellipse.

There are five elements in this XPS page:

The first is a Glyphs element with a single character. I’m not sure why it’s generated by Microsoft Word.
The second is the yellow rectangle.
The 3^rd is the blue outline of the rectangle. It’s possible to combine 2 and 3 into a single element.
The 4^th is the 50% transparent pink ellipse. Note that the ellipse has been converted into 4 pieces of Bezier curves.
The last one is the black outline of ellipse. Again it can be combined with 4 to save some space, provided we push the opacity into the filling brush first.

The XPS Document Writer does a quite good job of converting GDI/DDI commands into XPS. One of the things it put special handling is optimzation of GDI raster operation sequences into real transparency. When GDI+, which is used by Microsoft Word under the cover, prints shapes with transparency, it normally uses a sequence of GDI commands with GDI raster operation to simulate transparency. Raster operations basically mask off certain pixels off on the source and destination and then combine the remaining to give the impression that two things are blended together.

Here is the actual sequence of commands generated by GDI+ to print the 50% transparent pink ellipse:

hObj[2]=CreateSolidBrush(RGB(0xFF,0,0xFF));

SelectObject(hDC, hObj[2]);

PatBlt(hDC,2,207,752,565,PATINVERT);

SetROP2(hDC, R2_MASKPEN);

SetTextColor(hDC, RGB(0xFF,0xFF,0xFF));

static KDIB Dib_1(_TEXT("fp00001_1.bmp"));// 16x16x1

hObj[3]=Dib_1.CreateDIBPatternBrushPt(DIB_RGB_COLORS);

SelectObject(hDC, hObj[3]);

SetPolyFillMode(hDC, ALTERNATE);

BeginPath(hDC);

static const POINT Points_2[]={ 378, 208, 171, 208, 3, 334, 3,

489, 3, 645, 171, 771, 378, 771, 585, 771, 753, 645, 753,

489, 753, 334, 585, 208, 378, 208 };

PolyBezier(hDC, Points_2, 13);

EndPath(hDC);

FillPath(hDC);

SetPolyFillMode(hDC, ALTERNATE);

SelectObject(hDC, hObj[2]);

SetTextColor(hDC, PALETTERGB(0,0,0));

SetROP2(hDC, R2_COPYPEN);

PatBlt(hDC,2,207,752,565,PATINVERT);

SelectObject(hDC, GetStockObject(WHITE_BRUSH));

DeleteObject(hObj[2]);

The main GDI commands used are:

PatBlt with PATINVERT rop.
FillPath with R2_MASKPEN rop, using a 16 x 16 bit bitmap brush simulating 50% transparency,
PatBlt again with PATINVERT rop.

Now you’re ready to explore XPS Document Writer on your own.