Roger D. Peng wrote: > The following paragraph from ?pdf struck me as a bit odd: > > 'pdf' writes uncompressed PDF. It is primarily intended for > producing PDF graphics for inclusion in other documents, and > PDF-includers such as 'pdftex' are usually able to handle > compression. > > Should that be "...and PDF-includers such as 'pdftex' are usually _un_able to > handle compression" ?
Hmm, I think the documentation is correct but incomplete - pdftex *can* handle compression, but compression is not implemented in R's pdf output device. So it should say: "... PDF-includers such as 'pdftex' are usually able to handle compression, but R's pdf device does not utilise that feature of pdf." (I have checked a pdf generated by R, and it doesn't compress, and I was using pdflatex this morning to include a compressed pdf, so both parts are correct). There is a caveat: the PDF specs (and the postscript language standard) actually defines a few stream compression schemes - LZW and deflate are two I know of from the top of my head, I think there are more. But LZW used to be tangled up with the Unisys patent until recently when the patent expired, so most open-source softwares won't do it. deflate is implemented in zlib and ghostscript-written pdf usually have stream compression on. i.e. For some purposes such as getting smaller pdf's, it may be better to output from R postscript and use ghostscript to do ps2pdf rather than doing it directly from R, and to be pedantic, pdftex can only handle deflate encoded compression, AFAIK, for the reason I outlined above, but it is sufficient for most purposes, since most tools cannot generate LZW-compressed pdf's. HTL ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
