The problem, I suspect, is the way Cairo rights PDF files (the gmap.pdf file you attached above was created by Cairo). The Cairo *always* writes the page contents into one or more PDF transparency groups - even when all the contents are really opaque. The issue is that, due to the way PDF works (and PDF transparency in particular) the only way to be sure that all the page contents are opaque would be to pre-process each page, checking for non-opaque content, and then re-interpret the page using the information gleaned in the first pass - which would, frankly, result in an unacceptable performance drop for the vast majority of PDF files. Most interpreters I know will pre-scan the quickly accessible elements of a PDF page, and if no transparency constructs are found, will then elide the extra processing transparency requires. Unfortunately, those easily accessible elements don't contain (or, at least, don't reliably contain) the actual opacity information. So, in most cases I know, just the existence of the transparency constructs means that extra processing is enabled, regardless of the actual opacity values. Now, secondly, Postscript cannot represent PDF transparency in high level (vector etc) operations. So, the only way to get a visually accurate representation of a PDF containing transparency in Postscript is to "flatten" the transparency by rendering it to a sampled image - and clearly, sampled images end up being larger than vector graphics. Hence we have the result that basically every Cairo produced PDF will convert to Postscript as one or more sampled images per page. And that explains why the Postscript is so much larger than the PDF. Now, looking at the Postscript file you posted, it *appears* that the rendering for transparency flattening is being done at 1200dpi which is, frankly, ridiculous for a couple of reasons. First is, your printer has a maximum physical resolution of 600dpi (the ImageRET modes provide enhanced quality, claimed to be equivalent to 2400 and, IIRC, 3600 dpi, but the printer is still a 600 dpi printer). Secondly, our experience with Ghostscript's Postscript output, is that many printers are much, *much* faster at upsampling images than downsampling. So, my first suggestion would be to poke around the CUPS dialogues and/or the PPD, and see if you can drop the claimed resolution of the printer to at most 600dpi and, frankly, I'd even try 300 dpi. As a rule of thumb, in the printing world, it's generally claimed that dropping continuous tone, sampled image resolution by 50% from the physical resolution results in almost no visible loss of quality. Where that falls down, in cases like this, is because there is text involved, and the small details inherent in text shapes may well suffer visibly. Another thing we've found with the Postscript output from Ghostscript is that many printers are very, very slow at decompressing data, so if you can find an option to avoid compressing image data, that *might* make a difference - but that is highly printer dependent. I'd like to take this opportunity to rant (again): this kind of thing is the reason that PDF is such poor, poor choice as a print spool format. PDF has a *hugely* rich imaging model, *far* more so than Postscript, PCL5/PXL or any of the proprietary page description languages (PDL), which means for almost any low/midrange PDL based printer, there is a very high chance that the PDF content cannot be converted to a high level, vector representation, and must be rendered and sent as sampled images (bitmaps). Perhaps a PDF/A or PDF/X variant would be a better choice...... And I'm sure someone will point out that more and more printers are supporting direct PDF printing, but that really just moves the bottleneck: PDF transparency is (over!) complex, and is extremely processor and memory intensive. So a low/mid range printer, with limited memory and processing power, is going to struggle to print a file like these ones. In truth, many such PDF printers "get around" this by either not supporting transparency at all, or supporting only relatively trivial subset of the full PDF transparency model. Also, with more and more applications integrating Cairo to do their PDF output, with the transparency problems outlined above, the situation is only set to get worse. Anyway, as I said, look into adjusting the resolution, and possibly compression settings, and let us know how you fare.