invalid graphics state using dev.print (fwd)

"Paul" == Paul Roebuck <roebuck at mdanderson.org>
    on Wed, 8 Feb 2006 15:33:11 -0600 (CST) writes:

"Paul" == Paul Roebuck <roebuck at mdanderson.org>
   on Wed, 8 Feb 2006 15:33:11 -0600 (CST) writes:

    Paul> On Mon, 6 Feb 2006 18:12, Simon Urbanek wrote:

    >> On Feb 6, 2006, at 5:24 PM, Paul Roebuck wrote:
    >> 

    >>> Tried on R-Sig-Mac with no responses, but I need some kind
    >>> of answer.
    >>> [...]
    >>> Does the following work on your system?

    >> 
    >> Interesting, no, it doesn't either. For png and pdf I use
    >> Quartz + quartz.save (it produces much nicer results) so
    >> I didn't really notice, but you're right. First I thought
    >> those graphics state issues are specific to the Quartz
    >> device, but you have proven that it's not. It's in fact
    >> not even Mac-specific - I have just reproduced it on a
    >> Linux box - that's why I'm moving this to R-devel.

    Paul> It's been several workdays now with no responses. Could
    Paul> someone try the last three lines of code and see if they
    Paul> get the following error message?

    >> x11()
    >> plot(rnorm(10))
    >> dev.print(png)

    Paul> Error in dev.copy(device = function (filename = "Rplot%03d.png", width =
    Paul> 480,  :
    Paul> invalid graphics state

    >> traceback()

    Paul> 6: dev.copy(device = function (filename = "Rplot%03d.png", width = 480,
    Paul> height = 480, pointsize = 12, gamma = 1, colortype =
    Paul> getOption("X11colortype"),
    Paul> maxcubesize = 256, bg = "white", fonts = getOption("X11fonts"),
    Paul> res = NA)
    Paul> .Internal(X11(paste("png::", filename, sep = ""), width, height,
    Paul> pointsize, gamma, colortype, maxcubesize, bg, bg, fonts,
    Paul> res)), width = 6.98715785526809, height = 6.99452568428947)
    Paul> 5: eval(expr, envir, enclos)
    Paul> 4: eval(expr, p)
    Paul> 3: eval.parent(oc)
    Paul> 2: dev.off(eval.parent(oc))
    Paul> 1: dev.print(png)

    Paul> I noticed it on OS X, and Simon on Linux. 

Yes, I can confim getting the same.
Just on Linux though (as Simon)

I'd say this should make a ``nice little''  bug.report() 

Interestingly, replacing

    dev.print(png)

by  dev.copy(png) ; dev.off()  

which is about equivalent,  *does* work and so is a workaround
to your problem.

    Paul> Other platforms?  WFM?

    Paul> TIA

    >> version

    Paul> _
    Paul> platform powerpc-apple-darwin7.9.0
    Paul> arch     powerpc
    Paul> os       darwin7.9.0
    Paul> system   powerpc, darwin7.9.0
    Paul> status   Patched
    Paul> major    2
    Paul> minor    2.1
    Paul> year     2006
    Paul> month    02
    Paul> day      01
    Paul> svn rev  37245
    Paul> language R

    Paul> ----------------------------------------------------------
    Paul> SIGSIG -- signature too long (core dumped)

   >> x11()
   >> plot(rnorm(10))
   >> dev.print(png)

    Paul> Error in dev.copy(device = function (filename = "Rplot%03d.png", width =
    Paul> 480,  :
    Paul> invalid graphics state

I think the problem is that the width and height of the PNG device is
being taken (without regard for units) from the X11 device.  So
approximately 7 inches square screen window gets drawn into
approximately 7 *pixel* square PNG file and (understandably) R complains
that there is not enough room for the plot.

Another workaround is something like ...

dev.print(png, width=480, height=480)

... and a fix requires making dev.print() smarter so that it figures out
that it needs to convert width/height from inches to pixels.

On Mon, 20 Feb 2006, Paul Murrell wrote:

[...]

  >> x11()
  >> plot(rnorm(10))
  >> dev.print(png)

    Paul> Error in dev.copy(device = function (filename = "Rplot%03d.png", width =
    Paul> 480,  :
    Paul> invalid graphics state

I think the problem is that the width and height of the PNG device is
being taken (without regard for units) from the X11 device.  So
approximately 7 inches square screen window gets drawn into
approximately 7 *pixel* square PNG file and (understandably) R complains
that there is not enough room for the plot.

Yes, that it how it is documented to work.

Another workaround is something like ...

dev.print(png, width=480, height=480)

(Just one will do if you want to preserve the aspect ratio.)

... and a fix requires making dev.print() smarter so that it figures out
that it needs to convert width/height from inches to pixels.

I don't think there is a way to do that unambiguously (there is no
standard way to do the conversion), and in any case dev.print() was passed
a function, not the name of a function, and so does not in general know
how it behaves (and your 'png' need not be R's png()).

All we can do is to re-emphasize this on the help page, and add a warning
if a known bitmap device is detected (possibly inaccurately) by name.

On Mon, 20 Feb 2006, Paul Murrell wrote:

[...]

   >> x11()
   >> plot(rnorm(10))
   >> dev.print(png)

    Paul> Error in dev.copy(device = function (filename = "Rplot%03d.png", width =
    Paul> 480,  :
    Paul> invalid graphics state

I think the problem is that the width and height of the PNG device is
being taken (without regard for units) from the X11 device.  So
approximately 7 inches square screen window gets drawn into
approximately 7 *pixel* square PNG file and (understandably) R complains
that there is not enough room for the plot.

Yes, that it how it is documented to work.

Another workaround is something like ...

dev.print(png, width=480, height=480)

(Just one will do if you want to preserve the aspect ratio.)

... and a fix requires making dev.print() smarter so that it figures out
that it needs to convert width/height from inches to pixels.

I don't think there is a way to do that unambiguously (there is no
standard way to do the conversion)

..., and in any case dev.print() was passed
a function, not the name of a function, and so does not in general know
how it behaves (and your 'png' need not be R's png()).

All we can do is to re-emphasize this on the help page, and add a warning
if a known bitmap device is detected (possibly inaccurately) by name.

str(dev.cur())

BTW, I think it was perverse to call dev.print() except to do printing.

On Mon, 20 Feb 2006, Prof Brian Ripley wrote:

On Mon, 20 Feb 2006, Paul Murrell wrote:

 >> x11()
 >> plot(rnorm(10))
 >> dev.print(png)

I don't think there is a way to do that unambiguously (there is no
standard way to do the conversion), and in any case dev.print() was passed
a function, not the name of a function, and so does not in general know
how it behaves (and your 'png' need not be R's png()).

Prof Brian Ripley wrote:

On Mon, 20 Feb 2006, Prof Brian Ripley wrote:

On Mon, 20 Feb 2006, Paul Murrell wrote:

<snipped>

 >> x11()
 >> plot(rnorm(10))
 >> dev.print(png)

<snipped>

I don't think there is a way to do that unambiguously (there is no
standard way to do the conversion), and in any case dev.print() was passed
a function, not the name of a function, and so does not in general know
how it behaves (and your 'png' need not be R's png()).

There is a "standard" way of querying the X display directly about
the size each pixel supposedly represents - well, an X display can
be configured wrongly, etc, but you get what you ask for...

$ xdpyinfo |grep 'resolution'
 resolution:    75x75 dots per inch

(this 75x75 seems to be a default value as I did not set it anywhere,
but I believe it is configurable)

I am not sure about png files, but tiff files also have internal data
claiming x pixels corresponds to y inches. (and I am fairly sure jpeg
does *not* have this feature).