From hin-tak.leung at cimr.cam.ac.uk  Thu Mar  2 16:51:40 2006
From: hin-tak.leung at cimr.cam.ac.uk (Hin-Tak Leung)
Date: Thu, 02 Mar 2006 15:51:40 +0000
Subject: [Rd] minor oddity in pdf() help page
In-Reply-To: <Pine.LNX.4.64.0603021359190.27636@gannet.stats.ox.ac.uk>
References: <4406F168.9080605@jhsph.edu> <4406F84C.7020306@cimr.cam.ac.uk>
	<Pine.LNX.4.64.0603021359190.27636@gannet.stats.ox.ac.uk>
Message-ID: <4407148C.2030904@cimr.cam.ac.uk>

Prof Brian Ripley wrote:
> No, it means what it actually says.
> 
> If you include R's PDF in another application, the latter will usually 
> compress *if you asked the application for compressed PDF*.

Hmm, no, I don't know about "another application", but pdftex
actually tries to insert the graphic/pdf/page objects in
the origin form if possible - I would have a word with the author
and consider that behavior buggy if pdftex modifies graphic
insertion unncessarily.

i.e. the default behavior of pdftex is such that anything it
generates such as the text content part will be compressed, but
any externally included pdf graphics (such as from R) is
preserved in their original form if possible.

Even if pdftex behaves as you outlined (which I doubt), the paragraph
probably can be reworded to a less ambiguous form as e.g. "PDF-includers 
such as 'pdftex' are usually able to generate compressed pdf from 
uncompressed input." .

> On Thu, 2 Mar 2006, Hin-Tak Leung wrote:
> 
>> 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 at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>



[Rd] minor oddity in pdf() help page
Hin-Tak Leung