[Rd] Links to non-vignette documentation

[Berwin A Turlach]

G'day all,

>>>>> "DM" == Duncan Murdoch <murdoch at 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 at 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