G'day all,
>>>>> "DM" == Duncan Murdoch <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
