What causes rasterization of WPF printer output?

Question

I ran into a lot of printing problems in WPF, where individual combinations of printable objects suddenly initiate a rasterization of the printer output (which leads to an ugly and huge printer output and can lead to 30 seconds on each page). I found that often things like having any level of opacity set on the control will cause this. I forgot that all this does (I believe that using a canvas with cropping enabled can do it too), but now I am faced with another problem with a stack panel with a tiled graphic brush filling the border ... etc., which now causes this rasterization again.

So, before I start thinking again, trying to figure out what causes what, etc., I wanted to find out if anyone knows about the ultimate source of information about which specific elements can cause this? Or maybe some way to connect to the system where this happens to allow me to at least try to figure it out ...

This has certainly been a disappointing part of my several years at WPF.

update: I discovered today that simply including an image in a canvas can lead to rasterization. Not sequentially, but sometimes. It can be tied to size, or maybe it is cropped, etc. Argh.

I often print PDF files, but I found pretty much the same behavior between Adobe Acrobat Printer and other physical printers.

Answer 1

I am also struggling a bit with this problem. This week I began to study the problem again and started writing a small test application to isolate the problem. I managed to run rasterization in just a few drawing operations. Four rectangles, an ellipse and a line to be exact.

static void Main(string[] args) { var printers = new LocalPrintServer().GetPrintQueues(new[] { EnumeratedPrintQueueTypes.Local, EnumeratedPrintQueueTypes.Connections }); PrintQueue defaultPrinter = LocalPrintServer.GetDefaultPrintQueue(); PrintQueue printerToUse = printers.FirstOrDefault(p => p.Name.Contains("PDFCreator")) ?? defaultPrinter; // Use PDFCreator if available. PrintTicket ticket = printerToUse.DefaultPrintTicket; XpsDocumentWriter writer = PrintQueue.CreateXpsDocumentWriter(printerToUse); writer.Write(CreateVisual(), ticket); } private static Visual CreateVisual() { var visual = new DrawingVisual(); using (DrawingContext dc = visual.RenderOpen()) { var pen = new Pen(Brushes.Black, 3); var opacityBrush = new SolidColorBrush { Color = Colors.Violet, Opacity = 0.7 }; dc.PushClip(new RectangleGeometry(new Rect(20, 20, 150, 150))); dc.DrawLine(pen, new Point(0, 0), new Point(200, 300)); dc.DrawEllipse(new SolidColorBrush(Colors.LightGreen), pen, new Point(50, 80), 50, 70); dc.DrawRectangle(new SolidColorBrush(Colors.LightBlue), pen, new Rect(10, 100, 100, 100)); dc.DrawRectangle(new SolidColorBrush(Colors.LightPink), pen, new Rect(40, 120, 100, 100)); dc.DrawRectangle(new SolidColorBrush(Colors.LightGray), pen, new Rect(60, 140, 100, 100)); dc.DrawRectangle(opacityBrush, pen, new Rect(80, 160, 100, 100)); } return visual; } 

The full test application can be downloaded from here (VS 2010 solution).

During testing, I print to PDFCreator , a virtual PDF printer, to prevent mass use of paper. But I get the same result with real physical printers. It is difficult to notice the difference on paper using this example, however real-world cases may be more noticeable ( pic1 , pic2 ).

Here is a screenshot of the result: When you enlarge the PDF format, you see that the rectangles and ellipse are no longer in vector format and become blurry.

---

Rasterization Conditions

It seems very difficult to determine. I share the same experience as boomhauer that opacity and cropping seem to often cause rasterization. And my example really includes both of these types (for example, they were used specifically when trying to start rasterization). Not to say that any of them should be present during rasterization.

It makes sense that opacity can cause rasterization, but some other subtle changes that you think are not related to the problem can actually “prevent” the rasterization. Like changing the thickness of a pen in my example ( screenshot ). Other changes that somehow eliminate the rasterization condition, change the order of the drawing operations, delete any of the operations, and, of course, remove the opacity or cropping.

Bypass

I found that generating an XPS file and printing it from the Microsoft XPS Viewer would actually result in a raster-free release, even if they use the same drawings and printer.

 private static void GenerateXps() { var xpsDoc = new XpsDocument("wpf_printing_raster_test.xps", FileAccess.ReadWrite); XpsDocumentWriter writer = XpsDocument.CreateXpsDocumentWriter(xpsDoc); writer.Write(CreateVisual()); xpsDoc.Close(); } 

Screenshot here .

So instead of printing directly from your code, you can create an XPS och and then instruct Microsoft XPS Viewer to print XPS for you programmatically.

This, of course, is a bit of a hack, not an optimal solution. But I would be interested if someone has a good way to force printing from the Microsoft XPS Viewer, if no fix or real solution is found (have not tried it myself yet).

I would also be interested to know if anyone else has rasterized printouts even when printing from Microsoft XPS Viewer.

As a long shot, I tried to load the XPS file into a test application and print it ( code ). But it didn’t work, anyway a rasterized printout was obtained.

Decision?

I do not think this is a problem with the printer driver. When rasterization occurs, it happens on all printers without exception. I tried 4-5 different printers: from $ 100 HP 1020 to $ 6000 Konica Minolta C360 and several virtual printers.

The workaround also indicates that the Microsoft XPS Viewer sends something else in the printer driver, and then direct WPF printing.

We really should try to get Microsoft to take a look at this; it was reported as a bug in 2009, but nothing happened. Hope a small example of compressed code to reproduce the problem helps.