I tried to convert different PDF files (which contain only text) to PS. After which some of them are small and some are huge. For example:
169 kb PDF => 409 kb PS
82 kb PDF => 5749 kb PS
I tried these ghostscript options:
-dASCII85EncodePages=false
-r300
-dBATCH
-dPDFFitPage
-dFIXEDMEDIA
-dNOTRANSPARENCY
-dNOINTERPOLATE
-dDEVICEWIDTHPOINTS=595
-dDEVICEHEIGHTPOINTS=841
-dcupsBitsPerColor=8
-dcupsColorOrder=0
-dcupsColorSpace=1
-dcupsCompression=1
-scupsPageSizeName=A4
-sDEVICE=ps2write
Probably a problem with the original PDF, but what exactly I can not understand. I can send the source files, just where?
The problem here is due to a limitation of the ps2write device, and a quirk of the way the files are created.
Both PDF files use CIDFonts, the ps2write device only implements basic level 2 PostScript output, and CIDFonts were not included in the original level 2 specification (they were added in a supplement).
This means the ps2write device cannot currently output the CIDFonts defined in the PDF file, it must convert them to 'something else'. What it does is render the glyph shapes to bitmaps, and construct type 3 bitmap fonts, which it then uses in the body of the PostScript program. This is, of course, less than ideal, as bitmap fonts are poorer quality than vector descriptions of the glyph shapes. Since you've fixed the rendering at 300 dpi, that reduces the quality of the glyph bitmaps, but they should be acceptable for printing on a desktop printer.
So, given that both files contain CIDFonts, why is one much larger ? This is the 'quirk' of the way the files are created. The file test1.pdf has the fonts it uses embedded in the PDF file, and they are embedded as subsets, that is each font only contains the shapes descriptions of the glyphs it uses. The other file uses Arial and Arial-Bold (IIRC) but does not embed either CIDFont.
Fonts can only address up to 255 glyphs, while CIDFonts have a more or less unlimited range. When ps2write creates type 3 fonts to represent the embedded CIDFonts, it can't create a Font which has the full addressable range that a CIDFont would, so if more than 255 glyphs are used from a given font, it has to create multiple type 3 fonts.
So we fill up the font as we go, until we reach 255 glyphs, then we start a new font. The problem is that if we then encounter a glyph that was used earlier, and therefore defined in a previous font, we can't simply switch fonts (this is a limitation of the way ps2write works). So we have to include that glyph in the font we are currently creating as well. This means we end up with two copies of the bitmap in the output; one for the first font that uses it and one for the second font.
And that's exactly what is happening here. Test1.pdf uses embedded subsets, so we essentially never overflow the type 3 fonts, and the output PostScript program contains ~300 bitmaps for the glyphs. Test2.pdf overflows the 255 limit several times and so the output PostScript program contains ~2120 bitmaps for the glyphs.
There is nothing you can do about that, unless you can control the production of the input PDF files, so the question then becomes 'is this a problem for you, and if so, why ?'
[EDIT]
Well I doubt the size has any real impact on the printing time. PostScript is streamed to the printer so it starts processing the data as soon as it is sent.
Of course converting PDF to PostScript first is a time consuming step. Assuming your printer(s) cannot print PDF directly, the most obvious answer would be to print each page to a separate PostScript file using the -sOutputFile=out%d.ps syntax.
Overall the performance would be reduced, because multiple files need to be opened and closed, the prolog will be written to every file, and there can be no reuse of resources between pages, so shared resources will have to be written to each file. This means the total size of al the pages written as separate files will be considerably larger than the total written as one largen file.
However the advantage is that you do not have to process all the pages from the PDF file before you send the first page to the printer. As soon as page 1 is complete, the file out1.ps will be closed and ready to send to the printer, so you can start sending page 1 while Ghostscript continues to produce pages 2 onwards.