[R-SIG-Mac] [R] Sweave, lty = 3 line incorect in pdf output

[baptiste auguie]

Hi,

I'm slightly confused here, what you (Simon) describe looks a lot like
PR#14128 which was fixed last December,

------------------------------------------------------------------------
r50695 | ripley | 2009-12-09 13:37:27 +0100 (Wed, 09 Dec 2009) | 1 line

adjust line textures for butt end caps on postscript() and pdf() devices
------------------------------------------------------------------------

Was there another bug lurking around that only got apparent after this
change or is it unrelated? I checked the diff between the two versions
but I'm still not sure.

Thanks,

baptiste



On 13 February 2010 17:30, Simon Urbanek <simon.urbanek at r-project.org> wrote:
>
> On Feb 12, 2010, at 4:37 PM, Ken Knoblauch wrote:
>
>> Ken Knoblauch <ken.knoblauch <at> inserm.fr> writes:
>>> First, I want to thank everybody who responded for their
>>> helpful comments and suggestions, though the problem is
>>> still unresolved and if anyone has any additional ideas,
>>> I would be grateful.  Second, if I can test your patience
>>> just a bit more, I have found an additional clue that
>>> perhaps will help solve the mystery of the missing dotted
>>> lines (on my system, apparently).
>>>
>>> I tried on another Leopard system (64 bit R) with the same result, and then
>>> on a system running Tiger (all with a version of R 2.10.1 patched),
>>> The dotted lines appeared on Tiger.  I transferred the Tiger generated
>>> file to my Leopard Mac and the dotted line appears on the viewer,
>>> here, as well.  So, I investigated how the files might differ
>>> and the only thing that I can find is that the Tiger generated
>>> version contains the lines
>>>
>>> 1 J
>>> 1 j
>>>
>>> whereas, in the Leopard generated version, I only see
>>>
>>> 1 j
>>>
>>> If I add a line of 1 J to the Leopard generated file, after line 35,
>>> the dotted lines do appear in my viewer.
>>>
>>> I don't know what these commands do in pdf (I don't speak pdf).
>>> Would anyone have an idea what could have happened that my pdf()
>>> command does not produce them and most importantly, any ideas on
>>> how to fix it?
>>
>>>>> --
>>>>> Ken Knoblauch
>>>>> Inserm U846
>>>>> Stem-cell and Brain Research Institute
>>>>> Department of Integrative Neurosciences
>>>>> 18 avenue du Doyen Lépine
>>>>> 69500 Bron
>>>>> France
>>>>> tel: +33 (0)4 72 91 34 77
>>>>> fax: +33 (0)4 72 91 34 61
>>>>> portable: +33 (0)6 84 10 64 10
>>>>> http://www.sbri.fr/members/kenneth-knoblauch.html
>>
>> Some additional search in the pdf reference manual and I found that
>> 1 j refers to linejoin choice (ljoin = 1 in par)
>> 1 J to line end (lend = 1 in par)
>>
>>> From this I tried,
>>
>>
>> pdf(file = "testPP.pdf")
>> par(lend = 1) # the default is 0 according to ?par
>> x <- 1:10
>> plot(x, type = "l", lty = 3, lwd = 3)
>> lines(x, 0.5 * x)
>> dev.off()
>>
>> which produces the correct dotted line (in my viewer)...
>>
>
> Great, I think I know what's happening. The good news is that I have committed the fix to R. Let me explain what we see and then the issue.
>
> The issue comes from the fact that dots in lines are created by using 0-length pattern segments. What this means is that the appearance is mainly defined by the line end setting:
>
> lend0 = PDF1 = round = circle
> lend1 = PDF0 = butt = nothing since it's a rectangle of the length 0
> lend2 = PDF2 = square = squares in the direction of the line
>
> So what happens in the case where you see nothing is that the line end is set to butt (lend=1 -> 0 J) which produces 0-width rectangles and thus is invisible.
>
> The main bug was that the PDF device failed to set the line end (in the PDF) if the texture (lty) was also to be set. Therefore R would think that it changed the line cap to round, but in fact it did not so it was up to the viewer's default what the line cap would be. If it happened to be butt then the line would become invisible, because R thought it's round so it can use 0-length segment. R is smart enough to use 1-length segment if the type is butt cap so that's why butt cap worked for you. The difference in the output was due to the difference in R versions - not really due to OS versions - because the behavior wrt line cap = butt was changed between R 2.10.1 release and now.
>
> That is now all fixed in R-devel and R-patched.
>
> Thanks for your persistence, Ken, your digging was very helpful to pinpoint he right spot and the bug was not Mac-specific (in fact Quartz was unaffected), so many R users will be thankful :).
>
> Thanks,
> Simon
>
>
>
>> I can add par(lend = 1) throughout my Sweave document, I guess.
>> If anybody has any further suggestions, or how to fix this globally,
>> I'm interested in hearing from you.  Thanks.
>>
>> Ken
>>
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac at stat.math.ethz.ch
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>