Printing through PrintQueue job in ASP.NET MVC fails with 0 byte size printed file

Question

I tried this example from MSDN in an ASP.NET MVC project:

public void Print(string printQueueName, string printData)
    {
        PrintQueue printerQueue = new LocalPrintServer().GetPrintQueue(printQueueName);

        // Call AddJob
        PrintSystemJobInfo myPrintJob = printerQueue.AddJob();

        // Write a Byte buffer to the JobStream and close the stream
        Stream myStream = myPrintJob.JobStream;
        Byte[] myByteBuffer = UnicodeEncoding.Unicode.GetBytes(printData);
        myStream.Write(myByteBuffer, 0, myByteBuffer.Length);
        myStream.Close();
    }

I tried to print to PDF, XPS and OneNote virtual printers. After confirming printing dialog, printing job appears in printer queue then disappears, and the printed file is created, but with 0 byte size!!!

I don't know where is my fault, and hope to find help here.

Thanks in advance.

Answer 1

The example here which is close to MSDN does not work on my printer either. It's irrelevant because this example is not sufficient to print PDF or XPS as one cannot simply output a byte stream of these types as a stream to the printer. You have at least a few options:

• Use PrintDocument. Convert the PDF/TIFF/Possibly onenote files to Images (E.G. tiff files) and you can print with this class using the event PrintDocument.PrintPage and Graphics.DrawImage.
• Use/Buy 3rd party print API's for PDF. You can get away with direct XPS printing, but it's got some issues (see details below). OneNote I don't know.
• Print the files via the command line using Process
• Write your own print drivers

Further Details
I'm not familiar with OneNote printing. XPS printing can be quite tricky. The margins need to be calculated in code because they depend on the printer settings which can be found in the PrintTicket. Using WPF (which is closely tied to XPS) there's a bug I discovered somewhere in the XPS serialization process. XpsDocument does not preserve the calculated printable area. Documents will print with default printable areas which can result in cut off. I confirmed this bug on Microsoft Connect. See their response below.

Finally, if you just happen to be running SSRS then you can easily change the output type from PDF/XPS to image.

Feedback for XPS bug on Microsoft Connect (link is private):

Title: XpsDocument does not preserve the calculated arrangement for WPF's >FixedPage.Arrange()

The WPF team has recently reviewed this issue and will not be addressing this issue as at this time the team is focusing on the bugs impacting the highest number of WPF developers. If you believe that this was resolved in error, please reactivate this bug with any necessary supporting details.

We appreciate the feedback. However, this issue will not be addressed in the next version of WPF. Thank you. –WPF Team

.