davids@utstat.uucp (David Scollnik) (08/15/89)
line eater, line eater ... By now, I hope everyone has their own copy of VLT ... great program, isn't it, thanx willy et al ... Now, in version 4.058 ( the most current (?)), there is a terrific option which allows one to save the image on the graphics screen to a postscript file. Terrific !! Stupendous !! HOWEVER ... the laser printer I have access to seems unable to process these files, although it will print postscript files generated on the Sun Workstations used alongside the Amiga ( for example, plots created in and saved via the statistical programming languages "S" and "New S" ). The laser printer is an Apple product, if this means anything. The complaint seems to be the absence of any "currentpoint" statement in the postscript file generated by VLT. But this may only be a symptom, and not the real problem. In any case, has anyone successfully saved and printed postscript files with VLT ??? If so, could you please email or post any info relevant to my own problems ??? Thanks for your time ... -- David P.M. Scollnik | UUCP: utstat!davids University of Toronto | bitnet: davids@utstat.utoronto Deptartment of Statistics | arpa: davids@utstat.toronto.edu (hi mom !!!) -- David P.M. Scollnik | UUCP: utstat!davids University of Toronto | bitnet: davids@utstat.utoronto Deptartment of Statistics | arpa: davids@utstat.toronto.edu (hi mom !!!)
kent@swrinde.nde.swri.edu (Kent D. Polk) (08/15/89)
In article <1989Aug14.220122.561@utstat.uucp> davids@utstat.uucp (David Scollnik) writes: [...] (Info about VLT's image save to postscript file option} >HOWEVER ... the laser printer I have access to seems unable to >process these files, although it will print postscript files >generated on the Sun Workstations used alongside the Amiga [...] Interesting... I posted a message a while back about getting postscript output from the Amiga to a Sun postscript printer. I am currently using ProWrite/ProScript still since the other options suggested don't work. For example, Ifftops generates garbage on the postscript printer. I'm just sending the file to the Sun & then: lpr 'file.ps'. What's wrong? Thanks, Kent Polk - Southwest Research Institute kent@swrinde.nde.swri.edu
garvin@ccvr1.uucp (Michael A. Garvin) (08/15/89)
In article <20020@swrinde.nde.swri.edu> kent@swrinde.UUCP (Kent D. Polk) writes: >In article <1989Aug14.220122.561@utstat.uucp> davids@utstat.uucp (David Scollnik) writes: >[...] > >(Info about VLT's image save to postscript file option} > >>HOWEVER ... the laser printer I have access to seems unable to >>process these files, although it will print postscript files >>generated on the Sun Workstations used alongside the Amiga >[...] > >Interesting... I posted a message a while back about getting >postscript output from the Amiga to a Sun postscript printer. I am >currently using ProWrite/ProScript still since the other options >suggested don't work. For example, Ifftops generates garbage on the >postscript printer. I'm just sending the file to the Sun & then: >lpr 'file.ps'. What's wrong? > >kent@swrinde.nde.swri.edu Well, first about VLT. I had to change the PostScript header sent out with it to work with the Apple LaserWriter. Turns out that they don't like the definition that VLT uses for showing a line on the page. The offender is (in S:TekProlog.PS): /s {stroke newpath show} bdef Taking this out causes problems, though. You have to edit the VLT output PostScript file and take out all the references to this bdef. The easiest way I've found to do it is to do a global search and replace on ") s" and replace with ") show". Now, onto the PostScript printing problem. This depends on how you're getting the output to your PostScript printer, but we had a similar problem using a filter called "ln03rof" (it turns ASCII into PostScript for the PostScript capable DEC LN03 laser printer). We would get our PostScript printed out nicely for us; not the page set up by the PostScript code but the code itself (a source listing and not the final result). It turns out that the filter was wrapping the PostScript code in its own PostScript header; the result being that our code was being treated as text since the filter's PostScript was being interpreted first. Our fix was to read the documentation (gasp!) and learn that we needed a line in our call to the filter to tell it that the text going through it may be PostScript and not to wrap it. Other possible problems: CR/LF getting screwed up during transfer from Amiga to printing machine, not using ASCII file transfer method (Kermit binary instead of Kermit ASCII), or the filter not liking the Amiga code for some arcane reason. This is, of course, assuming that you're using a filter program and not sending the file straight to the printer. Anyways, hope this helps. garvin@ccvr1.ncsu.edu Michael Garvin NCSU Computing Center, Raleigh, NC
kent@swrinde.nde.swri.edu (Kent D. Polk) (08/16/89)
In article <3664@ncsuvx.ncsu.edu> garvin@ccvr1.ncsu.edu (Michael A. Garvin) writes: >[...] > Now, onto the PostScript printing problem. This depends on how you're >getting the output to your PostScript printer, but we had a similar problem >[...] > Other possible problems: CR/LF getting screwed up during transfer from >Amiga to printing machine, not using ASCII file transfer method (Kermit >binary instead of Kermit ASCII), or the filter not liking the Amiga code for >some arcane reason. This is, of course, assuming that you're using a filter >program and not sending the file straight to the printer. Transmission problem possibility: I'm using Dnet-nfs, so file transfer isn't the problem (I checked, the files are identical on both ends). CR/LF problem possibility: Now CR/LF may be a problem since I noticed that ProScript-produced files use LF-terminated lines, whereas Ifftops seems to generate CR-terminates lines. I actually get a graphic image using Ifftops, but it is truly garbage. I think this is the problem. (I really expected the Postscript printer to be a bit smarter I guess). Thanks much Kent Polk