Skip to content

R postscript generation error (lines versus points) (PR#5285)

5 messages · Stephen.Harker@spme.monash.edu.au, Peter Dalgaard, Paul Murrell

Original
Stephen.Harker@spme.monash.edu.au
# 
Full_Name: Stephen Harker
Version: 1.80
OS: linux (Yellow Dog 3.0 on ppc)
Submission from: (NULL) (130.194.13.101)


In creating a postscript file from a set of data in which the points are
plotted
using `points()' and lines drawn using `lines()' I have found since upgrading
from R version 1.4? to 1.8 that the two sets do not coinicide completely.  This
is best illustrated by a simple example given below.  Here the X11() output
appears correctly.  However, the postscript output shows that the lines and
points no
longer coincide on the right hand side, whereas the left hand side is perfect. 
Output to other devices such as pdf is perfect.  Possibly this reflects a
different scaling being applied when points() or lines() are selected. 

One reason I found this is that I use a number of scripts in R to plot and
multiplot data sets from x-ray and neutron powder diffraction analysis (and
Rietveld fitting of this data in particularl).  In these points() is used to
plot the data and lines() to plot the refinement from the analysis.  After
upgrading I found these were 
misaligned.  The example was created to mimic the problem.

%%% Example follows:
dtwoth <- seq(from=20,to=80,len=1024)
dcount <- rnorm(dtwoth) #

postscript(file="R-test2.ps",horizontal=FALSE,
         pointsize=18, onefile=FALSE,
         family="Helvetica", paper="a4") 

plot(dtwoth,dcount, 
  xlim=c(min(dtwoth),max(dtwoth)),ylim=c(min(dcount),max(dcount)),
 yaxt="n",xaxs="i",yaxs="i",xlab="2theta",ylab="counts",
 type="n")

lines(dtwoth,dcount)
points(dtwoth,dcount)

X11() 

plot(dtwoth,dcount, 
  xlim=c(min(dtwoth),max(dtwoth)),ylim=c(min(dcount),max(dcount)),
 yaxt="n",xaxs="i",yaxs="i",xlab="2theta",ylab="counts",
 type="n")

lines(dtwoth,dcount)
points(dtwoth,dcount)
Peter Dalgaard
# 
Stephen.Harker@spme.monash.edu.au writes:
[At the current rate, "1.80" would be about 36 years into the future.
Latest version is 1.8.1.]

I can't reproduce this with 1.8.0 on RedHat 8.0. Are you sure it isn't
your Postscript viewer that is playing tricks on you??
Paul Murrell
# 
Hi
Peter Dalgaard wrote:
> Stephen.Harker@spme.monash.edu.au writes:
 >
 >
 >>Full_Name: Stephen Harker
 >>Version: 1.80
 >>OS: linux (Yellow Dog 3.0 on ppc)
 >>Submission from: (NULL) (130.194.13.101)
 >>
 >>
 >>In creating a postscript file from a set of data in which the points are
 >>plotted
 >>using `points()' and lines drawn using `lines()' I have found since 
upgrading
 >>from R version 1.4? to 1.8 that the two sets do not coinicide 
completely.  This
 >>is best illustrated by a simple example given below.  Here the X11() 
output
 >>appears correctly.  However, the postscript output shows that the 
lines and
 >>points no
 >>longer coincide on the right hand side, whereas the left hand side is 
perfect.
 >>Output to other devices such as pdf is perfect.  Possibly this reflects a
 >>different scaling being applied when points() or lines() are selected.
 >>
 >>One reason I found this is that I use a number of scripts in R to 
plot and
 >>multiplot data sets from x-ray and neutron powder diffraction 
analysis (and
 >>Rietveld fitting of this data in particularl).  In these points() is 
used to
 >>plot the data and lines() to plot the refinement from the analysis. 
After
 >>upgrading I found these were
 >>misaligned.  The example was created to mimic the problem.
 >>
 >>%%% Example follows:
 >>dtwoth <- seq(from=20,to=80,len=1024)
 >>dcount <- rnorm(dtwoth) #
 >>
 >>postscript(file="R-test2.ps",horizontal=FALSE,
 >>         pointsize=18, onefile=FALSE,
 >>         family="Helvetica", paper="a4")
 >>
 >>plot(dtwoth,dcount,
 >>  xlim=c(min(dtwoth),max(dtwoth)),ylim=c(min(dcount),max(dcount)),
 >> yaxt="n",xaxs="i",yaxs="i",xlab="2theta",ylab="counts",
 >> type="n")
 >>
 >>lines(dtwoth,dcount)
 >>points(dtwoth,dcount)
 >
 >
 > [At the current rate, "1.80" would be about 36 years into the future.
 > Latest version is 1.8.1.]
 >
 > I can't reproduce this with 1.8.0 on RedHat 8.0. Are you sure it isn't
 > your Postscript viewer that is playing tricks on you??


I can't reproduce this either, but in trying your script I wonder if you 
are not properly "finishing" the postscript plot by calling dev.off 
before viewing.  If I run your script, then view R-test2.ps without 
quitting R, the last few points at the right end of the plot are missing 
(because the postscript file is not yet complete).  If I then quit R 
(the postscript file is completed and closed), the postscript output 
looks just like the X11 version.

Paul
Stephen.Harker@spme.monash.edu.au
# 
Hi,
On Tue, Nov 25, 2003 at 09:17:09AM +1300, Paul Murrell wrote:
:-)
Yes and no: I get the same result in prints from a PostScript file or
from files included into a LaTeX document in the case of the original
scripts that caused me to try to create a test case.  However, this
morning having read this comment I tried this test script and I find
it generates obvious `errors' using gs 8.11 (in /usr/local/bin) and
none obvious using the system gs (7.05 in /usr/bin).  I tried printing
the file to a HP Laserjet 4MV, 8000N and a Konica 7155 and find it is
similar to the gs 7.05 output.  This suggests two problems: a problem
with gs 8.11 as built on my system and that my test script does not
duplicate the problem I thought I was illustrating.

In the production scripts I have been using (with a history that goes
back to the mid 90's) this occurs in a vary obvious mismatch in the
lines() and points() that gets worse as x increases.  I had thought
that the script submitted duplicated the problem.  Now it appears that
it does not.  For the scripts I was using I get the mismatch on
printed postscript and similar(? I did not compare them fully) results
with the screen.
No: in my production versions dev.off() is called.  I noticed the
missing points you mentioned in the postscript file created.  However,
I did not worry about it as the error was noticeable in the alignment
of the `peaks' and `points' prior to the missing points.

I will need to test this further and to find a better way of
duplicating the error (if error it is).  I will have to try building R
1.8 on another system and test my Rietveld and other x-ray data
plotting scripts to see if it matches my current problem.  I will
contact you when I have more data (useful or otherwise).
Stephen.Harker@spme.monash.edu.au
# 
Hi,
On Tue, Nov 25, 2003 at 09:17:09AM +1300, Paul Murrell wrote:
After further checking I find that this is the solution, despite my
previous email saying it could not be the case.  I have now downgraded
to gs 8.00 on /usr/local/bin (previously gs 8.11) and all postscript
output views correctly even in the LaTeX documents using production
output of neutron and x-ray powder diffraction that were previously
causing problems.  That is to say that documents that previously
exhibited the problem now don't.

More surprsingly (to me) the printed output is correct.  I have my
printer queues set up using CUPS and appropriate ppd files specific
for our departmental printers.  As these are postscript printers and
the correct PPD files are used I had assumed this meant ghostscript
was not interacting with the printing.  I was most surprised to
discover this assumption must be wrong.  It would appear that gs is in
the loop with a postscript file being sent to a postscript printer as
I have them setup.

I will now have to work on a bug report for ghostscript 8.11.  It
appears I blamed the wrong upgrade (R rather than ghostscript,
encouraged by the printed results).  I knew I had upgraded the two
close together, but had not checked the dates sufficiently.  I assume
this closes this `bug report' unless you wish to be informed of any
progress in isolating the problem in gs 8.11.