![]() Secondly, our experience with Ghostscript's Postscript output, is that many printers are much, *much* faster at upsampling images than downsampling. 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). 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. Hence we have the result that basically every Cairo produced PDF will convert to Postscript as one or more sampled images per page.Īnd that explains why the Postscript is so much larger than the PDF. 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. Now, secondly, Postscript cannot represent PDF transparency in high level (vector etc) operations. ![]() 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. Unfortunately, those easily accessible elements don't contain (or, at least, don't reliably contain) the actual opacity information. ![]() 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. 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. The Cairo *always* writes the page contents into one or more PDF transparency groups - even when all the contents are really opaque. The problem, I suspect, is the way Cairo rights PDF files (the gmap.pdf file you attached above was created by Cairo). Of course, another workaround could be to use a PCL driver but no one is available for my printer (HP Color Laserjet 2605dn). See also Bug # 1095498 which I suspect is the same (old) thing, but I fill a new one since it doesn't seem to be printer specific. Of course these small PS files produced by pdftocairo, Evince of Firefox print flawlessly on my printer. I get a similar file if I print to PS directly from Google Map (Firefox). I have the same success if I open the PDF file with Evince and print it as a Postscript file. However, pdftocairo quickly produces an efficient file. It is worse with pdf2ps (and it takes longer to process), so replace pdftops by pdf2ps is not an option for me. As you can see, I get a much larger file (36 times) with pdftops. So I suspect that pdftops should be fixed.įor example, I join a problematic pdf produced by Google Map in Firefox. I don't know if modern Postscript printers can handle this quickly, but it's unacceptable here and certainly not an efficient way to print those files. After some manual PDF -> PS conversions, I see that pdftops inflates the file size for problematic cases, but is ok for other files (size similar to the original file, or even smaller). When this happens, I observed in system monitor that pdftops is running continuously. It happens with some PDF files (not all) and Firefox printing of Google map, for example. With my (old) postscript printer, print a single page can take many minutes on some situations.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |