several odfWeave questions

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

several odfWeave questions

bbolker
 [Sending both to the maintainer and to R-help, in case anyone else has
answers ...]

  I've looked in odfWeave documentation, vignette, and poked around on
the web some, and haven't found answers yet.

  1a. am I right in believing that odfWeave does not respect the
'keep.source' option?  Am I missing something obvious?

  1b. is there a way to set global options analogous to \SweaveOpts{}
directives in Sweave? (I looked at odfWeaveControl, it doesn't seem to
do it.)

  2. I tried to write a Makefile directive to process files from the
command line:

%.odt: %_in.odt
        $(RSCRIPT) -e "library(odfWeave);
odfWeave(\"$*_in.odt\",\"$*.odt\");"

  This works, *but* the resulting output file gives a warning ("The file
'odftest2.odt' is corrupt and therefore cannot be opened.
OpenOffice.org can try to repair the file ...").  Based on looking at
the contents, it seems that a spurious/unnecessary 'Rplots.pdf' file is getting
created and zipped in with the rest of the archive; when I unzip, delete
the Rplots.pdf file and re-zip, the ODT file opens without a warning.
Obviously I could post-process but it would be nicer to find a
workaround within R ...

  3. I find the requirement that all file paths be specified as absolute
rather than relative paths somewhat annoying -- I understand the reason,
but it goes against one practice that I try to encourage for
reproducibility, which is *not* to use absolute file paths -- when
moving a same set of data and analysis files across computers, it's hard
to enforce them all ending up in the same absolute location, which then
means that the recipient has to edit the ODT file.  It would be nice if
there were hooks for read.table() and load() as there are for plotting
and package/namespace loading -- then one could just copy them into the
working directory on the fly.
   has anyone experienced this/thought of any workarounds?
  (I guess one solution is to zip any necessary source files into the archive beforehand,
as illustrated in the vignette.)

  My test files are posted at
http://www.math.mcmaster.ca/~bolker/junk/odftest_in.odt and
http://www.math.mcmaster.ca/~bolker/junk/odftest.odt

 thanks,
    Ben Bolker


> > sessionInfo()
>  
R version 2.11.1 (2010-05-31)
i486-pc-linux-gnu

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=C              LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] odfWeave_0.7.16 XML_3.1-1       lattice_0.19-9

loaded via a namespace (and not attached):
[1] grid_2.11.1

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: several odfWeave questions

Mxkuhn
Ben,

>  1a. am I right in believing that odfWeave does not respect the
> 'keep.source' option?  Am I missing something obvious?

I believe it does, since this gets passed directly to Sweave.

>  1b. is there a way to set global options analogous to \SweaveOpts{}
> directives in Sweave? (I looked at odfWeaveControl, it doesn't seem to
> do it.)

Yes. There are examples of this in the 'examples' package directory.

>  2. I tried to write a Makefile directive to process files from the
> command line:
>
> %.odt: %_in.odt
>        $(RSCRIPT) -e "library(odfWeave);
> odfWeave(\"$*_in.odt\",\"$*.odt\");"
>
>  This works, *but* the resulting output file gives a warning ("The file
> 'odftest2.odt' is corrupt and therefore cannot be opened.
> OpenOffice.org can try to repair the file ...").  Based on looking at
> the contents, it seems that a spurious/unnecessary 'Rplots.pdf' file is getting
> created and zipped in with the rest of the archive; when I unzip, delete
> the Rplots.pdf file and re-zip, the ODT file opens without a warning.
> Obviously I could post-process but it would be nicer to find a
> workaround within R ...

Get the latest version form R-Forge. I haven't gotten this fix onto
CRAN yet (I've been on a caret streak lately).

>  3. I find the requirement that all file paths be specified as absolute
> rather than relative paths somewhat annoying -- I understand the reason,
> but it goes against one practice that I try to encourage for
> reproducibility, which is *not* to use absolute file paths -- when
> moving a same set of data and analysis files across computers, it's hard
> to enforce them all ending up in the same absolute location, which then
> means that the recipient has to edit the ODT file.  It would be nice if
> there were hooks for read.table() and load() as there are for plotting
> and package/namespace loading -- then one could just copy them into the
> working directory on the fly.
>   has anyone experienced this/thought of any workarounds?
>  (I guess one solution is to zip any necessary source files into the archive beforehand,
> as illustrated in the vignette.)

You can set the working directory with the (wait for it...) 'workDir'
argument. Using 'workDir = getwd()' will pack and unpack the files in
the current location and you wouldn't need to worry about setting the
path. I use the temp directory because I started over-wrting files.

Max

______________________________________________
[hidden email] 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.