invalid graphics state using dev.print (fwd)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

invalid graphics state using dev.print (fwd)

Paul Roebuck
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.

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

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

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

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

I noticed it on OS X, and Simon on Linux. Other platforms?
WFM?

TIA

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

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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: invalid graphics state using dev.print (fwd)

Martin Maechler
>>>>> "Paul" == Paul Roebuck <[hidden email]>
>>>>>     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.

Regards,
Martin

    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)

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: invalid graphics state using dev.print (fwd)

Paul Murrell
Hi


Martin Maechler wrote:

>>>>>>"Paul" == Paul Roebuck <[hidden email]>
>>>>>>    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.


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.

Paul


>     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)
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
[hidden email]
http://www.stat.auckland.ac.nz/~paul/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: invalid graphics state using dev.print (fwd)

Prof Brian Ripley
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.

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

--
Brian D. Ripley,                  [hidden email]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: invalid graphics state using dev.print (fwd)

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

> 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.

One more thing we can do is to get the devices to issue a warning if the
'width' and 'height' arguments appear inappropriate.  Since one might want
to produce long thin plots, I've decided to do so if
width < 20 && height < 20.   Even those are just about plausible if you
were trying to produce a small icon.

--
Brian D. Ripley,                  [hidden email]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: invalid graphics state using dev.print (fwd)

Paul Roebuck
In reply to this post by Prof Brian Ripley
On Mon, 20 Feb 2006, Prof Brian Ripley wrote:

> 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.

Might have snapped to this if the error message had said something
less vague.

> > 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)

What is the recommended method of converting width/height
from inches to pixels (preserving aspect ratio), even if
ambiguous?

> ..., 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.

Perhaps an extra attribute could be added to each device
where attr("type") = c("bitmap", "vector")

> str(dev.cur())
 Named int 2
 - attr(*, "names")= chr "quartz"
 - attr(*, "type")= chr "vector"

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

I was making a hardcopy of my plot which IMO would seem
a legitimate usage. Don't understand your "perverse"
comment here. Alternative recommendation?

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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: invalid graphics state using dev.print (fwd)

Hin-Tak Leung-2
In reply to this post by Prof Brian Ripley
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).

HTL

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: invalid graphics state using dev.print (fwd)

Prof Brian Ripley
On Tue, 21 Feb 2006, Hin-Tak Leung wrote:

> 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)

Yes, but this is png, not X11.  The resolution of your X11 screen is
unrelated to a .png file you might produce.

> 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).

Reading the help page for the R devices will enlighten you.  (Really, you
should do so before posting as we do ask.)  An assumption of 72ppi is
quite common, but so are 180 and 300.

The png/jpeg devices now tell careless users that small width/height
values are probably a mistake.

--
Brian D. Ripley,                  [hidden email]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel