Hi,

I thought I had summarized my findings to the list, but it seems I did  
not. After a while, the thread moved to the mac R help list and I  
produced a summary there. It is reproduced below if you are interested.

At the time, I was working on a report in LaTeX that had about 100  
maps produced with R (PBSmapping, pdf device). I found that the  
solution of compressing the LaTeX-produced pdf with either pdftk or  
Adobe Acrobat was as effective, and only 1% as much work as  
compressing each of the maps after they were produced with R.

Both means of compression did not introduce any loss of quality. All  
my figures were vector-based pdfs. They were large because of the  
resolution of the coastline on my maps. The compression helped to  
shrink them, and the figures in the report can still be zoomed without  
showing jaggies or other artefact. Because of similarity in final size  
between using pdftk (or Acrobat) and zipping the original report, I  
came to the conclusion that a zip-like lossless compression is used by  
pdftk and Acrobat. With today's fast computer the pdf opens just as  
fast and we do not notice. If this is false, please let me know.

Denis

============ my message on R for mac help list

Message: 1
Date: Thu, 24 May 2007 10:59:23 -0400
From: Chabot Denis <chabotd@globetrotter.net>
Subject: Re: [R-SIG-Mac] Reducing the size of pdf graphics files
	produced	with R
To: R list <r-help@stat.math.ethz.ch>, r-sig-mac@stat.math.ethz.ch
Cc: David Watson <dewatson@mac.com>
Message-ID: <6B6BEBC7-309E-4FD7-B591-15C345D38A49@globetrotter.net>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

> Hi again,
>
> Many of you have suggested other means than pdf device and/or
> conversion/compression of pdf outside of R.
>
> I ran some tests on a small, a medium-size and a large figure. Here I
> summarize the results, which depend very much on the original
> graphics file. Please note that I wish to retain a vector-based
> graphic file.
>
> You'll find at the end of this message the R program used to produce
> the graphics files.
>
> Starting with a small size graphic file: in order, these were
> produced by
>
> 1) postscript device
> 2) pdf device
> 3) bitmap device (pdf output)
> 4) dev2bitmap, pdf output, from a quartz window
> 5) quartz device saved to pdf via command quarts.save
> 6) quartz device saved to pdf via save menu in R gui
>
> -rw-r--r--   1 chabotd  chabotd    243446 May 23 21:00  
> test_ps_from_R.ps
> -rw-r--r--   1 chabotd  chabotd    572513 May 23 21:00   
> test_pdf_from_R.pdf
> -rw-r--r--   1 chabotd  chabotd    600106 May 24 09:21   
> test_pdf_bitmapR.pdf
> -rw-r--r--   1 chabotd  chabotd    600050 May 24 09:22   
> test_dev2bitmap.pdf
> -rw-r--r--   1 chabotd  chabotd   1657446 May 23 21:00   
> test_pdf_from_quartz.save.pdf
> -rw-r--r--   1 chabotd  chabotd    572634 May 23 21:01   
> test_pdf_from_quartz.menu.pdf
>
> These show how "test_pdf_from_R.pdf" can be shrunk outside of R
> 1) the command pdftk
> 2) opening the pdf in any Mac OS X pdf viewer and doing "print to
> compressed pdf"
>
> -rw-r--r--   1 chabotd  chabotd     68742 May 24 09:25   
> test_pdf_pdftk.pdf
> -rw-r--r--   1 chabotd  chabotd    100660 May 23 21:16   
> test_pdf_print_to_comppdf.pdf
>
> Finally, these show 3 conversions from postscript to pdf outside of R
> 1) command ps2pdf
> 2) command epstopdf
> 3) command pstopdf
>
> -rw-r--r--   1 chabotd  chabotd    566626 May 23 21:12   
> test_ps_ps2pdf.pdf
> -rw-r--r--   1 chabotd  chabotd    566587 May 24 10:21   
> test_ps_epstopdf.pdf
> -rw-r--r--   1 chabotd  chabotd   1939788 May 24 10:20   
> test_ps_pstopdf.pdf
>
> For this first example, all pdf produced directly within R were of
> similar size, except one (quartz.save) that was 3x larger. Producing
> a postscript file and transforming it into pdf resulted in no
> significant saving. However pdf output from R can be shrunk (here to
> 12% of original size) with pdftk. So far I found no adverse effect of
> this shrinking.
>
> I did the same with a larger graphic, this example came from Dave
> Watson. Using the same blocks as above:
>
> Produced with R:
> -rw-r--r--   1 chabotd  chabotd    854320 May 24 09:08   
> mauna_ps_from_R.eps
> -rw-r--r--   1 chabotd  chabotd   1000504 May 24 09:08   
> mauna_pdf_from_R.pdf
> -rw-r--r--   1 chabotd  chabotd     96737 May 24 09:08   
> mauna_pdf_bitmapR.pdf
> -rw-r--r--   1 chabotd  chabotd     97236 May 24 09:17   
> mauna_dev2bitmap.pdf
> -rw-r--r--   1 chabotd  chabotd    468195 May 24 09:08   
> mauna_pdf_from_quartz.save.pdf
> -rw-r--r--   1 chabotd  chabotd    999853 May 24 09:09   
> mauna_pdf_from_quartz.menu.pdf
>
> PS to pdf outside of R
> -rw-r--r--   1 chabotd  chabotd     95024 May 24 09:11   
> mauna_ps_ps2pdf.pdf
> -rw-r--r--   1 chabotd  chabotd    603021 May 24 10:40   
> mauna_ps_pstopdf.pdf
> -rw-r--r--   1 chabotd  chabotd     95015 May 24 10:40   
> mauna_ps_epstopdf.pdf
>
> pdf transformation outside of R
> -rw-r--r--   1 chabotd  chabotd    104487 May 24 09:12   
> mauna_pdf_pdftk.pdf
> -rw-r--r--   1 chabotd  chabotd    134663 May 24 09:23   
> mauna_print_to_comppdf.pdf
>
> For this example, different methods of producing pdf within R had
> very different file sizes. The two methods based on quartz performed
> in reverse order compare to the previous example. Overall, using
> bitmap device or postscript-transformed-to-pdf outside of R produced
> files about 10% the size of the file produced by pdf device. But the
> latter could be shrunk almost as much using pdftk.
>
> Finally, a larger-size example:
> Produced with R:
> -rw-r--r--   1 chabotd  chabotd   1426330 May 23 20:54  
> fig_ps_from_R.ps
> -rw-r--r--   1 chabotd  chabotd   3384788 May 23 20:54   
> fig_pdf_from_R.pdf
> -rw-r--r--   1 chabotd  chabotd   3494689 May 24 09:03   
> fig_pdf_bitmapR.pdf
> -rw-r--r--   1 chabotd  chabotd   3494689 May 24 10:46   
> fig_dev2bitmap.pdf
> -rw-r--r--   1 chabotd  chabotd   3384832 May 23 20:54   
> fig_pdf_from_quartz.menu.pdf
> -rw-r--r--   1 chabotd  chabotd   9583552 May 23 20:52   
> fig_pdf_from_quartz.save.pdf
>
> PS to pdf outside of R
> -rw-r--r--   1 chabotd  chabotd   3356223 May 23 21:12  
> fig_ps_ps2pdf.pdf
> -rw-r--r--   1 chabotd  chabotd  11397461 May 23 23:51   
> fig_ps_pstopdf.pdf
> -rw-r--r--   1 chabotd  chabotd   3354762 May 23 23:55   
> fig_ps_epstopdf.pdf
>
> pdf transformation outside of R
> -rw-r--r--   1 chabotd  chabotd    379307 May 23 22:31   
> fig_pdf_comptk.pdf
> -rw-r--r--   1 chabotd  chabotd    520509 May 24 00:19   
> fig_pdf_print_to_comppdf.pdf
>
> This time, as in the first example, there was little benefit going
> the bitmap device or ps to pdf route. Only shrinking the pdf with
> pdftk was effective. So examples with a lot of objects on the plot do
> not seem to benefit from postscript use, but one example with few
> objects (but objects that were "filled, don't know if it matters) did.
>
> I have never done this in R, but could the pdftk command be run from
> within a R script? This would allow one to compress automatically
> when needed.
>
> Thank you all for the suggestions,
>
> Denis
>
> ##############  R program that produced the above files
> #################
> # example 1, small
> pdf(file="test_pdf_from_R.pdf", w=5, h=5, version="1.4",
> bg="transparent")
> plot(rnorm(10000), rnorm(10000))
> dev.off()
>
> postscript(file="test_ps_from_R.ps", width=5, height=5,  
> paper="special")
> plot(rnorm(10000), rnorm(10000))
> dev.off()
>
> bitmap(file = "test_pdf_bitmapR.pdf", width=5, height=5, type =
> "pdfwrite")
> plot(rnorm(10000), rnorm(10000))
> dev.off()
>
> plot(rnorm(10000), rnorm(10000))
> quartz.save(file="test_pdf_from_quartz.save.pdf", type="pdf")
> dev2bitmap(file="test_dev2bitmap.pdf", width=5, height=5,
> type="pdfwrite")
> # here I also manually saved the quartz graphics and called it
> "test_pdf_from_quartz.menu.pdf"
>
>
> # Example from Dave Watson
>
>
> postscript(file = "mauna_ps_from_R.eps", width=5, height=5,
> horizontal=FALSE, paper="special", onefile=FALSE)
> filled.contour(volcano, color=terrain.colors, asp=1)
> title(main="volcano data: filled contour map")
> dev.off()
>
> pdf(file = "mauna_pdf_from_R.pdf", width=5, height=5)
> filled.contour(volcano, color=terrain.colors, asp=1)
> title(main="volcano data: filled contour map")
> dev.off()
>
> bitmap(file = "mauna_pdf_bitmapR.pdf", width=5, height=5, type =
> "pdfwrite")
> filled.contour(volcano, color=terrain.colors, asp=1)
> title(main="volcano data: filled contour map")
> dev.off()
>
> # on mac os x only
> quartz(w=5, h=5)
> filled.contour(volcano, color=terrain.colors, asp=1)
> title(main="volcano data: filled contour map")
> dev2bitmap(file="mauna_dev2bitmap.pdf", width=5, height=5,
> type="pdfwrite")
> quartz.save(file="mauna_pdf_from_quartz.save.pdf", type="pdf")
> # here I also manually saved the quartz graphics and called it
> "mauna_pdf_from_quartz.menu.pdf"
>
>
>
> # example 3, large
>
> x <- rep(1:99, 20)
>
> c <- 0
> for (a in 1:3) {
>   for (b in c(0.7, 0.9) ) {
>   c<-c+1
>   nam <- paste("Y", c, sep="")
>   assign(nam, a + b*x + rnorm(length(x),20,10))
>   }
>   }
> the.data <- data.frame(Y1, Y2, Y3, Y4, Y5, Y6)
> rm(Y1, Y2, Y3, Y4, Y5, Y6)
>
>
> pdf(file="fig_pdf_from_R.pdf", w=8, h=8, version="1.4",
> bg="transparent")
> pairs(the.data)
> dev.off()
>
> postscript(file="fig_ps_from_R.ps", width=8, height=8,  
> paper="special")
> pairs(the.data)
> dev.off()
>
> bitmap(file = "fig_pdf_bitmapR.pdf", width=8, height=8, type =
> "pdfwrite")
> pairs(the.data)
> dev.off()
>
> # on mac os x only
> quartz(w=8, h=8)
> pairs(the.data)
> dev2bitmap(file="fig_dev2bitmap.pdf", width=8, height=8,
> type="pdfwrite")
> quartz.save(file="fig_pdf_from_quartz.savev2.pdf", type="pdf")
> # here I also manually saved the quartz graphics and called it
> "fig_pdf_from_quartz.menu.pdf"

============


Le 7 févr. 08 à 07:24, Paul Hiemstra a écrit :

> Hi,
>
> I tried to compile gsview on my system, but that failed and because  
> CUPS-pdf works, I didn't try any further.
>
> cheers,
> Paul
>
> Gavin Simpson wrote:
>> On Thu, 2008-02-07 at 11:52 +0100, Paul Hiemstra wrote:
>>
>>> Hi all,
>>>
>>> Maybe a bit late, but I found a way that worked great for me.
>>>
>>> In windows, download CutePDF
>>> In linux (debian for me), install CUPS and cups-pdf
>>>
>>> Open your pdf with a viewer and print to CutePDF or cups-pdf. Both  
>>> support a range of compression options. I use cups-pdf and reduced  
>>> an R output file of 3.6 mb to 0.9 mb. Much better if you want to  
>>> include in a Latex article
>>>
>>
>> An alternative on Windows and Linux is GSView and Ghostscript:
>>
>> http://pages.cs.wisc.edu/~ghost/gsview/
>>
>> Using the convert option (File menu) one can use the pdfwrite  
>> driver and
>> set (under properties) CompressPages to TRUE. You can tweak a lot  
>> of the
>> PDF/Distiller preferences here as well.
>>
>> G
>>
>>
>>> cheers,
>>> Paul
>>>
>>> Chabot Denis wrote:
>>>
>>>> Hi,
>>>>
>>>> Without trying to print 1000000 points (see <http:// finzi.psych.upenn.edu/R/Rhelp02a/archive/42105.html 
>>>> >), I often print  maps for which I do not want to loose too much  
>>>> of coastline detail,  and/or plots with 1000-5000 points (yes,  
>>>> some are on top of each  other, but using transparency (i.e. rgb  
>>>> colors with alpha  information) this actually comes through as  
>>>> useful information.
>>>>
>>>> But the files are large (not as large as in the thread above of   
>>>> course, 800 KB to about 2 MB), especially when included in a  
>>>> LaTeX  document by the dozen.
>>>>
>>>> Acrobat (not the reader, the full program) has an option "reduce  
>>>> file  size". I don't know what it does, but it shrinks most of my  
>>>> plots to  about 30% or original size, and I cannot detect any  
>>>> loss of detail  even when zooming several times. But it is a pain  
>>>> to do this with  Acrobat when you generate many plots... And you  
>>>> need to buy Acrobat.
>>>>
>>>> Is this something the pdf device could do in a future version? I   
>>>> tried the "million points" example from the thread above and the  
>>>> 55  MB file was reduced to 6.9 MB, an even better shrinking I see  
>>>> on my  usual plots.
>>>>
>>>>
>>>> Denis Chabot
>>>>
>>>> ______________________________________________
>>>> R-help@stat.math.ethz.ch mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>>> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
>>>> and provide commented, minimal, self-contained, reproducible code.
>>>>
>>>
>
>
> -- 
> Drs. Paul Hiemstra
> Department of Physical Geography
> Faculty of Geosciences
> University of Utrecht
> Heidelberglaan 2
> P.O. Box 80.115
> 3508 TC Utrecht
> Phone: 	+31302535773
> Fax:	+31302531145
> http://intamap.geo.uu.nl/~paul
>


	[[alternative HTML version deleted]]

