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/ __
Re: [Rd] postscript failure manifests in plot.TukeyHSD
On 10-12-15 09:24 PM, Paul Murrell 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.
That sounds great to me. Proposed corresponding documentation change:
Index: pdf.Rd
===
--- pdf.Rd (revision 53854)
+++ pdf.Rd (working copy)
@@ -149,7 +149,10 @@
viewers. (PDF 1.4 requires Acrobat 5 or later.)
Line widths as controlled by \code{par(lwd=)} are in multiples of
- 1/96 inch. Multiples less than 1 are allowed. \code{pch=.} with
+ 1/96 inch. Multiples less than 1 are allowed; line widths less
+ than 0.01 will be set equal to this minimum value. Line dashes
+ are set proportional to line width; dash patterns less than 0.01
+ will be set to solid. \code{pch=.} with
\code{cex = 1} corresponds to a square of side 1/72 inch, which is
also the \sQuote{pixel} size assumed for graphics parameters such as
\code{cra}.
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
Re: [Rd] postscript failure manifests in plot.TukeyHSD
On 16/12/10 04:24 AM, Paul Murrell p.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. Cheers, Jari Oksanen 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
Re: [Rd] postscript failure manifests in plot.TukeyHSD
Jari Oksanen jari.oksanen at 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 be 1. == 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 ... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] postscript failure manifests in plot.TukeyHSD
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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] postscript failure manifests in plot.TukeyHSD
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
