Postscript query: plotting long vectors
When I run the example in R 1.6.2, and view it with gs, I get a good plot. When I run the example in R 1.7.0, and view it with gs, I get a bad plot. (run on the same host) My "bad plot" is as described by Stephen. In the "good" postscript file, about 100 lines in, there is this: %%EndProlog %%Page: 1 1 bp 77.04 91.44 743.76 534.96 cl 0.0000 0.0000 0.0000 rgb 0.75 setlinewidth [] 0 setdash np 101.73 313.20 m 101.74 313.21 l 101.74 313.23 l 101.74 313.24 l 101.75 313.25 l (followed by ~200000 lines of the same type, with slowly changing values) In the "bad" postscript file, at about the same point in the file, is this: %%EndProlog %%Page: 1 1 bp 77.04 91.44 743.76 534.96 cl 0 0 0 rgb 0.75 setlinewidth [] 0 setdash np 101.73 313.20 m 0.00 0.01 l 0.00 0.01 l 0.00 0.01 l 0.00 0.01 l 0.00 0.01 l (followed by ~200000 lines, including some like these) 0.00 0.00 l 0.00 0.00 l 0.00 -0.01 l 0.00 -0.01 l 0.00 -0.00 l 0.00 -0.00 l Looks like it might be a formatting issue on how these lines were written. My version information: ---- 1.6.2 ----
version
platform sparc-sun-solaris2.7 arch sparc os solaris2.7 system sparc, solaris2.7 status major 1 minor 6.2 year 2003 month 01 day 10 language R
---- 1.7.0 ----
version
_ platform sparc-sun-solaris2.7 arch sparc os solaris2.7 system sparc, solaris2.7 status major 1 minor 7.0 year 2003 month 04 day 16 language R [245]% gs --version 5.50 -Don
At 5:59 PM +0100 5/29/03, Stephen Eglen wrote:
Hi,
I have a query about the maximum length of vector that can be plotted
in one go in a postscript driver. Try the following code (in 1.7.0;
version details below):
t <- seq(from=0, to=4*pi, length=200000)
y <- sin(t)
postscript(file="o.ps")
plot(t, y, type="l")
dev.off()
If I view the postscript file o.ps in "gv", it takes many seconds
before eventually the axes appear, but then only one vertical line is
drawn within the plot area -- there is no sine curve. (this is on a
fast dual processor linux machine with 2Gb RAM.) This is clearly a
postscript problem, rather than a R problem, since reducing the length
of t down to something like 2000 solves the problem. By looking at
the file o.ps it looks like the line is drawn by one "rlineto" call
per point, followed eventually by a "stroke" after the last point.
I'm guessing that the postscript interpreter simply cannot remember so
many points in the path before it gets to the stroke.
The example above is artificial, but this problem appeared with a real
data set this morning. The fix was to replace the single call to
plot() with many calls to line(), breaking the t and y vectors into
more manageable chunks; in this way, each postscript path was
manageable and we got the plot.
I tried plotting the same long vectors in gnuplot by first writing
them from R:
write.table(cbind(t,y), sep="\t", file="eg.dat", row.names=F, col.names=F,
quote=F)
and then in gnuplot:
set term postscript
set output "gnuplot.ps"
plot "eg.dat" wi lines
This came out fine; in gnuplot.ps every 400 lines during the plot it
outputs "currentpoint stroke M" (M is defined to moveto). I had a
look at the gnuplot source (gnuplot-3.7.3/term/post.trm) and found
that it does keep count of the length of the current postscript path:
e.g. in the function PS_vector(x,y) we see (line 1122):
if (ps_path_count >= 400) {
fprintf(gpoutfile,"currentpoint stroke M\n");
ps_path_count = 0;
}
so every 400 points it draws the line so far and then continues.
(Matlab .ps files also seem to have regular "MP stroke".
I had a quick look in the corresponding R code src/main/devPS.c and
could not see any counter. Would it be worth adding such a counter
and periodic line output to PS_Polyline?
version
platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status major 1 minor 7.0 year 2003 month 04 day 16 language R
______________________________________________ R-help at stat.math.ethz.ch mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-help
-------------------------------------- Don MacQueen Environmental Protection Department Lawrence Livermore National Laboratory Livermore, CA, USA