[Rd] postscript failure manifests in plot.TukeyHSD

Thu Dec 16 05:03:16 CET 2010

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
>

