Re: [Rd] Links to non-vignette documentation

From: Berwin A Turlach <berwin_at_maths.uwa.edu.au>
Date: Sat 25 Feb 2006 - 07:41:13 GMT

G'day all,

>>>>> "DM" == Duncan Murdoch <murdoch@stats.uwo.ca> writes:

    DM> On 2/24/2006 7:27 AM, Romain Francois wrote:

    >> 
    >> What about using the latex package pdfpages to copy the pages from your 
    >> PDF file `interface96.pdf` to your Sweave file. 
Merci beaucoup, I wasn't aware that this style file exists, it definitely seems to be useful.
    DM> That's a nice hack.  You probably want the "fitpaper" option on the 
    DM> \includepdf command, so that you don't get an extra border around the 
    DM> page.  For example, this file test.Rnw [...]

    DM> \includepdf[fitpaper=true]{response.pdf} Additionally, if response.pdf has several pages and you want to include them all, you should also include a "pages" options, such as:

        \includepdf[fitpaper=true,pages=-]{interface96.pdf}

More details can be found in the pdfpages documentation, but by default only the first page is included.

    DM> produces an output that looks pretty much exactly like the     DM> "response.pdf" file I used as test input in a viewer. Perhaps interface96.pdf was created too long ago (it says PDF 1.2 at the top of that file), but the result looks strange in xpdf (the included pages are quite small and in the upper left corner, selecting "fit to page" creates an acceptable viewing results); no problem with acroread. This is on a linux box.

    DM> The only disadvantages I see are that both the test.pdf and
    DM> response.pdf files got built into the package (but only
    DM> test.pdf shows up in the index),
That is a potential disadvantage as it duplicates material. But I guess .Rbuildignore in the main directory of the package can help in this case. I have put the line "inst/doc/interface96.pdf" into the .Rbuildignore file of that package.
    DM> and that test.pdf is a lot larger than response.pdf.  (This
    DM> may be because response.pdf was small; I haven't checked if
    DM> the increase is additive or multiplicative).
I didn't check this either, but here are some results on including a 6 page pdf file (extracts from looking at the .tar.gz file produced by the build process). First, the old solution with a separate PDF file and a dummy vignette:
 drwxr-xr-x  berwin/berwin        0 clps/inst/
 drwxr-xr-x  berwin/berwin        0 clps/inst/doc/

-rw-r--r-- berwin/berwin 649 clps/inst/doc/clps.bib
-rw-r--r-- berwin/berwin 670 clps/inst/doc/interface96-vignette.Rnw
-rw-r--r-- berwin/berwin 105035 clps/inst/doc/interface96.pdf
-rw-r--r-- berwin/berwin 49242 clps/inst/doc/interface96-vignette.pdf
 

Second, with \includepdf and .Rbuildignore:

 drwxr-xr-x  berwin/berwin        0 clps/inst/
 drwxr-xr-x  berwin/berwin        0 clps/inst/doc/

-rw-r--r-- berwin/berwin 649 clps/inst/doc/clps.bib
-rw-r--r-- berwin/berwin 440 clps/inst/doc/interface96-vignette.Rnw
-rw-r--r-- berwin/berwin 191589 clps/inst/doc/interface96-vignette.pdf

Looks like an increase of about 40 kB to me which I would find acceptable.

    DM> A change to the R package build process would be to add support for a     DM> command like

    DM> %\VignetteExists

    DM> to the test.Rnw file, telling R not to bother trying to build the pdf, 
    DM> because it had already been built by other means.  Then I'd just have 
    DM> test.Rnw containing

Searching the "Writing R Extensions" manual for vignette, I noticed the following:
      Unless @kbd{R CMD build} is invoked with the
      @option{--no-vignettes} option, it will attempt to rebuild the
      vignettes (@pxref{Writing package vignettes}) in the package.
      To do so it installs the current package/bundle into a temporary
      library tree, but any dependent packages need to be installed in
      an available library tree (see the Note: below).

Thus there is already a mechanism to avoid (automatic) rebuilding of vignettes. But it seems to be a "all-or-nothing" solution and I could imagine that some packages might have "real" vignettes that the maintainer would like to have rebuild automatically and "dummy" vignettes that should not be rebuild. So a fine-grained control, along the way that you suggest, would be a nice way.

>>>>> "HT" == Hin-Tak Leung <hin-tak.leung@cimr.cam.ac.uk> writes:

    HT> I like pdfpages and do use it from time to time [...]  so such
    HT> constructions would break on sites which hasn't upgraded their
    HT> LaTeX installation in the last 3 years.
The "Writing R Extensions" manual states on page 15:
      @code{R CMD build} will automatically create PDF versions of the
      vignettes for distribution with the package sources.  By
      including the PDF version in the package sources it is not
      necessary that the vignettes can be compiled at install time,
      i.e., the package author can use private @LaTeX{} extensions
      which are only available on his machine.  Only the @R{} code
      inside the vignettes is part of the checking procedure,
      typesetting manuals is not part of the package QC.

Thus, only the (La)TeX installation of the maintainer of a package has to be on a reasonably up-to-date level to use such a construction.

Thanks everybody for their input and comments.

Cheers,

        Berwin



R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Sat Feb 25 18:50:02 2006

This archive was generated by hypermail 2.1.8 : Sat 25 Feb 2006 - 10:15:53 GMT