markad@blake.u.washington.edu (Mark Donnell) (07/13/90)
1) I am trying to print the output from WinWord on a remote NeXT printer. I print to a file, with the output comfigured for a Apple Laser Writer Plus. I save the printer initialization text to a file. I zmodem them up to the lab. I cat them together. I look at it and it looks generally like postscript. I try printing it with 'lpr text.eps' - it spools, then dissapears without any noticable effect on the printer. The printer is working and will print other files. I also tried to print them on a Apple Laser Writer Plus hooked up to a Sun in the lab. It printer out 'Error: spooled binary file rejected'. What am I doing wrong? Surely it can be done. 2) When I bring up windows in 386 mode, the screen blanks, although everything seems to be running fine. Someone mentioned that it might be that I have windows configured with the wrong driver. I have a genoa 5200 (?) video card. Does anyone out there know what driver will work with it? Or should I try to contact Genoa and get it from them? PreThanks Mark
andrzej@bigsur.UUCP (Andrzej Bieszczad) (07/13/90)
In article <4995@milton.u.washington.edu>, markad@blake.u.washington.edu (Mark Donnell) writes: > 1) I am trying to print the output from WinWord on a remote NeXT printer. > I print to a file, with the output comfigured for a Apple Laser Writer Plus. > I save the printer initialization text to a file. I zmodem them up to the lab. > I cat them together. I look at it and it looks generally like postscript. > > I try printing it with 'lpr text.eps' - it spools, then dissapears without > any noticable effect on the printer. The printer is working and will print > other files. > > I also tried to print them on a Apple Laser Writer Plus hooked up to a Sun > in the lab. It printer out 'Error: spooled binary file rejected'. > > What am I doing wrong? Surely it can be done. > ... > Mark I would also like to find out what the problem is. I used a SUN and a postscript printer and the message I got was the same: 'Error: spooled binary file rejected' Thanks in advance for any hints, Andrzej ======================================================================= Andrzej Bieszczad (Bell-Northern Research, Ltd.) USENET: uunet!bnrgate!bigsur!andrzej BitNet: andrzej@BNR.CA Surface: Dept. 7G12, P.O. Box 3511, Station C, Phone: (613) 763-2259 Ottawa, Ontario, Canada, K1Y 4H7 Fax: (613) 763-3283 =======================================================================
altman@sbstaff2.cs.sunysb.edu (Jeff Altman) (07/13/90)
Try removing the Ctrl-D characters from the beginning and ending of the file you are trying to print. Also, why do you need to save the init strings to a separate file, they should be saved as part of the file when you print to FILE: from within Windows. - Jeff (jaltman@ccmail.sunysb.edu)
markg@cbnewsk.att.com (mark.r.gibaldi) (07/14/90)
I have had no trouble at all printing laserwriter II NT output remotely as the original poster has had. I set up the printer to print to a file. Deep in the printer configration dialog boxes, it asks whether or not to create an "encapsulated" postcript file on output. I said yes. I then print to disk, kermit it up to the host computer, and print it on the laser writer. Two points. 1) do not send any printer initialization strings. The printer by default expects valid postscript files. 2) make sure you send the "raw" file to the printer. Most print spoolers run through filters which create a postscript file designed to recreate the original file inputed. For example use lpr -o raw. Mark R. Gibaldi AT&T Bell Laboratories mrg@cblph.att.com
dsampson@x102a.harris-atd.com (sampson david 58163) (07/16/90)
In article <4995@milton.u.washington.edu> markad@blake.u.washington.edu (Mark Donnell) writes: >1) I am trying to print the output from WinWord on a remote NeXT >printer. I print to a file, with the output comfigured for a Apple >Laser Writer Plus. I save the printer initialization text to a file. >I zmodem them up to the lab. I cat them together. I look at it and it >looks generally like postscript. >I try printing it with 'lpr text.eps' - it spools, then dissapears >without any noticable effect on the printer. The printer is working >and will print other files. Mark -- The next time you print to a file with the windows postscript driver, take a look at the result. The first line in the file will have something like this (without the quotes) "^D%! Adobe 2.0". The problem is that ^D as the 1st character. The Apple printers want to see the %! as the 1st two characters in a postscript file, otherwise it will look like something is printing, but you get no output. If you manually edit your file, you only need to replace the first line with %!. Everything else in the first line is just extra text. The %! tells the printer "Postscript commin' at ya". The ^D in front of that signal confuses the printer. It doesn't properly parse the line. I believe that ^D is an attempt to force a top of page (i.e. kicks out a sheet). I wrote a simple program in C to filter the Control-D out of the file. So my procedure for printing to a remote printer is as follows: 1) Print to a file using the postscript driver from whatever windows application you're in 2) Exit windows and filter out that ^D 3) Issue the lpr filename command command to the remote printer. I print to a SUN that is set up as a server. This procedure works fine. David -- ------------------------------------------------------------------------------- David Sampson Harris Corporation dsampson@x102a.ess.harris.com Gov't Aerospace Systems Divison uunet!x102a!dsampson Melbourne, Florida -------------------------------------------------------------------------------
stancil@walt.cc.utexas.edu (Glen Stancil) (07/18/90)
After much wasted upload time and senseless agravation, we discovered that
the Windows (2.1 in our case) postscript driver puts a CTRL-D at the top
and bottom of all files printed "to file". By editing out these two
characters, the files printed successfully. The environment is a PS/2
printing postscript to a file: uploading to a SUN fileserver: printing
to a network Apple Laserwriter. (als true using other fileservers -
encore multimax e.g.)
---flame on
If Microsoft could get rid of the (&)^( CTRL-D's, the world would be a
much safer place.
---flame off
I was hoping that this would be fixed in Win3 (mine is "in the mail"), but
it seems as not.... ah, the joys of vi.
----------------------------------------------------------------------------
Say what you mean, and mean what you say, and hear what is meant to be said.
Lewis Carroll + Webb's corrolary
----------------------------------------------------------------------------
Andy Webb - currently stancil@ccwf.cc.utexas.edualtman@sbstaff2.cs.sunysb.edu (Jeff Altman) (07/20/90)
The Ctrl-D's are necessary for printing Postscript from DOS to printers such as the Laserwriter and HP LJets with the Pacific Page Postscript cartridges. They only get in the way when printing Postscript on Non-DOS machines. Maybe an option should be placed as to whether or not the Ctrl-Ds should be sent, however, as it stands I would hate it greatly if the Ctrl-D's were removed since it would cause a large amount of confusion for those simple folks who only use DOS and need to print Postscript. Most programs (such as Corel Draw) state that when printing to a File in order to send it to a Professional printer for printing that the Ctrl-D's must be removed. My suggestion would be to write a short Unix filter (maybe with AWK) that would strip the control D's from your files and then send it to lpr. - Jeff (jaltman@ccmail.sunysb.edu)
chrisg@microsoft.UUCP (Chris GUZAK) (07/20/90)
In article <34226@ut-emx.UUCP> stancil@walt.cc.utexas.edu (Glen Stancil) writes: >After much wasted upload time and senseless agravation, we discovered that >the Windows (2.1 in our case) postscript driver puts a CTRL-D at the top >and bottom of all files printed "to file". By editing out these two >characters, the files printed successfully. The environment is a PS/2 >---flame on >If Microsoft could get rid of the (&)^( CTRL-D's, the world would be a >much safer place. >---flame off > The windows postscript driver generates printer dependant code. It is intended to be sent straight to a particular printer. This is so we can support printer dependant features like different paper sizes, input sources, and resolutions. Most PS printers require the ^D to terminate the job, without it they won't print. If you want to generate printer indpendant code, use the "Print to EPS File" option in the win3 driver. NOTE! this is not the same as printing to a FILE:. The output generated does not contain printer dependant code (well, not very much) and may not print without putting a ^D at the end. If you intend to pipe your printer output through an OS that thinks ^D means end of file you will have to add a filter. >Say what you mean, and mean what you say, and hear what is meant to be said. > Lewis Carroll + Webb's corrolary >---------------------------------------------------------------------------- >Andy Webb - currently stancil@ccwf.cc.utexas.edu
delahunt@adobe.COM (Jim DeLaHunt) (07/20/90)
This discussion on %! and control-D in PostScript(R) language files perpetuated some common misconceptions; I'd like to clear them up. I hope David Sampson will forgive me for picking on his message. In article <DSAMPSON.90Jul16111525@x102a.harris-atd.com> dsampson@x102a.harris-atd.com (sampson david 58163) writes: >In article <4995@milton.u.washington.edu> >markad@blake.u.washington.edu (Mark Donnell) writes: > >>1) I am trying to print the output from WinWord on a remote NeXT >>printer. I print to a file.... >>I try printing it with 'lpr text.eps' - it spools, then dissapears.... > >Mark -- The next time you print to a file with the windows postscript >driver, take a look at the result. The first line in the file will >have something like this (without the quotes) "^D%! Adobe 2.0". >The problem is that ^D as the 1st character. This much is correct. > The Apple printers want >to see the %! as the 1st two characters in a postscript file... >The %! tells the printer "Postscript commin' at ya". The ^D in >front of that signal confuses the printer. It doesn't properly parse >the line. I believe that ^D is an attempt to force a top of page >(i.e. kicks out a sheet). This is a common misconception. In fact, the ^D byte ($04) is a protocol used by the serial and Centronics drivers in many PostScript printers, and it means "end of job". Other communications methods may have out-of-band ways of conveying the same information: e.g. AppleTalk has an out-of-band "end of job" signal and so does not intercept ^D bytes in the input stream. The "%!" is a convention which means "this is a PostScript language program", rather than text, or PCL, or whatever. It conforms nicely to the Un*x convention that the first two bytes of the file tell how to handle it -- remember "#!/bin/sh"? Since "%!" starts with "%", it is a PostScript comment, and the PostScript interpreter ignores it. (There are other conventions; ask Adobe Developer Support for the Document Structuring Conventions spec.) The standard Windows PostScript language driver, mixing protocol and page description, emits a page description with ^D bytes before and after it. If you send this stream to a printer via a serial or parallel port, the printer's RS232C or Centronics drivers interpret the initial ^D as the end of a (null) job and remove it from the input stream. The following bytes are the next job. The drivers interpret the final ^D byte as an end-of-job signal, remove it from the input stream, and pass the end-of-job signal to the interpreter. The interpreter reverts to its initial state and waits for the next job. If you intercept the Windows driver's stream into a file, and print it with the NeXT's 'lpr', it is sent to the Display PostScript interpreter via a NeXT-internal method, with an out-of-band protocol for end-of-job signals. (The same problem arises if your Un*x box sends the file to a printer via AppleTalk.) The ^D bytes have no special meaning, so they are passed to the interpreter. The interpreter treats the initial ^D byte as an undefined PostScript name, and flushes the job with an error. However, David came up with exactly the right workaround: >I wrote a simple program in C to filter the Control-D out of the file. >So my procedure for printing to a remote printer is as follows: > >1) Print to a file using the postscript driver from whatever windows >application you're in > >2) Exit windows and filter out that ^D > >3) Issue the lpr filename command command to the remote printer. I hope this explanation is helpful. >David Sampson Harris Corporation >dsampson@x102a.ess.harris.com Gov't Aerospace Systems Divison >uunet!x102a!dsampson Melbourne, Florida --Jim DeLaHunt delahunt@adobe.com (Internet) Technical Support ...!{sun,apple,decwrl}!adobe!delahunt (UUCP) Adobe Systems Inc. +1-415-962-3790 (Phone) +1-415-961-3769 (Fax)