[Rd] postscript failure manifests in plot.TukeyHSD
p.murrell at auckland.ac.nz
Thu Dec 16 03:24:47 CET 2010
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
(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"
(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
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
>>>> 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
>>>> with me:
>>>> I couldn't view the resulting file with evince in Linux nor in the
>>>> Preview in MacOS. When I compared the generated "tukeyplot.ps" to the
>>>> 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
>>>> 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
>>>> 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
>>>> 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
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
64 9 3737599 x85392
paul at stat.auckland.ac.nz
More information about the R-devel