Re: [Rd] Wayland Display Support in R Plot
Hi I am unaware of any Wayland display support. One useful way forward would be an R package that provides such a device (along the lines of 'Cairo', 'tikzDevice', et al) Paul On 27/10/23 23:16, quentin.thorne via R-devel wrote: Hello, I'm interested in understanding the current state of Wayland display support in R plot, and I was wondering if any progress or discussions have taken place regarding this matter. As Wayland continues to gain popularity as a display protocol on modern Linux systems, having Wayland support for R's plotting capabilities would be a significant enhancement. Could anyone provide information on the current status of Wayland support in R plot? Are there any ongoing efforts, discussions, or packages in development that address this issue? I would appreciate any insights or guidance in this regard. Thank you for your time and assistance. Best regards, Quentin Thorne [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel <https://stat.ethz.ch/mailman/listinfo/r-devel> -- Dr Paul Murrell Te Kura Tatauranga | Department of Statistics Waipapa Taumata Rau | The University of Auckland Private Bag 92019, Auckland 1142, New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] proposal: 'dev.capabilities()' can also query Unicode capabilities of current graphics device
Hi
Yes, you can set up your own font and TeX installations are a good
source of Type 1 fonts. Here is an example (paths obviously specific to
my [Ubuntu 20.04] OS and TeX installation) ...
cmlgc <- Type1Font("cmlgc",
rep("/usr/share/texlive/texmf-dist/fonts/afm/public/cm-lgc/fcmr6z.afm", 4),
encoding="Cyrillic")
pdfFonts(cmlgc=cmlgc)
x <- '\u410\u411\u412'
pdf("cmlgc.pdf", family="cmlgc", encoding="Cyrillic")
plot(1:10, main = x)
dev.off()
embedFonts("cmlgc.pdf", out="cmlgc-embed.pdf",
fontpaths="/usr/share/texlive/texmf-dist/fonts/type1/public/cm-lgc/")
Final result attached.
Thanks for the patch for the unrelated memory problem; I will take a
look at that.
Paul
On 24/09/23 09:43, Ivan Krylov wrote:
On Wed, 20 Sep 2023 12:39:50 +0200
Martin Maechler wrote:
> The problem is that some pdf *viewers*,
> notably `evince` on Fedora Linux, for several years now,
> do *not* show *some* of the UTF-8 glyphs because they do not use
> the correct fonts
One more problem that makes it nontrivial to use Unicode with pdf() is
the graphics device not knowing some of the font metrics:
x <- '\u410\u411\u412'
pdf()
plot(1:10, main = x)
# Warning messages:
# 1: In title(...) : font width unknown for character 0xb0
# 2: In title(...) : font width unknown for character 0xe4
# 3: In title(...) : font width unknown for character 0xfc
# 4: In title(...) : font width unknown for character 0x7f
dev.off()
In the resulting PDF file, the three letters are visible, at least in
Evince 3.38.2, but they are all positioned in the same space.
I understand that this is strictly speaking not pdf()'s fault
(grDevices contains the font metrics for all standard Adobe fonts and a
few more), but I'm not sure what to do as a user. Should I call
pdfFonts(...), declaring a font with all symbols I need? Where does one
even get Type-1 Cyrillic Helvetica (or any other font) with separate
font metrics files for use with pdf()?
Actually, the wrong number of sometimes random character codes reminds
me of stack garbage. In src/library/grDevices/src/devPS.c, function
static double PostScriptStringWidth, there's this bit of code:
if(!strIsASCII((char *) str) &&
/*
* Every fifth font is a symbol font:
* see postscriptFonts()
*/
(face % 5) != 0) {
R_CheckStack2(strlen((char *)str)+1);
char buff[strlen((char *)str)+1];
/* Output string cannot be longer */
mbcsToSbcs((char *)str, buff, encoding, enc);
str1 = (unsigned char *)buff;
}
Later the characters in str1 are iterated over in order to calculate
the total width of the string. I didn't notice this myself until I saw
in the debugger that after a few iterations of the loop, the contents
of str1 are completely different from the result of mbcsToSbcs((char
*)str, buff, encoding, enc), and went to investigate. Only after the
debugger told me that there's no variable called "buff" I realised that
the VLA pointed to by str1 no longer exists.
--- src/library/grDevices/src/devPS.c (revision 85214)
+++ src/library/grDevices/src/devPS.c (working copy)
@@ -721,6 +721,8 @@
unsigned char p1, p2;
int status;
+ /* May be about to allocate */
+ void *alloc = vmaxget();
if(!metrics && (face % 5) != 0) {
/* This is the CID font case, and should only happen for
non-symbol fonts. So we assume monospaced with multipliers.
@@ -755,9 +757,8 @@
* Every fifth font is a symbol font:
* see postscriptFonts()
*/
- (face % 5) != 0) {
- R_CheckStack2(strlen((char *)str)+1);
- char buff[strlen((char *)str)+1];
+ (face % 5) != 0 && metrics) {
+ char *buff = R_alloc(strlen((char *)str)+1, 1);
/* Output string cannot be longer */
mbcsToSbcs((char *)str, buff, encoding, enc);
str1 = (unsigned char *)buff;
@@ -792,6 +793,7 @@
}
}
}
+ vmaxset(alloc);
return 0.001 * sum;
}
After this patch, I'm consistently getting the right character codes in
the warnings, but I still don't know how to set up the font metrics.
--
Best regards,
Ivan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
<https://stat.ethz.ch/mailman/listinfo/r-devel>
--
Dr Paul Murrell
Te Kura Tatauranga | Department of Statistics
Waipapa Taumata Rau | The University of Auckland
Private Bag 92019, Auckland 1142, New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
www.stat.auckland.ac.nz/~paul/
cmlgc-embed.pdf
Description: Adobe PDF document
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Tight bounding box around text in graphics?
Hi
strheight(), which is based GEStrHeight(), is pretty crude, not only
ignoring descenders, but also only considering the ascent of the overall
font (capital "M").
There is a GEStrMetric(), which returns character-specific ascent and
descent, but that is only currently exposed via grid::stringAscent() and
grid::stringDescent(). There is also grid::stringHeight(), which is as
unsubtle as strheight().
For example, these are all the same (just font ascent) ...
> strheight("y", "in")
[1] 0.1248031
> strheight("x", "in")
[1] 0.1248031
> strheight("M", "in")
[1] 0.1248031
... and these are all the same ...
> convertHeight(stringHeight("y"), "in")
[1] 0.124803149606299inches
> convertHeight(stringHeight("x"), "in")
[1] 0.124803149606299inches
> convertHeight(stringAscent("M"), "in")
[1] 0.124803149606299inches
... but these have more detail ...
> convertHeight(stringAscent("y"), "in")
[1] 0.0936023622047244inches
> convertHeight(stringDescent("y"), "in")
[1] 0.0416010498687664inches
> convertHeight(stringAscent("x"), "in")
[1] 0.0936023622047244inches
> convertHeight(stringDescent("x"), "in")
[1] 0inches
> convertHeight(stringHeight("M"), "in")
[1] 0.124803149606299inches
> convertHeight(stringDescent("M"), "in")
[1] 0inches
In theory, it should not be difficult to add a graphics::strascent() and
graphics::strdescent() if that would help.
Paul
On 26/09/23 08:06, Duncan Murdoch wrote:
I've mentioned in previous messages that I'm trying to redo rgl text.
Part of what I need is to measure the size of strings in pixels when
they are drawn by base graphics.
It appears that
strwidth(texts, "user", cex = cex, font = font, family = family)
gives accurate measurements of the width in user coordinates. I've got
those set up to match pixels, so I'm fine here.
However, the equivalent call for strheight() only measures height above
the baseline according to the docs, and indeed the number is smaller
than the size of what's displayed. Descenders (e.g. the tail of "y")
aren't counted.
Is there a way to measure how far a character might descend? Is it
valid to assume it won't descend more than a line height below the top
of the char?
I have a partial solution -- textshaping::shape_text gives a "height"
value that includes lots of space below the character, and a
"top_border" value that measures from the top of the textbox to the
baseline. So I think `height - top_border` would give me what I'm
asking for. But this only works with graphics devices in the ragg
package. Is there a general solution?
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
<https://stat.ethz.ch/mailman/listinfo/r-devel>
--
Dr Paul Murrell
Te Kura Tatauranga | Department of Statistics
Waipapa Taumata Rau | The University of Auckland
Private Bag 92019, Auckland 1142, New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] proposal: 'dev.capabilities()' can also query Unicode capabilities of current graphics device
Hi
The problem is what "supports UNICODE" means.
Graphics devices have a 'hasTextUTF8' boolean to indicate that ...
/* Some devices can plot UTF-8 text directly without converting
to the native encoding, e.g. windows(), quartz()
If this flag is true, all text *not in the symbol font* is sent
in UTF8 to the textUTF8/strWidthUTF8 entry points.
... and this is TRUE for the pdf() device for example.
It is also TRUE for Cairo devices, but the support is quite different
(as your examples demonstrate).
The Cairo devices do not alter UTF8 text at all, but the pdf() device
attempts to convert to a single-byte representation, which of course
will not always work.
The situation is only made more complex with the recent dev->glyph()
support because that offers another possible route to producing generic
UNICODE characters, including on pdf() devices.
Paul
On 21/09/23 04:12, Trevor Davis wrote:
> However, pdf() *does* support Unicode.
When I run a simple Unicode example like:
```
f <- tempfile(fileext = ".pdf")
pdf(f)
# U+2655 ♥ is found in most (all?) "sans" fonts like Arial, Dejavu Sans,
Arimo, etc.
# However, it is not in the Latin-1 encoding
grid::grid.text("\u2665")
dev.off()
```
I observe the following output:
```
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for <99>
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for <99>
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
```
When I open up the pdf file I just see three dots and not a heart as I
expected even if I open it up with `xpdf`.
In contrast the pdf generated by `cairo_pdf()` has a heart without
generating any warnings.
Avoiding such WARNINGs on certain CRAN check machines when I have a Unicode
graphics example that is worth including in a package's examples (if
protected by an appropriate if statement) is my main use case for such a
new feature. However, a new feature like `dev.capabilities()$unicode`
could certainly return something more sophisticated than a crude `TRUE` and
`FALSE` to distinguish between levels of Unicode support provided by
different graphics devices.
Thanks,
Trevor
On Wed, Sep 20, 2023 at 3:39 AM Martin Maechler
wrote:
> >>>>> Trevor Davis
> >>>>> on Thu, 31 Aug 2023 13:49:03 -0700 writes:
>
> > Hi,
>
> > It would be nice if `grDevices::dev.capabilities()` could also be
> used to
> > query whether the current graphics device supports Unicode. In such
> a case
> > I'd expect it to return `FALSE` if `pdf()` is the current graphics
> device
> > and something else for the Cairo or Quartz devices.
>
> > Thanks,
> > Trevor
>
> I agree in principle that this would be useful new feature for
> dev.capabilities()
>
> However, pdf() *does* support Unicode.
>
> The problem is that some pdf *viewers*,
> notably `evince` on Fedora Linux, for several years now,
> do *not* show *some* of the UTF-8 glyphs because they do not use
> the correct fonts {which *are* on the machine; good old `xpdf`
> does in that case show the glyphs}.
>
> Martin
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
<https://stat.ethz.ch/mailman/listinfo/r-devel>
--
Dr Paul Murrell
Te Kura Tatauranga | Department of Statistics
Waipapa Taumata Rau | The University of Auckland
Private Bag 92019, Auckland 1142, New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistency in grid::grid.polyline
Hi
The general "evolution" of grid.*() functions (that I have written) have
tended towards the grid.polyline() style ...
grid.*(...) {
grid.draw(*Grob(...))
}
With my thinking at least heading towards: if you are calling grid.*(),
then you want to actually draw something; if you want to just create a
description of something to draw, then you want to call *Grob().
In other words, I have come to view the 'draw' argument to grid.*() as
redundant.
That reflects how I use 'grid', so I may be unaware of an important
counter argument.
Paul
On 25/03/23 13:02, mikefc wrote:
Caution - Forged External Domain!
This e-mail cannot be validated and may not have been sent by the sender
shown in the 'From' field.
If you were not expecting to receive this e-mail we recommend you
contact the sender to confirm that they sent it.
If you believe this email was legitimately sent, we suggest the sender
notify their e-mail administrator that it has been received as a forged
(fake) e-mail by the University of Auckland.
Please contact the Staff Service Centre on extension 86000 if you
require further assistance.
Hi Paul and R-devel team,
There is an inconsistency in the definition of “grid.polyline” in
comparison to the other grid.* functions.
grid.polyline() simply passes all args (specified via … only) to
polylineGrob() and unconditionally calls grid.draw() on the returned object.
In contrast, all other functions in the grid.* family have a full set of
named arguments (reflecting the arguments to the *Grob() form of the
function). Internally to each of the grid.* family of functions, a draw
argument is used to enable/disable the drawing of the object at call time.
Is this a conscious choice? Should grid.polyline() behave like the
other grid.*() functions?
Kind regards,
Mike.
--
Dr Paul Murrell
Te Kura Tatauranga | Department of Statistics
Waipapa Taumata Rau | The University of Auckland
Private Bag 92019, Auckland 1142, New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about grid.group compositing operators in cairo
Hi This issue has expanded to include the behaviour of compositing operators in R graphics more generally. For the record, the discussion is continuing here ... https://github.com/pmur002/rgraphics-compositing Paul On 4/10/22 09:20, Paul Murrell wrote: Interim update: I have spoken with Thomas Lin Pedersen (cc'ed), the author/maintainer of 'ragg' and 'svglite', who is working on adding group support for those graphics devices and he has voted in support of the current Cairo implementation, so the needle has shifted towards Cairo at this stage. I still want to do more tests on other devices to gather more evidence. Paul p.s. Attached (if it makes it through the filters) is a manual modification of your original dsvg() example that has been changed so that it produces the Cairo result. This is probably not exactly how you would want to implement the dsvg() solution, but it is at least a proof of concept that the Cairo result can be produced in SVG. On 30/09/22 10:49, Paul Murrell wrote: Hi Some more thoughts ... <1> I said before that currently, dev->group() does this ... [OVER] shape shape shape OP shape shape shape ... and one option would be an implicit group on 'src' and 'dst' like this ... ([OVER] shape shape shape) OP ([OVER] shape shape shape) ... but another approach could be just an implicit group on each shape, like this ... [OVER] ([OVER] shape) ([OVER] shape) OP ([OVER] shape) ([OVER] shape) That may be a better representation of what you are already doing with dsvg() ? It may also better reflect what naturally occurs in some graphics systems. <2> Changing the Cairo implementation to work like that would I think produce the same result as your dsvg() for ... grid.group(src, "in", dst) ... and it would make what constitutes more than one shape much less surprising ... gList(rectGrob(), rectGrob()) ## multiple shapes (obviously) rectGrob(width=1:2/2) ## multiple shapes (less obvious) rectGrob(gp=gpar(col=, fill=)) ## NOT multiple shapes (no surprise) ... and it should not break any pre-existing non-group behaviour. <3> One casualty from this third option would be that the following would no longer solve the overlapping fill and stroke problem ... grid.group(overlapRect, "source") ... although the fact that that currently works is really a bit surprising AND that result could still be achieved by explicitly drawing separate shapes ... grid.group(rectGrob(gp=gpar(col=rgb(1,0,0,.5), lwd=20, fill=NA)), "source", rectGrob(gp=gpar(col=NA, fill="green"))) <4> I need to try some of this out and also check in with some other people who I think are working on implementing groups on different graphics devices. <5> In summary, don't go changing dsvg() too much just yet! Paul On 29/09/2022 1:30 pm, Paul Murrell wrote: Hi Would it work to explicitly record a filled-and-stroked shape as two separate elements (one only filled and one only stroked) ? Then it should only be as hard to apply the active operator on both of those elements as it is to apply the active operator to more than one shape (?) Paul On 29/09/22 10:17, Panagiotis Skintzos wrote: Thank you for the very thorough explanation Paul. To answer your question on 11: The dsvg device, simply defines svg elements with their attributes (rect with fill & stroke in my examples). It does not do any internal image processing like cairo. My concern is how to proceed with the implementation in dsvg. If I leave it as it is now, they're will be cases where it will give different results from cairo (and perhaps other devices that will implement group compositing in similar way). On the other hand It would be quite challenging in practice to simulate the cairo implementation and apply first the fill and then the stroke with the active operator, on the element itself. Any suggestions? :-) Panagiotis On 28/9/22 02:56, Paul Murrell wrote: > Hi > > Thanks for the code (and for the previous attachments). > > Some thoughts so far (HTML version with images attached) ... > > <1> > As you have pointed out, the Cairo device draws a stroked-and-filled > shape with two separate drawing operations: the path is filled and > then the path is stroked. I do not believe that there is any > alternative in Cairo graphics (apart from filling and stroking as an > isolated group and then drawing the group, which we will come back to). > > <2> > This fill-then-stroke approach is easy to demonstrate just with a thick > semitransparent border ... > > library(grid) > overlapRect <- rectGrob(width=.5, height=.5, > gp=gpar(fill="green", lwd=20, > col=rgb(1,0,0,.5))) > grid.newpage() > grid.draw(overlapRect) > > <
Re: [Rd] Question about grid.group compositing operators in cairo
Interim update: I have spoken with Thomas Lin Pedersen (cc'ed), the author/maintainer of 'ragg' and 'svglite', who is working on adding group support for those graphics devices and he has voted in support of the current Cairo implementation, so the needle has shifted towards Cairo at this stage. I still want to do more tests on other devices to gather more evidence. Paul p.s. Attached (if it makes it through the filters) is a manual modification of your original dsvg() example that has been changed so that it produces the Cairo result. This is probably not exactly how you would want to implement the dsvg() solution, but it is at least a proof of concept that the Cairo result can be produced in SVG. On 30/09/22 10:49, Paul Murrell wrote: Hi Some more thoughts ... <1> I said before that currently, dev->group() does this ... [OVER] shape shape shape OP shape shape shape ... and one option would be an implicit group on 'src' and 'dst' like this ... ([OVER] shape shape shape) OP ([OVER] shape shape shape) ... but another approach could be just an implicit group on each shape, like this ... [OVER] ([OVER] shape) ([OVER] shape) OP ([OVER] shape) ([OVER] shape) That may be a better representation of what you are already doing with dsvg() ? It may also better reflect what naturally occurs in some graphics systems. <2> Changing the Cairo implementation to work like that would I think produce the same result as your dsvg() for ... grid.group(src, "in", dst) ... and it would make what constitutes more than one shape much less surprising ... gList(rectGrob(), rectGrob()) ## multiple shapes (obviously) rectGrob(width=1:2/2) ## multiple shapes (less obvious) rectGrob(gp=gpar(col=, fill=)) ## NOT multiple shapes (no surprise) ... and it should not break any pre-existing non-group behaviour. <3> One casualty from this third option would be that the following would no longer solve the overlapping fill and stroke problem ... grid.group(overlapRect, "source") ... although the fact that that currently works is really a bit surprising AND that result could still be achieved by explicitly drawing separate shapes ... grid.group(rectGrob(gp=gpar(col=rgb(1,0,0,.5), lwd=20, fill=NA)), "source", rectGrob(gp=gpar(col=NA, fill="green"))) <4> I need to try some of this out and also check in with some other people who I think are working on implementing groups on different graphics devices. <5> In summary, don't go changing dsvg() too much just yet! Paul On 29/09/2022 1:30 pm, Paul Murrell wrote: Hi Would it work to explicitly record a filled-and-stroked shape as two separate elements (one only filled and one only stroked) ? Then it should only be as hard to apply the active operator on both of those elements as it is to apply the active operator to more than one shape (?) Paul On 29/09/22 10:17, Panagiotis Skintzos wrote: Thank you for the very thorough explanation Paul. To answer your question on 11: The dsvg device, simply defines svg elements with their attributes (rect with fill & stroke in my examples). It does not do any internal image processing like cairo. My concern is how to proceed with the implementation in dsvg. If I leave it as it is now, they're will be cases where it will give different results from cairo (and perhaps other devices that will implement group compositing in similar way). On the other hand It would be quite challenging in practice to simulate the cairo implementation and apply first the fill and then the stroke with the active operator, on the element itself. Any suggestions? :-) Panagiotis On 28/9/22 02:56, Paul Murrell wrote: > Hi > > Thanks for the code (and for the previous attachments). > > Some thoughts so far (HTML version with images attached) ... > > <1> > As you have pointed out, the Cairo device draws a stroked-and-filled > shape with two separate drawing operations: the path is filled and > then the path is stroked. I do not believe that there is any > alternative in Cairo graphics (apart from filling and stroking as an > isolated group and then drawing the group, which we will come back to). > > <2> > This fill-then-stroke approach is easy to demonstrate just with a thick > semitransparent border ... > > library(grid) > overlapRect <- rectGrob(width=.5, height=.5, > gp=gpar(fill="green", lwd=20, > col=rgb(1,0,0,.5))) > grid.newpage() > grid.draw(overlapRect) > > <3> > This fill-then-stroke approach is what happens on many (most?) > graphics devices, including, for example, the core windows() device, > the core quartz() device, the 'ragg' devices, and 'ggiraph'. The > latter is true because this
Re: [Rd] Question about grid.group compositing operators in cairo
Hi Some more thoughts ... <1> I said before that currently, dev->group() does this ... [OVER] shape shape shape OP shape shape shape ... and one option would be an implicit group on 'src' and 'dst' like this ... ([OVER] shape shape shape) OP ([OVER] shape shape shape) ... but another approach could be just an implicit group on each shape, like this ... [OVER] ([OVER] shape) ([OVER] shape) OP ([OVER] shape) ([OVER] shape) That may be a better representation of what you are already doing with dsvg() ? It may also better reflect what naturally occurs in some graphics systems. <2> Changing the Cairo implementation to work like that would I think produce the same result as your dsvg() for ... grid.group(src, "in", dst) ... and it would make what constitutes more than one shape much less surprising ... gList(rectGrob(), rectGrob()) ## multiple shapes (obviously) rectGrob(width=1:2/2) ## multiple shapes (less obvious) rectGrob(gp=gpar(col=, fill=)) ## NOT multiple shapes (no surprise) ... and it should not break any pre-existing non-group behaviour. <3> One casualty from this third option would be that the following would no longer solve the overlapping fill and stroke problem ... grid.group(overlapRect, "source") ... although the fact that that currently works is really a bit surprising AND that result could still be achieved by explicitly drawing separate shapes ... grid.group(rectGrob(gp=gpar(col=rgb(1,0,0,.5), lwd=20, fill=NA)), "source", rectGrob(gp=gpar(col=NA, fill="green"))) <4> I need to try some of this out and also check in with some other people who I think are working on implementing groups on different graphics devices. <5> In summary, don't go changing dsvg() too much just yet! Paul On 29/09/2022 1:30 pm, Paul Murrell wrote: Hi Would it work to explicitly record a filled-and-stroked shape as two separate elements (one only filled and one only stroked) ? Then it should only be as hard to apply the active operator on both of those elements as it is to apply the active operator to more than one shape (?) Paul On 29/09/22 10:17, Panagiotis Skintzos wrote: Thank you for the very thorough explanation Paul. To answer your question on 11: The dsvg device, simply defines svg elements with their attributes (rect with fill & stroke in my examples). It does not do any internal image processing like cairo. My concern is how to proceed with the implementation in dsvg. If I leave it as it is now, they're will be cases where it will give different results from cairo (and perhaps other devices that will implement group compositing in similar way). On the other hand It would be quite challenging in practice to simulate the cairo implementation and apply first the fill and then the stroke with the active operator, on the element itself. Any suggestions? :-) Panagiotis On 28/9/22 02:56, Paul Murrell wrote: > Hi > > Thanks for the code (and for the previous attachments). > > Some thoughts so far (HTML version with images attached) ... > > <1> > As you have pointed out, the Cairo device draws a stroked-and-filled > shape with two separate drawing operations: the path is filled and > then the path is stroked. I do not believe that there is any > alternative in Cairo graphics (apart from filling and stroking as an > isolated group and then drawing the group, which we will come back to). > > <2> > This fill-then-stroke approach is easy to demonstrate just with a thick > semitransparent border ... > > library(grid) > overlapRect <- rectGrob(width=.5, height=.5, > gp=gpar(fill="green", lwd=20, > col=rgb(1,0,0,.5))) > grid.newpage() > grid.draw(overlapRect) > > <3> > This fill-then-stroke approach is what happens on many (most?) > graphics devices, including, for example, the core windows() device, > the core quartz() device, the 'ragg' devices, and 'ggiraph'. The > latter is true because this is actually the defined behaviour for SVG ... > > https://www.w3.org/TR/SVG2/render.html#Elements <https://www.w3.org/TR/SVG2/render.html#Elements> > https://www.w3.org/TR/SVG2/render.html#PaintingShapesAndText <https://www.w3.org/TR/SVG2/render.html#PaintingShapesAndText> > > <4> > There are exceptions to the fill-then-stroke approach, including the > core pdf() device, but I think they are in the minority. The PDF > language supports a "B" operator that only fills within the border (no > overlap between fill and border). Demonstrating this is complicated > by the fact that not all PDF viewers support this correctly (e.g., > evince and Firefox do not; ghostscript and chrome do)! &
Re: [Rd] Question about grid.group compositing operators in cairo
Hi Would it work to explicitly record a filled-and-stroked shape as two separate elements (one only filled and one only stroked) ? Then it should only be as hard to apply the active operator on both of those elements as it is to apply the active operator to more than one shape (?) Paul On 29/09/22 10:17, Panagiotis Skintzos wrote: Thank you for the very thorough explanation Paul. To answer your question on 11: The dsvg device, simply defines svg elements with their attributes (rect with fill & stroke in my examples). It does not do any internal image processing like cairo. My concern is how to proceed with the implementation in dsvg. If I leave it as it is now, they're will be cases where it will give different results from cairo (and perhaps other devices that will implement group compositing in similar way). On the other hand It would be quite challenging in practice to simulate the cairo implementation and apply first the fill and then the stroke with the active operator, on the element itself. Any suggestions? :-) Panagiotis On 28/9/22 02:56, Paul Murrell wrote: > Hi > > Thanks for the code (and for the previous attachments). > > Some thoughts so far (HTML version with images attached) ... > > <1> > As you have pointed out, the Cairo device draws a stroked-and-filled > shape with two separate drawing operations: the path is filled and > then the path is stroked. I do not believe that there is any > alternative in Cairo graphics (apart from filling and stroking as an > isolated group and then drawing the group, which we will come back to). > > <2> > This fill-then-stroke approach is easy to demonstrate just with a thick > semitransparent border ... > > library(grid) > overlapRect <- rectGrob(width=.5, height=.5, > gp=gpar(fill="green", lwd=20, > col=rgb(1,0,0,.5))) > grid.newpage() > grid.draw(overlapRect) > > <3> > This fill-then-stroke approach is what happens on many (most?) > graphics devices, including, for example, the core windows() device, > the core quartz() device, the 'ragg' devices, and 'ggiraph'. The > latter is true because this is actually the defined behaviour for SVG ... > > https://www.w3.org/TR/SVG2/render.html#Elements <https://www.w3.org/TR/SVG2/render.html#Elements> > https://www.w3.org/TR/SVG2/render.html#PaintingShapesAndText <https://www.w3.org/TR/SVG2/render.html#PaintingShapesAndText> > > <4> > There are exceptions to the fill-then-stroke approach, including the > core pdf() device, but I think they are in the minority. The PDF > language supports a "B" operator that only fills within the border (no > overlap between fill and border). Demonstrating this is complicated > by the fact that not all PDF viewers support this correctly (e.g., > evince and Firefox do not; ghostscript and chrome do)! > > <5> > Forcing all R graphics devices to change the rendering of > filled-and-stroked shapes to match the PDF definition instead of > fill-then-stroke is unlikely to happen because it would impact a lot > of graphics devices, it would break existing behaviour, it may be > difficult/impossible for some devices, and it is not clear that it is > the best approach anyway. > > <6> > Finally getting back to your example, the fill-then-stroke approach > produces some interesting results when applying compositing operators > because the fill is drawn using the compositing operator to combine it > with previous drawing and then the stroke is drawn using the > compositing operator to combine it with *the result of combining the > fill with previous drawing*. The result makes sense in terms of how > the rendering works, but it probably fails the "principle of least > surprise". > > srcRect <- rectGrob(2/3, 1/3, width=.6, height=.6, > gp=gpar(lwd = 5, fill=rgb(0, 0, 0.9, 0.4))) > dstRect <- rectGrob(1/3, 2/3, width=.6, height=.6, > gp=gpar(lwd = 5, fill=rgb(0.7, 0, 0, 0.8))) > grid.newpage() > grid.group(srcRect, "in", dstRect) > > <7> > This issue is not entirely unanticipated because it can arise > slightly-less-unintentionally if we combine a 'src' and/or 'dst' that > draw more than one shape, like this ... > > src <- circleGrob(3:4/5, r=.2, gp=gpar(col=NA, fill=2)) > dst <- circleGrob(1:2/5, r=.2, gp=gpar(col=NA, fill=3)) > grid.newpage() > grid.group(src, "xor", dst) > > This was discussed in the Section "Compositing and blend modes" in the > original technical report about groups and compositing ... > > https://www.stat.auckl
Re: [Rd] Question about grid.group compositing operators in cairo
, an implicit (OVER) group would make it harder to
combine multiple shapes with an operator other than OVER (by quite a
lot?) ...
grid.group(groupGrob(shape, OP, groupGrob(shape, OP, shape)), OP, dst)
... instead of ...
grid.group(src, OP, dst)
The complicating factor is that what constitutes more than one shape (or
drawing operation) can be unexpected ...
gList(rectGrob(), rectGrob()) ## obvious
rectGrob(width=1:2/2) ## less obvious
rectGrob(gp=gpar(col=, fill=)) ## a bit of a surprise
<12>
In summary, while there is some temptation to add an implicit group
around 'src' and 'dst' in a group, there are also reasons not to.
Happy to hear further arguments on this.
Paul
On 28/09/2022 8:04 am, Panagiotis Skintzos wrote:
Here is the code again in text:
src <- rectGrob(2/3, 1/3, width=.6, height=.6, gp=gpar(lwd = 5,
fill=rgb(0, 0, 0.9, 0.4)))
dst <- rectGrob(1/3, 2/3, width=.6, height=.6, gp=gpar(lwd = 5,
fill=rgb(0.7, 0, 0, 0.8)))
svg("cairo.in.svg", width = 5, height = 5)
grid.group(src, "in", dst)
dev.off()
On 27/9/22 04:44, Paul Murrell wrote:
>
> Could you also please send me the SVG code that your device is
> generating for your example. Thanks!
>
> Paul
>
> On 27/09/22 08:50, Paul Murrell wrote:
>> Hi
>>
>> Thanks for the report. It certainly sounds like I have done
>> something stupid :) For my debugging and testing could you please
>> share the R code from your tests ? Thanks!
>>
>> Paul
>>
>> On 26/09/22 10:27, Panagiotis Skintzos wrote:
>>> Hello,
>>>
>>> I'm trying to update ggiraph package in graphic engine v15
>>> (currently we support up to v14).
>>>
>>> I've implemented the group operators and when I compare the outputs
>>> of ggiraph::dsvg with the outputs of svg/png, I noticed some weird
>>> results.
>>>
>>> Specifically, some operators in cairo (in, out, dest.in, dest.atop)
>>> give strange output, when any source element in the group has a
>>> stroke color defined.
>>>
>>> I attach three example images, where two stroked rectangles are used
>>> as source (right) and destination (left).
>>>
>>> cairo.over.png shows the result of the over operator in cairo
>>>
>>> cairo.in.png shows the result of the in operator in cairo
>>>
>>> dsvg.in.png shows the result of the in operator in dsvg
>>>
>>>
>>> You can see the difference between cairo.in.png and dsvg.in.png. I
>>> found out why I get different results:
>>>
>>> In dsvg implementation there is one drawing operation: Draw the
>>> source element, as whole (fill and stroke) over the destination
>>> element (using feComposite filter)
>>>
>>> In cairo implementation though there are two operations: Apply the
>>> fill on source and draw over the destination and then apply the
>>> stroke and draw over the result of the previous operation.
>>>
>>> I'm not sure if this is intentional or not. Shouldn't the source
>>> element being drawn first as whole (fill and stroke with over
>>> operator) and then apply the group operator and draw it over the
>>> destination? It would seem more logical that way.
>>>
>>>
>>> Thanks,
>>>
>>> Panagiotis
>>>
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
<https://stat.ethz.ch/mailman/listinfo/r-devel>
>>
>
--
Dr Paul Murrell
Te Kura Tatauranga | Department of Statistics
Waipapa Taumata Rau | The University of Auckland
Private Bag 92019, Auckland, New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about grid.group compositing operators in cairo
Could you also please send me the SVG code that your device is generating for your example. Thanks! Paul On 27/09/22 08:50, Paul Murrell wrote: Hi Thanks for the report. It certainly sounds like I have done something stupid :) For my debugging and testing could you please share the R code from your tests ? Thanks! Paul On 26/09/22 10:27, Panagiotis Skintzos wrote: Hello, I'm trying to update ggiraph package in graphic engine v15 (currently we support up to v14). I've implemented the group operators and when I compare the outputs of ggiraph::dsvg with the outputs of svg/png, I noticed some weird results. Specifically, some operators in cairo (in, out, dest.in, dest.atop) give strange output, when any source element in the group has a stroke color defined. I attach three example images, where two stroked rectangles are used as source (right) and destination (left). cairo.over.png shows the result of the over operator in cairo cairo.in.png shows the result of the in operator in cairo dsvg.in.png shows the result of the in operator in dsvg You can see the difference between cairo.in.png and dsvg.in.png. I found out why I get different results: In dsvg implementation there is one drawing operation: Draw the source element, as whole (fill and stroke) over the destination element (using feComposite filter) In cairo implementation though there are two operations: Apply the fill on source and draw over the destination and then apply the stroke and draw over the result of the previous operation. I'm not sure if this is intentional or not. Shouldn't the source element being drawn first as whole (fill and stroke with over operator) and then apply the group operator and draw it over the destination? It would seem more logical that way. Thanks, Panagiotis __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Dr Paul Murrell Te Kura Tatauranga | Department of Statistics Waipapa Taumata Rau | The University of Auckland Private Bag 92019, Auckland 1142, New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about grid.group compositing operators in cairo
Hi Thanks for the report. It certainly sounds like I have done something stupid :) For my debugging and testing could you please share the R code from your tests ? Thanks! Paul On 26/09/22 10:27, Panagiotis Skintzos wrote: Hello, I'm trying to update ggiraph package in graphic engine v15 (currently we support up to v14). I've implemented the group operators and when I compare the outputs of ggiraph::dsvg with the outputs of svg/png, I noticed some weird results. Specifically, some operators in cairo (in, out, dest.in, dest.atop) give strange output, when any source element in the group has a stroke color defined. I attach three example images, where two stroked rectangles are used as source (right) and destination (left). cairo.over.png shows the result of the over operator in cairo cairo.in.png shows the result of the in operator in cairo dsvg.in.png shows the result of the in operator in dsvg You can see the difference between cairo.in.png and dsvg.in.png. I found out why I get different results: In dsvg implementation there is one drawing operation: Draw the source element, as whole (fill and stroke) over the destination element (using feComposite filter) In cairo implementation though there are two operations: Apply the fill on source and draw over the destination and then apply the stroke and draw over the result of the previous operation. I'm not sure if this is intentional or not. Shouldn't the source element being drawn first as whole (fill and stroke with over operator) and then apply the group operator and draw it over the destination? It would seem more logical that way. Thanks, Panagiotis __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Dr Paul Murrell Te Kura Tatauranga | Department of Statistics Waipapa Taumata Rau | The University of Auckland Private Bag 92019, Auckland 1142, New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Converting width for a grob where graphics parameters have length 0 crashes R
Hi
There is now a fix for this problem in r-devel (r81197).
Thanks for reporting the problem!
Paul
On 15/11/2021 9:16 am, Paul Murrell wrote:
Hi
Thanks for bringing this (back) up.
It is still on my list, but now back nearer the top :)
Paul
On 14/11/2021 12:51 am, Gu, Zuguang wrote:
Dear developers,
In grid::gpar(), graphic parameters are not allowed to have length 0,
but this can be done by first creating a gpar object and later
modifying it:
gp = gpar(fontsize = 10)
gp$fontsize = numeric(0)
when a grob has a gp where some parameters have length 0, converting
the width or height of this grob will crash R.
?
A reproducible example is as follows:
> library(grid)
> gp = gpar(fontsize = 10)
> gp$fontsize = numeric(0)
> gb = textGrob("foo", gp = gp)
> convertWidth(grobWidth(gb), "mm")
[1] 21045 floating point exception R??
Best regards,
Zuguang Gu
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
<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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Converting width for a grob where graphics parameters have length 0 crashes R
Hi
Thanks for bringing this (back) up.
It is still on my list, but now back nearer the top :)
Paul
On 14/11/2021 12:51 am, Gu, Zuguang wrote:
Dear developers,
In grid::gpar(), graphic parameters are not allowed to have length 0,
but this can be done by first creating a gpar object and later modifying it:
gp = gpar(fontsize = 10)
gp$fontsize = numeric(0)
when a grob has a gp where some parameters have length 0, converting the
width or height of this grob will crash R.
?
A reproducible example is as follows:
> library(grid)
> gp = gpar(fontsize = 10)
> gp$fontsize = numeric(0)
> gb = textGrob("foo", gp = gp)
> convertWidth(grobWidth(gb), "mm")
[1] 21045 floating point exception R??
Best regards,
Zuguang Gu
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
<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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Segfault in setMask in R 4.1
Hi
The Cairo_1.5-12.2.tar.gz sources on CRAN contain the changes. It looks
like they have still not been merged back into the main package sources
on R Forge (cc'ing the package maintainer as a gentle reminder).
I think the Cairo package NEWS file should say 4.1.0 rather than 4.0.0
Paul
On 9/22/2021 9:08 AM, Mike Lee Williams wrote:
Thanks! AFAICT I am already using the latest version of Cairo, but these
links gives me a ton of leads to follow up.
One question (which may be better directed at the maintainer of Cairo):
exactly which version (or commit) of Cairo implements support for the
new setMask API?
CRAN still points to 1.5-12.2. The NEWS file
(https://www.rforge.net/Cairo/news.html
<https://www.rforge.net/Cairo/news.html>)
refers to changes implemented to support R 4.0.0 in Cairo 1.5-12, but my
understanding is that setMask was added in R 4.1.0.
I see no mention of changes to support setMask or R 4.1.x in Cairo
1.5-13 (not on CRAN yet, but the only release since 1.5-12 according to
the NEWS file). The 1.5-13 tarball at
https://www.rforge.net/Cairo/files/
<https://www.rforge.net/Cairo/files>
contains no mention of strings like "setMask", "releasePattern" or
"setPattern", which seem like they should be in there if that version
has implemented support for the new API.
Mike
On Tue, Sep 21, 2021, at 1:41 PM, Paul Murrell wrote:
> Hi
>
> dev->setMask() was introduced in R 4.1.0 ...
>
>
https://developer.r-project.org/Blog/public/2020/07/15/new-features-in-the-r-graphics-engine/
<https://developer.r-project.org/Blog/public/2020/07/15/new-features-in-the-r-graphics-engine>
>
>
https://www.stat.auckland.ac.nz/~paul/Reports/GraphicsEngine/definitions/definitions.html
<https://www.stat.auckland.ac.nz/~paul/Reports/GraphicsEngine/definitions/definitions.html>
>
> If your application is using its own custom graphics device, it will
> need updating, see ...
>
>
https://www.stat.auckland.ac.nz/~paul/Reports/GraphicsEngine/definitions/definitions.html#devices
<https://www.stat.auckland.ac.nz/~paul/Reports/GraphicsEngine/definitions/definitions.html#devices>
>
> But it looks like you may just be using the graphics device provided by
> the 'Cairo' package, which has already been updated. If that is the
> case, your problem may be solved simply be reinstalling the 'Cairo'
package.
>
> Paul
>
> p.s. the reason why it only happens for 'ggplot2' plots is that only
> 'grid' (which underlies 'ggplot2') attempts to set masks (the 'graphics'
> package does not).
>
> On 9/22/2021 4:52 AM, Mike Lee Williams wrote:
>> Thank you! Here is the output of option("devices"), which I think means
>> we're using Cairo:
>>
>> $device
>> function (width = 1280, height = 960, pointsize = 24, units = "px",
>> bg = "white", dpi = 160, ...)
>> {
>> devSym <- basename(tempfile(pattern = "SensePlot", tmpdir = ""))
>> newDev <- Cairo(width = width, height = height, pointsize = pointsize,
>> bg = bg, units = units, dpi = dpi, type = "raster", ...)
>> attr(newDev, "units") <- units
>> attr(newDev, "dpi") <- dpi
>> assign(devSym, newDev, SenseDevices)
>> invisible(newDev)
>> }
>>
>>
>>
>> "Sense" is the internal name of our application. I'm not sure what
>> "devSym" and "newDev" are, but If there are no known issues with Cairo
>> itself then our own code is presumably part of the problem.
>>
>> I would like to confirm that by failing to reproduce the bug in
>> "vanilla" R 4.1 with a Cairo device. If anyone has any tips for how to
>> do that (on Linux) or any other comments I would be very grateful.
>>
>> If our code is the problem then I'm still confused why a regular plot()
>> works, but a ggplot2 qplot() segfaults. Maybe this is a clue!
>>
>> I will post again if I figure anything out!
>>
>> Mike
>>
>> On Tue, Sep 21, 2021, at 3:37 AM, GILLIBERT, Andre wrote:
>> > Hello,
>> >
>> > Which graphic device (backend) do you use?
>> > The setMask() function calls the internal setMask function associated
>> > to the graphic device.
>> > If the Web application uses one of the standard graphic backend, the
>> > bug may come from the R core. If it uses a custom graphic backend, the
>> > bug may be in the backend.
>> >
>> > --
>> > Sincerely
>> > André GILLIBERT
>> >
>> > ATTENTION: Cet e-mail provient d’une adresse mail extérieure au CHU de
>> >
Re: [Rd] Segfault in setMask in R 4.1
Hi
dev->setMask() was introduced in R 4.1.0 ...
https://developer.r-project.org/Blog/public/2020/07/15/new-features-in-the-r-graphics-engine/
https://www.stat.auckland.ac.nz/~paul/Reports/GraphicsEngine/definitions/definitions.html
If your application is using its own custom graphics device, it will
need updating, see ...
https://www.stat.auckland.ac.nz/~paul/Reports/GraphicsEngine/definitions/definitions.html#devices
But it looks like you may just be using the graphics device provided by
the 'Cairo' package, which has already been updated. If that is the
case, your problem may be solved simply be reinstalling the 'Cairo' package.
Paul
p.s. the reason why it only happens for 'ggplot2' plots is that only
'grid' (which underlies 'ggplot2') attempts to set masks (the 'graphics'
package does not).
On 9/22/2021 4:52 AM, Mike Lee Williams wrote:
Thank you! Here is the output of option("devices"), which I think means
we're using Cairo:
$device
function (width = 1280, height = 960, pointsize = 24, units = "px",
bg = "white", dpi = 160, ...)
{
devSym <- basename(tempfile(pattern = "SensePlot", tmpdir = ""))
newDev <- Cairo(width = width, height = height, pointsize = pointsize,
bg = bg, units = units, dpi = dpi, type = "raster", ...)
attr(newDev, "units") <- units
attr(newDev, "dpi") <- dpi
assign(devSym, newDev, SenseDevices)
invisible(newDev)
}
"Sense" is the internal name of our application. I'm not sure what
"devSym" and "newDev" are, but If there are no known issues with Cairo
itself then our own code is presumably part of the problem.
I would like to confirm that by failing to reproduce the bug in
"vanilla" R 4.1 with a Cairo device. If anyone has any tips for how to
do that (on Linux) or any other comments I would be very grateful.
If our code is the problem then I'm still confused why a regular plot()
works, but a ggplot2 qplot() segfaults. Maybe this is a clue!
I will post again if I figure anything out!
Mike
On Tue, Sep 21, 2021, at 3:37 AM, GILLIBERT, Andre wrote:
> Hello,
>
> Which graphic device (backend) do you use?
> The setMask() function calls the internal setMask function associated
> to the graphic device.
> If the Web application uses one of the standard graphic backend, the
> bug may come from the R core. If it uses a custom graphic backend, the
> bug may be in the backend.
>
> --
> Sincerely
> André GILLIBERT
>
> ATTENTION: Cet e-mail provient d’une adresse mail extérieure au CHU de
> Rouen. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes
> à moins de connaître l'expéditeur et de savoir que le contenu est sûr.
> En cas de doute, transférer le mail à « DSI, Sécurité » pour analyse.
> Merci de votre vigilance
>
>
> I have inherited a build of R. We compile R from source and then use
a custom
> web application to allow users to enter R statements and render the
output (it's
> kind of like RStudio although the UX is quite different).
>
> Things were going fine until I tried to upgrade to R 4.1.x. The build
succeeds,
> but I get the following segfault when I make qplot (ggplot2) calls:
>
> *** caught segfault ***
> address (nil), cause 'memory not mapped'
>
> Traceback:
> 1: .setMask(NULL, NULL)
> 2: resolveMask.NULL(NULL)
> 3: (function (path) { UseMethod("resolveMask")})(NULL)
> 4: grid.newpage()
> 5: print.ggplot(x)
> 6: (function (x, ...) UseMethod("print"))(x)
>
> I am not an R developer, so I don't really know how to read this. I
am wondering
> if this is a known issue or if anyone has any suggestions. Here's
some things
> I've tested:
>
> - I get the same segfault in R 4.1.0 and R 4.1.1. I do not get this
error in R
> 4.0.4 or R 4.0.5.
>
> - The problem appears to be specific to the (graphics?) features of R
that
> ggplot2 uses. I do not get a segfault if I do a generic `plot(c(1,2,3))`.
>
> - I have tried versions of ggplot2 3.3.3 and 3.3.5.
>
> - The traceback points to files that were introduced in this commit
>
>
https://github.com/wch/r-source/commit/16755bcddffe0cb4238d8a4979387d92b93a8324#diff-5c63f74229830cdde7886a50bf06dafcdf1d5b3d42cfa06b26814876e58c5ab0
<https://github.com/wch/r-source/commit/16755bcddffe0cb4238d8a4979387d92b93a8324#diff-5c63f74229830cdde7886a50bf06dafcdf1d5b3d42cfa06b26814876e58c5ab0>
>
> I am not an R user or R developer so I'm a bit stuck here. I would be
happy to
> give the output of any commands. If anyone has any suggestions then
please let
> me know!
>
> Thanks!
> Mike Lee Williams
>
> __________
> R-devel@r-project.org mailing list
> https
Re: [Rd] [FORGED] Re: Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
I am not seeing that problem on my 18.04 ... > sessionInfo() R version 4.0.0 Patched (2020-05-12 r78431) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 18.04.4 LTS Matrix products: default BLAS: /home/pmur002/R/R-4-0-branch/BUILD/lib/libRblas.so LAPACK: /home/pmur002/R/R-4-0-branch/BUILD/lib/libRlapack.so locale: [1] LC_CTYPE=en_NZ.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_NZ.UTF-8LC_COLLATE=en_NZ.UTF-8 [5] LC_MONETARY=en_NZ.UTF-8LC_MESSAGES=en_NZ.UTF-8 [7] LC_PAPER=en_NZ.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.0.0 Paul On 26/05/20 2:21 pm, Kenny Bell wrote: Hi all, I have found after upgrading to R 4.0.0 (among other upgrades so this may not be the cause) that the degree symbol doesn't work correctly on Ubuntu 18.04. Googling brought me to this thread that appears related. I tried running: cairo_pdf() plot.new(); text(0.5,0.5, bquote(120*degree*N), cex=5) dev.off() and the ubuntu plot has the degree symbol vertically in the center of the line. The Windows one correctly shows as superscript. Anyone else see this behaviour? Cheers, Kenny On Fri, Apr 10, 2020 at 3:36 AM Nicolas Mailhot via R-devel < r-devel@r-project.org> wrote: Le mercredi 08 avril 2020 à 02:55 -0700, Gabriel Becker a écrit : Hi Paul, Hi Gabriel, Thanks a lot for the testing. The various font family settings seem to work too, from what I can tell. Both font families you suggested, however, Helvetica and Apple Symbols (the s is important) have significantly incomplete coverage with PUA on. That is to be expected, the AMS symbol dump in PUA space was a quick hack to make pre-unicode symbols available in an unicode world, pending their normalisation. That standardisation is long past (IIRC it occured by unicode 3.2 released in March 2002), so no newly created/updated font family is going to place those symbols in PUA anymore. Now adding the AMS symbols to new fonts has been slow, due to the large amount of software hardcoding Symbol (and equivallent) and masking the actual glyph userbase to font makers. It will accelerate with more apps expecting plain unicode by default. Thanks for the testing! Regards, -- Nicolas Mailhot __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] grid 4.0 generates wrong results when adding two complex units by sum()
Confirmed. This is fixed now in R-devel and R-patched. Thanks for the report! Paul On 29/04/20 10:05 pm, Gu, Zuguang wrote: Hi, In grid 4.0, adding two complex units by `sum()` seems to give wrong results. In the following example, `u1 + u2` gives the correct result, but `sum(u1, u2)` also `sum(unit.c(u1, u2))` give the wrong results. ``` library(grid) u1 = 0.4*sum(unit(1, "inch"), unit(1, "mm")) u2 = 0.1*sum(unit(1, "inch"), unit(1, "mm")) u1 # [1] 0.4*sum(1inches, 1mm) u2 # [1] 0.1*sum(1inches, 1mm) # this is correct u1 + u2 # [1] 0.5*sum(1inches, 1mm) # but this is wrong, it should return `sum(0.4inches, 0.4mm, 0.1inches, 0.1mm)`, right? sum(u1, u2) # [1] sum(0.4inches, 0.1mm, 1inches, 1mm) sum(unit.c(u1, u2)) # this is also wrong # [1] sum(0.4inches, 0.1mm, 1inches, 1mm) ``` Session info: ``` sessionInfo() # R version 4.0.0 (2020-04-24) # Platform: x86_64-apple-darwin17.0 (64-bit) # Running under: macOS Catalina 10.15.4 # # Matrix products: default # BLAS: /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib # LAPACK: /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib # # locale: # [1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8 # # attached base packages: # [1] grid stats graphics grDevices utils datasets methods # [8] base # # other attached packages: # [1] colorout_1.2-2 # # loaded via a namespace (and not attached): # [1] compiler_4.0.0 ``` Thanks! Zuguang Gu [[alternative HTML version deleted]] __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
Thanks for this Gabriel - extremely useful.
Those results look pretty good.
Paul
On 8/04/20 9:55 pm, Gabriel Becker wrote:
Hi Paul,
So I've run the tests (and am attaching all numerous pdfs here) but the
takeaway from what I can see is as follows:
raw, without specifying font family, "look good" (see plot*raw.pdf)
from your branch (my eye is upset by the positioning of the phi symbol
in plot2, but I've confirmed that it looks the same generated from
3.5.1, so that isn't your branch).
The various font family settings seem to work too, from what I can tell.
Both font families you suggested, however, Helvetica and Apple Symbols
(the s is important) have significantly incomplete coverage with PUA on.
Apple Symbols does have nearly complete coverage (though to my eye the
symbols are all smaller...) with PUA turned off, but Helvetica remains
very spotty, with disabling PUA only modestly increasing it's coverage,
and not in the places that seem likely to matter.
I hope that helps,
~G
On Tue, Apr 7, 2020 at 8:59 PM Gabriel Becker <mailto:gabembec...@gmail.com>> wrote:
Paul et al,
I will try to do this tonight or tomorrow, though it will not be
built with th system tools because I have yet to get that tto work
locally (spent a good chunk of this morning trying).
I will send a separate messaage regarding those difficulties as well
so that we can at least confirm that they are due to a
malconfiguration on my part.
Best,
~G
On Tue, Apr 7, 2020 at 7:25 PM Paul Murrell
mailto:p...@stat.auckland.ac.nz>> wrote:
The R-symfam branch (r78176) is now working, for my basic tests,
on ...
Ubuntu (pango < 1.44)
Ubuntu (no pango)
Fedora (pango > 1.44)
Windows
I need help to confirm that this builds on macOS and that the basic
tests work ...
https://github.com/pmur002/R-symfam-testing
Brian has been helping with the build, but I am still looking for
someone who can run the tests please. Happy to be fed PDF files to
scrutinize myself; it's generating the PDF files on macOS that
I need
help with.
Paul
On 6/04/20 2:59 pm, Paul Murrell wrote:
> Hi
>
> The R branch ...
>
> https://svn.r-project.org/R/branches/R-symfam/
>
> ... is now set up so that it works "out of the box" on Fedora
by setting
> the default to be 'symbolfamily=cairoSymbolFont(family,
usePUA=FALSE)'
> when grSoftVersion()["pango"] is greater than "1.44".
>
> This means that on Fedora 31 (at least on the Docker
container I am
> testing on) "sans"->"NimubusSans" is used as the symbol font
by default
> and R converts Adobe Symbol Encoding code points to non-PUA
UTF8 code
> points. This is not the prettiest result, but it is a lot
better than
> the page full of missing glyphs that we had.
>
> The default on less "bleeding edge" systems, e.g., my Ubuntu
18.04,
> remains 'symbolfamily="Symbol"'.
>
> The default on other platforms is supposed to be the same as
it was, but
> I need help to confirm that. I have set up a github repo ...
>
> https://github.com/pmur002/R-symfam-testing
>
> ... that describes how to test this on macOS and Windows if
anyone has
> time to do so.
>
> I will start trying to set up a Windows test unless someone
beats me to it.
>
> Paul
>
> On 30/03/20 3:24 pm, Paul Murrell wrote:
>> Hi
>>
>> I have created an R branch that contains a potential fix ...
>>
>> https://svn.r-project.org/R/branches/R-symfam/
>>
>> This allows, for example, ...
>>
>> cairo_pdf(symbolfamily="OpenSymbol")
>>
>> ... to specify that the OpenSymbol family should be used as the
>> "symbol" font (e.g., for "plotmath") in R.
>>
>> This is just a separate branch for now because, while I have
tested it
>> under Unbuntu 18.04 and Fedora 31, I cannot even build R for
Windows
>> (right now) or Mac (ever) and I do not want to drop a bomb
on R-devel
>> at this stage of the release process for R 4.0.0.
>>
>> The attached file contains at least an outline of steps
required to d
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
Thanks Gabriel. Simon and Brian are also helping out. I will start a speparate thread for the four of us to coordinate. Paul On 8/04/20 3:59 pm, Gabriel Becker wrote: Paul et al, I will try to do this tonight or tomorrow, though it will not be built with th system tools because I have yet to get that tto work locally (spent a good chunk of this morning trying). I will send a separate messaage regarding those difficulties as well so that we can at least confirm that they are due to a malconfiguration on my part. Best, ~G On Tue, Apr 7, 2020 at 7:25 PM Paul Murrell <mailto:p...@stat.auckland.ac.nz>> wrote: The R-symfam branch (r78176) is now working, for my basic tests, on ... Ubuntu (pango < 1.44) Ubuntu (no pango) Fedora (pango > 1.44) Windows I need help to confirm that this builds on macOS and that the basic tests work ... https://github.com/pmur002/R-symfam-testing Brian has been helping with the build, but I am still looking for someone who can run the tests please. Happy to be fed PDF files to scrutinize myself; it's generating the PDF files on macOS that I need help with. Paul On 6/04/20 2:59 pm, Paul Murrell wrote: > Hi > > The R branch ... > > https://svn.r-project.org/R/branches/R-symfam/ > > ... is now set up so that it works "out of the box" on Fedora by setting > the default to be 'symbolfamily=cairoSymbolFont(family, usePUA=FALSE)' > when grSoftVersion()["pango"] is greater than "1.44". > > This means that on Fedora 31 (at least on the Docker container I am > testing on) "sans"->"NimubusSans" is used as the symbol font by default > and R converts Adobe Symbol Encoding code points to non-PUA UTF8 code > points. This is not the prettiest result, but it is a lot better than > the page full of missing glyphs that we had. > > The default on less "bleeding edge" systems, e.g., my Ubuntu 18.04, > remains 'symbolfamily="Symbol"'. > > The default on other platforms is supposed to be the same as it was, but > I need help to confirm that. I have set up a github repo ... > > https://github.com/pmur002/R-symfam-testing > > ... that describes how to test this on macOS and Windows if anyone has > time to do so. > > I will start trying to set up a Windows test unless someone beats me to it. > > Paul > > On 30/03/20 3:24 pm, Paul Murrell wrote: >> Hi >> >> I have created an R branch that contains a potential fix ... >> >> https://svn.r-project.org/R/branches/R-symfam/ >> >> This allows, for example, ... >> >> cairo_pdf(symbolfamily="OpenSymbol") >> >> ... to specify that the OpenSymbol family should be used as the >> "symbol" font (e.g., for "plotmath") in R. >> >> This is just a separate branch for now because, while I have tested it >> under Unbuntu 18.04 and Fedora 31, I cannot even build R for Windows >> (right now) or Mac (ever) and I do not want to drop a bomb on R-devel >> at this stage of the release process for R 4.0.0. >> >> The attached file contains at least an outline of steps required to do >> a minimal test if anyone wants to try the fix on Linux. >> >> cc'ing Simon and Jeroen in case they are able to help with checking >> that this builds and works on Mac and/or Windows. >> >> NOTEs: >> - 'symbolfamily' can only be specified when a graphics device is >> opened, and it is then fixed for that device. >> - on Windows, for cairo-based devices, the "symbol" font is still >> hard-coded as "Standard Symbols L" >> >> Paul >> >> On 30/03/20 8:15 am, Paul Murrell wrote: >>> Hi >>> >>> Thanks for your input on this Iñaki and Nicolas. >>> >>> I am starting testing an R fix for this problem today. >>> >>> As suggested, the plan is to allow the R user to specify a font >>> family other than "symbol" for plotmath output (or, more generally, >>> in R parlance, for 'font=5' or 'fontface=5') on a Cairo-based >>> graphics device. >>> >>> Paul >>> >>> >>> On 27/03/20 11:30 pm, Iñaki Ucar wrote: >>&g
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
The R-symfam branch (r78176) is now working, for my basic tests, on ... Ubuntu (pango < 1.44) Ubuntu (no pango) Fedora (pango > 1.44) Windows I need help to confirm that this builds on macOS and that the basic tests work ... https://github.com/pmur002/R-symfam-testing Brian has been helping with the build, but I am still looking for someone who can run the tests please. Happy to be fed PDF files to scrutinize myself; it's generating the PDF files on macOS that I need help with. Paul On 6/04/20 2:59 pm, Paul Murrell wrote: Hi The R branch ... https://svn.r-project.org/R/branches/R-symfam/ ... is now set up so that it works "out of the box" on Fedora by setting the default to be 'symbolfamily=cairoSymbolFont(family, usePUA=FALSE)' when grSoftVersion()["pango"] is greater than "1.44". This means that on Fedora 31 (at least on the Docker container I am testing on) "sans"->"NimubusSans" is used as the symbol font by default and R converts Adobe Symbol Encoding code points to non-PUA UTF8 code points. This is not the prettiest result, but it is a lot better than the page full of missing glyphs that we had. The default on less "bleeding edge" systems, e.g., my Ubuntu 18.04, remains 'symbolfamily="Symbol"'. The default on other platforms is supposed to be the same as it was, but I need help to confirm that. I have set up a github repo ... https://github.com/pmur002/R-symfam-testing ... that describes how to test this on macOS and Windows if anyone has time to do so. I will start trying to set up a Windows test unless someone beats me to it. Paul On 30/03/20 3:24 pm, Paul Murrell wrote: Hi I have created an R branch that contains a potential fix ... https://svn.r-project.org/R/branches/R-symfam/ This allows, for example, ... cairo_pdf(symbolfamily="OpenSymbol") ... to specify that the OpenSymbol family should be used as the "symbol" font (e.g., for "plotmath") in R. This is just a separate branch for now because, while I have tested it under Unbuntu 18.04 and Fedora 31, I cannot even build R for Windows (right now) or Mac (ever) and I do not want to drop a bomb on R-devel at this stage of the release process for R 4.0.0. The attached file contains at least an outline of steps required to do a minimal test if anyone wants to try the fix on Linux. cc'ing Simon and Jeroen in case they are able to help with checking that this builds and works on Mac and/or Windows. NOTEs: - 'symbolfamily' can only be specified when a graphics device is opened, and it is then fixed for that device. - on Windows, for cairo-based devices, the "symbol" font is still hard-coded as "Standard Symbols L" Paul On 30/03/20 8:15 am, Paul Murrell wrote: Hi Thanks for your input on this Iñaki and Nicolas. I am starting testing an R fix for this problem today. As suggested, the plan is to allow the R user to specify a font family other than "symbol" for plotmath output (or, more generally, in R parlance, for 'font=5' or 'fontface=5') on a Cairo-based graphics device. Paul On 27/03/20 11:30 pm, Iñaki Ucar wrote: On Wed, 25 Mar 2020 at 12:25, Nicolas Mailhot wrote: R brought this all on itself by hardcoding a Windows-only “Symbol” font family name in its default conf. Linux systems are UTF-8 by default for ~20 years now, they don’t need the forcing of magic font families to handle symbols not present in the 8-bit legacy Windows encodings. The actual effect of this conf is not the selection of font files with special and unusual symbols. It is to priorize fonts that match the "Symbol" magic name. And those fonts are few and crumbling on Linux systems, because no one has needed to bother with them since Linux switched to UTF-8 last millenium. Just stop using “Symbol” in R and things will work a lot better. Alternatively, prepare to maintain the “Symbol” aliasing stack in fontconfig (and fight with wine for it), because *no* *one* *else* *cares* about this legacy Windows-specific stuff. So, in the light of Nicolas' input (thanks!), I think that font selection should be fixed upstream in R. I'd be happy to put all this together in R's bugzilla, but I don't have an account. Could someone please invite me? Iñaki __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
On 6/04/20 8:21 pm, Iñaki Ucar wrote: On Mon, 6 Apr 2020 at 04:59, Paul Murrell wrote: Hi The R branch ... https://svn.r-project.org/R/branches/R-symfam/ ... is now set up so that it works "out of the box" on Fedora by setting the default to be 'symbolfamily=cairoSymbolFont(family, usePUA=FALSE)' when grSoftVersion()["pango"] is greater than "1.44". That is awesome, thanks! Will you port this to the R-3-6-branch? I'll be very pleased if I can get this merged in time for R 4.0.0. I am not sure if there will be any further patch releases in the R 3.6 series. That would require wider discussion within R-core. Paul -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
Hi The R branch ... https://svn.r-project.org/R/branches/R-symfam/ ... is now set up so that it works "out of the box" on Fedora by setting the default to be 'symbolfamily=cairoSymbolFont(family, usePUA=FALSE)' when grSoftVersion()["pango"] is greater than "1.44". This means that on Fedora 31 (at least on the Docker container I am testing on) "sans"->"NimubusSans" is used as the symbol font by default and R converts Adobe Symbol Encoding code points to non-PUA UTF8 code points. This is not the prettiest result, but it is a lot better than the page full of missing glyphs that we had. The default on less "bleeding edge" systems, e.g., my Ubuntu 18.04, remains 'symbolfamily="Symbol"'. The default on other platforms is supposed to be the same as it was, but I need help to confirm that. I have set up a github repo ... https://github.com/pmur002/R-symfam-testing ... that describes how to test this on macOS and Windows if anyone has time to do so. I will start trying to set up a Windows test unless someone beats me to it. Paul On 30/03/20 3:24 pm, Paul Murrell wrote: Hi I have created an R branch that contains a potential fix ... https://svn.r-project.org/R/branches/R-symfam/ This allows, for example, ... cairo_pdf(symbolfamily="OpenSymbol") ... to specify that the OpenSymbol family should be used as the "symbol" font (e.g., for "plotmath") in R. This is just a separate branch for now because, while I have tested it under Unbuntu 18.04 and Fedora 31, I cannot even build R for Windows (right now) or Mac (ever) and I do not want to drop a bomb on R-devel at this stage of the release process for R 4.0.0. The attached file contains at least an outline of steps required to do a minimal test if anyone wants to try the fix on Linux. cc'ing Simon and Jeroen in case they are able to help with checking that this builds and works on Mac and/or Windows. NOTEs: - 'symbolfamily' can only be specified when a graphics device is opened, and it is then fixed for that device. - on Windows, for cairo-based devices, the "symbol" font is still hard-coded as "Standard Symbols L" Paul On 30/03/20 8:15 am, Paul Murrell wrote: Hi Thanks for your input on this Iñaki and Nicolas. I am starting testing an R fix for this problem today. As suggested, the plan is to allow the R user to specify a font family other than "symbol" for plotmath output (or, more generally, in R parlance, for 'font=5' or 'fontface=5') on a Cairo-based graphics device. Paul On 27/03/20 11:30 pm, Iñaki Ucar wrote: On Wed, 25 Mar 2020 at 12:25, Nicolas Mailhot wrote: R brought this all on itself by hardcoding a Windows-only “Symbol” font family name in its default conf. Linux systems are UTF-8 by default for ~20 years now, they don’t need the forcing of magic font families to handle symbols not present in the 8-bit legacy Windows encodings. The actual effect of this conf is not the selection of font files with special and unusual symbols. It is to priorize fonts that match the "Symbol" magic name. And those fonts are few and crumbling on Linux systems, because no one has needed to bother with them since Linux switched to UTF-8 last millenium. Just stop using “Symbol” in R and things will work a lot better. Alternatively, prepare to maintain the “Symbol” aliasing stack in fontconfig (and fight with wine for it), because *no* *one* *else* *cares* about this legacy Windows-specific stuff. So, in the light of Nicolas' input (thanks!), I think that font selection should be fixed upstream in R. I'd be happy to put all this together in R's bugzilla, but I don't have an account. Could someone please invite me? Iñaki ______ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] Re: Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
On 31/03/20 8:04 pm, Nicolas Mailhot wrote: Le mardi 31 mars 2020 à 15:07 +1300, Paul Murrell a écrit : Thanks, that's useful. For my own memory, this is the parenthesis block that might be useful ... U+239b Sm LEFT PARENTHESIS UPPER HOOK ⎛ U+239c Sm LEFT PARENTHESIS EXTENSION ⎜ U+239d Sm LEFT PARENTHESIS LOWER HOOK ⎝ U+239e Sm RIGHT PARENTHESIS UPPER HOOK ⎞ U+239f Sm RIGHT PARENTHESIS EXTENSION ⎟ U+23a0 Sm RIGHT PARENTHESIS LOWER HOOK ⎠ U+23a1 Sm LEFT SQUARE BRACKET UPPER CORNER ⎡ U+23a2 Sm LEFT SQUARE BRACKET EXTENSION ⎢ U+23a3 Sm LEFT SQUARE BRACKET LOWER CORNER ⎣ U+23a4 Sm RIGHT SQUARE BRACKET UPPER CORNER ⎤ U+23a5 Sm RIGHT SQUARE BRACKET EXTENSION ⎥ U+23a6 Sm RIGHT SQUARE BRACKET LOWER CORNER ⎦ U+23a7 Sm LEFT CURLY BRACKET UPPER HOOK ⎧ However, the situation is still not completely straightforward. The style of the symbols is also an issue and the DejaVu symbols are not as elegant as, say, the OpenSymbol symbols. What makes things tricky is that, AFAICS, DejaVu has (TTX Unicode cmap output) ... Ah, the endless design discussions… Myself I prefer a consistent design like Dejavu, over cobbling symbols of different designs, because they used to be in separate fonts. Anyway: ... while OpenSymbol has ... ... but neither has the other. OpenSymbol is incorrect (it suffers from the same pre-unicode bias as R). However, it is, to my knowledge, actively maintained. You can ask its upstream (LibreOffice) for Unicode conformance fixes if you find problems. Especially when it’s just fixing the map of an existing glyph, that should not be hard for them to fix. Anything PUA-related won’t interoperate well in an unicode world. (you can ask DejaVu too, maybe a request from a project like R will wake up its maintainers. But, that’s a long shot. DejaVu suffers from an almost done state without enough remaining work to interest designers). Regards, Thanks again! I will try contacting with those font projects. In the meantime, I will look at allowing the user to select a symbol-to-unicode mapping or a symbol-to-unicode-using-PUA mapping alongside their choice of symbolfamily so that we can get a variety of things to work for now. Paul -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] Any help needed in prep of 4.0.0?
Hi Thanks for the help you have given already with testing the plotmath/symbolfamily changes. If you could keep monitoring that thread, there are likely to be further calls for checking builds on Mac and Windows. Thanks! Paul On 1/04/20 8:35 am, Gabriel Becker wrote: Hi all, Are there any small patches or further testing that any R-core members would like help with in the preparation to 4.0.0? Sadly @Martin Maechler I don't have the numerical optimization chops to be any help with qbeta, sorry. But if there's anything else, small private wishlist items or things that could use another ste of eyes or some testing that you have locally or aa apatch you just haven't had time to write, please let me know on list or off. I'm happy to help. I will also, of course, be going through bugzilla to see what I can help with there. Best, ~G [[alternative HTML version deleted]] __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
On 1/04/20 8:24 am, Martin Maechler wrote:
Paul Murrell
on Tue, 31 Mar 2020 09:41:30 +1300 writes:
> Hi
> On 30/03/20 10:43 pm, Iñaki Ucar wrote:
>> On Mon, 30 Mar 2020 at 04:24, Paul Murrell
wrote:
>>>
>>> Hi
>>>
>>> I have created an R branch that contains a potential fix ...
>>>
>>> https://svn.r-project.org/R/branches/R-symfam/
>>>
>>> This allows, for example, ...
>>>
>>> cairo_pdf(symbolfamily="OpenSymbol")
>>>
>>> ... to specify that the OpenSymbol family should be used as the
"symbol"
>>> font (e.g., for "plotmath") in R.
>>
>> Will this be a default on Linux? Or are you planning any mechanism
>> (env variable, option...) to make it the default? Because, otherwise,
>> as pango is updated across distributions, R graphics will be "broken"
>> by default unless the user explicitly calls the graphics device in
>> that way to set that option, which I would say is uncommon.
> Good question. Currently, for x11() (and png() etc) the default is
> taken from X11.options(). So it is possible to set this default for a
> session, or even for an installation via one of the ?Startup mechanisms
> (e.g., an R_HOME/etc/Rprofile.site file).
> For svg(), cairo_pdf(), and cairo_ps(), the default is hard-coded in the
> function arguments, but I *think* they are used less as default graphics
> devices.
> Another option would be to try to detect Fedora and set the default
> X11.options() differently there. Two problems: I am not sure there is
> a reliable R code chunk for detecting Fedora (sessionInfo()$running?)
> let alone Fedora >= 30;
Yes, sessionInfo()$running is sufficient for both *and*
there's a faster way in latest R versions, as I had the same
need and found sessionInfo() should be modularized here, and so
we have the 'osVersion' variable since R 3.6.0
osVersion
[1] "Fedora 30 (Thirty)"
find("osVersion")
[1] "package:utils"
{it is put into utils at package load time}
Thanks Martin!
But I like Iñaki's suggestion (check Pango version) even more; that
looks like it will be precise (compared to deparsing 'osVersion'), plus
it will nicely transition other Linux distros when they presumably
transition to the newer Pango.
Paul
> what to set the default to? (just has to be a
> font with a good Unicode coverage that is pretty much guaranteed to be
> in a default Fedora install).
> Paul
>> Iñaki
>>
>>> This is just a separate branch for now because, while I have tested it
>>> under Unbuntu 18.04 and Fedora 31, I cannot even build R for Windows
>>> (right now) or Mac (ever) and I do not want to drop a bomb on R-devel
at
>>> this stage of the release process for R 4.0.0.
>>>
>>> The attached file contains at least an outline of steps required to do
a
>>> minimal test if anyone wants to try the fix on Linux.
>>>
>>> cc'ing Simon and Jeroen in case they are able to help with checking
that
>>> this builds and works on Mac and/or Windows.
>>>
>>> NOTEs:
>>> - 'symbolfamily' can only be specified when a graphics device is
opened,
>>> and it is then fixed for that device.
>>> - on Windows, for cairo-based devices, the "symbol" font is still
>>> hard-coded as "Standard Symbols L"
>>>
>>>
>>> Paul
>>>
>>> On 30/03/20 8:15 am, Paul Murrell wrote:
>>>> Hi
>>>>
>>>> Thanks for your input on this Iñaki and Nicolas.
>>>>
>>>> I am starting testing an R fix for this problem today.
>>>>
>>>> As suggested, the plan is to allow the R user to specify a font family
>>>> other than "symbol" for plotmath output (or, more generally, in R
>>>> parlance, for 'font=5' or 'fontface=5') on a Cairo-based graphics
device.
>>>>
>>>> Paul
>>>>
>>>>
>>>> On 27/03/20 11:30 pm, Iñaki Ucar wrote:
>>>>> On Wed, 25 Mar 2020 at 12:25, Nicolas Mailhot
>>>>> wrote:
>>>>>>
>>>>>>
R brought this all
Re: [Rd] [FORGED] Re: Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
On 31/03/20 11:50 am, Nicolas Mailhot wrote: Le mardi 31 mars 2020 à 10:14 +1300, Paul Murrell a écrit : Hi On 30/03/20 11:12 pm, Nicolas Mailhot wrote: Le lundi 30 mars 2020 à 15:24 +1300, Paul Murrell a écrit : Hi I have created an R branch that contains a potential fix ... https://svn.r-project.org/R/branches/R-symfam/ This allows, for example, ... cairo_pdf(symbolfamily="OpenSymbol") ... to specify that the OpenSymbol family should be used as the "symbol" font (e.g., for "plotmath") in R. Thanks for looking at it! But, really, there is no such thing as a Symbol font on Linux anymore. Symbol is pre-unicode thinking. Most modern general-purpose unicode fonts will include every codepoint Symbol ever shipped, and fontconfig will fallback gracefully when that’s not the case (unless your fontconfig integration is broken). Yep, the "symbol" font is an (outdated) R "plotmath" concept, but one that would take a fair bit of surgery to remove. R plotmath converts certain R expressions (in certain contexts) to code points in the Adobe Symbol Encoding (ASM), but for cairo-based devices, those are converted to UTF8 code points. Just use the sans-serif or monospace fontconfig defaults. You don’t need Symbol, or OpenSymbol, or any special font setup. Agreed. I got reasonable coverage from DejaVu Sans and FreeSerif. There are still a number of ASM code points that are not covered though, for example, ... F8EBE6 # LEFT PAREN TOP# parenlefttp (CUS) F8ECE7 # LEFT PAREN EXTENDER # parenleftex (CUS) F8EDE8 # LEFT PAREN BOTTOM # parenleftbt (CUS) Even OpenSymbol is missing a few (though perhaps not very common ones) ... All the F8* codepoints are in the private use area. That means you can’t rely on them existing in standard unicode fonts You need to use correct Unicode values for things to work: Ux239… for parenthesis, brackets https://www.unicode.org/charts/PDF/U2300.pdf F8E6BD # VERTICAL ARROW EXTENDER # arrowvertex (CUS) F8E7BE # HORIZONTAL ARROW EXTENDER # arrowhorizex (CUS) and 23AF/23D0 for arrow extensions (though arrow font support seems messy, probably because it sees little use; it’s a pity R comes so late to the party, those are just lines, it would have been trivial to get them into DejaVu before the project gone dormant). GFS NeoHellenic (Math block) seems complete but it’s not a common font family. F6DAD2 # REGISTERED SIGN SERIF # registerserif (CUS) F6D9D3 # COPYRIGHT SIGN SERIF # copyrightserif (CUS) F6DBD4 # TRADE MARK SIGN SERIF # trademarkserif (CUS) F8E8E2 # REGISTERED SIGN SANS SERIF# registersans (CUS) F8E9E3 # COPYRIGHT SIGN SANS SERIF # copyrightsans (CUS) F8EAE4 # TRADE MARK SIGN SANS SERIF# trademarksans (CUS) Those are useless nowadays, just use normal registered/copyright/trademark codepoints, and a font in the wished style (serif sans serif, whatever looks nice to you) Regards Thanks, that's useful. For my own memory, this is the parenthesis block that might be useful ... U+239b Sm LEFT PARENTHESIS UPPER HOOK ⎛ U+239c Sm LEFT PARENTHESIS EXTENSION ⎜ U+239d Sm LEFT PARENTHESIS LOWER HOOK ⎝ U+239e Sm RIGHT PARENTHESIS UPPER HOOK ⎞ U+239f Sm RIGHT PARENTHESIS EXTENSION ⎟ U+23a0 Sm RIGHT PARENTHESIS LOWER HOOK ⎠ U+23a1 Sm LEFT SQUARE BRACKET UPPER CORNER ⎡ U+23a2 Sm LEFT SQUARE BRACKET EXTENSION ⎢ U+23a3 Sm LEFT SQUARE BRACKET LOWER CORNER ⎣ U+23a4 Sm RIGHT SQUARE BRACKET UPPER CORNER ⎤ U+23a5 Sm RIGHT SQUARE BRACKET EXTENSION ⎥ U+23a6 Sm RIGHT SQUARE BRACKET LOWER CORNER ⎦ U+23a7 Sm LEFT CURLY BRACKET UPPER HOOK ⎧ However, the situation is still not completely straightforward. The style of the symbols is also an issue and the DejaVu symbols are not as elegant as, say, the OpenSymbol symbols. What makes things tricky is that, AFAICS, DejaVu has (TTX Unicode cmap output) ... ... while OpenSymbol has ... ... but neither has the other. So we could not simply switch to standard Unicode code points because, while that would work with the "ugly" DejaVu glyphs, that would mean that we could not access the "pretty" OpenSymbol glyphs. Paul -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
On 31/03/20 10:12 am, Iñaki Ucar wrote: On Mon, 30 Mar 2020 at 22:41, Paul Murrell wrote: Hi On 30/03/20 10:43 pm, Iñaki Ucar wrote: On Mon, 30 Mar 2020 at 04:24, Paul Murrell wrote: Hi I have created an R branch that contains a potential fix ... https://svn.r-project.org/R/branches/R-symfam/ This allows, for example, ... cairo_pdf(symbolfamily="OpenSymbol") ... to specify that the OpenSymbol family should be used as the "symbol" font (e.g., for "plotmath") in R. Will this be a default on Linux? Or are you planning any mechanism (env variable, option...) to make it the default? Because, otherwise, as pango is updated across distributions, R graphics will be "broken" by default unless the user explicitly calls the graphics device in that way to set that option, which I would say is uncommon. Good question. Currently, for x11() (and png() etc) the default is taken from X11.options(). So it is possible to set this default for a session, or even for an installation via one of the ?Startup mechanisms (e.g., an R_HOME/etc/Rprofile.site file). For svg(), cairo_pdf(), and cairo_ps(), the default is hard-coded in the function arguments, but I *think* they are used less as default graphics devices. Another option would be to try to detect Fedora and set the default X11.options() differently there. Two problems: I am not sure there is a reliable R code chunk for detecting Fedora (sessionInfo()$running?) let alone Fedora >= 30; what to set the default to? (just has to be a font with a good Unicode coverage that is pretty much guaranteed to be in a default Fedora install). As per Nicolas' comment (I failed to include him in CC in my last email, and he's not in this list, sorry for that) any font installed by default would have good symbol coverage, so there's really no need to set a different font for symbols. According again to Nicolas (he's one of the font experts in Fedora), the "sans-serif" or "monospace" fontconfig defaults would work out of the box, and if a symbol is not available, fontconfig should fallback gracefully to another font. So maybe instead of a new "symbolfamily" argument, maybe it's better to just use the "family" for all characters, including symbols, on Linux, and fontconfig should take care of everything (if I understood correctly your explanation, Nicolas; please correct me if I'm wrong). I think R will retain the idea of a separate symbol font in at least the short term because of backward compatibility and cross-platform support and support for a range of graphics devices. So this fix is just for cairo-based devices on Linux at most (probably only Fedora). So this becomes just a decision about user interface and default settings. I did consider the option of allowing the existing "family" parameter to be length-two (with the second one being an optional symbol font specification), but because of the overlaps of X11/cairo and different cairo-based device interfaces, this became awkward. Hence the separate "symbolfamily" interface. And in any case, this still means a separate "symbol" font specification (for the reasons above). Regarding changing to a default symbolfamily=family on Linux generally (rather than just on Fedora), I have at least one counter-example (my Ubuntu 18.04) that shows that this would degrade output significantly. For one, the symbols are a LOT uglier, plus there are some incorrect glyphs. So I think we have to stay with treating Fedora as a special case for now. Thanks for your point about just using symbolfamily=family as the Fedora default. That seems reasonable (and definitely better than it just being completely broken!). That does still leave the problem of how to set the default value for "symbolfamily" JUST on Fedora. I am not convinced we can use R code to detect Fedora >= 30 reliably (but happy to learn otherwise). Is it a possibility for the Fedora distribution to include a .Rprofile.site file that sets the X11.options() ? Paul -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
Hi On 30/03/20 11:12 pm, Nicolas Mailhot wrote: Le lundi 30 mars 2020 à 15:24 +1300, Paul Murrell a écrit : Hi I have created an R branch that contains a potential fix ... https://svn.r-project.org/R/branches/R-symfam/ This allows, for example, ... cairo_pdf(symbolfamily="OpenSymbol") ... to specify that the OpenSymbol family should be used as the "symbol" font (e.g., for "plotmath") in R. Thanks for looking at it! But, really, there is no such thing as a Symbol font on Linux anymore. Symbol is pre-unicode thinking. Most modern general-purpose unicode fonts will include every codepoint Symbol ever shipped, and fontconfig will fallback gracefully when that’s not the case (unless your fontconfig integration is broken). Yep, the "symbol" font is an (outdated) R "plotmath" concept, but one that would take a fair bit of surgery to remove. R plotmath converts certain R expressions (in certain contexts) to code points in the Adobe Symbol Encoding (ASM), but for cairo-based devices, those are converted to UTF8 code points. Just use the sans-serif or monospace fontconfig defaults. You don’t need Symbol, or OpenSymbol, or any special font setup. Agreed. I got reasonable coverage from DejaVu Sans and FreeSerif. There are still a number of ASM code points that are not covered though, for example, ... F8EBE6 # LEFT PAREN TOP# parenlefttp (CUS) F8ECE7 # LEFT PAREN EXTENDER # parenleftex (CUS) F8EDE8 # LEFT PAREN BOTTOM # parenleftbt (CUS) Even OpenSymbol is missing a few (though perhaps not very common ones) ... F8E560 # RADICAL EXTENDER # radicalex (CUS) F8E6BD # VERTICAL ARROW EXTENDER # arrowvertex (CUS) F8E7BE # HORIZONTAL ARROW EXTENDER # arrowhorizex (CUS) F6DAD2 # REGISTERED SIGN SERIF # registerserif (CUS) F6D9D3 # COPYRIGHT SIGN SERIF # copyrightserif (CUS) F6DBD4 # TRADE MARK SIGN SERIF # trademarkserif (CUS) F8E8E2 # REGISTERED SIGN SANS SERIF# registersans (CUS) F8E9E3 # COPYRIGHT SIGN SANS SERIF # copyrightsans (CUS) F8EAE4 # TRADE MARK SIGN SANS SERIF# trademarksans (CUS) Symbol’s codepoint coverage is laughable by 2020’s UTF-8 standards. Right, but there are still code points that are apparently not common in fonts with a very broad Unicode coverage. I did find a TrueType font that I could add a Unicode cmap to that gave complete coverage pretty much all by itself, but it is not distributable. Symbol << Normal Unicode font (DejaVu*) << Special math fonts (STIX2) I you do advanced math stuff, you may need a special math font like STIX, but that’s lights years more advanced than Symbol, and a general purpose font like DejaVu has been shipping a MATH block for several years now Sure. One way to look at the new 'symbolfamily' argument is that it allows us to tell R that the "symbol" font is just a normal font (for cairo-based graphics devices). Paul -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
Hi On 30/03/20 10:43 pm, Iñaki Ucar wrote: On Mon, 30 Mar 2020 at 04:24, Paul Murrell wrote: Hi I have created an R branch that contains a potential fix ... https://svn.r-project.org/R/branches/R-symfam/ This allows, for example, ... cairo_pdf(symbolfamily="OpenSymbol") ... to specify that the OpenSymbol family should be used as the "symbol" font (e.g., for "plotmath") in R. Will this be a default on Linux? Or are you planning any mechanism (env variable, option...) to make it the default? Because, otherwise, as pango is updated across distributions, R graphics will be "broken" by default unless the user explicitly calls the graphics device in that way to set that option, which I would say is uncommon. Good question. Currently, for x11() (and png() etc) the default is taken from X11.options(). So it is possible to set this default for a session, or even for an installation via one of the ?Startup mechanisms (e.g., an R_HOME/etc/Rprofile.site file). For svg(), cairo_pdf(), and cairo_ps(), the default is hard-coded in the function arguments, but I *think* they are used less as default graphics devices. Another option would be to try to detect Fedora and set the default X11.options() differently there. Two problems: I am not sure there is a reliable R code chunk for detecting Fedora (sessionInfo()$running?) let alone Fedora >= 30; what to set the default to? (just has to be a font with a good Unicode coverage that is pretty much guaranteed to be in a default Fedora install). Paul Iñaki This is just a separate branch for now because, while I have tested it under Unbuntu 18.04 and Fedora 31, I cannot even build R for Windows (right now) or Mac (ever) and I do not want to drop a bomb on R-devel at this stage of the release process for R 4.0.0. The attached file contains at least an outline of steps required to do a minimal test if anyone wants to try the fix on Linux. cc'ing Simon and Jeroen in case they are able to help with checking that this builds and works on Mac and/or Windows. NOTEs: - 'symbolfamily' can only be specified when a graphics device is opened, and it is then fixed for that device. - on Windows, for cairo-based devices, the "symbol" font is still hard-coded as "Standard Symbols L" Paul On 30/03/20 8:15 am, Paul Murrell wrote: Hi Thanks for your input on this Iñaki and Nicolas. I am starting testing an R fix for this problem today. As suggested, the plan is to allow the R user to specify a font family other than "symbol" for plotmath output (or, more generally, in R parlance, for 'font=5' or 'fontface=5') on a Cairo-based graphics device. Paul On 27/03/20 11:30 pm, Iñaki Ucar wrote: On Wed, 25 Mar 2020 at 12:25, Nicolas Mailhot wrote: R brought this all on itself by hardcoding a Windows-only “Symbol” font family name in its default conf. Linux systems are UTF-8 by default for ~20 years now, they don’t need the forcing of magic font families to handle symbols not present in the 8-bit legacy Windows encodings. The actual effect of this conf is not the selection of font files with special and unusual symbols. It is to priorize fonts that match the "Symbol" magic name. And those fonts are few and crumbling on Linux systems, because no one has needed to bother with them since Linux switched to UTF-8 last millenium. Just stop using “Symbol” in R and things will work a lot better. Alternatively, prepare to maintain the “Symbol” aliasing stack in fontconfig (and fight with wine for it), because *no* *one* *else* *cares* about this legacy Windows-specific stuff. So, in the light of Nicolas' input (thanks!), I think that font selection should be fixed upstream in R. I'd be happy to put all this together in R's bugzilla, but I don't have an account. Could someone please invite me? Iñaki __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
Thanks Gabriel. Sounds like both you and Brian can build the branch on Mac. Just need to check that Windows builds before I commit to r-devel. Paul On 30/03/20 7:43 pm, Gabriel Becker wrote: I do my devel/patch work on Mac so I can take a shot at testing your branch in the next couple days. ~G On Sun, Mar 29, 2020 at 7:24 PM Paul Murrell <mailto:p...@stat.auckland.ac.nz>> wrote: Hi I have created an R branch that contains a potential fix ... https://svn.r-project.org/R/branches/R-symfam/ This allows, for example, ... cairo_pdf(symbolfamily="OpenSymbol") ... to specify that the OpenSymbol family should be used as the "symbol" font (e.g., for "plotmath") in R. This is just a separate branch for now because, while I have tested it under Unbuntu 18.04 and Fedora 31, I cannot even build R for Windows (right now) or Mac (ever) and I do not want to drop a bomb on R-devel at this stage of the release process for R 4.0.0. The attached file contains at least an outline of steps required to do a minimal test if anyone wants to try the fix on Linux. cc'ing Simon and Jeroen in case they are able to help with checking that this builds and works on Mac and/or Windows. NOTEs: - 'symbolfamily' can only be specified when a graphics device is opened, and it is then fixed for that device. - on Windows, for cairo-based devices, the "symbol" font is still hard-coded as "Standard Symbols L" Paul On 30/03/20 8:15 am, Paul Murrell wrote: > Hi > > Thanks for your input on this Iñaki and Nicolas. > > I am starting testing an R fix for this problem today. > > As suggested, the plan is to allow the R user to specify a font family > other than "symbol" for plotmath output (or, more generally, in R > parlance, for 'font=5' or 'fontface=5') on a Cairo-based graphics device. > > Paul > > > On 27/03/20 11:30 pm, Iñaki Ucar wrote: >> On Wed, 25 Mar 2020 at 12:25, Nicolas Mailhot >> mailto:nicolas.mail...@laposte.net>> wrote: >>> >>> >>> >>> R brought this all on itself by hardcoding a Windows-only “Symbol” font >>> family name in its default conf. Linux systems are UTF-8 by default for >>> ~20 years now, they don’t need the forcing of magic font families to >>> handle symbols not present in the 8-bit legacy Windows encodings. >>> >>> The actual effect of this conf is not the selection of font files with >>> special and unusual symbols. It is to priorize fonts that match the >>> "Symbol" magic name. And those fonts are few and crumbling on Linux >>> systems, because no one has needed to bother with them since Linux >>> switched to UTF-8 last millenium. >>> >>> Just stop using “Symbol” in R and things will work a lot better. >>> Alternatively, prepare to maintain the “Symbol” aliasing stack in >>> fontconfig (and fight with wine for it), because *no* *one* *else* >>> *cares* about this legacy Windows-specific stuff. >> >> So, in the light of Nicolas' input (thanks!), I think that font >> selection should be fixed upstream in R. I'd be happy to put all this >> together in R's bugzilla, but I don't have an account. Could someone >> please invite me? >> >> Iñaki >> >> __ >> R-devel@r-project.org <mailto:R-devel@r-project.org> 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 p...@stat.auckland.ac.nz <mailto:p...@stat.auckland.ac.nz> http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org <mailto:R-devel@r-project.org> 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
Hi I have created an R branch that contains a potential fix ... https://svn.r-project.org/R/branches/R-symfam/ This allows, for example, ... cairo_pdf(symbolfamily="OpenSymbol") ... to specify that the OpenSymbol family should be used as the "symbol" font (e.g., for "plotmath") in R. This is just a separate branch for now because, while I have tested it under Unbuntu 18.04 and Fedora 31, I cannot even build R for Windows (right now) or Mac (ever) and I do not want to drop a bomb on R-devel at this stage of the release process for R 4.0.0. The attached file contains at least an outline of steps required to do a minimal test if anyone wants to try the fix on Linux. cc'ing Simon and Jeroen in case they are able to help with checking that this builds and works on Mac and/or Windows. NOTEs: - 'symbolfamily' can only be specified when a graphics device is opened, and it is then fixed for that device. - on Windows, for cairo-based devices, the "symbol" font is still hard-coded as "Standard Symbols L" Paul On 30/03/20 8:15 am, Paul Murrell wrote: Hi Thanks for your input on this Iñaki and Nicolas. I am starting testing an R fix for this problem today. As suggested, the plan is to allow the R user to specify a font family other than "symbol" for plotmath output (or, more generally, in R parlance, for 'font=5' or 'fontface=5') on a Cairo-based graphics device. Paul On 27/03/20 11:30 pm, Iñaki Ucar wrote: On Wed, 25 Mar 2020 at 12:25, Nicolas Mailhot wrote: R brought this all on itself by hardcoding a Windows-only “Symbol” font family name in its default conf. Linux systems are UTF-8 by default for ~20 years now, they don’t need the forcing of magic font families to handle symbols not present in the 8-bit legacy Windows encodings. The actual effect of this conf is not the selection of font files with special and unusual symbols. It is to priorize fonts that match the "Symbol" magic name. And those fonts are few and crumbling on Linux systems, because no one has needed to bother with them since Linux switched to UTF-8 last millenium. Just stop using “Symbol” in R and things will work a lot better. Alternatively, prepare to maintain the “Symbol” aliasing stack in fontconfig (and fight with wine for it), because *no* *one* *else* *cares* about this legacy Windows-specific stuff. So, in the light of Nicolas' input (thanks!), I think that font selection should be fixed upstream in R. I'd be happy to put all this together in R's bugzilla, but I don't have an account. Could someone please invite me? Iñaki __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
Hi Thanks for your input on this Iñaki and Nicolas. I am starting testing an R fix for this problem today. As suggested, the plan is to allow the R user to specify a font family other than "symbol" for plotmath output (or, more generally, in R parlance, for 'font=5' or 'fontface=5') on a Cairo-based graphics device. Paul On 27/03/20 11:30 pm, Iñaki Ucar wrote: On Wed, 25 Mar 2020 at 12:25, Nicolas Mailhot wrote: R brought this all on itself by hardcoding a Windows-only “Symbol” font family name in its default conf. Linux systems are UTF-8 by default for ~20 years now, they don’t need the forcing of magic font families to handle symbols not present in the 8-bit legacy Windows encodings. The actual effect of this conf is not the selection of font files with special and unusual symbols. It is to priorize fonts that match the "Symbol" magic name. And those fonts are few and crumbling on Linux systems, because no one has needed to bother with them since Linux switched to UTF-8 last millenium. Just stop using “Symbol” in R and things will work a lot better. Alternatively, prepare to maintain the “Symbol” aliasing stack in fontconfig (and fight with wine for it), because *no* *one* *else* *cares* about this legacy Windows-specific stuff. So, in the light of Nicolas' input (thanks!), I think that font selection should be fixed upstream in R. I'd be happy to put all this together in R's bugzilla, but I don't have an account. Could someone please invite me? Iñaki __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] src/modules/X11/devX11.c, can we remove "#if BUG" yet
reated yet, or has already been destroyed, leading to a NULL reference somewhere. I have a vague recollection that the issue was window manager dependent (in 2001 probably not twm, more likely xvwm on RedHat if it was affecting me). A proper fix should go via proper understanding of the X11 protocol - uncommenting a line is as bad as commenting it in the 1st place So more like "wait for window to exist THEN process events" -- but the 1st part may be WM specific, etc. I recall docs being quite obtuse, and the X11 "mechanism not policy" credo doesn't help as WMs are not obliged to (say) send notifications, so you can end up stalling, waiting for events that never happen. It is entirely possible that there is stuff in here that I didn't understand properly at the time, and still don't! - pd On 24 Apr 2019, at 02:30 , Paul Murrell wrote: Hi Sorry, I can't offer an explanation for the commented-out line. However, regarding your final question of avoiding the R-core bottleneck, you do have the option of creating a third-party graphics device package. See, for example, the 'tikzDevice' and 'svglite' packages on CRAN. Does that provide you with a way forward ? Paul On 20/04/2019 5:27 p.m., frede...@ofb.net wrote: Dear R Devel, I know that someone put this line in src/modules/X11/devX11.c:2824 for a reason, because commenting it out causes R to miss an important ConfigureNotify event in my window manager. The result is that plots are initially drawn off the window borders, unreadable. R_ProcessX11Events((void*) NULL); Unfortunately for me, this line is commented in the standard release of R, it has "#if BUG ... #endif" around it. I guess it is also unfortunate for anyone who uses the same window manager as I do, namely i3, which I think is pretty popular among Unix power users these days; not to mention other full-screen window managers which probably exhibit the same bug in R. Maybe everyone on the Core team uses twm as their window manager? Or RStudio on Windows? Which would be sad because then we're not representing an important user demographic, namely those who prefer software which is modern and powerful, yet simple to understand and modify; fully configurable and interoperable and so on. I first reported this bug 3 years ago. In doing research for my bug report, I found that the line was commented out by Peter Dalgaard in 2001 with the explanation "X11 segfault fix - I hope". I don't know what the way forward is. Obviously the Core Team has reason to say, "look, this isn't very important, it's been broken since 2001, maybe fixing it will cause the undocumented segfault bug to reappear, clearly no one here uses your window manager". Do I have to submit a correctness proof for the proposed change? What do I do? https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702 As mentioned in my bug report, I checked using gdb that ConfigureNotify is indeed being received by the call to R_ProcessX11Events() when it is uncommented. I haven't experienced any segfaults. It's good that Peter left evidence that "R_ProcessX11Events" was being called 18 years ago from X11DeviceDriver(). If he had deleted the line, rather than commenting it, then discovering the reason for the window rendering bug would have been much harder for me. However, the downside is that now it is not just a matter of inserting the line where it belongs; I also feel a bit like I have to explain why it was initially removed. But although I've given it some thought, I still have no idea. Somewhat tangentially, I am wondering if there is some way that we could make the development of R's graphics code proceed at a faster rate, for example by pulling it out into a separate module, so that people could offer alternative implementations via CRAN etc., rather than having R Core be the bottleneck. Would this make sense? Has it already been done? Thank you, Frederick __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x
Re: [Rd] [FORGED] src/modules/X11/devX11.c, can we remove "#if BUG" yet
Hi Sorry, I can't offer an explanation for the commented-out line. However, regarding your final question of avoiding the R-core bottleneck, you do have the option of creating a third-party graphics device package. See, for example, the 'tikzDevice' and 'svglite' packages on CRAN. Does that provide you with a way forward ? Paul On 20/04/2019 5:27 p.m., frede...@ofb.net wrote: Dear R Devel, I know that someone put this line in src/modules/X11/devX11.c:2824 for a reason, because commenting it out causes R to miss an important ConfigureNotify event in my window manager. The result is that plots are initially drawn off the window borders, unreadable. R_ProcessX11Events((void*) NULL); Unfortunately for me, this line is commented in the standard release of R, it has "#if BUG ... #endif" around it. I guess it is also unfortunate for anyone who uses the same window manager as I do, namely i3, which I think is pretty popular among Unix power users these days; not to mention other full-screen window managers which probably exhibit the same bug in R. Maybe everyone on the Core team uses twm as their window manager? Or RStudio on Windows? Which would be sad because then we're not representing an important user demographic, namely those who prefer software which is modern and powerful, yet simple to understand and modify; fully configurable and interoperable and so on. I first reported this bug 3 years ago. In doing research for my bug report, I found that the line was commented out by Peter Dalgaard in 2001 with the explanation "X11 segfault fix - I hope". I don't know what the way forward is. Obviously the Core Team has reason to say, "look, this isn't very important, it's been broken since 2001, maybe fixing it will cause the undocumented segfault bug to reappear, clearly no one here uses your window manager". Do I have to submit a correctness proof for the proposed change? What do I do? https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702 As mentioned in my bug report, I checked using gdb that ConfigureNotify is indeed being received by the call to R_ProcessX11Events() when it is uncommented. I haven't experienced any segfaults. It's good that Peter left evidence that "R_ProcessX11Events" was being called 18 years ago from X11DeviceDriver(). If he had deleted the line, rather than commenting it, then discovering the reason for the window rendering bug would have been much harder for me. However, the downside is that now it is not just a matter of inserting the line where it belongs; I also feel a bit like I have to explain why it was initially removed. But although I've given it some thought, I still have no idea. Somewhat tangentially, I am wondering if there is some way that we could make the development of R's graphics code proceed at a faster rate, for example by pulling it out into a separate module, so that people could offer alternative implementations via CRAN etc., rather than having R Core be the bottleneck. Would this make sense? Has it already been done? Thank you, Frederick __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] Could we make filled.contour() more suitable for PDF viewers?
Hi
One problem with that solution is that it is drawing the wrong thing.
The border of the polygonal regions is drawn centred on the edge of the
region, so it overlaps adjacent regions. The following code exaggerates
the problem ...
pdf("demo.pdf")
dev.control("enable")
image(x=1:2, y=1:2, z=matrix(1:4, ncol=2))
library(gridGraphics)
grid.echo()
rect <- grid.get("rect", grep=TRUE)
grid.edit("rect", grep=TRUE,
gp=gpar(col=adjustcolor(1:4, alpha=.5), lwd=10,
fill=adjustcolor(rect$gp$fill, alpha=.5)))
dev.off()
Paul
On 16/03/19 10:43 AM, Abs Spurdle wrote:
Note that I sent this to r-devel, yesterday.
However, it didn't appear on the mailing list.
So, I'm resending it.
Today, I plotted the following:
filled.contour (,,z, color.palette=terrain.colors)
It looked OK, in R.
However, when I created a PDF document, the plot (and other similar plots)
had grid (and other) lines in it, that shouldn't be there.
Note that this problem is more obvious with terrain.colors than cm.colors,
which is the default.
I found this in the help file for the pdf() function:
"the problem is much more likely to be in your viewer than in R... apparent
grids on image plots (turn off graphics anti-aliasing in your viewer if you
can)..."
Later, I found (in Acrobat Reader XI) the following option:
Edit > Preferences... > Page Display > Smooth line art
I unticked this option and it corrected the problem.
In principle, this is a problem with the PDF viewer, and not R.
However, it would be better if filled.contour() didn't have this result.
And I've decided not to use filled.contour() because of this.
Note that filled.contour() calls .filled.contour(), which calls:
+ .External.graphics(C_filledcontour, x, y, z, levels, col)
Also note that I had a similar plot with a similar problem.
It contained the following line:
+ polygon (xsub, ysub, border=NA, col=colstr)
But the problem was corrected after changing it to:
+ polygon (xsub, ysub, border=colstr, col=colstr)
I'm assuming that an equally simple change to C_filledcontour, could
correct the problem above.
[[alternative HTML version deleted]]
__
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R cairo_pdf function does not respect plotting boundaries
Hi
I have committed this fix to r-devel (r76226).
Please let me know if this does not fix things for you.
Paul
On 5/03/19 8:22 PM, Lee Steven Kelvin wrote:
Hi Paul,
Great, thank you for looking in to this, and I'm glad that you're able
to reproduce it at your end too.
From your reply, I'm happy that it seems like the fix may be fairly
trivial, but I understand the necessity for caution.
If there's anything else I can do to help, please do let me know.
Thank you again,
Best,
Lee
On Monday, 4 March 2019, Paul Murrell <mailto:p...@stat.auckland.ac.nz>> wrote:
Hi
(cc'ed to r-devel where further discussion should probably take place)
Thanks Lee. I see that problem.
There is a "+ 1" in the Cairo device code for setting the clipping
region
(https://github.com/wch/r-source/blob/ba600867f2a94e46cf9eb75dc8b37f12b08a4561/src/library/grDevices/src/cairo/cairoFns.c#L156
<https://github.com/wch/r-source/blob/ba600867f2a94e46cf9eb75dc8b37f12b08a4561/src/library/grDevices/src/cairo/cairoFns.c#L156>)
Remove the "+ 1" and the problem goes away (for your example at least).
The comment on the line above that code suggests that the "+ 1" was
modelled on the X11 device code, but X11 deals in integer pixels and
Cairo (at the API level) does not, so it would seem that the "+ 1"
is just unnecessary.
However, I have a slight nagging worry that we have been here
before, so I would like to do some more testing before committing
that change.
Paul
On 1/03/19 8:13 AM, Lee Steven Kelvin wrote:
Hello all,
When producing a plot in R using the cairo_pdf device, the
resultant plot does not respect the plotting boundaries. Lines
and shaded regions will spill over the lower x-axis and the
right-side y-axis (sides 1 and 4). I would like to know if it is
possible to fix this behaviour when using 'cairo_pdf' in R?
As an example, see the image at this web link:
https://i.stack.imgur.com/0lfZd.png
<https://i.stack.imgur.com/0lfZd.png>
This image is a screenshot of a PDF file constructed using the
following minimum working example code:
cairo_pdf(file="test.pdf", width=0.5, height=0.5)
par("mar"=c(0.25,0.25,0.25,0.25))
plot(NA, xlim=c(0,1), ylim=c(0,1), axes=FALSE)
polygon(x=c(-1,-1,2,2), y=c(-1,2,2,-1), density=5, col="green3",
lwd=10)
abline(h=0.25, col="red", lwd=5)
abline(h=0.75, col="hotpink", lwd=5, lend=1)
abline(v=0.25, col="blue", lwd=5)
abline(v=0.75, col="cyan", lwd=5, lend=1)
box()
dev.off()
Here I'm plotting a shaded region in green using 'polygon', with
boundaries that lie outside the plot. I'm also drawing two sets
of horizontal/vertical lines using 'abline'. The first in each
pair uses standard rounded line caps, whilst the second in each
pair uses butt line caps.
As you can see, the shading lines and the default rounded-end
ablines all extend beyond the plotting region along the lower
and right-hand side axes. Only when using 'lend=1' am I able to
contain the ablines to the plotting region. I know of no such
fix for the shading lines however.
I would naively expect the R plotting region to be respected,
and for it to be impossible to plot outside of this region
unless explicitly specified by the user.
I have tested this on the other cairo devices (SVG and PS), and
also reproduce the same behaviour, indicating that this is an
issue with the cairo graphics API, or its implementation within R.
This behaviour does not occur when using the standard R 'pdf'
graphics device. I would switch to 'pdf' in general, however,
'cairo_pdf' has several advantages over 'pdf', notably, reduced
output file sizes on occasion and support for a larger array of
UTF-8 characters, so ideally I would prefer to use cairo_pdf.
I should note that I have also posted this message on
StackOverflow at this web link:
https://stackoverflow.com/questions/54892809/r-cairo-pdf-function-does-not-respect-plotting-boundaries
<https://stackoverflow.com/questions/54892809/r-cairo-pdf-function-does-not-respect-plotting-boundaries>
Thank you in advance for any insights into this issue.
Sincerely,
Lee Kelvin
--
Dr Lee Kelvin
Department of Physics
UC Davis
One Shields Avenue
Davis, CA 95616
USA
Ph: +1 (530) 752-1500
Fax: +1 (530) 752-4717
[[alternative HTML version deleted]]
__
r-h
Re: [Rd] [FORGED] [R] R cairo_pdf function does not respect plotting boundaries
Hi
(cc'ed to r-devel where further discussion should probably take place)
Thanks Lee. I see that problem.
There is a "+ 1" in the Cairo device code for setting the clipping region
(https://github.com/wch/r-source/blob/ba600867f2a94e46cf9eb75dc8b37f12b08a4561/src/library/grDevices/src/cairo/cairoFns.c#L156)
Remove the "+ 1" and the problem goes away (for your example at least).
The comment on the line above that code suggests that the "+ 1" was
modelled on the X11 device code, but X11 deals in integer pixels and
Cairo (at the API level) does not, so it would seem that the "+ 1" is
just unnecessary.
However, I have a slight nagging worry that we have been here before, so
I would like to do some more testing before committing that change.
Paul
On 1/03/19 8:13 AM, Lee Steven Kelvin wrote:
Hello all,
When producing a plot in R using the cairo_pdf device, the resultant plot does
not respect the plotting boundaries. Lines and shaded regions will spill over
the lower x-axis and the right-side y-axis (sides 1 and 4). I would like to
know if it is possible to fix this behaviour when using 'cairo_pdf' in R?
As an example, see the image at this web link:
https://i.stack.imgur.com/0lfZd.png
This image is a screenshot of a PDF file constructed using the following
minimum working example code:
cairo_pdf(file="test.pdf", width=0.5, height=0.5)
par("mar"=c(0.25,0.25,0.25,0.25))
plot(NA, xlim=c(0,1), ylim=c(0,1), axes=FALSE)
polygon(x=c(-1,-1,2,2), y=c(-1,2,2,-1), density=5, col="green3", lwd=10)
abline(h=0.25, col="red", lwd=5)
abline(h=0.75, col="hotpink", lwd=5, lend=1)
abline(v=0.25, col="blue", lwd=5)
abline(v=0.75, col="cyan", lwd=5, lend=1)
box()
dev.off()
Here I'm plotting a shaded region in green using 'polygon', with boundaries
that lie outside the plot. I'm also drawing two sets of horizontal/vertical
lines using 'abline'. The first in each pair uses standard rounded line caps,
whilst the second in each pair uses butt line caps.
As you can see, the shading lines and the default rounded-end ablines all
extend beyond the plotting region along the lower and right-hand side axes.
Only when using 'lend=1' am I able to contain the ablines to the plotting
region. I know of no such fix for the shading lines however.
I would naively expect the R plotting region to be respected, and for it to be
impossible to plot outside of this region unless explicitly specified by the
user.
I have tested this on the other cairo devices (SVG and PS), and also reproduce
the same behaviour, indicating that this is an issue with the cairo graphics
API, or its implementation within R.
This behaviour does not occur when using the standard R 'pdf' graphics device.
I would switch to 'pdf' in general, however, 'cairo_pdf' has several advantages
over 'pdf', notably, reduced output file sizes on occasion and support for a
larger array of UTF-8 characters, so ideally I would prefer to use cairo_pdf.
I should note that I have also posted this message on StackOverflow at this web
link:
https://stackoverflow.com/questions/54892809/r-cairo-pdf-function-does-not-respect-plotting-boundaries
Thank you in advance for any insights into this issue.
Sincerely,
Lee Kelvin
--
Dr Lee Kelvin
Department of Physics
UC Davis
One Shields Avenue
Davis, CA 95616
USA
Ph: +1 (530) 752-1500
Fax: +1 (530) 752-4717
[[alternative HTML version deleted]]
__
r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] grDevices::convertColor and colorRamp(space='Lab') Performance Improvements
Thanks Brodie. Having a look at all of this is on my list. Paul On 03/10/18 14:13, Brodie Gaslam via R-devel wrote: `grDevices::convertColor` performance can be improved by 30-300x with small changes to the code. `colorRamp(space='Lab')` uses `convertColor` so it too benefits from substantial performance gains. `convertColor` vectorizes explicitly over the rows of the input color matrix using `apply`. The level-1 patch [1] illustrates a possible minimal set of changes to achieve this with just R matrix and vector operations. The changes consist primarily of switching `if/else` to `ifelse`, `c` to `cbind`, `sum` to `rowSums`, etc. This results in speedups of 30-100x as shown in table 1: to from Apple RGB sRGB CIE RGB XYZ Lab Luv Apple RGB NA 38.3 55.8 30.3 60.2 56.3 sRGB 38.7 NA 55.7 36.5 62.9 52.7 CIE RGB 45.2 44.4 NA 30.6 51.5 43.1 XYZ 73.4 57.5 69.1 NA 92.2 69.0 Lab 46.6 56.6 65.4 72.0 NA 61.3 Luv 73.2 107.3 67.3 105.8 97.8 NA ## Table 1: ## Ratios of `grDevices` to 'level-1' patch speeds for 8000 colors ## from each supported color space to all other supported color spaces. A few incremental changes as detailed in the level-2 patch [2] yield additional performance improvements: to from Apple RGB sRGB CIE RGB XYZ Lab Luv Apple RGB NA 97.1 106.2 89.0 117 83.4 sRGB 92.5 NA 99.4 86.4 120 76.0 CIE RGB 119.2 184.2 NA 82.2 135 83.4 XYZ 122.3 209.8 140.9 NA 171 148.8 Lab 166.4 168.2 255.4 288.5 NA 265.1 Luv 141.7 173.6 279.6 310.1 195 NA ## Table 2: ## Ratios of `grDevices` to level-2 patch speeds for 8000 colors ## from each supported color space to all other supported color spaces. Not shown here is that the patched versions of `convertColor` are faster with small inputs as well, though the difference is less marked. I have posted tests on github [3], along with the results of running them on my system [4]. While these tests are not proof that the patches do not change the function other than to make it faster, the tests results combined with the narrow scope of the changes hopefully provides sufficient evidence this is the case. For those wanting to run the tests, installation and testing instructions are on the github landing page for this project [5]. There are some minor (in my opinion) changes in behavior that need to be discussed: * Inputs that would previously stop with errors or work inconsistently now work consistently (e.g. zero-row inputs or inputs containing NA/NaN/Inf). * Column names are consistently set to the color space initials; these were previously inconsistently set / mangled by `c`. These are discussed at length with examples in [6]. It would be possible to preserve the existing behavior, but doing so would require some contortions that serve no other purposes than that. Additionally, in many cases the existing behavior is inconsistent across different input/output color spaces. Finally, most of the differences involve corner case inputs such as those containing NA/NaN/Inf, or zero rows. I am entirely amenable to modify the patches to preserve existing behavior in these cases if that is considered desirable. These patches should be coordinated with #17473 [7], which I found while working on this issue. --- 'level-1' patch: [1]: https://raw.githubusercontent.com/brodieG/grDevices2/level-2/extra/level-1.txt 'level-2' patch: [2]: https://raw.githubusercontent.com/brodieG/grDevices2/level-2/extra/level-2.txt Tests on github, and the result of running them: [3]: https://github.com/brodieG/grDevices2/blob/level-2/tests/convertColor.R [4]: https://raw.githubusercontent.com/brodieG/grDevices2/level-2/tests/convertColor.Rout Github landing page for this project: [5]: https://github.com/brodieG/grDevices2 Discussion of differences introduces by patches: [6]: https://htmlpreview.github.io/?https://raw.githubusercontent.com/brodieG/grDevices2/level-2/extra/differences.html Indirectly related bugzilla issue #17473: [7]: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17473 __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] Possible bug with chromatic adaptation in grDevices::convertColor
Thanks for the report (and the bug report).
I need to make time to have a closer look at this.
Paul
On 14/09/18 14:03, brodie gaslam via R-devel wrote:
It appears that the chromatic adaptation feature of `grDevices::convertColor`is
broken, and likely has been for many years. While a little surprising, it is
an obscure enough feature that there is some possibility this is actually
broken, as opposed to user error on my part. If it turns out to the latter, I
apologize in advance for spamming this list.
Consider:
rgb.in <- c("#CC", "#EE") clr <- t(col2rgb(rgb.in)) / 255 clr.out <- convertColor(clr,
"sRGB", "sRGB") rgb(clr.out) ## [1] "#CC" "#EE"
convertColor(clr, "sRGB", "sRGB", "D65", "D50") ## Error in
match.arg(from, nWhite) : ## 'arg' must be NULL or a character vector
This appears to be because `grDevices:::chromaticAdaptation` expects the whitepoints to
be provided in the character format (e.g. "D65"), but they are already
converted by `convertColor` into the tristimulus values. After applying the patch at the
end of this e-mail, we get:
clr.out <- convertColor(clr, "sRGB", "sRGB", "D65", "D50") rgb(clr.out) ## [1]
"#DACAB0" "#FEECCE"
I do not have a great way of confirming that the conversion is correct with my changes, but I did
verify that the `M` matrix computed within`grDevics:::chromaticAdaptation` for the
"D65"->"D50" conversion (approximately) matches the corresponding matrix from
brucelindbloom.com chromatic adaptation page:
http://www.brucelindbloom.com/Eqn_ChromAdapt.html
Additionally visual inspection via
scales::show_col(c(rgb.in, rgb(clr.out)))
is consistent with a shift from bluer indirect daylight ("D65") to yellower direct
daylight ("D50") illuminant.
It is worth noting that the adaption method currently in`grDevices:::chromaticAdaptation` appears
to be the "Von Kries" method, not the "Bradford" method as documented in
`?convertColor` and in the comments of thesources. I base this on comparing the cone response
domain matrices on the aforementioned brucelindbloom.com page to the `Ma` matrix defined
in`grDevics:::chromaticAdaptation`.
Given that brucelindbloom.com appears to recommend "Bradford", that the sources suggest
that was the intent, that `chromaticAdaptation` is only used by`convertColor` in the R sources,
that `chromaticAdapation` is not exported, and that that feature appears currently inaccessible via
`convertColor`, it may be worth using this opportunity to change the adaptation method to
"Bradford".
A suggested patch follows. It is intended to minimize the required changes,
although doing so requires a double transposition. The transpositions could be
easily avoided, but it would require reformulating the calculations
in`chromaticAdaption`.
Best,
Brodie.
Index: src/library/grDevices/R/convertColor.R
===
--- src/library/grDevices/R/convertColor.R (revision 75298)
+++ src/library/grDevices/R/convertColor.R (working copy)
@@ -81,7 +81,7 @@
}
chromaticAdaptation <- function(xyz, from, to) {
- ## bradford scaling algorithm
+ ## Von Kries scaling algorithm
Ma <- matrix(c( 0.40024, -0.22630, 0.,
0.70760, 1.16532, 0.,
-0.08081, 0.04570, 0.91822), nrow = 3L, byrow = TRUE)
@@ -242,8 +242,8 @@
if (is.null(from.ref.white))
from.ref.white <- to.ref.white
- from.ref.white <- c2to3(white.points[, from.ref.white])
- to.ref.white <- c2to3(white.points[, to.ref.white])
+ from.ref.white.3 <- c2to3(white.points[, from.ref.white])
+ to.ref.white.3 <- c2to3(white.points[, to.ref.white])
if (is.null(nrow(color)))
color <- matrix(color, nrow = 1L)
@@ -262,19 +262,19 @@
rgb
}
- xyz <- apply(color, 1L, from$toXYZ, from.ref.white)
+ xyz <- apply(color, 1L, from$toXYZ, from.ref.white.3)
if (is.null(nrow(xyz)))
xyz <- matrix(xyz, nrow = 1L)
- if (!isTRUE(all.equal(from.ref.white, to.ref.white))) {
+ if (!isTRUE(all.equal(from.ref.white.3, to.ref.white.3))) {
mc <- match.call()
if (is.null(mc$from.ref.white) || is.null(mc$to.ref.white))
warning("color spaces use different reference whites")
- xyz <- chromaticAdaptation(xyz, from.ref.white, to.ref.white)
+ xyz <- t(chromaticAdaptation(t(xyz), from.ref.white, to.ref.white))
}
- rval <- apply(xyz, 2L, to$fromXYZ, to.ref.white)
+ rval <- apply(xyz, 2L, to$fromXYZ, to.ref.white.3)
if (inherits(to,"RGBcolorConverter"))
rval <- trim(rval)
Re: [Rd] [FORGED] Re: plotmath degree symbol
Awesome. Thanks for confirming. Paul On 05/09/18 19:46, Edzer Pebesma wrote: Thanks, Paul -- setting the ~/.fonts.conf file the way ?X11 describes it under the section you pointed to resolved the problem for me, on ubuntu. On 09/04/2018 11:55 PM, Paul Murrell wrote: Hi Thanks for that, but I still cannot confirm on ... sudo docker run -v $(pwd):/home/work/ -w /home/work --rm -ti rocker/r-ver:3.5.1 Could you please read the comments within the "Cairo Fonts" section of the ?X11 help page, in case that offers some explanation. Paul On 29/08/18 02:15, Martin Møller Skarbiniks Pedersen wrote: On Fri, 24 Aug 2018 at 19:53, Edzer Pebesma wrote: In plotmath expressions, R's degree symbol, e.g. shown by plot(1, main = parse(text = "1*degree*C")) has sunk to halfway the text line, instead of touching its top. In older R versions this looked much better. I can confirm this problem. R version 3.5.1 (2018-07-02) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 18.04.1 LTS Matrix products: default BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1 LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1 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=en_US.UTF-8 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 loaded via a namespace (and not attached): [1] compiler_3.5.1 __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] Re: plotmath degree symbol
Hi Thanks for that, but I still cannot confirm on ... sudo docker run -v $(pwd):/home/work/ -w /home/work --rm -ti rocker/r-ver:3.5.1 Could you please read the comments within the "Cairo Fonts" section of the ?X11 help page, in case that offers some explanation. Paul On 29/08/18 02:15, Martin Møller Skarbiniks Pedersen wrote: On Fri, 24 Aug 2018 at 19:53, Edzer Pebesma wrote: In plotmath expressions, R's degree symbol, e.g. shown by plot(1, main = parse(text = "1*degree*C")) has sunk to halfway the text line, instead of touching its top. In older R versions this looked much better. I can confirm this problem. R version 3.5.1 (2018-07-02) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 18.04.1 LTS Matrix products: default BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1 LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1 locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8LC_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 loaded via a namespace (and not attached): [1] compiler_3.5.1 __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plotmath degree symbol
Hi Sorry, but this seems to be working ok for me ... > sessionInfo() R version 3.4.2 (2017-09-28) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 16.04.5 LTS Matrix products: default BLAS: /usr/lib/libblas/libblas.so.3.6.0 LAPACK: /usr/lib/lapack/liblapack.so.3.6.0 locale: [1] LC_CTYPE=en_NZ.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_NZ.UTF-8LC_COLLATE=en_NZ.UTF-8 [5] LC_MONETARY=en_NZ.UTF-8LC_MESSAGES=en_NZ.UTF-8 [7] LC_PAPER=en_NZ.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_3.4.2 ... and ... > sessionInfo() R Under development (unstable) (2018-08-22 r75177) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 16.04.3 LTS Matrix products: default BLAS: /home/pmur002/R/r-devel/BUILD/lib/libRblas.so LAPACK: /home/pmur002/R/r-devel/BUILD/lib/libRlapack.so locale: [1] LC_CTYPE=en_NZ.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_NZ.UTF-8LC_COLLATE=en_NZ.UTF-8 [5] LC_MONETARY=en_NZ.UTF-8LC_MESSAGES=en_NZ.UTF-8 [7] LC_PAPER=en_NZ.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics utils datasets grDevices methods base loaded via a namespace (and not attached): [1] compiler_3.6.0 ... what is your setup ? Paul On 25/08/18 05:53, Edzer Pebesma wrote: In plotmath expressions, R's degree symbol, e.g. shown by plot(1, main = parse(text = "1*degree*C")) has sunk to halfway the text line, instead of touching its top. In older R versions this looked much better. -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] recordPlot/replayPlot not working with saveRDS/readRDS
Thanks for the fix Martin.
Paul
On 04/04/18 02:07, Martin Maechler wrote:
Paul Murrell <p...@stat.auckland.ac.nz>
on Tue, 3 Apr 2018 09:41:56 +1200 writes:
> Hi What you are doing "wrong" is loading a recordedplot
> into the same session that it was created in. The
> saveRDS()/readRDS() works if you save in one R session and
> then read in a different R session. The assumption is
> that if you are still in the same session that created the
> recordedplot you still have the recordedplot (e.g., you
> can just do replayPlot(r) instead of replayPlot(r2). Is
> that a bad assumption ?
Not "bad", really, but somewhat *un*intuitive I believe to most
users, including me.
I would have done the same as Winston to check if saving and
loading of a recorded plot work fine.
Also, the error message we get is not very helpful:
> saveRDS(r, 'recordedplot.rds')
> r <- readRDS('recordedplot.rds')
> png('test2.png')
> replayPlot(r)
Error: NULL value passed as symbol address
{coming from deep down: checkValidSymbolId() in src/main/dotcode.c }
I've pondered a bit and in the end found it easy enough to
tryCatch() the error, and "do the right thing" instead.
As that should typically only happen in exactly such a use case,
the change should be "uniformly >=" the previous state.
Ideally, maybe we (R core) would provide an R level API to a
"TRUE/FALSE" valued version of checkValidSymbolId() or its
caller, so that *from R code* one could check if the
recordedplot 'x' passed to replayPlot() with its external
pointers needs to be fixed up by
x <- restoreRecordedPlot(x)
or not.
But that would be another topic I'd not get envolved deeply just now.
Martin
Paul
On 03/04/18 05:23, Winston Chang wrote:
The documentation for recordPlot says the following:
As of R 3.3.0, it is possible (again) to replay a plot from another R session
using, for example, saveRDS and readRDS.
However, I haven't been able to save and restore a plot displaylist
and have it work within the same R session, using R 3.4.3 or 3.3.3.
Here's an example:
# Save displaylist for a simple plot
png('test.png')
dev.control(displaylist ="enable")
plot(1:5, 1:5)
r <- recordPlot()
dev.off()
# Replay plot. This works.
png('test1.png')
replayPlot(r)
dev.off()
# Save the plot and load it, then try to replay it. This does not work.
saveRDS(r, 'recordedplot.rds')
r2 <- readRDS('recordedplot.rds')
png('test2.png')
replayPlot(r2) ## Error: NULL value passed as symbol address
dev.off()
Is there something that I'm doing wrong here?
__________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] recordPlot/replayPlot not working with saveRDS/readRDS
Hi
What you are doing "wrong" is loading a recordedplot into the same
session that it was created in. The saveRDS()/readRDS() works if you
save in one R session and then read in a different R session. The
assumption is that if you are still in the same session that created the
recordedplot you still have the recordedplot (e.g., you can just do
replayPlot(r) instead of replayPlot(r2). Is that a bad assumption ?
Paul
On 03/04/18 05:23, Winston Chang wrote:
The documentation for recordPlot says the following:
As of R 3.3.0, it is possible (again) to replay a plot from another R session
using, for example, saveRDS and readRDS.
However, I haven't been able to save and restore a plot displaylist
and have it work within the same R session, using R 3.4.3 or 3.3.3.
Here's an example:
# Save displaylist for a simple plot
png('test.png')
dev.control(displaylist ="enable")
plot(1:5, 1:5)
r <- recordPlot()
dev.off()
# Replay plot. This works.
png('test1.png')
replayPlot(r)
dev.off()
# Save the plot and load it, then try to replay it. This does not work.
saveRDS(r, 'recordedplot.rds')
r2 <- readRDS('recordedplot.rds')
png('test2.png')
replayPlot(r2) ## Error: NULL value passed as symbol address
dev.off()
Is there something that I'm doing wrong here?
__
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] Height not set properly in grDevices::jpeg() with type = "cairo"
Hi
That fix checks out for me so I have committed the change to r-devel.
Thanks for the report!
Paul
On 28/11/17 16:25, Marius wrote:
Hi,
I have been having issues producing plots in JPEG format, using type =
"cairo" to get better anti-aliasing. When trying to set the physical
size with units = "cm" or units = "mm", the width is set correctly but
the height is not - it looks like the height is simply treated as
pixels regardless of the 'units' argument.
Example:
x = 1:10
y = 2 * x
jpeg("ExamplePlot.jpg",
type = "cairo",
width = 200,
height = 200,
units = "mm",
res = 96)
plot(x, y)
dev.off()
On my system (Windows 7, running R 3.4.2), this produces a plot that
is 755 x 200 pixels, and is vertically very squashed.
Looking at grDevices::jpeg, it looks like the culprit is these lines:
g <- .geometry(width, height, units, res)
if (match.arg(type) == "cairo") {
antialias <- match(match.arg(antialias), aa.cairo)
invisible(.External(C_devCairo, filename, 3L, g$width,
height, pointsize, bg, res, antialias, quality, if
(nzchar(family)) family else "sans",
300))
}
g$width is used, but "height" is used instead of "g$height". I suspect
simply using "g$height" here would fix the issue but have not had time
to test this.
My R.version:
platform x86_64-w64-mingw32
arch x86_64
os mingw32
system x86_64, mingw32
status
major 3
minor 4.2
year 2017
month 09
day28
svn rev73368
language R
version.string R version 3.4.2 (2017-09-28)
nickname Short Summer
Please let me know if any further information is needed.
Thanks,
Marius
______
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] missing extern in GraphicsBase.h
Hi I have committed the suggested "extern" patch. Could you please confirm that this fixes the issue on Solaris (and anything else you can test) ? Thanks! Paul On 16/02/18 03:39, dmitrii.pasech...@maths.ox.ac.uk wrote: Dear all, in src/include/GraphicsBase.h one has a declaration int baseRegisterIndex; the same as in src/main/devices.c which causes problems on Solaris, see bug #17385, and other platforms with "unusual" linkers, see bug #16633. By right, global variables like baseRegisterIndex are to be declared just once, and not in a header file, but in a *.c file. Then, to use them elsewhere in the code, one declares them as extern in the header. (as proposed on #17385) Otherwise one has an undefined behaviour, some linkers might silently prepend extern, some not... May I humbly request attention to this bug (which is classified as UNCONFIRNMED---and indeed it needs an extra effort to reproduce the error on, say, Linux --- but it really is an obvious C bug, which will rear its ugly head sooner or later again) Thanks, Dmitrii __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] y label for X11 graphics
Sorry, can't reproduce on ... > sessionInfo() R version 3.4.1 (2017-06-30) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 14.04.5 LTS Matrix products: default BLAS: /usr/lib/libblas/libblas.so.3.0 LAPACK: /usr/lib/lapack/liblapack.so.3.0 locale: [1] LC_CTYPE=en_NZ.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_NZ.UTF-8LC_COLLATE=en_NZ.UTF-8 [5] LC_MONETARY=en_NZ.UTF-8LC_MESSAGES=en_NZ.UTF-8 [7] LC_PAPER=en_NZ.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_3.4.1 ... or on ... > sessionInfo() R Under development (unstable) (2017-09-12 r73246) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 14.04.5 LTS Matrix products: default BLAS: /home/pmur002/R/r-devel/BUILD/lib/libRblas.so LAPACK: /home/pmur002/R/r-devel/BUILD/lib/libRlapack.so locale: [1] LC_CTYPE=en_NZ.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_NZ.UTF-8LC_COLLATE=en_NZ.UTF-8 [5] LC_MONETARY=en_NZ.UTF-8LC_MESSAGES=en_NZ.UTF-8 [7] LC_PAPER=en_NZ.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_3.5.0 Paul On 14/09/17 04:03, Therneau, Terry M., Ph.D. wrote: In the following plot, the y label is missing if it is too long. x11(type="Xlib") plot(1:5, 1:5, ylab="Do, a deer, a female deer") # missing label plot(1:5, 1:5, ylab="Do") # label is present All is well for x11(type="cairo") This is true both under R devel 2017-09-01 on xubuntu (my desktop), and 3.4.1 on Centos 6.9 (department servers). A minor question is why my locally compiled version defaults to Xlib rather than cairo, since both work as explicit arguments to the x11() command. Terry T. __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] italic font on cairo devices in R 3.4
Hi
Do you have the 'fonts-texgyre' (Debian) package installed?
If not, does installing that help?
Paul
On 07/07/17 20:30, Ilia Kats wrote:
[cross-post from R-help]
Hi all,
I have the following problem: Since R 3.4.0, italic fonts rendered on
Cairo devices appear pixelated. Here's a minimal example:
cairo_pdf('test.pdf')
plot(1:10, ylab=expression(italic(test)))
dev.off()
The same problem occurs with bolditalic, but not bold. I am using Debian
Stretch. Several friends tried the same on their machines, another
Debian machine has the same problem. On MacOSX the output was not
pixelated, but it wasn't italic either. Ubuntu 16.04.2 xenial works
fine. My impression is that R somehow can't find the proper font to use
and falls back to something weird. Ideas?
Note that I'm not subscribed to the list, so please CC me in replies.
Cheers, Ilia
__
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] arrows: no vectors for "code" and "angle" parameters
Hi
I have added a warning (r-devel r72811).
I did this rather than allow vectors for length/angle/code because ...
- consistency with (implicit) description of arguments in help page
- backward compatibility (or at least no risk of not-backwards-incompatible)
- it was easier
Note that it is only the length/angle/code that are scalar, e.g., the
graphical parameters ARE recycled ...
arrows(x0 = x0, y0 = y0, x1 = x1, y1 = y1,
length = mylengths, code = mycodes, angle = myangle,
col = 1:3, lwd=1:3, lty=1:3)
Thanks for the report and suggestion.
Paul
On 20/06/17 09:58, Paul Johnson wrote:
I was teaching new R users to make some fun graphs. I had some arrows examples
worked up we came across a problem. The arrows function ignores 2nd
and following elements of vectors given as code an angle.
Would you please consider 1) allowing vectors for code and angle, or
2) returning an error or warning when user mistakenly supplies a
vector for those parameters? When code like this is wrapped into an
Sweaved document--we I don't see the graph on the screen--this error
is difficult to catch while proofreading.
Example:
x0 <- c(-1, -4, 4.5)
y0 <- c(-1, -4, -8)
x1 <- c(2, -2, -3)
y1 <- c(4, 4, 18)
mylengths <- c(0.2, 0.3, 0.15)
mycodes <- c(3, 2, 1)
myangle <- c(10, 60, 80)
plot(x = c(-5, 5), y = c(-10, 20),
type = "n", xlab = "", ylab = "")
arrows(x0 = x0, y0 = y0, x1 = x1, y1 = y1,
length = mylengths, code = mycodes, angle = myangle)
I found a workaround, but this is more difficult to explain to beginners...
plot(x = c(-5, 5), y = c(-10, 20),
type = "n", xlab = "", ylab = "")
mapply(arrows, x0 = x0, y0 = y0, x1 = x1, y1 = y1,
length = mylengths, angle = myangle, code = mycodes)
pj
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error messages in replayPlot()
Hi
The "figure margins too large" message is suppressed on replay because
that replay code is also played when resizing a graphics device (so if
it was printed to the console you could get millions of error messages
as you resized a window) - on replay, the message is drawn on the
graphics device instead (take a look at the PNG that your second example
creates), but that is not necessarily easy to access.
Paul
On 16/05/17 00:07, Jeroen Ooms wrote:
I was wondering if there is something that can be done to improve
error messages when replaying a recorded plot. For example a graphics
device that is too small usually results in a helpful error message:
png(height = 100)
plot(1)
# Error in plot.new() : figure margins too large
dev.off()
However when this happens when replaying a recorded plot, the error
message is not so helpful.
myplot <- evaluate::evaluate("plot(1)")[[2]]
png(height = 100)
replayPlot(myplot)
# Error in replayPlot(x) : invalid graphics state
dev.off()
A more informative error message that hints at what exactly is invalid
about the graphics state would be very helpful in this case.
__
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] polypath winding rule with transparency
Thanks for the additional information. I see the behaviour that you are reporting (on Windows), which is pretty weird behaviour! Hopefully this will shed some light on the other problem that you reported, rather than being another unrelated problem. Paul On 24/04/2017 1:37 p.m., Michael Sumner wrote: On Thu, 4 Aug 2016 at 17:53 Michael Sumner <mdsum...@gmail.com <mailto:mdsum...@gmail.com>> wrote: On Thu, 4 Aug 2016 at 11:17 Paul Murrell <p...@stat.auckland.ac.nz <mailto:p...@stat.auckland.ac.nz>> wrote: Hi Just to clarify, I think this IS a problem with grid.path() as well as polypath(). Hi, oh dear - sorry about that I appreciate the deeper explanation, I knew about the id aspect in grid, but just forgot in my haste. I'll be more careful with examples if I find any more clues. I've found a possibly related issue, again only on Windows as far as I can see. These two plots give different results, the second is completely transparent rather than the expected light blue region on the left. Whether it works or not seems to depend on the specific geometry of the device and *not on the specific xlim interval chosen*. I can get the problem to come and by interactively resizing the window resulting from the first plot. Somehow it's related to the intersection-detection of the filled polygon with the plot region (?). pp <- matrix(c(0, 0, 0, 1, 1, 1, 1, 0, 0, 0), ncol = 2, byrow = TRUE) xlim <- c(0.24, 1.5) ## ok at xlim[1] = 0.24 ## first plot, ok (but also try resizing the window by dragging the left side out) plot(pp, main = "winding/transparent", xlim = xlim) polypath(pp, col = "#ADD8E6E6", rule = "winding") xlim <- c(0.25, 1.5) ## second plot, not ok plot(pp, main = "winding/transparent", xlim = xlim) polypath(pp, col = "#ADD8E6E6", rule = "winding") Cheers, Mike. Cheers, Mike. For the example you give, grid.path() diverts to drawing a polygon (because there is no 'id' specified), and the NAs in 'x' generate two separate polygons, which get drawn one on top of the other. The correct analogy to the polypath() example is ... x2 <- matrix(x[!is.na <http://is.na>(x)], ncol=2) grid.path(x2[,1], x2[,2], id=rep(1:2, each=4), rule="winding", gp=gpar(="#BEBEBE80")) ... which produces the same (wrong) result as polypath() on Windows. Also, the grid.path() result for your example is NOT the same as the correct result; we do NOT want a separate shade for the intersecting region when the "winding" fill rule is working correctly. The fill should be the same across the union of the square regions (this is what Cairo and PDF on Linux produce). Another data point: the problem is NOT just a matter of getting the rules round the wrong way in the devWindows.c; using rule="evenodd" produces the SAME result as using rule="winding". One more data point: this is not JUST a problem with polypath(). Creating a self-intersecting polygon and then drawing it, using polygon(), in windows(fillEvenOdd=FALSE) and windows(filleEvenOdd=TRUE) produces exactly the same result. Sadly, none of that helps to explain why the "winding" rule is not working on Windows :( Thanks for reporting the problem - needs more study to find out what is going wrong. Paul On 03/08/16 18:47, Michael Sumner wrote: > Hello, > > it's probably worth adding that this is not a problem with pathGrob, only > polypath. > > This code is sufficient to demonstrate the problem in Windows. > > ## overlapping, both clock-wise > x <- cbind(c(.1, .1, .6, .6, NA, .4, .4, .9, .9), > c(.1, .6, .6, .1, NA, .4, .9, .9, .4)) > ## only a problem on Windows windows() and png() > plot(x);polypath(x, rule = "winding", col = "#BEBEBE80") > > This code shows the same behaviour on different systems/devices. > > ## no problem on Windows/Linux/PNG/PDF ... > library(grid) > grid.newpage() > pushViewport(viewport(0.5, 0.5, width = 1, height = 1)) > grid.draw(pathGrob(x[,1], x[,2], rule = "winding", gp = gpar(fill = > "#BEBEBE80"))) > > Cheers, Mike. > > On Wed, 3 Aug 2016 at 16:24 Michael Sumner <mdsum...@gmail.com <mailto:mdsum...@gmail.com>> wrote: >
[Rd] Graphics Device API change
Hi r72261 in r-devel has modified the graphics device API and bumped R_GE_version in GraphicsEngine.h (to satisfy PR 16951). This means that ... (i) third-party graphics device packages need to be reinstalled. (ii) third-party graphics device packages will ideally need a new version for r-devel. (iii) any packages that make use of getGraphicsEvent() should test against r-devel (and let me know of any problems). Thanks Paul -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] Re: Replaying a recorded plot (mixed base and grid) from pdf() in cairo_pdf() crashes R
Hi
I decided to blame cairo_pdf().
There is a fix in r-devel (r72242) that works for the reported case,
plus some basic sanity checks.
I could not complete 'make check-devel' because it was failing on
reg-tests-1d.R ...
> stopifnot(length(fd) == 10, identical(fd, format(dct <-
as.POSIXct(dlt
Error: identical(fd, format(dct <- as.POSIXct(dlt))) is not TRUE
... anyone else seeing that ?
I would appreciate confirmation from a heavier user of cairo_pdf() that
I have not broken anything.
Paul
On 21/02/17 08:27, Paul Murrell wrote:
Hi
This appears to be happening (at least) because cairo_pdf() delays
initialising a Cairo surface until BM_NewPage(), rather than
initiliasing a Cairo surface in BM_Open(), and replayPlot() triggers
some activity (set clip region) on the device BEFORE a new page is
started (so the pointer to the Cairo surface is null, so BOOM).
Not sure yet whether to blame replayPlot() for not starting with a new
page operation OR to blame cairo_pdf() for not initialising a Cairo
surface at device startup.
If anyone who knows more about Cairo (or cairo_pdf()) wants to point out
a good reason for the way cairo_pdf() currently works, please don't hold
back.
Paul
On 21/02/17 05:30, Yihui Xie wrote:
A quick follow-up: I just used cairo_pdf() as the recording device,
and it crashes R as well, so it is probably not relevant to pdf() but
an issue specific to cairo_pdf().
cairo_pdf()
dev.control('enable')
library("grid")
plot(1)
grid.text("A")
res = recordPlot()
dev.off()
cairo_pdf()
replayPlot(res)
dev.off()
Regards,
Yihui
--
https://yihui.name
On Mon, Feb 20, 2017 at 10:24 AM, Yihui Xie <x...@yihui.name> wrote:
Hi,
I wonder if this is expected or I'm doing a wrong thing.
pdf()
dev.control('enable')
library("grid")
plot(1)
grid.text("A")
res = recordPlot()
dev.off()
cairo_pdf()
replayPlot(res)
dev.off()
*** caught segfault ***
address 0x4, cause 'memory not mapped'
sessionInfo()
R version 3.3.2 (2016-10-31)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: macOS Sierra 10.12.3
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_3.3.2 yaml_2.1.14
Regards,
Yihui
--
https://yihui.name
__
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] Re: Replaying a recorded plot (mixed base and grid) from pdf() in cairo_pdf() crashes R
Hi
This appears to be happening (at least) because cairo_pdf() delays
initialising a Cairo surface until BM_NewPage(), rather than
initiliasing a Cairo surface in BM_Open(), and replayPlot() triggers
some activity (set clip region) on the device BEFORE a new page is
started (so the pointer to the Cairo surface is null, so BOOM).
Not sure yet whether to blame replayPlot() for not starting with a new
page operation OR to blame cairo_pdf() for not initialising a Cairo
surface at device startup.
If anyone who knows more about Cairo (or cairo_pdf()) wants to point out
a good reason for the way cairo_pdf() currently works, please don't hold
back.
Paul
On 21/02/17 05:30, Yihui Xie wrote:
A quick follow-up: I just used cairo_pdf() as the recording device,
and it crashes R as well, so it is probably not relevant to pdf() but
an issue specific to cairo_pdf().
cairo_pdf()
dev.control('enable')
library("grid")
plot(1)
grid.text("A")
res = recordPlot()
dev.off()
cairo_pdf()
replayPlot(res)
dev.off()
Regards,
Yihui
--
https://yihui.name
On Mon, Feb 20, 2017 at 10:24 AM, Yihui Xie <x...@yihui.name> wrote:
Hi,
I wonder if this is expected or I'm doing a wrong thing.
pdf()
dev.control('enable')
library("grid")
plot(1)
grid.text("A")
res = recordPlot()
dev.off()
cairo_pdf()
replayPlot(res)
dev.off()
*** caught segfault ***
address 0x4, cause 'memory not mapped'
sessionInfo()
R version 3.3.2 (2016-10-31)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: macOS Sierra 10.12.3
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_3.3.2 yaml_2.1.14
Regards,
Yihui
--
https://yihui.name
__
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] getGraphicsEvent() alternative for cairo graphics device?
Hi Yes, we have regression tests for graphics. In general, but especially for core R code, I would rather have confidence that a fix has not broken existing behaviour before I commit it. I cannot argue with the point that we could respond to some bug reports faster. Paul On 09/12/16 12:58, frede...@ofb.net wrote: Hi Paul, Thanks for keeping me posted and letting me know what I should do. Are there regression tests for other graphics functions in R? To me that sounds a bit unnecessary. I think you get more testing from people who use R; and having a good turnaround for applying patches (some have been waiting 5 years) would invite better participation. Thank you, Frederick On Fri, Dec 09, 2016 at 12:01:55PM +1300, Paul Murrell wrote: Hi Just taking a bit more of a look at this today (currently fixated on making sure I can build some good regression tests). The best thing you can do is to keep reminding me like this :) Paul On 09/12/16 11:19, frede...@ofb.net wrote: Hi Paul, Thanks for your efforts. Do you have an idea when my patch(es) might be committed? Is there anything I can do to help move this along? Thanks, Frederick On Mon, Nov 14, 2016 at 08:55:20AM +1300, Paul Murrell wrote: Hi The current status is that I am keen for people to contribute some testing code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951) There were also some getGraphicsEvent() changes/fixes suggested by Richard Bodewits (cc'ed), for which I am also seeking test code. Paul On 13/11/16 09:00, frede...@ofb.net wrote: Hi Paul, Just checking in to see what the status is. From my perspective it seems logical to split off X11 into a separate package, so development can proceed at a reasonable rate, but I haven't yet tried to see if that's even possible. Thanks, Frederick On Tue, Jul 26, 2016 at 09:23:35AM +1200, Paul Murrell wrote: Hi Taking a look at those patches is now on my todo list, so I may be in touch with both of you at some point to request some testing. Paul On 26/07/16 07:17, frede...@ofb.net wrote: Dear Daniel Greenidge, To enable getGraphicsEvent on Cairo, you have two patches to choose from: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364 https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951 The second one is by me, and the first one is from five years ago by Hugo Mildenberger. Both patches are very simple, they move some lines enabling getGrahpicsEvent outside of a if(!cairo) statement. My patch also adds the ability to execute code (e.g. for animation) while the interface is idle. Top guy Duncan Murdoch has expressed that he doesn't have time to work on applying these patches, and I haven't had any responses from the rest of the R Core Team. I was thinking that perhaps your best bet is to try to create a package called e.g. "X11-fixes" which people can use to get a better X11 library (there is also a bug waiting to be fixed from 2001: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702). I don't know if CRAN would accept such a package, or if you'd have to distribute it via GitHub, but R has excellent tools to facilitate the distribution of code via packages. Whether the R kernel exports enough functions to allow a package to take over event handling, I'm not sure. I was intending to look more into the details of this possibility but haven't had time. Best wishes, Frederick On Mon, Jul 25, 2016 at 02:15:59PM -0400, Daniel Greenidge wrote: Hi all, I'm writing an interactive plotting function for viewing fMRI datasets. Currently, I get keypresses using grDevices::getGraphicsEvent(). Unfortunately getGraphicsEvent() only supports the X11(type="Xlib") graphics device on Unix systems. The Xlib device doesn't support buffering (i.e. dev.hold() and dev.flush()), so redrawing the plots causes lots of flickering. Is there a way to get keypresses while using the cairo graphics device? Alternatively, is there a way to prevent flickering with the Xlib graphics device? Best, Daniel Greenidge __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckl
Re: [Rd] getGraphicsEvent() alternative for cairo graphics device?
Hi Just taking a bit more of a look at this today (currently fixated on making sure I can build some good regression tests). The best thing you can do is to keep reminding me like this :) Paul On 09/12/16 11:19, frede...@ofb.net wrote: Hi Paul, Thanks for your efforts. Do you have an idea when my patch(es) might be committed? Is there anything I can do to help move this along? Thanks, Frederick On Mon, Nov 14, 2016 at 08:55:20AM +1300, Paul Murrell wrote: Hi The current status is that I am keen for people to contribute some testing code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951) There were also some getGraphicsEvent() changes/fixes suggested by Richard Bodewits (cc'ed), for which I am also seeking test code. Paul On 13/11/16 09:00, frede...@ofb.net wrote: Hi Paul, Just checking in to see what the status is. From my perspective it seems logical to split off X11 into a separate package, so development can proceed at a reasonable rate, but I haven't yet tried to see if that's even possible. Thanks, Frederick On Tue, Jul 26, 2016 at 09:23:35AM +1200, Paul Murrell wrote: Hi Taking a look at those patches is now on my todo list, so I may be in touch with both of you at some point to request some testing. Paul On 26/07/16 07:17, frede...@ofb.net wrote: Dear Daniel Greenidge, To enable getGraphicsEvent on Cairo, you have two patches to choose from: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364 https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951 The second one is by me, and the first one is from five years ago by Hugo Mildenberger. Both patches are very simple, they move some lines enabling getGrahpicsEvent outside of a if(!cairo) statement. My patch also adds the ability to execute code (e.g. for animation) while the interface is idle. Top guy Duncan Murdoch has expressed that he doesn't have time to work on applying these patches, and I haven't had any responses from the rest of the R Core Team. I was thinking that perhaps your best bet is to try to create a package called e.g. "X11-fixes" which people can use to get a better X11 library (there is also a bug waiting to be fixed from 2001: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702). I don't know if CRAN would accept such a package, or if you'd have to distribute it via GitHub, but R has excellent tools to facilitate the distribution of code via packages. Whether the R kernel exports enough functions to allow a package to take over event handling, I'm not sure. I was intending to look more into the details of this possibility but haven't had time. Best wishes, Frederick On Mon, Jul 25, 2016 at 02:15:59PM -0400, Daniel Greenidge wrote: Hi all, I'm writing an interactive plotting function for viewing fMRI datasets. Currently, I get keypresses using grDevices::getGraphicsEvent(). Unfortunately getGraphicsEvent() only supports the X11(type="Xlib") graphics device on Unix systems. The Xlib device doesn't support buffering (i.e. dev.hold() and dev.flush()), so redrawing the plots causes lots of flickering. Is there a way to get keypresses while using the cairo graphics device? Alternatively, is there a way to prevent flickering with the Xlib graphics device? Best, Daniel Greenidge __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] getGraphicsEvent() alternative for cairo graphics device?
Hi That sounds good - somewhere public like that would be best. Thanks! Paul On 16/11/16 00:13, Mark O'Connell wrote: Hi Paul, No problem. Is it best if I post examples to the bug report 16951? Kind regards, Mark -- Mark O'Connell, PhD student Department of Mathematics & Statistics 231 Top Logic National University of Ireland, Maynooth ----- Paul Murrell <p...@stat.auckland.ac.nz> wrote: Thanks Frederick. Mark, if you have any examples to share, they would also be gratefully received. Paul On 14/11/16 14:53, frede...@ofb.net wrote: Hi Paul, OK I tried not to make the examples too fancy. Please let me know what you think. They should probably be amended to support the Windows platform, but I think that task would be much easier for someone with access to Windows... By the way I'm Cc'ing Mark O'Connell who shared with me some great getGraphicsEvent examples - well, I found them useful, perhaps if these are going to the R distro somewhere, then his examples should be included as well. Thank you, Frederick On Mon, Nov 14, 2016 at 01:51:08PM +1300, Paul Murrell wrote: Great. Thanks! Paul On 14/11/16 13:41, frede...@ofb.net wrote: Hi Paul, Thank you, for some reason I didn't seem to get an email notification for your bugzilla comment! I will try to send you something shortly. Frederick On Mon, Nov 14, 2016 at 08:55:20AM +1300, Paul Murrell wrote: Hi The current status is that I am keen for people to contribute some testing code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951) There were also some getGraphicsEvent() changes/fixes suggested by Richard Bodewits (cc'ed), for which I am also seeking test code. Paul On 13/11/16 09:00, frede...@ofb.net wrote: Hi Paul, Just checking in to see what the status is. From my perspective it seems logical to split off X11 into a separate package, so development can proceed at a reasonable rate, but I haven't yet tried to see if that's even possible. Thanks, Frederick On Tue, Jul 26, 2016 at 09:23:35AM +1200, Paul Murrell wrote: Hi Taking a look at those patches is now on my todo list, so I may be in touch with both of you at some point to request some testing. Paul On 26/07/16 07:17, frede...@ofb.net wrote: Dear Daniel Greenidge, To enable getGraphicsEvent on Cairo, you have two patches to choose from: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364 https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951 The second one is by me, and the first one is from five years ago by Hugo Mildenberger. Both patches are very simple, they move some lines enabling getGrahpicsEvent outside of a if(!cairo) statement. My patch also adds the ability to execute code (e.g. for animation) while the interface is idle. Top guy Duncan Murdoch has expressed that he doesn't have time to work on applying these patches, and I haven't had any responses from the rest of the R Core Team. I was thinking that perhaps your best bet is to try to create a package called e.g. "X11-fixes" which people can use to get a better X11 library (there is also a bug waiting to be fixed from 2001: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702). I don't know if CRAN would accept such a package, or if you'd have to distribute it via GitHub, but R has excellent tools to facilitate the distribution of code via packages. Whether the R kernel exports enough functions to allow a package to take over event handling, I'm not sure. I was intending to look more into the details of this possibility but haven't had time. Best wishes, Frederick On Mon, Jul 25, 2016 at 02:15:59PM -0400, Daniel Greenidge wrote: Hi all, I'm writing an interactive plotting function for viewing fMRI datasets. Currently, I get keypresses using grDevices::getGraphicsEvent(). Unfortunately getGraphicsEvent() only supports the X11(type="Xlib") graphics device on Unix systems. The Xlib device doesn't support buffering (i.e. dev.hold() and dev.flush()), so redrawing the plots causes lots of flickering. Is there a way to get keypresses while using the cairo graphics device? Alternatively, is there a way to prevent flickering with the Xlib graphics device? Best, Daniel Greenidge __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New
Re: [Rd] getGraphicsEvent() alternative for cairo graphics device?
Thanks Frederick. Mark, if you have any examples to share, they would also be gratefully received. Paul On 14/11/16 14:53, frede...@ofb.net wrote: Hi Paul, OK I tried not to make the examples too fancy. Please let me know what you think. They should probably be amended to support the Windows platform, but I think that task would be much easier for someone with access to Windows... By the way I'm Cc'ing Mark O'Connell who shared with me some great getGraphicsEvent examples - well, I found them useful, perhaps if these are going to the R distro somewhere, then his examples should be included as well. Thank you, Frederick On Mon, Nov 14, 2016 at 01:51:08PM +1300, Paul Murrell wrote: Great. Thanks! Paul On 14/11/16 13:41, frede...@ofb.net wrote: Hi Paul, Thank you, for some reason I didn't seem to get an email notification for your bugzilla comment! I will try to send you something shortly. Frederick On Mon, Nov 14, 2016 at 08:55:20AM +1300, Paul Murrell wrote: Hi The current status is that I am keen for people to contribute some testing code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951) There were also some getGraphicsEvent() changes/fixes suggested by Richard Bodewits (cc'ed), for which I am also seeking test code. Paul On 13/11/16 09:00, frede...@ofb.net wrote: Hi Paul, Just checking in to see what the status is. From my perspective it seems logical to split off X11 into a separate package, so development can proceed at a reasonable rate, but I haven't yet tried to see if that's even possible. Thanks, Frederick On Tue, Jul 26, 2016 at 09:23:35AM +1200, Paul Murrell wrote: Hi Taking a look at those patches is now on my todo list, so I may be in touch with both of you at some point to request some testing. Paul On 26/07/16 07:17, frede...@ofb.net wrote: Dear Daniel Greenidge, To enable getGraphicsEvent on Cairo, you have two patches to choose from: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364 https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951 The second one is by me, and the first one is from five years ago by Hugo Mildenberger. Both patches are very simple, they move some lines enabling getGrahpicsEvent outside of a if(!cairo) statement. My patch also adds the ability to execute code (e.g. for animation) while the interface is idle. Top guy Duncan Murdoch has expressed that he doesn't have time to work on applying these patches, and I haven't had any responses from the rest of the R Core Team. I was thinking that perhaps your best bet is to try to create a package called e.g. "X11-fixes" which people can use to get a better X11 library (there is also a bug waiting to be fixed from 2001: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702). I don't know if CRAN would accept such a package, or if you'd have to distribute it via GitHub, but R has excellent tools to facilitate the distribution of code via packages. Whether the R kernel exports enough functions to allow a package to take over event handling, I'm not sure. I was intending to look more into the details of this possibility but haven't had time. Best wishes, Frederick On Mon, Jul 25, 2016 at 02:15:59PM -0400, Daniel Greenidge wrote: Hi all, I'm writing an interactive plotting function for viewing fMRI datasets. Currently, I get keypresses using grDevices::getGraphicsEvent(). Unfortunately getGraphicsEvent() only supports the X11(type="Xlib") graphics device on Unix systems. The Xlib device doesn't support buffering (i.e. dev.hold() and dev.flush()), so redrawing the plots causes lots of flickering. Is there a way to get keypresses while using the cairo graphics device? Alternatively, is there a way to prevent flickering with the Xlib graphics device? Best, Daniel Greenidge __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] getGraphicsEvent() alternative for cairo graphics device?
Great. Thanks! Paul On 14/11/16 13:41, frede...@ofb.net wrote: Hi Paul, Thank you, for some reason I didn't seem to get an email notification for your bugzilla comment! I will try to send you something shortly. Frederick On Mon, Nov 14, 2016 at 08:55:20AM +1300, Paul Murrell wrote: Hi The current status is that I am keen for people to contribute some testing code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951) There were also some getGraphicsEvent() changes/fixes suggested by Richard Bodewits (cc'ed), for which I am also seeking test code. Paul On 13/11/16 09:00, frede...@ofb.net wrote: Hi Paul, Just checking in to see what the status is. From my perspective it seems logical to split off X11 into a separate package, so development can proceed at a reasonable rate, but I haven't yet tried to see if that's even possible. Thanks, Frederick On Tue, Jul 26, 2016 at 09:23:35AM +1200, Paul Murrell wrote: Hi Taking a look at those patches is now on my todo list, so I may be in touch with both of you at some point to request some testing. Paul On 26/07/16 07:17, frede...@ofb.net wrote: Dear Daniel Greenidge, To enable getGraphicsEvent on Cairo, you have two patches to choose from: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364 https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951 The second one is by me, and the first one is from five years ago by Hugo Mildenberger. Both patches are very simple, they move some lines enabling getGrahpicsEvent outside of a if(!cairo) statement. My patch also adds the ability to execute code (e.g. for animation) while the interface is idle. Top guy Duncan Murdoch has expressed that he doesn't have time to work on applying these patches, and I haven't had any responses from the rest of the R Core Team. I was thinking that perhaps your best bet is to try to create a package called e.g. "X11-fixes" which people can use to get a better X11 library (there is also a bug waiting to be fixed from 2001: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702). I don't know if CRAN would accept such a package, or if you'd have to distribute it via GitHub, but R has excellent tools to facilitate the distribution of code via packages. Whether the R kernel exports enough functions to allow a package to take over event handling, I'm not sure. I was intending to look more into the details of this possibility but haven't had time. Best wishes, Frederick On Mon, Jul 25, 2016 at 02:15:59PM -0400, Daniel Greenidge wrote: Hi all, I'm writing an interactive plotting function for viewing fMRI datasets. Currently, I get keypresses using grDevices::getGraphicsEvent(). Unfortunately getGraphicsEvent() only supports the X11(type="Xlib") graphics device on Unix systems. The Xlib device doesn't support buffering (i.e. dev.hold() and dev.flush()), so redrawing the plots causes lots of flickering. Is there a way to get keypresses while using the cairo graphics device? Alternatively, is there a way to prevent flickering with the Xlib graphics device? Best, Daniel Greenidge __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] getGraphicsEvent() alternative for cairo graphics device?
Hi The current status is that I am keen for people to contribute some testing code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951) There were also some getGraphicsEvent() changes/fixes suggested by Richard Bodewits (cc'ed), for which I am also seeking test code. Paul On 13/11/16 09:00, frede...@ofb.net wrote: Hi Paul, Just checking in to see what the status is. From my perspective it seems logical to split off X11 into a separate package, so development can proceed at a reasonable rate, but I haven't yet tried to see if that's even possible. Thanks, Frederick On Tue, Jul 26, 2016 at 09:23:35AM +1200, Paul Murrell wrote: Hi Taking a look at those patches is now on my todo list, so I may be in touch with both of you at some point to request some testing. Paul On 26/07/16 07:17, frede...@ofb.net wrote: Dear Daniel Greenidge, To enable getGraphicsEvent on Cairo, you have two patches to choose from: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364 https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951 The second one is by me, and the first one is from five years ago by Hugo Mildenberger. Both patches are very simple, they move some lines enabling getGrahpicsEvent outside of a if(!cairo) statement. My patch also adds the ability to execute code (e.g. for animation) while the interface is idle. Top guy Duncan Murdoch has expressed that he doesn't have time to work on applying these patches, and I haven't had any responses from the rest of the R Core Team. I was thinking that perhaps your best bet is to try to create a package called e.g. "X11-fixes" which people can use to get a better X11 library (there is also a bug waiting to be fixed from 2001: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702). I don't know if CRAN would accept such a package, or if you'd have to distribute it via GitHub, but R has excellent tools to facilitate the distribution of code via packages. Whether the R kernel exports enough functions to allow a package to take over event handling, I'm not sure. I was intending to look more into the details of this possibility but haven't had time. Best wishes, Frederick On Mon, Jul 25, 2016 at 02:15:59PM -0400, Daniel Greenidge wrote: Hi all, I'm writing an interactive plotting function for viewing fMRI datasets. Currently, I get keypresses using grDevices::getGraphicsEvent(). Unfortunately getGraphicsEvent() only supports the X11(type="Xlib") graphics device on Unix systems. The Xlib device doesn't support buffering (i.e. dev.hold() and dev.flush()), so redrawing the plots causes lots of flickering. Is there a way to get keypresses while using the cairo graphics device? Alternatively, is there a way to prevent flickering with the Xlib graphics device? Best, Daniel Greenidge __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Handlers in setGraphicsEventHandlers() can recursively call getGraphicsEvent(). Intended behavior?
Hi
Thanks for the further analysis. Sounds reasonable to me.
What would be good to get from you is:
- a test that does recursive getGraphicsEvent() calls, that is fixed by
your patch
- a test that produces the newline prompt from getGraphicsEvent(), that
is fixed by your other patch
- a test that loses event handling with setTimeLimit(), that is fixed by
your other other patch.
I have a partial list of packages that are known to make use of
getGraphicsEvent(), so we can hopefully involve those package authors in
testing for backward compatibility.
Paul
On 21/09/16 23:23, Richard Bodewits wrote:
doKeybd() gets called in CHelpKeyIn() and NHelpKeyIn() in
library/grDevices/src/devWindows.c, where the call is encapsulated in an
'if (dd->gettingEvent)' block. So the only times this code ever calls
doKeybd() is when gettingEvent is in fact set.
Further, it's called in two locations in X11_eventHelper(), in
modules/X11/devX11.c, where the state of gettingEvent seems to be moot
for its handling.
doMouseEvent() in turn is called in HelpMouseClick(), HelpMouseMove(),
and HelpMouseUp() in devWindows.c, where again each call is only made
after checking if gettingEvent is true.
In devX11.c it's called once in X11_eventHelper(), after checking if
gettingEvent is true.
Other than these calls, gettingEvent does not get checked anywhere
outside of main/gevents.c, and nothing called in doKeybd() or
doMouseEvent() depends on its state being toggled either which way.
As far as I've been able to ascertain these lines are completely
superfluous, as well as introducing a recursion issue that they seem to
have been meant to somehow prevent.
As for tests, I can look into cooking something up, though I'm going to
be spread a little thin for the next three months.
After 12 years of this code being in place I doubt I'll be able to cover
every imaginable usecase scenario by myself though.
But thanks for replying. Was starting to think I was screaming into the
void. ;-)
- Richard Bodewits
On 09/21/2016 03:42 AM, Paul Murrell wrote:
Hi
Is the correct patch to remove the setting of the gettingEvent flag or
would it be better to flip the TRUE/FALSE setting (set to TRUE before
handling then reset to FALSE after handling) ?
Also, for this patch and for the other two you sent, one difficulty will
be with testing the patches. I have no testing code for this, so would
need at least a test or two from you (ideally someone would also have
some regression tests, beyond ?getGraphicsEvent, to ensure continuity of
previous behaviour).
Paul
On 18/09/2016 3:29 a.m., Richard Bodewits wrote:
Hey all.
As in general it's a bad idea to allow an event handler to generate an
event, and as comments in the code seem to suggest this isn't the
intention either, I was wondering about recursion in getGraphicsEvent().
In main/gevents.c, both doMouseEvent() and doKeybd() have the following
line;
dd->gettingEvent = FALSE; /* avoid recursive calls */
And they reset it to TRUE before returning. The effective result of this
is that the event handlers on the R side are allowed to call
getGraphicsEvent(), and recurse until they eventually would run out of
stack space. Though R does catch and handle that cleanly with the error;
Error: evaluation nested too deeply: infinite recursion /
options(expressions=)?
A quick scan of the SVN logs suggests this code has been untouched since
its introduction in 2004, so I'm left to wonder if this is intended
behavior. It stands out as a bit of a sore thumb due to the generic
check for recursion in do_getGraphicsEvent() in the same file, which
will error out with error(_("recursive use of 'getGraphicsEvent' not
supported")) if dd->gettingEvent is already set to TRUE. Which would
suggest recursively calling it is very much not intended to be possible.
To me, setting gettingEvent to FALSE seems like an easy mistake to make
if you temporarily interpret gettingEvent to mean that event(s) are
allowed to still come in. But the actual interpretation in
do_getGraphicsEvents() is the opposite, as it's interpreted as an
indicator of whether or not an event is currently being processed.
I've removed the gettingEvent altering lines from both doMouseEvent()
and doKeybd() to no ill effect, and doing so disabled the ability to
call getGraphicsEvent() from inside one of the assigned handlers as
expected. But after 12 (!) years, it's conceivable that people have come
to depend on this behavior in existing scripts. Is this something that
should be left alone to minimize disruption? Or should this be fixed (if
it is indeed unintended) for the sake of protecting people from infinite
recursions?
I've included a small patch as attachment that removes the offending
lines.
- Richard Bodewits
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-
Re: [Rd] Handlers in setGraphicsEventHandlers() can recursively call getGraphicsEvent(). Intended behavior?
Hi
Is the correct patch to remove the setting of the gettingEvent flag or
would it be better to flip the TRUE/FALSE setting (set to TRUE before
handling then reset to FALSE after handling) ?
Also, for this patch and for the other two you sent, one difficulty will
be with testing the patches. I have no testing code for this, so would
need at least a test or two from you (ideally someone would also have
some regression tests, beyond ?getGraphicsEvent, to ensure continuity of
previous behaviour).
Paul
On 18/09/2016 3:29 a.m., Richard Bodewits wrote:
Hey all.
As in general it's a bad idea to allow an event handler to generate an
event, and as comments in the code seem to suggest this isn't the
intention either, I was wondering about recursion in getGraphicsEvent().
In main/gevents.c, both doMouseEvent() and doKeybd() have the following
line;
dd->gettingEvent = FALSE; /* avoid recursive calls */
And they reset it to TRUE before returning. The effective result of this
is that the event handlers on the R side are allowed to call
getGraphicsEvent(), and recurse until they eventually would run out of
stack space. Though R does catch and handle that cleanly with the error;
Error: evaluation nested too deeply: infinite recursion /
options(expressions=)?
A quick scan of the SVN logs suggests this code has been untouched since
its introduction in 2004, so I'm left to wonder if this is intended
behavior. It stands out as a bit of a sore thumb due to the generic
check for recursion in do_getGraphicsEvent() in the same file, which
will error out with error(_("recursive use of 'getGraphicsEvent' not
supported")) if dd->gettingEvent is already set to TRUE. Which would
suggest recursively calling it is very much not intended to be possible.
To me, setting gettingEvent to FALSE seems like an easy mistake to make
if you temporarily interpret gettingEvent to mean that event(s) are
allowed to still come in. But the actual interpretation in
do_getGraphicsEvents() is the opposite, as it's interpreted as an
indicator of whether or not an event is currently being processed.
I've removed the gettingEvent altering lines from both doMouseEvent()
and doKeybd() to no ill effect, and doing so disabled the ability to
call getGraphicsEvent() from inside one of the assigned handlers as
expected. But after 12 (!) years, it's conceivable that people have come
to depend on this behavior in existing scripts. Is this something that
should be left alone to minimize disruption? Or should this be fixed (if
it is indeed unintended) for the sake of protecting people from infinite
recursions?
I've included a small patch as attachment that removes the offending lines.
- Richard Bodewits
__
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] Re: polypath winding rule with transparency
Hi
Just to clarify, I think this IS a problem with grid.path() as well as
polypath().
For the example you give, grid.path() diverts to drawing a polygon
(because there is no 'id' specified), and the NAs in 'x' generate two
separate polygons, which get drawn one on top of the other.
The correct analogy to the polypath() example is ...
x2 <- matrix(x[!is.na(x)], ncol=2)
grid.path(x2[,1], x2[,2], id=rep(1:2, each=4),
rule="winding", gp=gpar(="#BEBEBE80"))
... which produces the same (wrong) result as polypath() on Windows.
Also, the grid.path() result for your example is NOT the same as the
correct result; we do NOT want a separate shade for the intersecting
region when the "winding" fill rule is working correctly. The fill
should be the same across the union of the square regions (this is what
Cairo and PDF on Linux produce).
Another data point: the problem is NOT just a matter of getting the
rules round the wrong way in the devWindows.c; using rule="evenodd"
produces the SAME result as using rule="winding".
One more data point: this is not JUST a problem with polypath().
Creating a self-intersecting polygon and then drawing it, using
polygon(), in windows(fillEvenOdd=FALSE) and windows(filleEvenOdd=TRUE)
produces exactly the same result.
Sadly, none of that helps to explain why the "winding" rule is not
working on Windows :(
Thanks for reporting the problem - needs more study to find out what is
going wrong.
Paul
On 03/08/16 18:47, Michael Sumner wrote:
Hello,
it's probably worth adding that this is not a problem with pathGrob, only
polypath.
This code is sufficient to demonstrate the problem in Windows.
## overlapping, both clock-wise
x <- cbind(c(.1, .1, .6, .6, NA, .4, .4, .9, .9),
c(.1, .6, .6, .1, NA, .4, .9, .9, .4))
## only a problem on Windows windows() and png()
plot(x);polypath(x, rule = "winding", col = "#BEBEBE80")
This code shows the same behaviour on different systems/devices.
## no problem on Windows/Linux/PNG/PDF ...
library(grid)
grid.newpage()
pushViewport(viewport(0.5, 0.5, width = 1, height = 1))
grid.draw(pathGrob(x[,1], x[,2], rule = "winding", gp = gpar(fill =
"#BEBEBE80")))
Cheers, Mike.
On Wed, 3 Aug 2016 at 16:24 Michael Sumner <mdsum...@gmail.com> wrote:
Hi, I see different results in png() and pdf() for polypath() on Windows
when using the "winding" rule
## overlapping, both clock-wise
x <- cbind(c(.1, .1, .6, .6, NA, .4, .4, .9, .9),
c(.1, .6, .6, .1, NA, .4, .9, .9, .4))
pfun <- function() {
plot(x)
polypath(x * 0.8 + 0.2, rule = "winding", col = "#BEBEBE80")
polypath(x, rule = "winding", col = "#BEBEBE80")
}
## output "windows.png/pdf" or "unix.png/pdf"
label <- .Platform$OS.type
png(sprintf("%s.png", label))
pfun()
dev.off()
pdf(sprintf("%s.pdf", label))
pfun()
dev.off()
Visually, the result in the "windows.png" file is as if the "evenodd" rule
was specified. All other examples unix.pdf, unix.png, windows.pdf give me
the expected result - which is "all bounded regions shaded grey, with two
tones for the different regions of overlap". The unexpected result is the
completely transparent region.
Is this a known/expected difference on Windows? I see the unexpected
result in 3.3.1 and in R version 3.3.1 Patched (2016-07-27 r70991) on
Windows.
Cheers, Mike.
--
Dr. Michael Sumner
Software and Database Engineer
Australian Antarctic Division
203 Channel Highway
Kingston Tasmania 7050 Australia
--
Dr. Michael Sumner
Software and Database Engineer
Australian Antarctic Division
203 Channel Highway
Kingston Tasmania 7050 Australia
[[alternative HTML version deleted]]
__
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [FORGED] Different results based on the order of arguments to par
Hi
The main issue here is that the 'graphics' package has no real concept
of going back to a previous plot (the 'grid' package has explicit
support for that sort of thing). In 'graphics' you can only go forwards
to the next plot; you can fake going back by creating a new plot that
is like a previous plot.
par(plt=, usr=) is not designed to return you to a previous plot.
If it sounds like I am reluctant to change the behaviour of par(plt=,
usr=) to support your use case, that is probably because I am.
You could add examples and warnings to subplot() documentation about
this behaviour, but ideally users would not be encouraged to do this at all.
I would prefer to see something along the lines of ...
hist(rexp(1000), main='')
abline( v=1, col='red')
sp.par <- subplot(hist(rnorm(100), main=''), x='topright')
subplotadd <- function(fun, pars) {
par(new=TRUE)
par(pars['plt'])
plot.new()
par(pars['usr'])
fun
}
subplotadd(abline(v=0, col='red'), sp.par)
Paul
On 16/03/16 04:31, Greg Snow wrote:
Paul,
I was trying to make a minimal self contained example, but I guess I
went too far on the minimizing. The original problem came from code
more like:
library(TeachingDemos)
hist(rexp(1000), main='')
abline( v=1, col='red')
sp.par <- subplot(hist(rnorm(100), main=''), x='topright')
op <- par(sp.par[c('usr', 'plt')])
abline(v=0, col='red')
par(op)
and so plot.new, plot.window, etc. are called as part of the sub plot
(specifically by hist(rnorm(100))) and I am trying to go back and add
a reference line to the subplot so the user coordinates need to be set
back to match the subplot (and the plotting region needs to be set so
that the line is clipped appropriately). With the code as above the
user coordinates are not changed appropriately, in fact if 'xpd=NA' is
added to the par call then the vertical line is added at 0 on the big
histogram, not the little one as planned.
If the order is changed in the call to par ( op <-
par(sp.par[c('plt','usr')]) ) then everything works as planned. It
just seems a potential danger to have different behavior when the
order of the arguments change without this fact at least documented.
Maybe a warning and additional examples in the subplot documentation
will be sufficient, since nobody else seems to have complained about
this yet. But, I am vain enough to think that somewhere in the world
there is someone else who will make as stupid a mistake as me, so
wanted to make others aware. If nothing else, the next person (which
may be forgetful future me) may see this in a search and at least know
to order the arguments correctly.
On Mon, Mar 14, 2016 at 7:04 PM, Paul Murrell <p...@stat.auckland.ac.nz> wrote:
Hi
I'm going to try to blame user error here.
par(usr) is used to reset the coordinates on the CURRENT plot.
par(plt) is used to specify the location of the NEXT plot.
The correct approach should be to set up the location for the next plot,
start a new plot, set up coordinates on the new plot.
Neither of your examples performs the "start a new plot" step.
I would expect to see something like ...
dev.new()
hist(rexp(100))
# Set up location of new plot
par(plt=c(0.5,0.9,0.5,0.77))
# Avoid new page
par(new=TRUE)
# Start new plot
plot.new()
# Set up coordinates on new plot
# (though plot.window() might be better here)
par(usr=c(0,1,0,1))
# Start drawing
box()
points(c(0,1), c(0,1), pch=16, col='red', cex=3)
Is there a good argument against doing that?
Paul
On 15/03/16 10:27, Greg Snow wrote:
I ran into this issue when trying to modify a subplot (subplot
function in the TeachingDemos package), but here is a more minimal
example of the issue (I don't know that it is serious enough to call a
bug):
This code works how I expect:
dev.new()
hist(rexp(100))
par(plt=c(0.5,0.9,0.5,0.77), usr=c(0,1,0,1))
box() # show new plt region
points(c(0,1), c(0,1), pch=16, col='red', cex=3)
it creates a histogram then changes the plotting region so that I can
add an annotation, changes the user coordinates within the new region,
then plots some points using the new coordinate system.
But if I change the order of the arguments to par like so:
dev.new()
hist(rexp(100))
par(usr=c(0,1,0,1), plt=c(0.5,0.9,0.5,0.77))
box() #show new plt region
points(c(0,1), c(0,1), pch=16, col='red')
then the points do not show up (or if we add xpd=NA to the par call
then we see them outside of the plotting region). So clearly the
behavior of par depends on the order of the arguments specified.
This is not explicitly documented, though there is a hinting at the
behavior in the note on the par help page (it was following this
warning that led to me first encountering the issue, since I was
specifying only the parameters that I needed, not everything, and
happened to specify usr before plt), but "usr" is not included in the
list in the note (because it does something different from what the
not
Re: [Rd] [FORGED] Different results based on the order of arguments to par
Hi I'm going to try to blame user error here. par(usr) is used to reset the coordinates on the CURRENT plot. par(plt) is used to specify the location of the NEXT plot. The correct approach should be to set up the location for the next plot, start a new plot, set up coordinates on the new plot. Neither of your examples performs the "start a new plot" step. I would expect to see something like ... dev.new() hist(rexp(100)) # Set up location of new plot par(plt=c(0.5,0.9,0.5,0.77)) # Avoid new page par(new=TRUE) # Start new plot plot.new() # Set up coordinates on new plot # (though plot.window() might be better here) par(usr=c(0,1,0,1)) # Start drawing box() points(c(0,1), c(0,1), pch=16, col='red', cex=3) Is there a good argument against doing that? Paul On 15/03/16 10:27, Greg Snow wrote: I ran into this issue when trying to modify a subplot (subplot function in the TeachingDemos package), but here is a more minimal example of the issue (I don't know that it is serious enough to call a bug): This code works how I expect: dev.new() hist(rexp(100)) par(plt=c(0.5,0.9,0.5,0.77), usr=c(0,1,0,1)) box() # show new plt region points(c(0,1), c(0,1), pch=16, col='red', cex=3) it creates a histogram then changes the plotting region so that I can add an annotation, changes the user coordinates within the new region, then plots some points using the new coordinate system. But if I change the order of the arguments to par like so: dev.new() hist(rexp(100)) par(usr=c(0,1,0,1), plt=c(0.5,0.9,0.5,0.77)) box() #show new plt region points(c(0,1), c(0,1), pch=16, col='red') then the points do not show up (or if we add xpd=NA to the par call then we see them outside of the plotting region). So clearly the behavior of par depends on the order of the arguments specified. This is not explicitly documented, though there is a hinting at the behavior in the note on the par help page (it was following this warning that led to me first encountering the issue, since I was specifying only the parameters that I needed, not everything, and happened to specify usr before plt), but "usr" is not included in the list in the note (because it does something different from what the note is specifically warning about). I see a few different potential responses to this issue: 1. consider that this is a rare enough issue that only Greg Snow will ever care and he has already learned the lesson, so do nothing (other than laugh at Greg when he forgets and has to remember to properly order his par arguments). 2. Since this came up as an issue with subplot, force the author of subplot and the TeachingDemos package to add a note or warning to the documentation for that function. 3. Expand the note on the help page for par (or add another note) that warns that the order of the parameters matters and to therefore be careful in which order you specify arguments (probably with some detail on the suggested ordering). While there will be many users who never read this, we will at least be able to point to the note if anyone else is affected by this issue. 4. Modify the par function to reorder the list created from its args so that they are evaluated in a consistent order (and probably add documentation to the help page to this effect). Thoughts? -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Could unit.list() from grid package be made an exported function?
Hi On 09/03/16 09:54, Wilke, Claus O wrote: Paul, Subassignment for units has been committed to r-devel. You should now be able to do things like ... x <- unit(1:3, "mm") x[2] <- unit(.5, "npc") (see grid/tests/units.R for more complex examples) Yes, I just tried the latest R devel and it works for me. However: Great. Thanks for testing it out. This works for me for the three stackoverflow scenarios. I ran into an additional problem when trying to replicate this example: http://stackoverflow.com/a/32583612/4975218 This line in the function set_panel_size() causes an error for me: g$widths[panel_index_w] <- rep(list(width), nw) Error in `[<-.unit`(`*tmp*`, panel_index_w, value = list(4, 4, 4)) : Value being assigned must be a unit Right, that line (and the one below) can now just use rep() on a unit (no need for lists anymore), like this ... g$widths[panel_index_w] <- rep(width, nw) (full example code attached) Paul I can avoid the error by changing the line into: g$widths[panel_index_w] <- rep(grid:::unit.list(width), nw) This, however, again uses grid:::unit.list(). Maybe there’s another way around this, but turning a single width value into a unit.list seems the obvious way to go in a case like this. So again, I’d like to request that grid:::unit.list() be made an exported function as well. It seems quite useful any time somebody wants to make a list of units. Thanks! Claus -- Claus Wilke Professor and Department Chair, Integrative Biology The University of Texas at Austin 2500 Speedway, A4800 Austin, Texas 78712 512 232 2459 -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Could unit.list() from grid package be made an exported function?
Hi Subassignment for units has been committed to r-devel. You should now be able to do things like ... x <- unit(1:3, "mm") x[2] <- unit(.5, "npc") (see grid/tests/units.R for more complex examples) This works for me for the three stackoverflow scenarios. Any confirmation that it also works for you would be welcome. Paul On 07/03/16 07:34, Wilke, Claus O wrote: Hello, certain manipulations of ggplot2 graphs, in particular aligning them, require the function grid:::unit.list(). See e.g. these posts on stackoverflow: http://stackoverflow.com/questions/34032621/element-replacement-in-grid-unit-vector http://stackoverflow.com/questions/32580946/setting-absolute-size-of-facets-in-ggplot2/32583612#32583612 http://stackoverflow.com/a/35823179/4975218 Since this seems to be a reasonably common issue, would it be possible to export grid:::unit.list(), so it can be used in packages? (Am I sending this to the right audience? It’s not clear to me how to reach the maintainer of the grid package in base R.) Thanks! Claus -- Claus Wilke Professor and Department Chair, Integrative Biology The University of Texas at Austin 2500 Speedway, A4800 Austin, Texas 78712 512 232 2459 [[alternative HTML version deleted]] __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Could unit.list() from grid package be made an exported function?
Hi I think the right solution is to add [<- methods for units. I will take a look at whether I can get that done for the release of R 3.3.0 Paul On 07/03/16 07:34, Wilke, Claus O wrote: Hello, certain manipulations of ggplot2 graphs, in particular aligning them, require the function grid:::unit.list(). See e.g. these posts on stackoverflow: http://stackoverflow.com/questions/34032621/element-replacement-in-grid-unit-vector http://stackoverflow.com/questions/32580946/setting-absolute-size-of-facets-in-ggplot2/32583612#32583612 http://stackoverflow.com/a/35823179/4975218 Since this seems to be a reasonably common issue, would it be possible to export grid:::unit.list(), so it can be used in packages? (Am I sending this to the right audience? It’s not clear to me how to reach the maintainer of the grid package in base R.) Thanks! Claus -- Claus Wilke Professor and Department Chair, Integrative Biology The University of Texas at Austin 2500 Speedway, A4800 Austin, Texas 78712 512 232 2459 [[alternative HTML version deleted]] __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel no longer supports Ubuntu 14.04 LTS (insufficient PCRE version)
Hi For the record, Dirk (after a couple of false starts and admirable persistance!) has got this to work for me. So on Ubuntu 14.04, adding Dirk's PPA, followed by apt-get update pulls down a backport for libpcre3. Thanks Dirk! Paul On 24/11/2015 4:57 p.m., Dirk Eddelbuettel wrote: Sebastian, Paul, Ubuntu 14.04 builds (for Linux 32 and 64 bit, ie i386 and amd64) of the (most current) pcre package (ie 8.35-7) for Ubuntu are now in my PPA at https://launchpad.net/~edd/+archive/ubuntu/misc/+packages These should work. You can add this PPA as I do in some Travis runs via sudo add-apt-repository -y ppa:edd/misc and then just do apt-get update; apt-get install libpcre3-dev which should do the trick -- but I haven't tested. Contact me off-list if you fail. Oh, and I guess we should have had this whole thread over on r-sig-debian. Best, Dirk -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel no longer supports Ubuntu 14.04 LTS (insufficient PCRE version)
For the record ... I'm on Ubuntu 14.04 too (probably until 16.04 comes out) Paul On 21/11/15 10:39, Prof Brian Ripley wrote: I think you have it backwards: Ubuntu 14.04 does not support R-devel PCRE 8.32 is 3 years old, so Ubuntu 14.04 shipped an already quite old version 19 months ago. R has long said that its requirement was PCRE (version 8.10 or later, preferably 8.32 or later) and 8.32 is indeed preferable: the aim is that all the current PCRE regex syntax be usable on all platforms. Given that you appear to be installing R from the sources, PCRE is no more difficult to install from source R-devel is 'under development' and months off release: if this proves to be too restrictive we can postpone the aim to 3.4.x. On 20/11/2015 15:14, Sebastian Meyer wrote: Since yesterday's r69662, R no longer ./configure[s] on a standard Ubuntu 14.04.3 installation, which ships with PCRE 8.31 (http://packages.ubuntu.com/trusty-updates/libpcre3-dev) I get: checking if PCRE version >= 8.32, < 10.0 and has UTF-8 support... no checking whether PCRE support suffices... configure: error: pcre library and headers are required Are there any workarounds for this except for manually compiling and installing a more recent version of PCRE from source? Thanks! Sebastian -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] grDevice in R HEAD been broken for 6 weeks.
Hi This should be fixed in r-devel r69442. Thanks very much for reporting the problem! Paul On 26/09/15 19:39, Hin-Tak Leung wrote: geDevice has been failing check for 6 weeks now with --enable-strict-barrier , bisected to: r69049 | murrell | 2015-08-14 00:03:12 +0100 (Fri, 14 Aug 2015) | 2 lines first hack at adding grid display list to recorded plot objects, so can add further grid drawing following a replayPlot() It seems to be broken by the GE_SaveSnapshotState addition in src/library/grid/src/state.c: case GE_SaveSnapshotState: +/* + * Save the current 'grid' DL. + */ +PROTECT(result = allocVector(VECSXP, 3)); +SET_VECTOR_ELT(result, 0, gridStateElement(dd, GSS_DL)); +SET_VECTOR_ELT(result, 1, gridStateElement(dd, GSS_DLINDEX)); +UNPROTECT(1); break; showCols2() Loading required package: grid Error in grDevices:::recordPalette() : LOGICAL() can only be applied to a 'logical', not a 'list' Calls: demo ... eval -> eval -> showCols2 -> grid.newpage -> Execution halted somewhere else it seems to expect the outcome of GE_SaveSnapshotState to be a logical array rather than a list, though I cannot find where it is. Any chance of that getting fixed any time soon? -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pointer ownership with GECreateDevDesc/GEDestroyDevDesc
This seems like the best solution (free and NULL the dev pointer in
dev_Close(), BEFORE GEdestroyDevDesc() has a go).
I think this should be safe because dev_Close() and GEdestroyDevDesc()
are only called in one place (so your free() should always happen before
GEdestroyDevDesc() and your free() shouldn't happen in any other,
potentially inappropriate, context).
Paul
On 09/23/14 03:15, Ritch Melton wrote:
I perused the source for RStudio and noticed that they had a similar
problem. I didn't think that the GEDevDesc structure was exported, but
apparently this is a worthwhile workaround to the defect.
void GD_Close(pDevDesc dev)
{
...elided...
// explicitly free and then null out the dev pointer of the GEDevDesc
// This is to avoid incompatabilities between the heap we are
compiled with
// and the heap R is compiled with (we observed this to a problem with
// 64-bit R)
std::free(s_pGEDevDesc-dev);
s_pGEDevDesc-dev = NULL;
// set GDDevDesc to NULL so we don't reference it again
s_pGEDevDesc = NULL;
}
}
I will
On Fri, Sep 19, 2014 at 10:37 AM, Ritch Melton skygu...@gmail.com wrote:
According to the R Internals document, for a custom device, I should
create a pDevDesc structure that gets passed to GECreateDevDesc.
..elided...
pDevDesc dev;
/* Allocate and initialize the device driver data */
if (!(dev = (pDevDesc) calloc(1, sizeof(DevDesc return 0;
/* or error() */
/* set up device driver or free ’dev’ and error() */
gdd = GEcreateDevDesc(dev); GEaddDevice2(gdd, dev_name);
...elided...
which indicates to me that the calling code owns the pDevDesc structure
and should be responsible for freeing it.
However, in GEdestroyDevDesc, that particular code calls free(dd-dev),
freeing the pointer.
In my case, I have a device implemented and created in a language that is
using a different allocator. The pDevDesc I pass in is not owned by R and
causes a crash on free with dev.off().
I thought I could mitigate the issue, by making a call to the allocator R
is using via an exported R function, such as R_alloc, but I did not see
such a function available to me.
I would like to know if I should be creating the pDevDesc via an imported
alloc routine somehow? or is there a way to prevent this code from freeing
the structure I pass in.
Blue Skies,
Ritch
[[alternative HTML version deleted]]
__
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package keyval Error: noupquote undefined
I'm getting the same problem
(I'm on Ubuntu 12.04, TeXLive 2009 and likely to remain there for the
next year or so)
Paul
On 06/10/14 07:40, Yihui Xie wrote:
Cc'ing to the author of this commit.
If TeXLive = 2013 or a certain version of inconsolata/zi4 is
required, I think it should be documented somewhere, otherwise please
consider backward compatibility with TeXLive = 2012. Personally I
prefer the latter, given how infrequently TeXLive is upgraded. It is
not unusual to see TeXLive that has been a few years older than its
latest version.
One possible solution is to test the version of inconsolata or zi4:
\@ifpackagelater{inconsolata}{2013/06/09}{
% use noupquote
}
{
% do not use
}
although I do not quite understand the rationale to write a homemade
version of upquote in Rd.sty...
Regards,
Yihui
--
Yihui Xie xieyi...@gmail.com
Web: http://yihui.name
On Wed, Jun 4, 2014 at 1:18 PM, Yihui Xie x...@yihui.name wrote:
Hi,
Due to a change in Rd.sty a few days ago
(https://github.com/wch/r-source/commit/620eb9a#diff-3bf3d821c6faae50cd6ec931f6f63296L272),
the default installation of TeXLive 2009 or 2012 no longer works when
building Rd to PDF. The error log is like this:
===
Converting Rd files to LaTeX .
Creating pdf output from LaTeX ...
Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet, :
Running 'texi2dvi' on 'Rd2.tex' failed.
LaTeX errors:
! Package keyval Error: noupquote undefined.
See the keyval package documentation for explanation.
Type H return for immediate help.
...
! Emergency stop.
...
l.37 \ProcessOptions*
! == Fatal error occurred, no output PDF file produced!
Output:
This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian)
entering extended mode
LaTeX2e 2009/09/24
Babel v3.8l and hyphenation patterns for english, usenglishmax, dumylang, noh
yphenation, loaded.
(./Rd2.tex (/usr/share/texmf-texlive/tex/latex/base/book.cls
Document Class: book 2007/10/19 v1.4h Standard LaTeX document class
(/usr/share/texmf-texlive/tex/latex/base/bk10.clo))
(/home/yihui/repos/r-source/share/texmf/tex/latex/Rd.sty
(/usr/share/texmf-texlive/tex/latex/base/ifthen.sty)
(/usr/share/texmf-texlive/tex/latex/tools/longtable.sty)
(/usr/share/texmf-texlive/tex/latex/tools/bm.sty)
(/usr/share/texmf-texlive/tex/latex/base/alltt.sty)
(/usr/share/texmf-texlive/tex/latex/tools/verbatim.sty)
(/usr/share/texmf-texlive/tex/latex/ltxmisc/url.sty)
(/usr/share/texmf-texlive/tex/latex/base/textcomp.sty
(/usr/share/texmf-texlive/tex/latex/base/ts1enc.def))
(/usr/share/texmf-texlive/tex/latex/base/fontenc.sty
(/usr/share/texmf-texlive/tex/latex/base/t1enc.def))
(/usr/share/texmf-texlive/tex/latex/psnfss/times.sty)
(/usr/share/texmf-texlive/tex/latex/inconsolata/inconsolata.sty
(/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty)
! Package keyval Error: noupquote undefined.
See the keyval package documentation for explanation.
Type H return for immediate help.
...
l.37 \ProcessOptions*
?
! Emergency stop.
...
l.37 \ProcessOptions*
! == Fatal error occurred, no output PDF file produced!
Transcript written on Rd2.log.
Error in running tools::texi2pdf()
===
Here is my sessionInfo():
sessionInfo()
R Under development (unstable) (2014-06-04 r65854)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_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
$ pdflatex --version
pdfTeX 3.1415926-1.40.10-2.2 (TeX Live 2009/Debian)
kpathsea version 5.0.0
Copyright 2009 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).
The problem is reproducible with TeXLive 2012 and Ubuntu 12.04. I went
through the R-admin manual, and I did not seem to find a requirement
of the TeXLive version there.
Here is a minimal foo.Rd that shows the problem when running `Rd CMD
Rd2pdf foo.Rd`:
\name{foo}
\alias{foo}
\title{Foo}
\description{
Bar.
}
Regards,
Yihui
--
Yihui Xie xieyi...@gmail.com
Web: http://yihui.name
__
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] png(type='cairo'): point symbols without boarders are not anti-aliased?
Hi
Is this the same as Bug 15462 ?
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15462
Paul
On 10/22/13 10:43, Yihui Xie wrote:
Hi,
It seems that anti-aliasing in png(type = 'cairo') is not well
supported for the point symbols without boarders, e.g. pch = 16. The
Cairo package works well, though. You can compare png() with
CairoPNG():
png(): http://i.imgur.com/8niB3jX.png
CairoPNG(): http://i.imgur.com/FZBJOxm.png
f = function(dev, ..., main = '') {
dev(...)
plot(c(1, 2, 1, 2), c(1, 1, 2, 2), pch=c(16, 19), cex=c(2, 2, 15, 15),
xlim=c(0.5, 2.5), ylim=c(0.5, 3), main = deparse(substitute(dev)))
dev.off()
}
f(grDevices::png, 'png-base.png', type = 'cairo')
f(Cairo::CairoPNG, 'png-Cairo.png')
If I remove the border for pch=19 (i.e. lwd=0), the point shows rough
edges as well.
I'm not sure if that is expected, or it is due to my misconfiguration
somewhere. I installed R via `apt-get install r-base-dev` under Ubuntu
using the CRAN repository.
sessionInfo()
R version 3.0.2 (2013-09-25)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] Cairo_1.5-2 tools_3.0.2
capabilities()
jpeg png tifftcltk X11 aqua http/ftp sockets
TRUE TRUE TRUE TRUE TRUEFALSE TRUE TRUE
libxml fifo clediticonv NLS profmemcairo
TRUE TRUE TRUE TRUE TRUE TRUE TRUE
Regards,
Yihui
--
Yihui Xie xieyi...@gmail.com
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA
__
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] inconsistency/bug in recordPlot/replayPlot
Hi Unfortunately, my main advice would be not to rely on recordPlot() because it (or at least the underlying display list format) was never intended for this sort of thing. I doubt that helps though :) I might be able to help more, or look at developing a transportable object class for R graphics, if I had a better understanding of what you want to do. Perhaps off list? Paul On 09/24/13 15:31, Gabriel Becker wrote: Paul, Thanks for the response. On Mon, Sep 23, 2013 at 7:43 PM, Paul Murrell p...@stat.auckland.ac.nz mailto:p...@stat.auckland.ac.nz wrote: snip par(bg=white) plot(1:10) recplot = recordPlot() png(bgreplay.png) replayPlot(recplot) dev.off() Would that satisfy your use case ? Unfortunately it does not, as my use-case is in a caching/dynamic document setting. Thus I am capturing plotting from evaluation of an arbitrary piece of code within a series of such evaluations. I cannot be guaranteed the code doesn't call dev.off() or explicitly create a new device and I wouldn't want to clobber any non-white background set in previous code. I thought putting par(bg=white) after the call to png() (or bg=white in the png call) might work, but it appears that replayPlot is actively setting the background to transparent so that didn't fly. Any other ideas or advice would be appreciated. ~G Paul On 09/14/13 09:17, Gabriel Becker wrote: Hey all, I've run accross what seems to be a bug in the recordPlot/replayPlot functionality (or at least the lack of a feature which seems pretty reasonable to expect to be there) When drawing to a file-based graphics device (I tested with png()), the file resulting from calling replayPlot on a recordedplot object does not contain an identical image to that captured by the same graphics device when used on the plot that was recorded. Reproducible (at least for me on linux) example: png(noreplay.png) plot(1:10) dev.off() plot(1:10) recplot = recordPlot() png(withreplay.png) replayPlot(recplot) dev.off() The resulting png files are attached. You'll notice that the noreplay.png has the expected white background, while withoutreplay.png has no/a transparent background. This seems likely to be related to the note in ?dev.print : Note that these functions copy the _device region_ and not a plot: the background colour of the device surface is part of what is copied. Most screen devices default to a transparent background, which is probably not what is needed when copying to a device such as ‘png’. Now this may be as intended because it is not allowed to draw recordedplot objects to devices other than the one they were recorded on (AFAIK the primary purpose of recordedplot objects is fast redraws internally), but alas that is what my use-case calls for. Furthermore, I don't think I'm alone in thinking wistfully about how useful it would be to have an actual, transportable object class which can fully represent an R plot in any R-based context. I'm pretty sure I can compile a patch which does this if it would be considered, though there would be a delay of a week or two before I could burrow out from under the mound of other stuff I currently need to be doing sessionInfo below, and I have also confirmed that the behavior remains unchanged in the current trunk. Thanks, ~G sessionInfo() R version 3.0.1 (2013-05-16) Platform: x86_64-pc-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=C 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 loaded via a namespace (and not attached): [1] compiler_3.0.1 tools_3.0.1 R-devel@r-project.org mailto:R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/__listinfo/r-devel 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 p...@stat.auckland.ac.nz mailto:p...@stat.auckland.ac.nz http
Re: [Rd] inconsistency/bug in recordPlot/replayPlot
Hi If you want an explicit background (rather than just relying on what the device gives you), you can do something like ... par(bg=white) plot(1:10) recplot = recordPlot() png(bgreplay.png) replayPlot(recplot) dev.off() Would that satisfy your use case ? Paul On 09/14/13 09:17, Gabriel Becker wrote: Hey all, I've run accross what seems to be a bug in the recordPlot/replayPlot functionality (or at least the lack of a feature which seems pretty reasonable to expect to be there) When drawing to a file-based graphics device (I tested with png()), the file resulting from calling replayPlot on a recordedplot object does not contain an identical image to that captured by the same graphics device when used on the plot that was recorded. Reproducible (at least for me on linux) example: png(noreplay.png) plot(1:10) dev.off() plot(1:10) recplot = recordPlot() png(withreplay.png) replayPlot(recplot) dev.off() The resulting png files are attached. You'll notice that the noreplay.png has the expected white background, while withoutreplay.png has no/a transparent background. This seems likely to be related to the note in ?dev.print : Note that these functions copy the _device region_ and not a plot: the background colour of the device surface is part of what is copied. Most screen devices default to a transparent background, which is probably not what is needed when copying to a device such as ‘png’. Now this may be as intended because it is not allowed to draw recordedplot objects to devices other than the one they were recorded on (AFAIK the primary purpose of recordedplot objects is fast redraws internally), but alas that is what my use-case calls for. Furthermore, I don't think I'm alone in thinking wistfully about how useful it would be to have an actual, transportable object class which can fully represent an R plot in any R-based context. I'm pretty sure I can compile a patch which does this if it would be considered, though there would be a delay of a week or two before I could burrow out from under the mound of other stuff I currently need to be doing sessionInfo below, and I have also confirmed that the behavior remains unchanged in the current trunk. Thanks, ~G sessionInfo() R version 3.0.1 (2013-05-16) Platform: x86_64-pc-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=C 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 loaded via a namespace (and not attached): [1] compiler_3.0.1 tools_3.0.1 __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Patch: fix segfault from empty raster
Hi Protecting against empty rasters seems like a good idea(!) Thanks for the report. Could you please try sending me your suggested patch directly? (it did not make it through via r-devel) Paul On 09/16/13 22:24, QRD wrote: Hi, A colleague recently came across an R crash, which I can boil down to the following, running under Rgui on Windows 7: library(ggplot2) ggplot(data.frame(x=1, y=1, z=4.7), aes(x, y, z=z)) + stat_summary2d() This reliably causes a segmentation fault. sessionInfo() below. What's happening is that (for reasons which I'll discuss with the ggplot2 developers) the 'colorbar' guide is being built with a zero-size source raster. In L_raster() (grid.c), this raster is not a nativeRaster, so we do image = (unsigned int*) R_alloc(n, sizeof(unsigned int)); with n = 0, and R_alloc() gives us a NULL pointer. The display of this raster requests interpolation, so we end up in R_GE_rasterInterpolate(), where 'sraster' is NULL, and chaos ensues as it tries to read source pixels. It seems to me that it doesn't make sense to display an empty raster, so I inserted a check in L_raster(). A proof-of-concept patch is attached. With this patch, R gives an error message instead of a segfault. Does this seem a sensible change? If so, could something like it be incorporated? Thanks, Ben. - - - - 8 - - - - sessionInfo() R version 3.0.1 (2013-05-16) Platform: x86_64-w64-mingw32/x64 (64-bit) locale: [1] LC_COLLATE=English_Ireland.1252 LC_CTYPE=English_Ireland.1252 [3] LC_MONETARY=English_Ireland.1252 LC_NUMERIC=C [5] LC_TIME=English_Ireland.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] ggplot2_0.9.3.1 loaded via a namespace (and not attached): [1] colorspace_1.2-2 compiler_3.0.1 dichromat_2.0-0digest_0.6.3 [5] grid_3.0.1 gtable_0.1.2 labeling_0.2 MASS_7.3-26 [9] munsell_0.4plyr_1.8 proto_0.3-10 RColorBrewer_1.0-5 [13] reshape2_1.2.2 scales_0.2.3 stringr_0.6.2 tools_3.0.1 __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistencies in device_Raster when axes are reflected
Hi On 12/01/2012 7:11 a.m., Sharpie wrote: I noticed some undocumented and inconsistent behavior in device_Raster when a plot is produced with reflected axes such as: image(volcano, xlim = c(1,0), useRaster = TRUE) image(volcano, ylim = c(1,0), useRaster = TRUE) The `pdf` device will perform horizontal and vertical reflections, while `quartz` will ignore the transformations when plotting to the screen, but when plotting to a file, `quartz(file = 'test.pdf', type = 'pdf')`, it will produce horizontal reflections and ignore vertical ones. When the `xlim` or `ylim` is reversed, negative widths and heights are passed to the C function `device_Raster`, which is not a behavior documented in `R_ext/GraphicsDevice.h`. Also, the values of `x` and `y` passed to `device_Raster` will be shifted by the width or height of the image such that the coordinates no longer reference the bottom-left corner of the image as `R_ext/GraphicsDevice.h` says they should. Given the inconsistencies in documentation and behavior, I am wondering what the intended behavior of `device_Raster` is in this situation. I think the problem is that I just failed to anticipate this situation (i.e., the current documentation and behaviour both assume xlim[1] xlim[2] and ylim[1] ylim[2]). Will take a look at where to apply a fix (EITHER allow the API to be more flexible [allow negative 'width' and 'height' and 'x' and 'y' to be other than left-bottom], which will require complicating the code in some devices OR keep the API fixed and complicate the graphics engine code instead). The rotation argument adds an interesting twist ... Thanks for the report! Paul Thanks! -Charlie - Charlie Sharpsteen Undergraduate-- Environmental Resources Engineering Humboldt State University -- View this message in context: http://r.789695.n4.nabble.com/Inconsistencies-in-device-Raster-when-axes-are-reflected-tp4286320p4286320.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Graphics device hook to manipulate plotmath
Hi On 7/12/2011 9:34 a.m., Zack Weinberg wrote: Is there a hook that allows a graphics device to apply transformations to plotmath expressions *before* they are rendered? If there isn't one yet, would it be feasible to add one? No such hook exists. Plotmath expression get split off before the graphics engine (in 'graphics' and 'grid'). One possibility might be to add a device flag that says the device wants to handle plotmath, plus a new device call, DEV_math() say, so that 'graphics' and 'grid' can send plotmath unaltered to the device. But there are likely to be complications. For example, both 'graphics' and 'grid' can ask for metric information about text, so there would be more work to ensure that metric information corresponded to what the device would draw for plotmath expressions. Paul The motivation for this hook is graphic devices that feed into something that already has support for math layout, such as the tikzDevice package (which has TeX downstream). Given text(x, y, expression(alpha+beta+gamma+delta)) it would be ideal (in terms of output quality) if tikzDevice could process that as if text(x, y, $\\alpha+\\beta+\\gamma+\\delta$) had been written instead. This would also be easier to *implement*, from the device side, than a back-conversion from Adobe-Symbol glyph requests to TeX math symbol macros. (Users of tikzDevice can of course write all their TeX math expressions directly, but this may be a great deal of conversion work, and is also inconvenient for someone tweaking their plots in one of the interactive graphics devices before saving them permanently.) Thanks in advance, zw p.s. I am not subscribed to this list, please cc: me on replies. __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] grid stringHeight
Hi
This is a basic feature of both strheight() and stringHeight(). They
both ignore any descenders in the text. I cannot remember why it was
done this way originally. The future solution is probably to add an
argument that allows descenders to be included in text height.
Plotmath works on bounding boxes so its behaviour is different, but of
course that has its own problems because there is no sense of baseline
for expressions.
Paul
On 27/04/2011 11:06 a.m., baptiste auguie wrote:
Dear all,
I'm puzzled by the behavior of stringHeight in the grid package.
Consider the following test,
library(grid)
test- function(lab=dog, ...){
g1- textGrob(lab)
g2- rectGrob(height=grobHeight(g1), width=grobWidth(g1))
gg- gTree(children=gList(g1,g2), ...)
print(c(height:, convertUnit(stringHeight(lab), mm, y)))
grid.draw(gg)
}
grid.newpage()
test()
test(expression(dog), vp=viewport(x=0.6))
## notice how the dog's tail is being cut off, where
## expression yields a snug cage
grid.newpage()
test(aoc)
test(expression(aoc), vp=viewport(x=0.6))
It appears that stringHeight correctly calculates the height for an
expression, but not for a basic string. I think it used to produce the
same output for both.
Best regards,
baptiste
sessionInfo()
R version 2.13.0 alpha (2011-03-27 r55076)
Platform: i386-apple-darwin9.8.0 (32-bit)
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets grid methods
[8] base
__
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gList and gTree methods of grid::grobX
Hi
baptiste auguie wrote:
Dear all,
In an attempt to draw fill patterns in grid graphics, I have
encountered a behavior of grobX that I cannot understand from the
documentation. Consider this,
library(grid)
## gTree
g1 - gTree(children=gList(
rectGrob(0.5,0.5, width=unit(0.8,npc),
height=unit(2,cm)),
circleGrob(r=0.3)), vp=viewport(0.5,0.5))
## gList
g1 - gList(rectGrob(0.5,0.5, width=unit(0.8,npc),
height=unit(2,cm)),
circleGrob(r=0.3))
## loop over angles to map the boundary
gtheta - function(g, theta){
sapply(theta, function(.t){
gx - convertX(grobX(g, .t), npc)
gy - convertY(grobY(g, .t), npc)
c(gx,gy)
})
}
angles - seq(0,360,by=30)
p1 - gtheta(g1, angles)
grid.newpage()
grid.draw(g1)
grid.points(p1[1,],p1[2,], gp=gpar(cex=0.2),
default.units=npc)
If I'm not mistaken, neither gList nor gTree seem to produce the
documented behavior,
If the grob describes multiple shapes, the boundary value will either
correspond to the edge of a bounding box around all of the shapes
described by the grob (for multiple rectangles, circles, xsplines, or
text), or to a convex hull around all vertices of all shapes described
by the grob (for multiple polygons, points, lines, polylines, and
segments).
That description is referring to a single *grob* object that draws
multiple shapes, something like ...
g1 - circleGrob(x=1:3/4, y=1:3/4, r=.1)
... in your example.
The behaviour of gTrees is pretty much undefined, but the user is free
to slap a class on the gTree and write their own xDetails() and
yDetails() methods to achieve the outcome that they want. I have
wondered about supplying a default that makes some sort of union of the
boundaries of the children of a gTree, but have not yet implemented that.
The gList case has been explicitly coded to produce the result from the
last object in the gList, but I cannot recall why I ever thought that
might be a good default. Again, making the gList the children of a
gTree with a specific class provides the opportunity to control what
grobX() and grobY() return for yourself.
Paul
with gList, I observe that the boundary is only considered for the
first shape, whilst gTree ignores all children altogether.
It works fine for single shapes (e.g. g1 = circleGrob(r=0.3)).
The same behavior is observed with quartz(), pdf() and png().
Sincerely,
baptiste
sessionInfo()
R version 2.12.1 Patched (2010-12-30 r53895)
Platform: i386-apple-darwin9.8.0 (32-bit)
locale:
[1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] grid stats graphics grDevices utils datasets
methods base
loaded via a namespace (and not attached):
[1] tools_2.12.1
__
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using rasterImage within image
Hi On 15/02/2011 8:11 a.m., Simon Urbanek wrote: On Feb 14, 2011, at 12:26 PM, Ben Bolker wrote: Paul Murrellp.murrellat auckland.ac.nz writes: Hi On 12/02/2011 7:22 p.m., Michael Sumner wrote: Hello, that appears to have fixed it. Thank you very much. I can now repeat the reported workflow and the image appears on the fifth (and subsequent) calls. Great. Thanks for checking. Paul That's great. Just a little bump: I would encourage Simon (in his copious spare time), or other interested members of R-core, to decide on a good name for the argument (as a reminder, I prefer 'method=c(raster,image)'). Furthermore, I would strongly encourage that raster be made the default behavior for the development release of R ... Unfortunately I just encountered a speed bump today - I had no idea that the Windows device doesn't even support transparent pixels. That needs to be fixed before we can make it the default... See the table at the bottom of http://developer.r-project.org/Raster/raster-RFC.html for the full list of limitations. Paul Cheers, Simon __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using rasterImage within image
/ iEYEARECAAYFAk1TFVcACgkQc5UpGjwzenOa6ACfVnJq67cG0czATeyti7AxgUbw ZWwAniA7JuYCv4clq8e6jwWQuMvw/r+m =/da6 -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using rasterImage within image
Hi
On 10/02/2011 7:54 p.m., Michael Sumner wrote:
Hello, I'm afraid the SDI graphics issue is still a problem in 2.13.0
2011-02-09 r54308.
Bother. Thanks very much for testing. I'll keep looking.
Paul
To reproduce, in a fresh R session (Windows in SDI mode):
## create a dummy dataset
m- matrix(c(0.2, 0.4, 0.6, 0.8), 2, 2)
## simple helper function to open the windows() device and plot the matrix
draw.f- function(x) {
plot(0, xlim = c(0, 1), ylim = c(0, 1))
rasterImage(x, 0, 0, 1, 1, interpolate = FALSE)
}
draw.f(m)
## repeat the following 2 lines five times:
dev.off()
draw.f(m)
On the fifth attempt, only the background plot appears - but the
raster is visible on resize of the windows() device.
Cheers, Mike.
sessionInfo()
R version 2.13.0 Under development (unstable) (2011-02-09 r54308)
Platform: x86_64-pc-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
[3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
[5] LC_TIME=English_Australia.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
On Thu, Feb 10, 2011 at 5:31 PM, baptiste auguie
baptiste.aug...@googlemail.com wrote:
Dear all,
Back when grid.raster() was introduced, it was suggested that perhaps
grid.rect() could use grid.raster() in case of even spacing. The
response at the time was that it would be best to keep the two
functions separate at a lower level, that is grid.rect() and
grid.raster(), but perhaps a new function grid.image() could be
proposed at a higher level with the two possible backends. If this is
done in grid graphics, perhaps the same convention could be used for
base graphics: image() would be high level with the backend option,
and a new function (tiles(), perhaps?) would implement the current
behavior of image().
In any case, it would be nice to have a unified scheme to switch
between tiles and raster; currently lattice (panl.levelplot.raster)
and a few other packages all do it separately.
Best wishes,
baptiste
On 9 February 2011 23:29, Ben Bolkerbbol...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11-02-09 03:09 PM, Henrik Bengtsson wrote:
On Wed, Feb 9, 2011 at 11:53 AM, Simon Urbanek
simon.urba...@r-project.org wrote:
On Feb 9, 2011, at 2:36 PM, Henrik Bengtsson wrote:
On Wed, Feb 9, 2011 at 11:25 AM, Simon Urbanek
simon.urba...@r-project.org wrote:
Ben,
I have committed something analogous to R-devel (your rotation
code was not unlike mine, I replicated the color handling from
R internals to be consistent, I fixed the drawing limits and
added a check for x/y conformance). Note that useRaster can
only be used when x, y form a regular grid. Although I tried a
lot of corner cases (requiring quite a few fixes), I'm sure I
did not test all of them, so volunteers please give it a go and
compare it with non-raster output.
The only thing I'm not quite happy about is the argument name:
useRaster. Personally, I hate camel case in R (it has crept in
more recently making it horribly inconsistent) so please feel
free to suggest a better name ;).
It.is.spelled.camelCase.
Fortunately not in English ;)
What about style=c(image, raster)? This allows for future
extensions too.
Hmm.. it's not really a style - the output doesn't change
(ideally) - it's more of a back-end specification .. also we
already have oldstyle argument in image() adding to the confusion
...
flavor=c(image, raster) renderer=c(image, raster)
backend=c(image, raster) ...
Thanks Simon! (Any reports on the SDI Windows raster rendering issue,
or do we need a warning/workaround there?)
I like backend, or possibly method
One minor consideration: if raster eventually becomes the default
(as I hope it will), there would need to be some internal logic that
drops back to image if the user specifies uneven spacing and doesn't
explicitly specify the 'backend/method' parameter ...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1TFVcACgkQc5UpGjwzenOa6ACfVnJq67cG0czATeyti7AxgUbw
ZWwAniA7JuYCv4clq8e6jwWQuMvw/r+m
=/da6
-END PGP SIGNATURE-
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using rasterImage within image
Hi
Just committed another fix that solves this problem for me at least. If
you want to test for yourself, the magic revision number that you are
looking for is r54330.
Thanks again for your help.
Paul
On 10/02/2011 7:54 p.m., Michael Sumner wrote:
Hello, I'm afraid the SDI graphics issue is still a problem in 2.13.0
2011-02-09 r54308.
To reproduce, in a fresh R session (Windows in SDI mode):
## create a dummy dataset
m- matrix(c(0.2, 0.4, 0.6, 0.8), 2, 2)
## simple helper function to open the windows() device and plot the matrix
draw.f- function(x) {
plot(0, xlim = c(0, 1), ylim = c(0, 1))
rasterImage(x, 0, 0, 1, 1, interpolate = FALSE)
}
draw.f(m)
## repeat the following 2 lines five times:
dev.off()
draw.f(m)
On the fifth attempt, only the background plot appears - but the
raster is visible on resize of the windows() device.
Cheers, Mike.
sessionInfo()
R version 2.13.0 Under development (unstable) (2011-02-09 r54308)
Platform: x86_64-pc-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
[3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
[5] LC_TIME=English_Australia.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
On Thu, Feb 10, 2011 at 5:31 PM, baptiste auguie
baptiste.aug...@googlemail.com wrote:
Dear all,
Back when grid.raster() was introduced, it was suggested that perhaps
grid.rect() could use grid.raster() in case of even spacing. The
response at the time was that it would be best to keep the two
functions separate at a lower level, that is grid.rect() and
grid.raster(), but perhaps a new function grid.image() could be
proposed at a higher level with the two possible backends. If this is
done in grid graphics, perhaps the same convention could be used for
base graphics: image() would be high level with the backend option,
and a new function (tiles(), perhaps?) would implement the current
behavior of image().
In any case, it would be nice to have a unified scheme to switch
between tiles and raster; currently lattice (panl.levelplot.raster)
and a few other packages all do it separately.
Best wishes,
baptiste
On 9 February 2011 23:29, Ben Bolkerbbol...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11-02-09 03:09 PM, Henrik Bengtsson wrote:
On Wed, Feb 9, 2011 at 11:53 AM, Simon Urbanek
simon.urba...@r-project.org wrote:
On Feb 9, 2011, at 2:36 PM, Henrik Bengtsson wrote:
On Wed, Feb 9, 2011 at 11:25 AM, Simon Urbanek
simon.urba...@r-project.org wrote:
Ben,
I have committed something analogous to R-devel (your rotation
code was not unlike mine, I replicated the color handling from
R internals to be consistent, I fixed the drawing limits and
added a check for x/y conformance). Note that useRaster can
only be used when x, y form a regular grid. Although I tried a
lot of corner cases (requiring quite a few fixes), I'm sure I
did not test all of them, so volunteers please give it a go and
compare it with non-raster output.
The only thing I'm not quite happy about is the argument name:
useRaster. Personally, I hate camel case in R (it has crept in
more recently making it horribly inconsistent) so please feel
free to suggest a better name ;).
It.is.spelled.camelCase.
Fortunately not in English ;)
What about style=c(image, raster)? This allows for future
extensions too.
Hmm.. it's not really a style - the output doesn't change
(ideally) - it's more of a back-end specification .. also we
already have oldstyle argument in image() adding to the confusion
...
flavor=c(image, raster) renderer=c(image, raster)
backend=c(image, raster) ...
Thanks Simon! (Any reports on the SDI Windows raster rendering issue,
or do we need a warning/workaround there?)
I like backend, or possibly method
One minor consideration: if raster eventually becomes the default
(as I hope it will), there would need to be some internal logic that
drops back to image if the user specifies uneven spacing and doesn't
explicitly specify the 'backend/method' parameter ...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1TFVcACgkQc5UpGjwzenOa6ACfVnJq67cG0czATeyti7AxgUbw
ZWwAniA7JuYCv4clq8e6jwWQuMvw/r+m
=/da6
-END PGP SIGNATURE-
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [.raster bug {was str() on raster objects fails ..}
Hi
On 7/02/2011 8:36 p.m., Martin Maechler wrote:
Simon Urbaneksimon.urba...@r-project.org
on Sun, 6 Feb 2011 20:53:01 -0500 writes:
On Feb 6, 2011, at 8:10 PM, Paul Murrell wrote:
Hi
On 3/02/2011 1:23 p.m., Simon Urbanek wrote:
On Feb 2, 2011, at 7:00 PM, Paul Murrell wrote:
Hi
Martin Maechler wrote:
On Wed, Feb 2, 2011 at 23:30, Simon
Urbaneksimon.urba...@r-project.org wrote:
On Feb 1, 2011, at 8:16 PM, Paul Murrell wrote:
Hi
On 2/02/2011 2:03 p.m., Henrik Bengtsson wrote:
On Tue, Feb 1, 2011 at 4:46 PM, Paul
Murrellp.murr...@auckland.ac.nz wrote:
Hi
On 1/02/2011 9:22 p.m., Martin Maechler wrote:
Henrik Bengtssonh...@biostat.ucsf.edu on
Mon, 31 Jan 2011 11:16:59 -0800 writes:
Hi, str() on raster objects fails for certain
dimensions. For example:
str(as.raster(0, nrow=1, ncol=100)) 'raster'
chr [1, 1:100]
#00 #00 #00 #00 ...
str(as.raster(0, nrow=1, ncol=101)) Error in
`[.raster`(object,
seq_len(max.len)) : subscript out of bounds
This seems to do with how str() and [.raster()
is coded; when subsetting as a vector, which
str() relies on, [.raster() still returns a
matrix-like object, e.g.
img- as.raster(1:25, max=25, nrow=5, ncol=5);
img[1:2]
[,1] [,2] [,3] [,4] [,5] [1,] #0A0A0A
#3D3D3D #707070 #A3A3A3 #D6D6D6 [2,]
#141414 #474747 #7A7A7A #ADADAD
#E0E0E0
compare with:
as.matrix(img)[1:2]
[1] #0A0A0A #3D3D3D
The easy but incomplete fix is to do:
str.raster- function(object, ...) {
str(as.matrix(object), ...); }
Other suggestions?
The informal raster class is behaving
``illogical'' in the following sense:
r- as.raster(0, nrow=1, ncol=11)
r[seq_along(r)]
Error in `[.raster`(r, seq_along(r)) : subscript
out of bounds
or, here equivalently,
r[1:length(r)]
Error in `[.raster`(r, 1:length(r)) : subscript
out of bounds
When classes do behave in such a way, they
definitely need their own str() method.
However, the bug really is in [.raster:
Currently, r[i] is equivalent to r[i,] which is
not at all matrix-like and its help clearly says
that subsetting should work as for matrices. A
recent thread on R-help/R-devel has mentioned the
fact that [ methods for matrix-like methods
need to use both nargs() and missing() and that
[.dataframe has been the example to follow
forever, IIRC already in S and S-plus as of 20
years ago.
The main motivation for non-standard behaviour
here is to make sure that a subset of a raster
object NEVER produces a vector (because the
conversion back to a raster object then produces a
single-column raster and that may be a
surprise). Thanks for making the code more
standard and robust.
The r[i] case is still tricky. The following
behaviour is quite convenient ...
r[r == black]- white
... but the next behaviour is quite jarring (at
least in terms of the raster image that results
from it) ...
r2- r[1:(nrow(r) + 1)]
So I think there is some justification for further
non-standardness to try to ensure that the subset
of a raster image always produces a sensible
image. A simple solution would be just to outlaw
r[i] for raster objects and force the user to
write r[i, ] or r[, j], depending on what they
want.
FYI, I've tried out Martin's updated version at it
seems like a one-column raster matrix is now
returned for r[i], e.g.
Yes, that's what I've been looking at ...
r- as.raster(1:8, max=8, nrow=2, ncol=4); r
[,1] [,2] [,3] [,4] [1,] #202020 #606060
#9F9F9F #DFDFDF [2,] #404040 #808080
#BFBFBF #FF
r[1:length(r)]
[,1] [1,] #202020 [2,] #404040 [3,] #606060
[4,] #808080 [5,] #9F9F9F [6,] #BFBFBF [7,]
#DFDFDF [8,] #FF
... and the above is exactly the sort of thing that
will fry your mind if the image that you are
subsetting is, for example, a photo.
Why doesn't raster behave consistently like any matrix
object?
I would expect simply
r[1:length(r)]
[1] #202020 #404040 #606060 #808080 #9F9F9F
#BFBFBF
#DFDFDF [8] #FF
Where it's obvious what happened. I saw the comment about
the
vector but I'm not sure I get it - why don't you want a
vector?
The raster is no different than matrices - you still need
to
define the dimensions when going back anyway
Re: [Rd] using rasterImage within image
Hi On 9/02/2011 3:51 p.m., Michael Sumner wrote: Hello, There's a problem for rasterImage when used in SDI mode in Windows, which may be worth considering. https://stat.ethz.ch/pipermail/r-sig-geo/2010-July/008820.html I had off-list emails with Duncan Murdoch and Paul Murrell about this and they determined that it was in SDI only, and there's still no resolution for it as far as I know. I checked in the latest dev build of 2.13.0 2011-02-04 r54221 just in case. I committed a bug fix this morning (r54280), which improves Windows raster drawing for some simple test cases. I'd love to know if that has had any effect on the problem that you reported. Paul This has been in use in the derived function image.SpatialGridDataFrame in the sp package since rasterImage was released, the sp function incorporates a warning for users in SDI mode. Cheers, Mike. On Wed, Feb 9, 2011 at 12:49 PM, Ben Bolkerbbol...@gmail.com wrote: Has anyone yet tried incorporating rasterImage into the base image() function? It seems to make a *huge* difference, with a very small number of added/changed lines of code. (Of course I have barely tested it at all.) Is there any reason this *shouldn't* go into the next release? source(image.R) z- matrix(runif(1e6),nrow=1000) image(z) image(z,useRaster=TRUE) (Patch against SVN 54284 attached; people can contact me if it doesn't go through and they want it.) Ben Bolker __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [.raster bug {was str() on raster objects fails ..}
Hi
On 3/02/2011 1:23 p.m., Simon Urbanek wrote:
On Feb 2, 2011, at 7:00 PM, Paul Murrell wrote:
Hi
Martin Maechler wrote:
On Wed, Feb 2, 2011 at 23:30, Simon
Urbaneksimon.urba...@r-project.org wrote:
On Feb 1, 2011, at 8:16 PM, Paul Murrell wrote:
Hi
On 2/02/2011 2:03 p.m., Henrik Bengtsson wrote:
On Tue, Feb 1, 2011 at 4:46 PM, Paul
Murrellp.murr...@auckland.ac.nz wrote:
Hi
On 1/02/2011 9:22 p.m., Martin Maechler wrote:
Henrik Bengtssonh...@biostat.ucsf.edu on Mon,
31 Jan 2011 11:16:59 -0800 writes:
Hi, str() on raster objects fails for certain
dimensions. For example:
str(as.raster(0, nrow=1, ncol=100)) 'raster' chr
[1, 1:100]
#00 #00 #00 #00 ...
str(as.raster(0, nrow=1, ncol=101)) Error in
`[.raster`(object,
seq_len(max.len)) : subscript out of bounds
This seems to do with how str() and [.raster() is
coded; when subsetting as a vector, which str()
relies on, [.raster() still returns a matrix-like
object, e.g.
img- as.raster(1:25, max=25, nrow=5, ncol=5);
img[1:2]
[,1] [,2] [,3] [,4] [,5] [1,]
#0A0A0A #3D3D3D #707070 #A3A3A3 #D6D6D6
[2,] #141414 #474747 #7A7A7A #ADADAD
#E0E0E0
compare with:
as.matrix(img)[1:2]
[1] #0A0A0A #3D3D3D
The easy but incomplete fix is to do:
str.raster- function(object, ...) {
str(as.matrix(object), ...); }
Other suggestions?
The informal raster class is behaving ``illogical''
in the following sense:
r- as.raster(0, nrow=1, ncol=11) r[seq_along(r)]
Error in `[.raster`(r, seq_along(r)) : subscript out of
bounds
or, here equivalently,
r[1:length(r)]
Error in `[.raster`(r, 1:length(r)) : subscript out of
bounds
When classes do behave in such a way, they definitely
need their own str() method.
However, the bug really is in [.raster: Currently,
r[i] is equivalent to r[i,] which is not at all
matrix-like and its help clearly says that subsetting
should work as for matrices. A recent thread on
R-help/R-devel has mentioned the fact that [ methods
for matrix-like methods need to use both nargs() and
missing() and that [.dataframe has been the example
to follow forever, IIRC already in S and S-plus as of
20 years ago.
The main motivation for non-standard behaviour here is to
make sure that a subset of a raster object NEVER produces
a vector (because the conversion back to a raster object
then produces a single-column raster and that may be a
surprise). Thanks for making the code more standard
and robust.
The r[i] case is still tricky. The following behaviour
is quite convenient ...
r[r == black]- white
... but the next behaviour is quite jarring (at least in
terms of the raster image that results from it) ...
r2- r[1:(nrow(r) + 1)]
So I think there is some justification for further
non-standardness to try to ensure that the subset of a
raster image always produces a sensible image. A simple
solution would be just to outlaw r[i] for raster objects
and force the user to write r[i, ] or r[, j], depending
on what they want.
FYI, I've tried out Martin's updated version at it seems
like a one-column raster matrix is now returned for r[i],
e.g.
Yes, that's what I've been looking at ...
r- as.raster(1:8, max=8, nrow=2, ncol=4); r
[,1] [,2] [,3] [,4] [1,] #202020 #606060
#9F9F9F #DFDFDF [2,] #404040 #808080 #BFBFBF
#FF
r[1:length(r)]
[,1] [1,] #202020 [2,] #404040 [3,] #606060 [4,]
#808080 [5,] #9F9F9F [6,] #BFBFBF [7,] #DFDFDF [8,]
#FF
... and the above is exactly the sort of thing that will fry
your mind if the image that you are subsetting is, for
example, a photo.
Why doesn't raster behave consistently like any matrix object?
I would expect simply
r[1:length(r)]
[1] #202020 #404040 #606060 #808080 #9F9F9F #BFBFBF
#DFDFDF [8] #FF
Where it's obvious what happened. I saw the comment about the
vector but I'm not sure I get it - why don't you want a vector?
The raster is no different than matrices - you still need to
define the dimensions when going back anyway, moreover what you
get now is not consistent at all since there raster never had
that dimension anyway ...
Cheers, Simon
I agree that this would be the most logical and notably least
surprising behavior, which I find the most important argument
(I'm sorry my last message was cut off as it was sent
accidentally before being finished completely).
I think this behaviour might surprise some ...
download.file(http://cran.r-project.org/Rlogo.jpg;, Rlogo.jpg)
library(ReadImages) logo- read.jpeg(Rlogo.jpg)
rLogo- as.raster(logo) rLogoBit- rLogo[50:60, 50:60]
library(grid) # Original image grid.raster(rLogoBit)
grid.newpage() # Subset produces a vector
grid.raster(rLogoBit[1:length(rLogoBit)])
But this should fail IMHO since you're supplying a vector but
grid.raster (assuming it's the same as rasterImage) requires a matrix
- exactly as you would expect in the matrix case - if a function
requires a matrix and you pass a vector, it will bark. I think you
are explaining why going to vector
Re: [Rd] [.raster bug {was str() on raster objects fails ..}
Hi
Martin Maechler wrote:
On Wed, Feb 2, 2011 at 23:30, Simon Urbanek simon.urba...@r-project.org wrote:
On Feb 1, 2011, at 8:16 PM, Paul Murrell wrote:
Hi
On 2/02/2011 2:03 p.m., Henrik Bengtsson wrote:
On Tue, Feb 1, 2011 at 4:46 PM, Paul Murrellp.murr...@auckland.ac.nz wrote:
Hi
On 1/02/2011 9:22 p.m., Martin Maechler wrote:
Henrik Bengtssonh...@biostat.ucsf.edu
on Mon, 31 Jan 2011 11:16:59 -0800 writes:
Hi, str() on raster objects fails for certain dimensions. For
example:
str(as.raster(0, nrow=1, ncol=100)) 'raster' chr [1, 1:100]
#00 #00 #00 #00 ...
str(as.raster(0, nrow=1, ncol=101)) Error in `[.raster`(object,
seq_len(max.len)) : subscript out of bounds
This seems to do with how str() and [.raster() is coded; when
subsetting as a vector, which str() relies on, [.raster()
still returns a matrix-like object, e.g.
img- as.raster(1:25, max=25, nrow=5, ncol=5);
img[1:2]
[,1] [,2] [,3] [,4] [,5]
[1,] #0A0A0A #3D3D3D #707070 #A3A3A3 #D6D6D6
[2,] #141414 #474747 #7A7A7A #ADADAD #E0E0E0
compare with:
as.matrix(img)[1:2]
[1] #0A0A0A #3D3D3D
The easy but incomplete fix is to do:
str.raster- function(object, ...) {
str(as.matrix(object), ...);
}
Other suggestions?
The informal raster class is behaving ``illogical''
in the following sense:
r- as.raster(0, nrow=1, ncol=11)
r[seq_along(r)]
Error in `[.raster`(r, seq_along(r)) : subscript out of bounds
or, here equivalently,
r[1:length(r)]
Error in `[.raster`(r, 1:length(r)) : subscript out of bounds
When classes do behave in such a way, they definitely need their
own str() method.
However, the bug really is in [.raster:
Currently, r[i] is equivalent to r[i,] which is not at all
matrix-like and its help clearly says that subsetting should
work as for matrices.
A recent thread on R-help/R-devel has mentioned the fact that
[ methods for matrix-like methods need to use both nargs() and
missing() and that [.dataframe has been the example to follow
forever, IIRC already in S and S-plus as of 20 years ago.
The main motivation for non-standard behaviour here is to make sure that a
subset of a raster object NEVER produces a vector (because the conversion
back to a raster object then produces a single-column raster and that may be
a surprise). Thanks for making the code more standard and robust.
The r[i] case is still tricky. The following behaviour is quite convenient
...
r[r == black]- white
... but the next behaviour is quite jarring (at least in terms of the raster
image that results from it) ...
r2- r[1:(nrow(r) + 1)]
So I think there is some justification for further non-standardness to try
to ensure that the subset of a raster image always produces a sensible
image. A simple solution would be just to outlaw r[i] for raster objects
and force the user to write r[i, ] or r[, j], depending on what they want.
FYI, I've tried out Martin's updated version at it seems like a
one-column raster matrix is now returned for r[i], e.g.
Yes, that's what I've been looking at ...
r- as.raster(1:8, max=8, nrow=2, ncol=4);
r
[,1] [,2] [,3] [,4]
[1,] #202020 #606060 #9F9F9F #DFDFDF
[2,] #404040 #808080 #BFBFBF #FF
r[1:length(r)]
[,1]
[1,] #202020
[2,] #404040
[3,] #606060
[4,] #808080
[5,] #9F9F9F
[6,] #BFBFBF
[7,] #DFDFDF
[8,] #FF
... and the above is exactly the sort of thing that will fry your mind if the
image that you are subsetting is, for example, a photo.
Why doesn't raster behave consistently like any matrix object? I would expect
simply
r[1:length(r)]
[1] #202020 #404040 #606060 #808080 #9F9F9F #BFBFBF #DFDFDF
[8] #FF
Where it's obvious what happened. I saw the comment about the vector but I'm
not sure I get it - why don't you want a vector? The raster is no different
than matrices - you still need to define the dimensions when going back anyway,
moreover what you get now is not consistent at all since there raster never had
that dimension anyway ...
Cheers,
Simon
I agree that this would be the most logical and notably least
surprising behavior,
which I find the most important argument
(I'm sorry my last message was cut off as it was sent accidentally
before being finished completely).
I think this behaviour might surprise some ...
download.file(http://cran.r-project.org/Rlogo.jpg;,
Rlogo.jpg)
library(ReadImages)
logo - read.jpeg(Rlogo.jpg)
rLogo - as.raster(logo)
rLogoBit - rLogo[50:60, 50:60]
library(grid)
# Original image
grid.raster(rLogoBit)
grid.newpage()
# Subset produces a vector
grid.raster(rLogoBit[1:length(rLogoBit)])
Paul
Martin
Paul
r[1:5,drop=TRUE]
[,1]
[1,] #202020
[2,] #404040
[3,] #606060
[4,] #808080
[5,] #9F9F9F
Warning message:
In `[.raster`(r, 1:5, drop = TRUE) :
'drop' is always implicitly
Re: [Rd] [.raster bug {was str() on raster objects fails ..}
Hi
On 1/02/2011 9:22 p.m., Martin Maechler wrote:
Henrik Bengtssonh...@biostat.ucsf.edu
on Mon, 31 Jan 2011 11:16:59 -0800 writes:
Hi, str() on raster objects fails for certain dimensions. For
example:
str(as.raster(0, nrow=1, ncol=100)) 'raster' chr [1, 1:100]
#00 #00 #00 #00 ...
str(as.raster(0, nrow=1, ncol=101)) Error in `[.raster`(object,
seq_len(max.len)) : subscript out of bounds
This seems to do with how str() and [.raster() is coded; when
subsetting as a vector, which str() relies on, [.raster()
still returns a matrix-like object, e.g.
img- as.raster(1:25, max=25, nrow=5, ncol=5);
img[1:2]
[,1] [,2] [,3] [,4] [,5]
[1,] #0A0A0A #3D3D3D #707070 #A3A3A3 #D6D6D6
[2,] #141414 #474747 #7A7A7A #ADADAD #E0E0E0
compare with:
as.matrix(img)[1:2]
[1] #0A0A0A #3D3D3D
The easy but incomplete fix is to do:
str.raster- function(object, ...) {
str(as.matrix(object), ...);
}
Other suggestions?
The informal raster class is behaving ``illogical''
in the following sense:
r- as.raster(0, nrow=1, ncol=11)
r[seq_along(r)]
Error in `[.raster`(r, seq_along(r)) : subscript out of bounds
or, here equivalently,
r[1:length(r)]
Error in `[.raster`(r, 1:length(r)) : subscript out of bounds
When classes do behave in such a way, they definitely need their
own str() method.
However, the bug really is in [.raster:
Currently, r[i] is equivalent to r[i,] which is not at all
matrix-like and its help clearly says that subsetting should
work as for matrices.
A recent thread on R-help/R-devel has mentioned the fact that
[ methods for matrix-like methods need to use both nargs() and
missing() and that [.dataframe has been the example to follow
forever, IIRC already in S and S-plus as of 20 years ago.
The main motivation for non-standard behaviour here is to make sure that
a subset of a raster object NEVER produces a vector (because the
conversion back to a raster object then produces a single-column raster
and that may be a surprise). Thanks for making the code more standard
and robust.
The r[i] case is still tricky. The following behaviour is quite
convenient ...
r[r == black] - white
... but the next behaviour is quite jarring (at least in terms of the
raster image that results from it) ...
r2 - r[1:(nrow(r) + 1)]
So I think there is some justification for further non-standardness to
try to ensure that the subset of a raster image always produces a
sensible image. A simple solution would be just to outlaw r[i] for
raster objects and force the user to write r[i, ] or r[, j], depending
on what they want.
Paul
Thank you, Henrik, for the bug report.
Martin
__
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [.raster bug {was str() on raster objects fails ..}
Hi
On 2/02/2011 2:03 p.m., Henrik Bengtsson wrote:
On Tue, Feb 1, 2011 at 4:46 PM, Paul Murrellp.murr...@auckland.ac.nz wrote:
Hi
On 1/02/2011 9:22 p.m., Martin Maechler wrote:
Henrik Bengtssonh...@biostat.ucsf.edu
on Mon, 31 Jan 2011 11:16:59 -0800 writes:
Hi, str() on raster objects fails for certain dimensions. For
example:
str(as.raster(0, nrow=1, ncol=100)) 'raster' chr [1, 1:100]
#00 #00 #00 #00 ...
str(as.raster(0, nrow=1, ncol=101)) Error in `[.raster`(object,
seq_len(max.len)) : subscript out of bounds
This seems to do with how str() and [.raster() is coded; when
subsetting as a vector, which str() relies on, [.raster()
still returns a matrix-like object, e.g.
img- as.raster(1:25, max=25, nrow=5, ncol=5);
img[1:2]
[,1] [,2] [,3] [,4] [,5]
[1,] #0A0A0A #3D3D3D #707070 #A3A3A3 #D6D6D6
[2,] #141414 #474747 #7A7A7A #ADADAD #E0E0E0
compare with:
as.matrix(img)[1:2]
[1] #0A0A0A #3D3D3D
The easy but incomplete fix is to do:
str.raster- function(object, ...) {
str(as.matrix(object), ...);
}
Other suggestions?
The informal raster class is behaving ``illogical''
in the following sense:
r- as.raster(0, nrow=1, ncol=11)
r[seq_along(r)]
Error in `[.raster`(r, seq_along(r)) : subscript out of bounds
or, here equivalently,
r[1:length(r)]
Error in `[.raster`(r, 1:length(r)) : subscript out of bounds
When classes do behave in such a way, they definitely need their
own str() method.
However, the bug really is in [.raster:
Currently, r[i] is equivalent to r[i,] which is not at all
matrix-like and its help clearly says that subsetting should
work as for matrices.
A recent thread on R-help/R-devel has mentioned the fact that
[ methods for matrix-like methods need to use both nargs() and
missing() and that [.dataframe has been the example to follow
forever, IIRC already in S and S-plus as of 20 years ago.
The main motivation for non-standard behaviour here is to make sure that a
subset of a raster object NEVER produces a vector (because the conversion
back to a raster object then produces a single-column raster and that may be
a surprise). Thanks for making the code more standard and robust.
The r[i] case is still tricky. The following behaviour is quite convenient
...
r[r == black]- white
... but the next behaviour is quite jarring (at least in terms of the raster
image that results from it) ...
r2- r[1:(nrow(r) + 1)]
So I think there is some justification for further non-standardness to try
to ensure that the subset of a raster image always produces a sensible
image. A simple solution would be just to outlaw r[i] for raster objects
and force the user to write r[i, ] or r[, j], depending on what they want.
FYI, I've tried out Martin's updated version at it seems like a
one-column raster matrix is now returned for r[i], e.g.
Yes, that's what I've been looking at ...
r- as.raster(1:8, max=8, nrow=2, ncol=4);
r
[,1] [,2] [,3] [,4]
[1,] #202020 #606060 #9F9F9F #DFDFDF
[2,] #404040 #808080 #BFBFBF #FF
r[1:length(r)]
[,1]
[1,] #202020
[2,] #404040
[3,] #606060
[4,] #808080
[5,] #9F9F9F
[6,] #BFBFBF
[7,] #DFDFDF
[8,] #FF
... and the above is exactly the sort of thing that will fry your mind
if the image that you are subsetting is, for example, a photo.
Paul
r[1:5,drop=TRUE]
[,1]
[1,] #202020
[2,] #404040
[3,] #606060
[4,] #808080
[5,] #9F9F9F
Warning message:
In `[.raster`(r, 1:5, drop = TRUE) :
'drop' is always implicitly FALSE in '[.raster'
Also,
r[1:5]- white
r
[,1][,2][,3] [,4]
[1,] white white white #DFDFDF
[2,] white white #BFBFBF #FF
/Henrik
Paul
Thank you, Henrik, for the bug report.
Martin
__
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] postscript failure manifests in plot.TukeyHSD
Hi On 17/12/2010 2:17 a.m., Ben Bolker wrote: On 10-12-16 12:09 AM, Jari Oksanen wrote: On 16/12/10 04:24 AM, Paul Murrellp.murr...@auckland.ac.nz wrote: Hi According to the PostScript Language Reference Manual and the PDF Reference, in both PDF and PostScript ... ... a line width of zero is valid, but not recommended (and is clearly not supported by some viewers). ... a line dash pattern cannot be specified as all zero lengths. (So, because R generates the line dash pattern proportional to the line width, a specification of lwd=0 and lty=anything-other-than-solid-or-none does not make sense.) I think three fixes are required: (i) Enforce a minimum line width of 0.01 (mainly because that is not zero, but also because that is the smallest value greater than zero when you round to 2dp like the PDF and PostScript devices do and it's still REALLY thin). (ii) If the line dash pattern ends up as all zeroes (to 2dp), because the line width is so small (thin), force the dash pattern to solid instead. (iii) plot.TukeyHSD() should not use lwd=0 (0.5 is plenty difference to be obviously lighter than the main plot lines) I will commit these unless there are better suggestions or bitter objections. Paul, The difference between working previous (of R 2.11.1) and failing current-still-yesterday (R 2.12.1 RC) was: $ diff -U2 oldtukeyplot.ps /Volumes/TIKKU/tukeyplot.ps --- oldtukeyplot.ps2010-12-14 12:06:07.0 +0200 +++ /Volumes/TIKKU/tukeyplot.ps2010-12-14 12:13:32.0 +0200 @@ -172,5 +172,5 @@ 0 setgray 0.00 setlinewidth -[ 3.00 5.00] 0 setdash +[ 0.00 0.00] 0 setdash np 660.06 91.44 m So 0.00 setlinewidth worked, but [0.00 0.00] 0 setdash failed. Assuming PostScript is anything like English, it is the all-zero dash that caused the failure. Thanks Jari. Since the PDF and PostScript references recommend NOT using 0 line width I think it is still worthwhile enforcing a lower limit. Cheers, Jari Oksanen Yes; I think Paul's fix #2 does this, and fixes #1 and #3 are trying to avoid problems in the future ... Thanks for your help with this Ben and for the documentation suggestions. The fixes have now been committed to the development version. Paul cheers Ben Bolker -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] postscript failure manifests in plot.TukeyHSD
Hi According to the PostScript Language Reference Manual and the PDF Reference, in both PDF and PostScript ... ... a line width of zero is valid, but not recommended (and is clearly not supported by some viewers). ... a line dash pattern cannot be specified as all zero lengths. (So, because R generates the line dash pattern proportional to the line width, a specification of lwd=0 and lty=anything-other-than-solid-or-none does not make sense.) I think three fixes are required: (i) Enforce a minimum line width of 0.01 (mainly because that is not zero, but also because that is the smallest value greater than zero when you round to 2dp like the PDF and PostScript devices do and it's still REALLY thin). (ii) If the line dash pattern ends up as all zeroes (to 2dp), because the line width is so small (thin), force the dash pattern to solid instead. (iii) plot.TukeyHSD() should not use lwd=0 (0.5 is plenty difference to be obviously lighter than the main plot lines) I will commit these unless there are better suggestions or bitter objections. Paul On 15/12/2010 7:20 a.m., Ben Bolker wrote: On 10-12-14 01:16 PM, Peter Ehlers wrote: On 2010-12-14 09:27, Ben Bolker wrote: Jari Oksanenjari.oksanenat oulu.fi writes: Hello R Developers, Dear R-developers, I ran some standard tests with currently (today morning) compiled R release candidate in Linux R 2.12.1 RC (2010-12-13 r53843). Some of these tests used plot.TukeyHSD function. This worked OK on the screen (X11 device), but PostScript file could not be rendered. The following example had the problem with me: postscript(file=tukeyplot.ps) example(plot.TukeyHSD) dev.off() I couldn't view the resulting file with evince in Linux nor in the standard Preview in MacOS. When I compared the generated tukeyplot.ps to the same file generated with an older R in my Mac, I found one difference: $ diff -U2 oldtukeyplot.ps /Volumes/TIKKU/tukeyplot.ps --- oldtukeyplot.ps2010-12-14 12:06:07.0 +0200 +++ /Volumes/TIKKU/tukeyplot.ps2010-12-14 12:13:32.0 +0200 @@ -172,5 +172,5 @@ 0 setgray 0.00 setlinewidth -[ 3.00 5.00] 0 setdash +[ 0.00 0.00] 0 setdash np 660.06 91.44 m Editing the changed line to its old value [ 3.00 5.00] 0 setdash also fixed the problem both in Linux and in Mac. Evidently something has changed, and probably somewhere else than in plot.TukeyHSD (which hasn't changed since r51093 in trunk and never in R-2-12-branch). I know nothing about PostScript so that I cannot say anything more (and I know viewers can fail with standard conforming PostScript but it is a bit disconcerting that two viewers fail when they worked earlier). I must really be avoiding work today ... I can diagnose this (I think) but don't know the best way to solve it. At this point, line widths on PDF devices were allowed to be1. == r52180 | murrell | 2010-06-02 23:20:33 -0400 (Wed, 02 Jun 2010) | 1 line Changed paths: M /trunk/NEWS M /trunk/src/library/grDevices/src/devPS.c allow lwd less than 1 on PDF device == The behavior of PDF devices (by experiment) is to draw a 0-width line as 1 pixel wide, at whatever resolution is currently being rendered. On the other hand, 0-width lines appear to break PostScript. (with the Linux viewer 'evince' I get warnings about rangecheck -15 when trying to view such a file). plot.TukeyHSD contains the lines abline(h = yvals, lty = 1, lwd = 0, col = lightgray) abline(v = 0, lty = 2, lwd = 0, ...) which are presumably meant to render minimum-width lines. I don't know whether it makes more sense to (1) change plot.TukeyHSD to use positive widths (although that may not help: I tried setting lwd=1e-5 and got the line widths rounded to 0 in the PostScript file); (2) change the postscript driver to *not* allow line widths 1 (i.e., distinguish between PS and PDF and revert to the pre-r52180 behaviour for PS only). On reflection #2 seems to make more sense, but digging through devPS.c it's not immediately obvious to me where/how in SetLineStyle or PostScriptSetLineTexture one can tell whether the current driver is PS or PDF ... That may not do it. I find the same problem (fixed by Jari's replacement of [ 0.00 0.00] with [ 3.00 5.00]; haven't tried anything else yet) when I use pdf() instead of postscript(). This is on Vista. Peter Ehlers With PDF, I get invalid value for a dash setting from evince -- perhaps the dash lengths are being set relative to the line width? (Could investigate but had better continue with other things ...) Ben Bolker __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R
Re: [Rd] strange interaction between rasterImage and Grid graphics
Hi Thanks for narrowing down the problem. I have committed some more defensive code and a change that fixes the problem (for me ... R version 2.13.0 Under development (unstable) (2010-09-28 r53056) Platform: i686-pc-linux-gnu (32-bit) Paul On 10/3/2010 10:25 PM, Brian G. Peterson wrote: On Sat, 2 Oct 2010 22:36:07 -0700, Deepayan Sarkar deepayan.sar...@gmail.com wrote: On Sat, Oct 2, 2010 at 4:35 PM, Paul Murrellp.murr...@auckland.ac.nz wrote: The only device I've tried is quartz(), x11() crashed with rasterImage, That is more serious. I have heard of a couple of others like this and I think the common thread may be 64-bit MacOS X. I need to get access to such a beast to take a look. Or maybe just 64 bit. I have (running Debian unstable) sessionInfo() R version 2.12.0 Under development (unstable) (2010-09-02 r52864) Platform: x86_64-unknown-linux-gnu (64-bit) and I get reproducible crashes (same 'memory not mapped' segfault) with x11(type=Xlib) example(rasterImage) #or library(lattice) example(panel.levelplot.raster) [I noticed this a while back, but neglected to report.] -Deepayan Paul *** caught segfault *** address 0x28, cause 'memory not mapped' Traceback: 1: rasterImage(matrix(1), 1, 1, 1, 1) sessionInfo() R version 2.11.1 (2010-05-31) x86_64-apple-darwin9.8.0 I can confirm the problem exists in 2.11.1 as well on 64 bit Ubuntu: R version 2.11.1 (2010-05-31) x11(type=Xlib) example(rasterImage) rstrIm require(grDevices) rstrIm ## set up the plot region: rstrIm op- par(bg = thistle) rstrIm plot(c(100, 250), c(300, 450), type = n, xlab=, ylab=) HitReturn to see next plot: rstrIm image- as.raster(matrix(0:1, ncol=5, nrow=3)) rstrIm rasterImage(image, 100, 300, 150, 350, interpolate=FALSE) *** caught segfault *** address 0x28, cause 'memory not mapped' Traceback: 1: rasterImage(image, 100, 300, 150, 350, interpolate = FALSE) 2: eval.with.vis(expr, envir, enclos) 3: eval.with.vis(ei, envir) 4: source(tf, local, echo = echo, prompt.echo = paste(prompt.prefix, getOption(prompt), sep = ), continue.echo = paste(prompt.prefix, getOption(continue), sep = ), verbose = verbose, max.deparse.length = Inf, encoding = encoding, skip.echo = skips, keep.source = TRUE) 5: example(rasterImage) The lattice example in Deepyan's email library(lattice) example(panel.levelplot.raster) works for me in 2.11.1 Regards, - Brian sessionInfo() R version 2.11.1 (2010-05-31) x86_64-pc-linux-gnu locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_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] grid stats graphics grDevices utils datasets methods [8] base other attached packages: [1] lattice_0.19-11 loaded via a namespace (and not attached): [1] tools_2.11.1 -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strange interaction between rasterImage and Grid graphics
Hi baptiste auguie wrote: Dear all, This may be specific to Mac, I haven't had a chance to test another platform. Consider this, plot(1,1,t=n) rasterImage(matrix(1),1,1,1,1) library(grid) grid.rect(gp=gpar(fill=grey)) The grid.rect covers the full device window as expected. However, when I resize the window ever so slightly (interactive device) the rectGrob is suddenly clipped to the previous plot window. I cannot understand this behavior, and it doesn't happen if one removes the rasterImage() call, so I suspect something iffy is going on with the display list or something. It happens like this: # 1. Clip to the device and draw axes and labels plot(1,1,t=n) # 2. Clip to the plot region and draw raster rasterImage(matrix(1),1,1,1,1) library(grid) # Oooh! This is the first time any grid drawing # has occurred on the device, so initialize grid # stuff, including the top-level viewport, # *which clips to the device* # 3. Draw a rectangle grid.rect(gp=gpar(fill=grey)) # Resize the window ... # which triggers a redraw ... # Oooh! There is grid output on this device so # initialize grid stuff, including the top-level # viewport *which clips to the device* ... # 1. Clip to the device and draw axes and labels # 2. Clip to the plot region and draw raster # 3. Draw a rectangle A workaround is to explicitly do a clip before the grid.rect(), i.e., ... plot(1,1,t=n) rasterImage(matrix(1),1,1,1,1) library(grid) grid.clip() grid.rect(gp=gpar(fill=grey)) ... and I will add this example to the things I will look at when I am trying to clean up the grid code a bit. The only device I've tried is quartz(), x11() crashed with rasterImage, That is more serious. I have heard of a couple of others like this and I think the common thread may be 64-bit MacOS X. I need to get access to such a beast to take a look. Paul *** caught segfault *** address 0x28, cause 'memory not mapped' Traceback: 1: rasterImage(matrix(1), 1, 1, 1, 1) sessionInfo() R version 2.11.1 (2010-05-31) x86_64-apple-darwin9.8.0 locale: [1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8 attached base packages: [1] grid stats graphics grDevices utils datasets methods base __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] scalable delimiters in plotmath
Hi
[shifting to r-devel]
On 13/09/2010 8:43 a.m., David Winsemius wrote:
On Sep 12, 2010, at 4:11 PM, Paul Murrell wrote:
Hi
On 13/09/2010 7:57 a.m., baptiste auguie wrote:
Oh, right I see. I was completely off then. Maybe it's not so easy to
add delimiters after all, I'll have to look at the list of symbol
pieces to see if these can be constructed too.
The plotmath stuff assumes a font with an Adobe Symbol encoding.
The characters we have to play with are shown at
http://www.stat.auckland.ac.nz/~paul/R/CM/AdobeSym.pdf
.
You can see the components of growable delimiters on the bottom
two rows.
Hello Paul;
Both Baptiste and I have looked at the plotmath.c code and it appears
that only a few of those delimiters are supported. We specifically
have tried to use the angle brackets:
plot(1,1,
xlab=expression(bgroup(symbol(0xe1),atop(x,y),symbol(0xf1
Error in bgroup(symbol(225), atop(x, y), symbol(241)) :
invalid group delimiter
The supported delimiters appear to each be built up from three parts
that are then assembled within a bounding box and as far as I can
determine are limited to |, ||, [, {, (, ), },and }. I
needed to download the full source to find a copy, but I'm fairly sure
a guRu of your standing needs no help finding the code that handles
the bgroup display inside plotmath.c. I am not at my machine where I
was looking at it, but the code that I just found in expanded form on
the Internet bore your name as a copyright holder.
So I guess my feature request would be:
---add option for using scalable single character delimiters such as
Symbol(0xe1) and Symbol(0xe1).
Unfortunately, I don't think this is trivial. How are these supposed to
scale? Just get drawn bigger? (which is unlikely to produce nice
results because the lines will get thicker).
I'm guessing that the reason three-component delimiters were chosen is
that it was easier to expand the middle section while not expanding
the ends as much but that's just the guess of someone who is perusing
without really being able to fully grasp the intricacies of what is
being done.
That's about right. This is all modelled on TeX's equation formatting
algorithms. The Computer Modern fonts have this kind of extendable
components for very large delimiters, but for angled brackets it looks
like the TeX solution is just to offer various big versions. For
example, try the following TeX document ...
\documentclass{article}
\begin{document}
\[ \left\{
\begin{array}{ccc}
a b c \\
a b c \\
a b c \\
a b c \\
a b c \\
a b c \\
a b c \\
d e f \end{array}
\right\} \]
\[ \left\langle
\begin{array}{ccc}
a b c \\
a b c \\
a b c \\
a b c \\
a b c \\
a b c \\
a b c \\
d e f \end{array}
\right\rangle \]
\end{document}
Paul
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] large files produced from image plots?
Hi [shifted this to r-devel] I can't reproduce this yet on my systems, but I have heard of at least one other example of a raster-related crash (on a 64-bit system I think). Baptiste: I would love to see that broken PDF if you still have it. Paul On 9/09/2010 8:00 a.m., baptiste auguie wrote: Hi, I get the same crash with x11() with sessionInfo() R version 2.11.1 (2010-05-31) x86_64-apple-darwin9.8.0 locale: [1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8 attached base packages: [1] grid stats graphics grDevices utils datasets methods [8] base However it works fine with quartz(). Have you tried other devices? pdf() doesn't crash R for me, but the output is incorrect. png() is OK but defeats the purpose here. rasterImage is quite a recent addition, it would probably be appreciated to report any such odd behavior to R-devel. Interestingly (or not), the x11() test does not crash for me using grid.raster instead of rasterImage. Best, baptiste On 8 September 2010 21:47, Stephen T.obsessiv...@hotmail.com wrote: Hi Baptiste, Thanks for your suggestion. I have to look into this further, but anything I try with rasterImage() gives me this type of error (below is from running the example in the help file). This is with R 2.11.1 on OS X 10.5 - *** caught bus error *** address 0x24, cause 'non-existent physical address' Traceback: 1: rasterImage(image, 100, 300, 150, 350, interpolate = FALSE) Possible actions: 1: abort (with core dump, if enabled) 2: normal R exit 3: exit R without saving workspace 4: exit R saving workspace This is not an obvious error, is it? Thanks, Stephen Subject: Re: [R] large files produced from image plots? From: baptiste.aug...@googlemail.com Date: Wed, 8 Sep 2010 19:41:46 +0200 CC: r-h...@r-project.org To: obsessiv...@hotmail.com Hi, Have you tried the recent rasterImage() function? HTH, baptiste On Sep 8, 2010, at 7:30 PM, Stephen T. wrote: Hi list, I wonder if anyone has thoughts on making image plots in R [using image() or image.plot(), or filled.contour()]- I've made quite a bit now, but they seem quite large in size when exported to pdf file format (even after compressing with pdftk or ghostscript, which I regularly do). I know that for images, raster graphics output (png, tiff) may be the way to go, but often the ones I make are multi-panel plots with other graphics on them, and are usually included in a LaTeX document (PDFLaTeX does accept png) and require stretching/shrinking (and/or possibly editing with Adobe Illustrator). I have had some luck exporting image plots from Matlab (to postscript or pdf) before in the sense that the files seem smaller and less pixelated. Is this a difference in the way image() plots are produced, or with the way the image is written to the pdf() device (if anyone is familiar with other image-exporting programs...)? The other day I had a 13MB dataset, and probably plotted 3/4 of it! using image() and the compressed pdf output was about 8 MB (it contained other stuff but was an addition of a few KB). I tried filled.contour(), as I understand that it colors polygons to fill contours instead of coloring rectangles at each pixel - and it has saved me before - but this time the contours may have been too sharp as as its compressed pdf came out to be 62 MB... (ouch!). I have not tested this data set with other software programs so it may just have been a difficult data set. Is there a good solution to this (or is it simply not to use a vector-graphics format in these instances), and just for my curiosity, are you aware of any things that other software (data analysis) programs do uder the hood to make their exported images smaller/smoother? Thanks much! Stephen [[alternative HTML version deleted]] __ r-h...@r-project.org 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. __ r-h...@r-project.org 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. -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] what is the best way for an external interface to interact with graphics, libraries
Hi On 8/09/2010 9:23 a.m., Simon Urbanek wrote: On Sep 7, 2010, at 3:07 PM, ghostwheel wrote: Simon Urbanek wrote: I don't know the mechanics of the actual inserting in TeXmac but it would be trivial to simply create a copy of the plot as EPS (or whatever is needed) at the time of insertion. See dev.copy2eps() for a function that does exactly that. Great. It works much better than my recordPlot() hack. But it seems to only work for 'screen devices'. I'd like to be able to work remotely without X11. Is there any equivalent graphics device that would be copyable with dev.copy2eps? Is there any way to tell R give me whatever you have till now in eps? No (AFAIR PS devoice does not keep a display list). PS device does not keep a display list *by default*. You should be able to turn it on via ... dev.control(enable) Paul However, you can use any other device that uses a display list, e.g. CairoPS from the Cairo package (in fact any of the Cairo devices..). Cheers, Simon __ R-devel@r-project.org 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 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gpar fill and transparency on devices
Hi
The help page for Working with Viewports (e.g., pushViewport()) has a
brief mention when talking about the ROOT viewport ...
The viewport tree always has a single root viewport (created by the
system) which corresponds to the entire device (and default graphical
parameter settings).
... which is a reasonable place for it because this is a feature of the
gpar of the ROOT viewport, not of gpars in general. That mention might
be a bit hard to find, but a very similar statement is also made in the
Section on Viewports in the R Graphics book. That in turn might be hard
to find if you don't have the book, but that chapter is also available
online (http://www.stat.auckland.ac.nz/~paul/RGraphics/chapter5.pdf)
It might be worth adding something more explicit about this sort of
gotcha ...
Some devices have different default graphics parameter settings, so it
is not safe to assume that the ROOT viewport will be identical on
different devices.
... ?
Paul
On 5/08/2010 8:14 a.m., baptiste auguie wrote:
Dear list,
I'm puzzled by the graphical output in the following example,
library(grid)
foo- function(){
grid.rect(gp=gpar(fill=black))
print(get.gpar()$fill)
grid.rect(width=0.2,height=0.2)
}
png(test.png, bg = transparent)
foo()
dev.off()
png(test1.png, bg = white)
foo()
dev.off()
It seems that the default value of gpar()$fill is set according to the
device background. I couldn't find this documented in ?gpar or in
?png, and it caused a rather puzzling bug in my code (the pdf() output
was OK, whilst the png output (default bg to white) was seemingly
empty because covered by a white rectangle.)
Best regards,
baptiste
__
R-devel@r-project.org 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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
