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.ps 2010-12-14 12:06:07.000000000 +0200 +++ /Volumes/TIKKU/tukeyplot.ps 2010-12-14 12:13:32.000000000 +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). Cheers, Jari Oksanen
postscript failure manifests in plot.TukeyHSD
9 messages · Peter Ehlers, Paul Murrell, Ben Bolker +1 more
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.ps 2010-12-14 12:06:07.000000000 +0200 +++ /Volumes/TIKKU/tukeyplot.ps 2010-12-14 12:13:32.000000000 +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 ...
On 2010-12-14 09:27, Ben Bolker wrote:
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.ps 2010-12-14 12:06:07.000000000 +0200 +++ /Volumes/TIKKU/tukeyplot.ps 2010-12-14 12:13:32.000000000 +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 ...
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
On 10-12-14 01:16 PM, Peter Ehlers wrote:
On 2010-12-14 09:27, Ben Bolker wrote:
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.ps 2010-12-14 12:06:07.000000000 +0200 +++ /Volumes/TIKKU/tukeyplot.ps 2010-12-14 12:13:32.000000000 +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 ...
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
1 day later
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 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.ps 2010-12-14 12:06:07.000000000 +0200 +++ /Volumes/TIKKU/tukeyplot.ps 2010-12-14 12:13:32.000000000 +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 ...
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 at 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 paul at stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/
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 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.ps 2010-12-14 12:06:07.000000000 +0200 +++ /Volumes/TIKKU/tukeyplot.ps 2010-12-14 12:13:32.000000000 +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 ...
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 at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
On 16/12/10 04:24 AM, "Paul Murrell" <p.murrell at 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.ps 2010-12-14 12:06:07.000000000 +0200 +++ /Volumes/TIKKU/tukeyplot.ps 2010-12-14 12:13:32.000000000 +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 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.ps 2010-12-14 12:06:07.000000000 +0200 +++ /Volumes/TIKKU/tukeyplot.ps 2010-12-14 12:13:32.000000000 +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 ...
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 at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
On 10-12-16 12:09 AM, Jari Oksanen wrote:
On 16/12/10 04:24 AM, "Paul Murrell" <p.murrell at 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.ps 2010-12-14 12:06:07.000000000 +0200 +++ /Volumes/TIKKU/tukeyplot.ps 2010-12-14 12:13:32.000000000 +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
Yes; I think Paul's fix #2 does this, and fixes #1 and #3 are trying
to avoid problems in the future ...
cheers
Ben Bolker
5 days later
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 Murrell"<p.murrell at 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.ps 2010-12-14 12:06:07.000000000 +0200 +++ /Volumes/TIKKU/tukeyplot.ps 2010-12-14 12:13:32.000000000 +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 paul at stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/