Hi,
I'm raising the issue, again, of those pesky thin lines that show up
with a pdf graphics device, otherwise known as FAQ 7.36. I have read
the FAQ and understand that I can eliminate them by adjusting the
anti-aliasing
option for viewing them on the screen, but this doesn't necessarily
eliminate them for a print device or for transferring them into a powerpoint
or similar type of presentation format. I have noticed that pdf's
generated
by some other software do not have the problem that the R generated ones
do. For example, I can generate a pdf figure in R and with Asymptote
(http://asymptote.sourceforge.net/) and put them in the same LaTeX document
and the Asymptote generated pdf shows no thin lines independently of
the anti-alias setting while the R generated one does. So it is not
just the viewer
that is at issue as some pdf generators can make an image that is resistant
to this problem.
After some experimentation, I found that I could fix the problem in a pdf file
generated in R using the pdf graphics device by running the file
through a filter.
Here is a short R example that produces the lines if your
anti-aliasing setting
is set (in)appropriately:
pdf("TestBand.pdf")
n <- 16
x <- y <- seq(1, n)
z <- matrix(1, n, n)
z[, 7:10] <- 0.5
z[, c(5, 12)] <- 0
cc <- seq(0, 1, len = 256)
image(z, col = grey(cc), axes = FALSE)
dev.off()
and afterwards I corrected the file with the following awk filter
#FixLines.awk
{
if ($NF == "rg") {
print $0
for (i = 1; i < NF; i++) printf "%6.3f ", $i
print " RG"
}
else {if ($NF == "f") {
for (i = 1; i < (NF - 1); i++) printf "%6.3f ", $i
print "re b"
} else print $0
}
}
and then this from a terminal command line:
awk -f FixLines.awk < TestBand.pdf > FT.pdf
alternatively, the following Python script works just as well:
import sys
InFile = open(sys.argv[1], mode = "r")
for line in InFile:
if(line.rfind("rg") != -1):
print line,
print line.replace("rg", "RG"),
elif(line.rfind("re f") != -1):
print line.replace("re f", "re b"),
else:
print line,
InFile.close()
What I found was that the pdf's generated from R contain commands that
are filling but not stroking rectangles that would correspond to the elements
of the matrix visualized with the image function. So with the filter,
I located the
lines that set the fill color and added another line that set the stroke color
to be the same, then changed the rectangle fill commands, "re f", to
fill and stroke commands, "re b".
I think that this could be patched in devPS.c (untested) by something like
devPS.c6945
if(R_VIS(gc->fill)) {
PDF_SetFill(gc->fill, dd);
PDF_SetLineColor(gc->fill, dd);
fprintf(pd->pdffp, "0 0 %.2f %.2f re b\n",
72.0 * pd->width, 72.0 * pd->height);
}
or if the current behavior is desired under certain circumstances, perhaps an
argument, StrokeandFill, could be added to the pdf device (postscript, too, I
suppose) so that this behavior could be selected?
Perhaps, there are some more fundamental issues here that I'm not aware of.
i'd like to hear about them, if so. Thank you.
Ken
--
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
--
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
