minor oddity in pdf() help page

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

minor oddity in pdf() help page

Roger D. Peng
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" ?

-roger
--
Roger D. Peng  |  http://www.biostat.jhsph.edu/~rpeng/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: minor oddity in pdf() help page

Hin-Tak Leung-2
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: minor oddity in pdf() help page

Prof Brian Ripley
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*.

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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

--
Brian D. Ripley,                  [hidden email]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: minor oddity in pdf() help page

Roger D. Peng
Okay, it might be the early morning hour---when I read it a second time it made
sense.

-roger

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*.
>
> 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
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>

--
Roger D. Peng  |  http://www.biostat.jhsph.edu/~rpeng/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: minor oddity in pdf() help page

Hin-Tak Leung-2
In reply to this post by Prof Brian Ripley
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
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Loading...