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.urba...@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@stat.math.ethz.ch >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac > > _______________________________________________ > R-SIG-Mac mailing list > R-SIG-Mac@stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > _______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
