I pursued this in the Microsoft Partner Support Community. The ultimate reply there was that they have confirmed the issue and the "escalation engineers are working at this issue."
The workaround I came up with myself is to print using System.Printing
rather than the System.Drawing.Printing
.
internal override void Print(string printerName, string baseFilePath, string baseFileName)
{
using (var printQueue = GetPrintQueue(printerName))
{
XpsDocumentWriter xpsDocumentWriter = PrintQueue.CreateXpsDocumentWriter(printQueue);
IEnumerable<string> filesToPrint = GetFilesToPrint(baseFilePath, baseFileName);
PrintUsingCollator(xpsDocumentWriter, filesToPrint);
}
}
private static void PrintUsingCollator(XpsDocumentWriter xpsDocumentWriter,
IEnumerable<string> filesToPrint)
{
SerializerWriterCollator collator = xpsDocumentWriter.CreateVisualsCollator();
collator.BeginBatchWrite();
foreach (var fileName in filesToPrint)
{
Image image = CreateImage(fileName);
ArrangeElement(image);
collator.Write(image);
}
collator.EndBatchWrite();
}
/// <remarks>
/// This method needs to be called in order for the element to print the right size.
/// </remarks>
private static void ArrangeElement(UIElement element)
{
var box = new Viewbox {Child = element};
box.Measure(new Size(double.PositiveInfinity, double.PositiveInfinity));
box.Arrange(new Rect(box.DesiredSize));
}
System.Printing
is a newer API based on WPF. The down side to it in this particular case is that it is memory usage. Because System.Windows.Controls.Image
is GC-ed (where as System.Drawing.Image
requires explicit disposal) and I am loading relatively large images, it does seem to thrash memory usage a bit and ultimately be a bit slower on large jobs.