Postscript query: plotting long vectors

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?

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.

 version

 version

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