Home/ Questions/Q 7951761
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-04T02:39:33+00:00

I might be barking up the wrong tree with my question, so I’ll try

  • 0

I might be barking up the wrong tree with my question, so I’ll try to give a thorough description of the problem.

We have a Windows Service which takes an XML file and generates a PDF. Then it outputs the generated PDF to Ghostscript using a -sOutputFile="%printer%" parameter, followed by the name of one of our network printers, based on data in the XML file.

We have previously used -sDEVICE=mswinpr2, but this was generating print commands of around 70-80MB in size, which wasn’t particularly helpful when we were on a local network. Now that we have a central print server for multiple sites, the printing times for these PDFs has become astronomical, given these absurd filesizes.

These files were being generated using:

  " -sDEVICE=mswinpr2 -sPAPERSIZE=a4" _
& " -dBATCH -dNOPAUSE -dSAFER -dNoCancel" _
& " -sOutputFile=""%printer%" & [somePrinter] & """"

I have been playing around with Ghostscript’s settings and thought I’d found the answer with PNGs, using the following Ghostscript command:

  " -sDEVICE=png16m -r600x600 -sPAPERSIZE=a4" _
& " -dBATCH -dNOPAUSE -dSAFER -dNoCancel -dQUIET" _
& " -sOutputFile=""%printer%" & [somePrinter] & """"

This works fine for single pages, generating only around 150kb of data for a single-page document, but on multiple pages, only the first page is printed. I’ve done some testing by outputting to a file instead of a printer and it turns out that some kind of weird multi-page PNG is being created, and I think the printers are just getting confused.

Actual Question:

My only real constraint here is that I need to take a PDF file as input, and output directly to a printer, with no user interaction, and a small filesize.

Can someone recommend me a GhostScript setting (or an alternative to GhostScript) that will achieve this, because I’m running out of ideas?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The mswinpr2 device uses the Windows Printing System to do the work of dealing with the multitude of different printers. It works by rendering the incoming file to a bitmap, blitting the bitmap to a printer device context, and then telling the device context to print to the printer. Obviously high resolution full colour pages can produce quite large bitmaps. An A4 page @600 dpi, CMYK colour amounts to about 130Mb (8.26*600 * 11.69*600 * 4)

    So you always end up sending a bitmap to the printer. Of course this can be large, often the printer will understand some printing language which could make the output smaller, but that would entail Ghostscript ‘knowing’ about the printer and producing the correct output. The beauty of mswinpr2 is that it leverages the OS to do the heavy lifting. The downside is that it always produces bitmaps, but at least it can print to any printer supported by Windows.

    It seems you were fortunate with your first printer in that it understood PNG, most printers don’t, as you have discovered, and will treat the incoming data as native printer data. The effect of this could be anything, but its very unlikely to produce any useful printout.

    If you know that a given printer supports PCL or PostScript, then you can use the appropriate Ghostscript device to convert your PDF file into one of those languages (PCL files will probably still be huge).

    Note that PDF files containing transparency will still have to be converted, at least partially, to bitmaps, because no other printing language supports PDF’s concept of transparency.

    I see you’ve discovered this yourself. I would recommend that instead of pswrite you use ps2write, it will produce smaller output that runs faster. Also the pswrite device is deprecated and no longer supported.

    You should probably also set the resolution appropriate for your printer. ps2write will sometimes haev to render areas of the page to bitmap (eg for PDF transparency) and uses the resolution parameter to decide what resolution of image to create. The default is 720 dpi, which will print well on almost any device. However, its way too large for most devices and will produce large bitmaps again under some conditions (Cairo-produced PDF files are particularly prone to this problem since they declare the entire portion of every page to be transparent)

    • 0