has someone tried `filled.contours' with a `quartz' device? for me, contrary to using `X11' the display is corrupted by visible rendering of all contour lines (looks as if `contour' output is overlayed on the image with a thin line width in a whitish color) as well as the pixel boundaries . the same happens, when I first draw to `X11' and then `dev.print' to a pdf-file: with `gv' under X everything looks fine, using `PreView' under Aqua looks like the `quartz' ouput. I know that Apple's pdf rendering engine used to be buggy (don't know if this is still true) but I'm not sure that this is the reason. it seems that somehow gaps of one screen-pixel are introduced between the constant-color patches. is this known? can something be done about this? regards, joerg ps: partly the problems occur with `image', too: here the quartz display of looks ok, but viewing the same image after dev.print(pdf) shows the image pixels separated by (I presume one) screen-pixel gaps. viewing the pdf-output with `xpdf' on a linux machine showed similar behaviour.
filled.contours and quartz() problem
7 messages · Simon Urbanek, David Winsemius, Marc Schwartz +1 more
On Oct 30, 2009, at 11:05 , Joerg van den Hoff wrote:
has someone tried `filled.contours' with a `quartz' device? for me, contrary to using `X11' the display is corrupted by visible rendering of all contour lines (looks as if `contour' output is overlayed on the image with a thin line width in a whitish color) as well as the pixel boundaries . the same happens, when I first draw to `X11' and then `dev.print' to a pdf-file: with `gv' under X everything looks fine, using `PreView' under Aqua looks like the `quartz' ouput. I know that Apple's pdf rendering engine used to be buggy (don't know if this is still true) but I'm not sure that this is the reason. it seems that somehow gaps of one screen-pixel are introduced between the constant-color patches. is this known? can something be done about this?
FAQ 12.10
regards, joerg ps: partly the problems occur with `image', too: here the quartz display of looks ok, but viewing the same image after dev.print(pdf) shows the image pixels separated by (I presume one) screen-pixel gaps. viewing the pdf-output with `xpdf' on a linux machine showed similar behaviour.
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
On Oct 30, 2009, at 11:05 AM, Joerg van den Hoff wrote:
has someone tried `filled.contours' with a `quartz' device?
I just did with the first example in the help page and the output is not as expected. The left axis tick.labels are plotted partially outside the display window, the labels on the color legend are mostly out of the plot window and the axis labels are completely outside the window. Resizing does not fix the problem, nor does saving and viewing in Preview.app.
for me, contrary to using `X11' the display is corrupted by visible rendering of all contour lines (looks as if `contour' output is overlayed on the image with a thin line width in a whitish color) as well as the pixel boundaries .
I'm not seeing anything that looks visually unpleasant, but the edges appear to have a light highlight.
the same happens, when I first draw to `X11' and then `dev.print' to a pdf-file: with `gv' under X everything looks fine, using `PreView' under Aqua looks like the `quartz' ouput.
Plotting to x11() "works". But I do agree that the edges appear unhighlighted in comparison to the quartz output.
I know that Apple's pdf rendering engine used to be buggy (don't know if this is still true) but I'm not sure that this is the reason.
I am guessing this is new, since I am pretty sure that I have plotted that example before and not had the incorrect sizing.
it seems that somehow gaps of one screen-pixel are introduced between the constant-color patches. is this known? can something be done about this? regards, joerg ps: partly the problems occur with `image', too: here the quartz display of looks ok, but viewing the same image after dev.print(pdf) shows the image pixels separated by (I presume one) screen-pixel gaps. viewing the pdf-output with `xpdf' on a linux machine showed similar behaviour.
_______________________________________________
> sessionInfo() R version 2.9.2 (2009-08-24) (Now that's weird, I thought I had installed the release candidate for 2.10) x86_64-apple-darwin9.8.0 locale: en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] splines stats graphics grDevices utils datasets methods base other attached packages: [1] Hmisc_3.7-0 epicalc_2.9.2.8 survival_2.35-7 foreign_0.8-38 loaded via a namespace (and not attached): [1] cluster_1.12.1 grid_2.9.2 lattice_0.17-26
David Winsemius, MD Heritage Laboratories West Hartford, CT
So reinstalling the 2.10 version (R version 2.10.0 Patched (2009-10-29 r50258)) has fixed the previous graphing anomalies I noticed with filled contour.
On Oct 30, 2009, at 11:56 AM, David Winsemius wrote:
On Oct 30, 2009, at 11:05 AM, Joerg van den Hoff wrote:
has someone tried `filled.contours' with a `quartz' device?
I just did with the first example in the help page and the output is not as expected. The left axis tick.labels are plotted partially outside the display window, the labels on the color legend are mostly out of the plot window and the axis labels are completely outside the window. Resizing does not fix the problem, nor does saving and viewing in Preview.app.
snip
_______________________________________________ sessionInfo()
R version 2.9.2 (2009-08-24) (Now that's weird, I thought I had installed the release candidate for 2.10)
snip David Winsemius, MD Heritage Laboratories West Hartford, CT
On Oct 30 2009 (Fri, 11:38), Simon Urbanek wrote:
On Oct 30, 2009, at 11:05 , Joerg van den Hoff wrote:
has someone tried `filled.contours' with a `quartz' device? for me, contrary to using `X11' the display is corrupted by visible rendering of all contour lines (looks as if `contour' output is overlayed on the image with a thin line width in a whitish color) as well as the pixel boundaries . the same happens, when I first draw to `X11' and then `dev.print' to a pdf-file: with `gv' under X everything looks fine, using `PreView' under Aqua looks like the `quartz' ouput. I know that Apple's pdf rendering engine used to be buggy (don't know if this is still true) but I'm not sure that this is the reason. it seems that somehow gaps of one screen-pixel are introduced between the constant-color patches. is this known? can something be done about this?
FAQ 12.10
thanks, I had'nt noticed that (quick googling before pestering the mailing list did'nt show this :-)) but this was not quite/exclusively my problem: 12.10 addresses only `image' behaviour and states that this is taken care of in quartz. for image, I can confirm that this is true. but not for `filled.contours': here `quartz' excatly shows what I have described previously. but by using quartz(antialias=F) the problem indeed goes away. so, indeed your answer solved my problem (thanks again). two last remarks: should FAQ 12.10 not be augmented in order to state that use of `filled.contour' with quartz requires to use quartz(antialias=F)? it would be even better, I believe, to add an updated FAQ 12.10 to the manpage of quartz (and maybe `pdf'), which after all is a more obvious place to look for a solution than the FAQ (which e.g. escaped my attention altogether...) joerg
regards, joerg ps: partly the problems occur with `image', too: here the quartz display of looks ok, but viewing the same image after dev.print(pdf) shows the image pixels separated by (I presume one) screen-pixel gaps. viewing the pdf-output with `xpdf' on a linux machine showed similar behaviour.
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
On Oct 30, 2009, at 11:53 AM, Joerg van den Hoff wrote:
On Oct 30 2009 (Fri, 11:38), Simon Urbanek wrote:
On Oct 30, 2009, at 11:05 , Joerg van den Hoff wrote:
has someone tried `filled.contours' with a `quartz' device? for me, contrary to using `X11' the display is corrupted by visible rendering of all contour lines (looks as if `contour' output is overlayed on the image with a thin line width in a whitish color) as well as the pixel boundaries . the same happens, when I first draw to `X11' and then `dev.print' to a pdf-file: with `gv' under X everything looks fine, using `PreView' under Aqua looks like the `quartz' ouput. I know that Apple's pdf rendering engine used to be buggy (don't know if this is still true) but I'm not sure that this is the reason. it seems that somehow gaps of one screen-pixel are introduced between the constant-color patches. is this known? can something be done about this?
FAQ 12.10
thanks, I had'nt noticed that (quick googling before pestering the mailing list did'nt show this :-)) but this was not quite/exclusively my problem: 12.10 addresses only `image' behaviour and states that this is taken care of in quartz. for image, I can confirm that this is true. but not for `filled.contours': here `quartz' excatly shows what I have described previously. but by using quartz(antialias=F) the problem indeed goes away. so, indeed your answer solved my problem (thanks again). two last remarks: should FAQ 12.10 not be augmented in order to state that use of `filled.contour' with quartz requires to use quartz(antialias=F)? it would be even better, I believe, to add an updated FAQ 12.10 to the manpage of quartz (and maybe `pdf'), which after all is a more obvious place to look for a solution than the FAQ (which e.g. escaped my attention altogether...) joerg
FWIW, this is also covered in the general R FAQ 7.36: http://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-are-there-unwanted-borders HTH, Marc Schwartz
On Oct 30 2009 (Fri, 12:01), Marc Schwartz wrote:
On Oct 30, 2009, at 11:53 AM, Joerg van den Hoff wrote:
On Oct 30 2009 (Fri, 11:38), Simon Urbanek wrote:
On Oct 30, 2009, at 11:05 , Joerg van den Hoff wrote:
has someone tried `filled.contours' with a `quartz' device? for me, contrary to using `X11' the display is corrupted by visible rendering of all contour lines (looks as if `contour' output is overlayed on the image with a thin line width in a whitish color) as well as the pixel boundaries . the same happens, when I first draw to `X11' and then `dev.print' to a pdf-file: with `gv' under X everything looks fine, using `PreView' under Aqua looks like the `quartz' ouput. I know that Apple's pdf rendering engine used to be buggy (don't know if this is still true) but I'm not sure that this is the reason. it seems that somehow gaps of one screen-pixel are introduced between the constant-color patches. is this known? can something be done about this?
FAQ 12.10
thanks, I had'nt noticed that (quick googling before pestering the mailing list did'nt show this :-)) but this was not quite/exclusively my problem: 12.10 addresses only `image' behaviour and states that this is taken care of in quartz. for image, I can confirm that this is true. but not for `filled.contours': here `quartz' excatly shows what I have described previously. but by using quartz(antialias=F) the problem indeed goes away. so, indeed your answer solved my problem (thanks again). two last remarks: should FAQ 12.10 not be augmented in order to state that use of `filled.contour' with quartz requires to use quartz(antialias=F)? it would be even better, I believe, to add an updated FAQ 12.10 to the manpage of quartz (and maybe `pdf'), which after all is a more obvious place to look for a solution than the FAQ (which e.g. escaped my attention altogether...) joerg
FWIW, this is also covered in the general R FAQ 7.36: http://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-are-there-unwanted-borders HTH,
OK, you win. had I seen those two, I would have got it. not much sense in arguing against a FAQ... but the thing runs at about 40 pages at the moment and it really did not occur to me that this seeminlgy very special problem would be in the FAQ at all. I still would prefer to see "FAQs" which can be assigned to one or two manpages, there as well. at the very least a comment concerning the antialias switch of `quartz' would do no harm... but anyway, I'm happy again. thanks again joerg
Marc Schwartz