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