# Postmortem: The Pitfalls of Direct PDF Printing in WPF Without PDF Rendering
**Summary**
An attempt to print PDF files directly to the default printer without utilizing a PDF reader failed. The developer tried using a temporary file approach and expected silent printing via the OS-default printer, but the PDF format couldn't be processed natively by printers.
**Root Cause**
- **Fundamental misunderstanding of PDF processing**: Printers don't interpret PDF files directly. They require rasterized page descriptions (e.g., PCL, PostScript) generated by PDF rendering engines.
- **Ignoring printer language requirements**: Raw PDF data sent to the printer results in print failures or garbage output since printers lack built-in PDF interpreters.
**Why This Happens in Real Systems**
- Developers assume printers accept PDFs like documents in text/image formats
- Efforts to reduce dependencies by avoiding third-party PDF libraries
- Misinterpretation of "PDF printer" virtual devices (which require rendering engines)
**Real-World Impact**
- **Wasted resources**: Hundreds of corrupted print jobs queued overnight
- **Service disruption**: Critical documents (invoices, labels) failing to print
- **Hardware issues**: Printers jammed with unprocessable jobs requiring manual reset
- **User frustration**: Silent failures with no print dialog mean no error feedback
**Example** Code (Problematic Approach)
```csharp
// Non-functional approach attempting raw PDF printing
var tempPdfPath = Path.Combine(Path.GetTempPath(), "temp.pdf");
File.WriteAllBytes(tempPdfPath, pdfData);
// This fails - printers can't process raw PDF
new Process()
{
StartInfo = new ProcessStartInfo(tempPdfPath)
{
Verb = "printto",
Arguments = "\"Printer Name\"",
CreateNoWindow = true,
UseShellExecute = true
}
}.Start();
How Senior Engineers Fix It
Solution 1: Render via XPS Intermediate Format
// Convert PDF to XPS using PdfiumViewer/Ghostscript
byte[] xpsData = PdfConverter.ToXps(pdfData);
using (var stream = new MemoryStream(xpsData))
{
using var doc = new XpsDocument(stream, CompressionOption.Normal);
var printQueue = LocalPrintServer.GetDefaultPrintQueue();
var writer = PrintQueue.CreateXpsDocumentWriter(printQueue);
writer.Write(doc.GetFixedDocumentSequence());
}
Solution 2: Silent Printing Through System APIs
# Using PowerShell (system print dialog suppressed)
Start-Process -FilePath $pdfPath -Verb Print -WindowStyle Hidden
Key Considerations:
- Library selection: Use battle-tested PDF renderers (PdfiumViewer, PDFSharp) for XPS/PostScript conversion
- Fallback handling: Implement print monitoring with
PrintSystemJobInfo to detect failures
- Performance optimization: Chunk large documents to prevent spooler overload
- Printer capability checks: Validate PCL/PostScript support programmatically
Why Juniors Miss It
- Abstraction over-reliance: Belief that OS/document interactions “just work” regardless of format
- Underexposure to printer protocols: Lack of awareness about PCL/PostScript dependencies
- Testing gaps: Only verified on systems with PDF readers installed (which silently handle printing)
- Documentation blind spots: Microsoft docs explicitly state
Process.Start() for PDF requires a PDF handler
