Ok, So I've been given a task to build a light weight printing feature that will replace a third party tool that costs a significant amount of money,and not only that, has far too many features.
I've managed to build a little system that polls some data and calls an endpoint on an on-premise MVC app, which in turn prints the document.
All is great, but I'm really struggling to figure out why the PDF file size bloats when hitting the Print Queue.
Currently the File size is 822KB when I print manually via Adobe the PDF is compressed to 342KB
BUT using the system it bloats to an astonishing 4.22MB
To note I am using the PDFium SDK Nuget package to take away some of the heavy lifting. Having said that, I do utilize System.Drawing.Printing to craft settings to pass to PDFium
.
A little code to demonstrate printing:
public bool PrintPDF(string printer,
string filePath)
{
try
{
var printerSettings = new PrinterSettings
{
PrinterName = "Hewlett-Packard HP LaserJet P2015 Series",
Copies = 1,
};
using (var document = PdfDocument.Load(@"C:\folder\Documentation\test.pdf"))
{
using (var printDocument = document.CreatePrintDocument())
{
printDocument.PrinterSettings = printerSettings;
printDocument.DefaultPageSettings = pageSettings;
printDocument.DocumentName = "test.pdf";
printDocument.PrintController = new StandardPrintController();
printDocument.Print();
}
}
return true;
}
catch(System.Exception ex)
{
new Email().SendEmail("", "TEST ERR", ex.Message, "email address");
return false;
}
}
At the moment I'd be happy if it printed the physical size (822KB) rather than bloating it.
Id really appreciate some guidance and a nudge in the right direction.
PDF is (usually) a vector representation of the page, its a page description. PDF can contain bitmap data as well, but for text and line art its usually vector, and white space simply isn't included in the description at all.
When you print, then behind the scenes the application creates a device context compatible with the printer you select, replays the drawing commands it used to draw the content on the display, and then tells the printer context to print.
That causes the device driver to be handed the GDI commands to draw the page. Depending on the printer type (ie what page description language it understands) the device driver can simply pass on the commands (for a GDI printer), convert them to a high level vector representation (like PostScript) or render them to a bitmap. Some drivers may do a combination of these approaches. The result is then sent to the printer.
The Adobe PDF 'printer' works by co-opting the Windows PostScript printer driver, which converts GDI commands into vector PostScript operations, which are easily turned into vector PDF operations, resulting in a small representation of the page.
It sounds to me like your printer (or possibly printer driver) is 'dumb' and wants, or is being sent, a big bitmap. Once upon a time, in the days when printers ran on serial interfaces and 9600 baud was fast, it was worth keeping the file size small and having the printer be smart, because it took a long time to send the data. Nowadays, that's less of a concern, even several megabytes can transfer rapidly, and if you send a pre-rendered bitmap to the printer, the printer can be dumb and still print fast, because all it has to do is transfer the bits.
You haven't really said what you mean when you "print manually using Adobe" or "use the system" so I can't tell you more than that, but my guess would be that your big PDF simply contains a large (compressed) image.