emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Dan Davison <davison@stats.ox.ac.uk>
To: Graham Smith <myotisone@gmail.com>,
	Joseph Cole <coljo582@student.otago.ac.nz>
Cc: emacs-orgmode@gnu.org
Subject: Re: Org babel R Help
Date: Sun, 21 Mar 2010 10:19:13 -0400	[thread overview]
Message-ID: <878w9liwpq.fsf@stats.ox.ac.uk> (raw)
In-Reply-To: <2c75873c1003210253q491d221bib59d195a8c9e4e41@mail.gmail.com> (Graham Smith's message of "Sun, 21 Mar 2010 09:53:41 +0000")

Graham Smith <myotisone@gmail.com> writes:

> Joseph/Dan
>
>>>> 2) Width/Height exports for R graphics output. Do they work?
>>>>
>>>> I've tried a lot of combinations of :width and :height as exports, and
>>>> they don't seem to work at all. I've tried small numbers (1-10), large
>>>> numbers (100-2000) and numbers prefixed by "cm" with no luck.
>>>
>>> Hmm, I'm not seeing a problem here. It works for me with both png and
>>> pdf output. E.g.
>>>
>>> #+begin_src R :file z.pdf :width 20 :height 40 :exports both
>>> plot(1:10)
>>> #+end_src
>>
>>> What image format (i.e. R graphics device) are you using?  Can you post
>>> an example block that is not working? The values for :width and :height
>>> will be passed straight on to the graphics device, so their meaning
>>> depends on which graphics device is being used in R.
>>
>> I'm trying the code you posted with the latest org-mode from ubuntu and
>> getting nothing in my results if I use png.

Hi Joseph,

I also get nothing with png:
,----
| #+begin_src R :file z.png :width 20 :height 40 :exports both
`----
If you do C-c C-c on the block, you should get an error buffer
explaining why
,----
| Error in plot.new() : figure margins too large
| Calls: write.table ... inherits -> main -> plot -> plot.default -> plot.new
| Execution halted
`----
In R, for png(), jpg() et al, the default units for width and height are
pixels. For pdf() and ps() width and height are in inches. So while 20
and 40 are sensible values for pdf they are not for png.

>> If I use pdf, I get a really
>> tiny chart which is incomprehensible. Width and height seem to work
>> randomly, as using 20:40 work with pdf (although tiny), but 100,100 do not
>> work at all.

What do you mean when you say "100,100 do not work at all"? What I get
is something which looks very much like a blank plot inserted into the
pdf. However if you look closely, it is in fact a scaled down version of
a large pdf (100 inches by 100 inches). The axes, plotting characters
and label annotation are very hard to see because they have not been
scaled up and are tiny relative to the plot dimensions.

>>
>> It only works correctly if I use the #+attr_latex: width=Xcm and omit the
>> width and height.
>
> Based on what is happening here with me on Ubuntu 9.10, R 2.10 and orgmode 6.34.
>
> The  ":file z.pdf :width 20 :height 40 :exports both"  is affecting
> the size of the graphic that R produces. If you open x.pdf directly
> you will find that it changes size as expected.
>
> BUT regardless of the size of the z.pdf, Latex defaults to a fixed,
> and tiny, standard size.  Unless you give an explicit latex command
> #+attr_latex: width=Xcm
>

Thanks Graham for the further explanation.

So I believe we do understand the situation. The question is how do we
improve it. First the facts:

1. With png R graphics :width and :height specify pixel dimensions and
   must be sensible for the graphic to be produced without an R error.
2. With pdf R graphics, :width and :height are in inches. However, the
   pdf output produced by org rescales the resulting image down to a
   small default size.

So as Graham has explained, a good approach at the moment is to create
the graphics with C-c C-c in buffer, get rid of ':exports both', and
manually insert an ATTR_LaTeX line. You may or may not want to
use :width and :height to set plot dimensions in R, in addition to the
rescaling at the latex stage. See also Graham's recent thread

"[babel] captions and figure size on export"
http://comments.gmane.org/gmane.emacs.orgmode/22837

As for improvements, it is tempting to think that 

1. org-babel should automatically insert the ATTR_LaTeX line in
   accordance with :width and :height when creating latex output.
2. org-babel should keep existing ATTR_LaTeX lines attached to their
   respective figures (contra Graham's thread linked above)

I've had a brief look and doubtless all this is possible. It brings up
issues of what units :width and :height are assumed to be in (e.g. just
because R uses inches for pdf() doesn't mean that anyone else thinks
that's a sensible decision). And we have to be a careful because it
means altering what org-babel considers to be part of its results.

>
>> Using babel. For some reason my R graphics embedded within my pdf's don't
>> seem to be as "nice" as viewing them from within R, i.e. slightly fuzzy
>> edges. It's like the antialiasing has failed or something. The text labels
>> on the axes are definitely not up to latex standard.

OK, well we definitely don't want org-babel to be producing sub-par pdf
images, so it would be very helpful if you could help us further
here. First, can we determine whether this is an org-mode/org-babel
issue or an R/latex/pdf issue? E.g. If you create a pdf in R and embed
it in a LaTeX document manually does it come out looking better than the
equivalent operation done in org-babel? What about if you use postscript
output rather than pdf? If you use Sweave, how does the image in the pdf
output of Sweave compare to that of org-babel? Any further
investigations here would be much appreciated.

Dan


>
> Are you just viewing them or printing them. I find with Ubuntu that
> the default viewer seems to arbitrarily  change between programs and
> the quality of graphics on the screen varies, but the quality of
> printed output stays the same. Try opening the final PDF in an
> alternative viewer and see if things still appear the same.


>
> Graham
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

  reply	other threads:[~2010-03-21 14:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-19  8:01 Org babel R Help Joseph Cole
2010-03-19 14:30 ` Dan Davison
     [not found]   ` <5084fc611003210151x41850afcg36b275679ae76acb@mail.gmail.com>
2010-03-21  9:18     ` Joseph Cole
2010-03-21  9:53       ` Graham Smith
2010-03-21 14:19         ` Dan Davison [this message]
2010-03-21 17:45           ` Graham Smith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878w9liwpq.fsf@stats.ox.ac.uk \
    --to=davison@stats.ox.ac.uk \
    --cc=coljo582@student.otago.ac.nz \
    --cc=emacs-orgmode@gnu.org \
    --cc=myotisone@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).