rmontjoy@uceng.UC.EDU (sun god) (03/04/91)
Hi. Does anyone have a program that can tell if a file is not postscript and put it in postscript(assuming the original file was ascii). If not is just checking for %! good enough to ensure a postscript file? thanks. Rob Montjoy - Rob.Montjoy@UC.Edu Computer Engineer - montjoy@ucbeh.BITNET University of Cincinnati - montjoy@babbage.ece.uc.edu Electrical and Computer Enginering - uunet!uceng!rmontjoy
d89mb@efd.lth.se (Magnus Bodin) (03/04/91)
A file to be accepted by a laser-writer must start with
%!
at the first line.
Just testing that will do. But that depends on what you're gonna use
the information for... But files not starting with '%!' won't be accepted
by PostScript-printers as PostScript, at least not apple's...
Takelr|,
--
Magnus Bodin "Nec fasces, nec opes,
Institute of Tychology, sola artis sceptra perennant"
Box 5127, 220 05 Sweden (Tycho Brahe, Stj{rneborg 1584)bruce@watnxt2.ucr.edu (Ahmon Dancy) (03/05/91)
Well, after about 2 years of half-heartedly trying to figure it out without asking, I will now give up. I don't know if this is a really dumb question but.. What the HELL is postscript? I've heard lots of stuff about it but I could never really understand 'what' it is. Assistance is appreciated. BRUCE!
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (03/05/91)
In article <1991Mar4.075212.12828@lth.se>, d89mb@efd.lth.se (Magnus Bodin) writes: > > A file to be accepted by a laser-writer must start with > %! > > at the first line. > > Just testing that will do. But that depends on what you're gonna use This is just plain not so. The % is a comment. The interpreter will just ignore this line. NONE of my files use the %!. It is merely a commenting structure having to do with EPS. (Encapsulated postscript). Some SPOOLERS like to see it, but the printer its self could give a rats hind end about it. EPS has been defined by Adobe, but it has wound up being a real rats nest of complexity. This application can't interpret that applications eps file and vise-versa. In my opion it is highly over-rated and quite useless. But then again I don't use my postscript printer as an output device for canned programs much, except for Pagemaker, Microsoft word, and Arts & letters, none of the literaly thousands of programs (well over 300 disks full) that I have support Postscript so EPS really is no big deal for me. I have rarely derived any benifit from it, though I suppose that if I were importing postscript files it might have some. Actualy the only thing that normally affects anything is the bounding box line. Cheers Woody
d89mb@efd.lth.se (Magnus Bodin) (03/05/91)
PostScript is a page-descriptive computer language that are used in an increasing number of laser-writers. It would be too awkward if all word-processors, drawing and page-making programs sent out a 300dpi gigant bitmap to the laserwriter, so therefore the printer accepts commands in a more intelligent way --- In PostScript. PostScript is a post-fix language that is created by Adobe inc. and laser- writer-developers have to pay Adobe for using this language-interpreter. That's why PostScript-writers are more expensive than e.g. LaserJets. Example of PostScript-program: %! % % comments starts with %, and the first line must start with '%!' % % /Times-Roman findfont % find font in dictionary 30 scalefont % Rescale it to 30 point-height (1 point= 1/72 inch) setfont % Setfont 100 100 moveto % Move to 100,100 (0,0 is bottom left) (Hejsan vaerlden!) show % Type the string "Hejsan vaerlden!" to the right.. showpage % Print the page on a paper. ---- cut here ---- That's it! Yes, there are of course several more commands and instructions... You can define your own fonts, procedures and functions, and do very complex drawing in this language. Takelr|, Magnus
jgreely@morganucodon.cis.ohio-state.edu (J Greely) (03/05/91)
In article <1894@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: >NONE of my files use the %!. It is merely a commenting >structure having to do with EPS. (Encapsulated postscript). You're either oversimplifying for this novice, or you've never learned the difference between the Document Structuring Conventions and the Encapsulated PostScript specifications. "%!" is a magic cookie that identifies any PostScript file, usually for the convenience of a spooler (even if you don't need it, it's nice to put it in if you distribute your PostScript code). The stricter form "%!PS-Adobe-a.b" claims conformance with version a.b of the DSC, and the bondage-and-discipline form "%!PS-Adobe-a.b EPSF-c.d" claims that it conforms to the stricter rules of version c.d of the EPS specifications. All in the name of clarity, of course. Both of them are quite useful to anyone who doesn't live in a single-user world, or makes regular use of good text-processing software. Try making an arbitrary PS file print out two-up, double-sided, in signature order. >EPS has been defined by Adobe, but it has wound up being a real rats nest >of complexity. Nope. The specifications (both DSC and EPS) are pretty clear. Each revision is better than the previous one, and usually special-cases common mistakes that have found their way into the marketplace. The problem is usually programs that generate bad code and refuse to accept anything that isn't broken the same way. -- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)
brown@vidiot.UUCP (Vidiot) (03/06/91)
In article <1894@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: <In article <1991Mar4.075212.12828@lth.se>, d89mb@efd.lth.se (Magnus Bodin) writes: <> <> A file to be accepted by a laser-writer must start with <> %! <> <> at the first line. <> <> Just testing that will do. But that depends on what you're gonna use < <This is just plain not so. The % is a comment. The interpreter will just <ignore this line. NONE of my files use the %!. It is merely a commenting <structure having to do with EPS. (Encapsulated postscript). Some SPOOLERS <like to see it, but the printer its self could give a rats hind end about it. <EPS has been defined by Adobe, but it has wound up being a real rats nest <of complexity. This application can't interpret that applications eps <file and vise-versa. In my opion it is highly over-rated and quite <useless. But then again I don't use my postscript printer as an output <device for canned programs much, except for Pagemaker, Microsoft word, <and Arts & letters, none of the literaly thousands of programs (well over <300 disks full) that I have support Postscript so EPS really is no <big deal for me. I have rarely derived any benifit from it, though I suppose <that if I were importing postscript files it might have some. Actualy <the only thing that normally affects anything is the bounding box line. Not quite. The %! on the first line is required by the LaserWriter printers and compatibles. It is NOT part of the definition for EPSF or EPSI. If that special comment line is missing, the LaserWriter series printers will change to Diablo emulation mode and the PostScript program will print out as a source listing, i.e., the PostScript code will print as normal text and the program will not run. -- harvard\ att!nicmad\ spool.cs.wisc.edu!astroatc!vidiot!brown Vidiot ucbvax!uwvax..........!astroatc!vidiot!brown rutgers/ decvax!nicmad/ INTERNET:vidiot!brown%astroatc@spool.cs.wisc.edu
glenn@heaven.woodside.ca.us (Glenn Reid) (03/06/91)
> In article <1991Mar4.075212.12828@lth.se>, d89mb@efd.lth.se (Magnus Bodin) writes: > > > > A file to be accepted by a laser-writer must start with > > %! In article <1894@chinacat.Unicom.COM> (Woody Baker @ Eagle Signal) replies: > This is just plain not so. The % is a comment. The interpreter will just > ignore this line. NONE of my files use the %!. It is merely a commenting > structure having to do with EPS. (Encapsulated postscript). Some SPOOLERS > like to see it, but the printer its self could give a rats hind end about it. > EPS has been defined by Adobe, but it has wound up being a real rats nest > of complexity. This application can't interpret that applications eps > file and vise-versa. In my opion it is highly over-rated and quite > useless. Woody, I wasn't sure we could count on you for many more myopic postings, but I'm glad to see that you're still healthy and well. Your world view is firmly entrenched in having your own PC, your own printer, and home-brew PostScript. The original poster wanted to know how to identify a PostScript program so it could be routed, by the spooler, in an appropriate manner. You point out that the comments are "over-rated and quite useless." However, this is exactly the situation under which they are quite useful, and it happens to be a very common scenario among folks who have networks, more than one computer, more than one kind of printer, and so forth. You are right that the printer doesn't require %! to accept it as a PostScript file, and you're right that it's a spooling convention. You are not right, however, in omitting these conventions from your files out of spite (it makes them much more non-portable), and you are not right for condemning conventions just because you don't happen to need them for anything.\ It should be pointed out that I have, in the past, had a hand in designing these conventions, and therefore I am somewhat partial toward them, but we did not invent the *need* for these conventions, only a syntax for solving real-world, multi-computer problems such as the one faced by the original poster. > But then again I don't use my postscript printer as an output > device for canned programs much, except for Pagemaker, Microsoft word, > and Arts & letters, none of the literaly thousands of programs (well over > 300 disks full) that I have support Postscript so EPS really is no > big deal for me. Perhaps the reason your thousands of programs don't support PostScript is because you haven't upgraded them in the last five years, while this revolution took place? Just a guess. All of the major (and even minor) PC software that has support for printing at all has support for PostScript. EPS is real, it is useful, and you might as well get used to it. Open up your favorite PC magazine and look for clip art, and see how many of them don't support EPS format. > I have rarely derived any benifit from it Therefore it is useless for everyone else, and should not be used by anyone. In fact, it's a good idea to post to a public forum and tell everyone how much you, personally, dislike it. In fairness, DOS is a standard, and lots of people post to worldwide forums about how much they dislike it. But they don't recommend not using an operating system at all, they recommend using something better, which you haven't done. -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us NeXT/PostScript developers ..{adobe,next}!heaven!glenn 415-851-1785 (fax 851-1470)
glenn@heaven.woodside.ca.us (Glenn Reid) (03/07/91)
In article <1448@vidiot.UUCP> brown@vidiot.UUCP (Vidiot) writes: > Not quite. The %! on the first line is required by the LaserWriter printers > and compatibles. It is NOT part of the definition for EPSF or EPSI. If that > special comment line is missing, the LaserWriter series printers will change > to Diablo emulation mode and the PostScript program will print out as a source > listing, i.e., the PostScript code will print as normal text and the program > will not run. Wow. Are you sure? This is certainly not the case with my LaserWriter II NTX (Version 47.0). I can appreciate that I don't have the newest or most wonderful LaserWriter, but I'd be surprised if recognition of %! were built into the printer itself. Are you sure it's not the print spooler that's recognizing %! and filtering it to text (lpr) mode? If you're running TranScript, TranScript does indeed do this at the spooling level. -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us NeXT/PostScript developers ..{adobe,next}!heaven!glenn 415-851-1785 (fax 851-1470)
jj1h+@andrew.cmu.edu (Joseph Jackson) (03/07/91)
Excerpts from netnews.comp.lang.postscript: 6-Mar-91 Re: How can I tell if a fil.. Vidiot@vidiot.UUCP (2017) > Not quite. The %! on the first line is required by the LaserWriter > printers and compatibles. It is NOT part of the definition for EPSF or > EPSI. If that special comment line is missing, the LaserWriter series > printers will change to Diablo emulation mode and the PostScript program > will print out as a source listing, i.e., the PostScript code will print > as normal text and the program will not run. No, really. It's just a comment to the LaserWriter. Trust me! I use kermit to have close and personal conversations with my LaserWriters all the time and never bother typing in the PostScript magic characters. What you are most likely seeing is the effect of some nice spooling software. Many spoolers will wrap non-PostScript files with a simple PostScript program which causes the file to be shown line-by-line on the page (as though you were using a very slow and expensive line printer. ;-) What kind of system are you using? How are your printers attached? If you do have some way of getting your PostScript engine to perform automatic mode changing, I'd be interested in learning more about it. How is the printer changed from Diablo emulation mode back to the normal PostScript interpreter? How does it know that the Diablo document is finished printing? Perhaps the mode switching is a feature of some custom PostScript interpreter which must be downloaded to the printer every time it is powered up? Joe Jackson Distributed Workstation Services Carnegie Mellon University Internet: jj1h+@andrew.cmu.edu Bitnet: jj1h+@ANDREW AT&Tnet: (412) 268-8799
henry@angel.Eng.Sun.COM (Henry McGilton) (03/07/91)
In article <1448@vidiot.UUCP>, brown@vidiot.UUCP (Vidiot) writes:
* %! on the first line is required by LaserWriter printers and compatibles.
In my opinion, this statement is false. The %! serves to identify
a file as PostScript to utilities such as the UNIX file command,
and for utility packages such as TranScript to do the Correct Thing
with the file. To the very best of my knowledge, %! is a
PostScript comment that is ignored by the printer's PostScript
interpreter. I am willing to admit I am wrong if somebody out there
can come up with a definitive test case to prove otherwise.
* It is NOT part of the definition for EPSF or EPSI.
From Encapsulated PostScript File Format--Version 3.0, section 2.1:
The two required DSC Header comments are:
%!PS-Adobe-3.0 EPSF-3.0
%%BoundingBox: llx lly urx ury
* If that special comment line is missing, the LaserWriter series
* printers will change to Diablo emulation mode and the PostScript
* program will print out as a source listing, i.e., the PostScript
* code will print as normal text and the program will not run.
TranScript software makes the decision to print a PostScript lacking
%! as simple text via a program called pstext which sends the
contents of the text file to the printer in 11-point Courier.
TranScript DOES NOT switch the printer to Diablo emulation mode.
........ Henrybrown@vidiot.UUCP (Vidiot) (03/08/91)
In article <449@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) writes: <In article <1448@vidiot.UUCP> brown@vidiot.UUCP (Vidiot) writes: <> Not quite. The %! on the first line is required by the LaserWriter printers <> and compatibles. It is NOT part of the definition for EPSF or EPSI. If that <> special comment line is missing, the LaserWriter series printers will change <> to Diablo emulation mode and the PostScript program will print out as a <source <> listing, i.e., the PostScript code will print as normal text and the program <> will not run. < <Wow. Are you sure? This is certainly not the case with my LaserWriter <II NTX (Version 47.0). I can appreciate that I don't have the newest or most <wonderful LaserWriter, but I'd be surprised if recognition of %! were built <into the printer itself. Are you sure it's not the print spooler that's <recognizing %! and filtering it to text (lpr) mode? If you're running <TranScript, TranScript does indeed do this at the spooling level. Two of us looked at the TranScript spooler and neither of us saw anything that the filters did that made it run enscript (or whatever) to turn text into PostScript. So, that left the printer doing the work. But, if the printer doesn't do the work, then what piece of TranScript is doing the work. Sorry about the misleading info. -- harvard\ att!nicmad\ spool.cs.wisc.edu!astroatc!vidiot!brown Vidiot ucbvax!uwvax..........!astroatc!vidiot!brown rutgers/ decvax!nicmad/ INTERNET:vidiot!brown%astroatc@spool.cs.wisc.edu
brown@vidiot.UUCP (Vidiot) (03/08/91)
In article <487@appserv.Eng.Sun.COM> henry@angel.Eng.Sun.COM (Henry McGilton) writes: <In article <1448@vidiot.UUCP>, brown@vidiot.UUCP (Vidiot) writes: < < * %! on the first line is required by LaserWriter printers and compatibles. <In my opinion, this statement is false. The %! serves to identify <a file as PostScript to utilities such as the UNIX file command, <and for utility packages such as TranScript to do the Correct Thing <with the file. To the very best of my knowledge, %! is a <PostScript comment that is ignored by the printer's PostScript <interpreter. I am willing to admit I am wrong if somebody out there <can come up with a definitive test case to prove otherwise. See previous posting. < * It is NOT part of the definition for EPSF or EPSI. Sorry, I should have added more to that statement. The %! by itself is not part of EPSF ot EPSI. <From Encapsulated PostScript File Format--Version 3.0, section 2.1: < < The two required DSC Header comments are: < %!PS-Adobe-3.0 EPSF-3.0 < %%BoundingBox: llx lly urx ury But, as you point out here, the %! with the rest of the line is. I should have said that it takes more than just %! for these formats. I knew that, but I just didn't say that. < * If that special comment line is missing, the LaserWriter series < * printers will change to Diablo emulation mode and the PostScript < * program will print out as a source listing, i.e., the PostScript < * code will print as normal text and the program will not run. <TranScript software makes the decision to print a PostScript lacking <%! as simple text via a program called pstext which sends the <contents of the text file to the printer in 11-point Courier. <TranScript DOES NOT switch the printer to Diablo emulation mode. I don't have the source on this system, the other person has TranScript source. So, he missed how it worked and I was miss-informed. I guess that I should have read the TranScript(8) man page, as it does tell all. I should have known better :-( -- harvard\ att!nicmad\ spool.cs.wisc.edu!astroatc!vidiot!brown Vidiot ucbvax!uwvax..........!astroatc!vidiot!brown rutgers/ decvax!nicmad/ INTERNET:vidiot!brown%astroatc@spool.cs.wisc.edu
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (03/08/91)
In article <1448@vidiot.UUCP>, brown@vidiot.UUCP (Vidiot) writes: > In article <1894@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) writes: > <In article <1991Mar4.075212.12828@lth.se>, d89mb@efd.lth.se (Magnus Bodin) writes: > > Not quite. The %! on the first line is required by the LaserWriter printers > and compatibles. It is NOT part of the definition for EPSF or EPSI. If that > special comment line is missing, the LaserWriter series printers will change > to Diablo emulation mode and the PostScript program will print out as a source Just which printers? I think that you are getting the MAC printing software confused with the printer. Every laser that I've ever seen could care less about comment lines. The PS-410 might well key off of those, in it's auto switching, but that is not altogether the only way to recognize PS code. Not having a PS-410 I can't verify this, but having worked with several Apple printers, I have never seen this behavior. Cheers Woody
halliday@van-bc.wimsey.bc.ca (Laura Halliday) (03/08/91)
With all the discussion of %! and friends, the original question, i.e. can you look at a file and tell if it's PostScript or not, appears to have gotten lost in the shuffle. Document Structuring comments notwithstanding, the problem is that PostScript is a language that was designed to be interpreted, and thus has rich operators and simplistic syntax. It's a lot easier to look for syntax than for vocabulary. Hence the problem. I went through this issue in another forum where somebody wanted to make a system that you could mail files to, and it would decide how to print them. The decision was to look for %!, and if it was there, print as PostScript. If not, make a few tests (e.g. look for parentheses) and if these tests were inconclusive, try printing as PostScript anyway to avoid producing reams of paper covered with gibberish if you guessed wrong. Oh yes - and fire the next person who writes an application that generates PostScript output that doesn't conform to the Document Structuring Conventions. ...laura
rsmith@well.sf.ca.us (Ross Smith) (03/09/91)
glenn@heaven.woodside.ca.us (Glenn Reid) writes: >> In article <1991Mar4.075212.12828@lth.se>, d89mb@efd.lth.se (Magnus Bodin) >writes: >> > >> > A file to be accepted by a laser-writer must start with >> > %! >manner. You point out that the comments are "over-rated and quite useless." >However, this is exactly the situation under which they are quite useful, >and it happens to be a very common scenario among folks who have networks, >more than one computer, more than one kind of printer, and so forth. The QMS PS-410 automatically senses if the print job is PostScript, HP PCL, or HP-GL. One of the ways (but not the only way) that it senses a PostScript print job is if the print job begins with a %!. As this auto-sensing ability will become more common in the future we should all now begin our PostScript files with %!, even if it isn't an EPS file. -- Ross Smith rsmith@well.sf.ca.us {apple,pacbell,hplabs,ucbvax}!well!rsmith
glenn@heaven.woodside.ca.us (Glenn Reid) (03/10/91)
In article <1460@vidiot.UUCP> brown@vidiot.UUCP (Vidiot) writes: > Two of us looked at the TranScript spooler and neither of us saw > anything that the filters did that made it run enscript (or whatever) > to turn text into PostScript. So, that left the printer doing the > work. But, if the printer doesn't do the work, then what piece of > TranScript is doing the work? The "pscomm" filter looks for this flag, and if it's not there, it filters the file through "pstext", which is a simplistic version of "enscript". Read the man page for "pscomm" for more details. I would quote it here, but it's copyrighted, and would bore too many people, besides :) -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us NeXT/PostScript developers ..{adobe,next}!heaven!glenn 415-851-1785 (fax 851-1470)
jj1h+@andrew.cmu.edu (Joseph Jackson) (03/12/91)
Excerpts from netnews.comp.lang.postscript: 7-Mar-91 Re: How can I tell if a fil.. Vidiot@vidiot.UUCP (1572) > Two of us looked at the TranScript spooler and neither of us saw anything that > the filters did that made it run enscript (or whatever) to turn text into > PostScript. So, that left the printer doing the work. But, if the printer > doesn't do the work, then what piece of TranScript is doing the work. Yeah, it's a rather hidden feature. The lpd sends the print job through all the necessary filters and as a last step calls "pscomm" to pipe the output over the serial line to the printer. "pscomm" has some intelligence built in to it which isn't obvious. "pscomm" looks at the first few bytes of the input stream looking for the "%!" PostScript magic. If it doesn't find it, it will call "enscript" to convert the (assumedly text) file to PostScript. You can change what program is called by setting the PSTEXT variable in the .options file which is located in the spool directory for the given queue. Here's one way of looking at it: this feature provides some degree of compatibility with the old days of simple line printers. Think of how many things would break if you suddenly needed to specify an lpr switch when queuing straight text. Things like "ls | lpr" wouldn't work any more. Another feature allows TranScript to handle both face-up and face-down printers. "pscomm" can be configured to call a page reversal filter for selected printers. It uses the same "psrev" command which is normally made available to users. At my site, reversal is the default. For newer page-up printers, I add the line "REVERSE=" to the associated .options file to avoid unnecessary page reversal. Check out the file psint.sh for more details on .options file. In normal TranScript installations, all of the filters listed in the printcap are actually hard-links to psint.sh. That script invokes the .options file. Joe Jackson Distributed Workstation Services Carnegie Mellon University Internet: jj1h+@andrew.cmu.edu Bitnet: jj1h+@ANDREW AT&Tnet: (412) 268-8799
ken@csis.dit.csiro.au (Ken Yap) (03/12/91)
As a side note, there are some PS interpreters that understand structured comments. A case in point is the Dataproducts 1260. How do I know? When an area larger than A4 was specified for the bounding box, a bug in the interpreter was tickled and characters came out 2x tall. I was most annoyed. However the leading %! is noted by the print filter or spooler in all the systems I know.
kaufman@eecs.nwu.edu (Michael L. Kaufman) (03/12/91)
Something that has been bothering me is what happens if you want to print out
a postscript file as straight text. I mean if you want to view the postscript
source. Most of these automatic solutions will force you to pipe your file
through something if you don't want anything to happen. Kind of ironic.
Michael
--
Michael Kaufman | I've seen things you people wouldn't believe. Attack ships on
kaufman | fire off the shoulder of Orion. I watched C-beams glitter in
@eecs.nwu.edu | the dark near the Tannhauser gate. All those moments will be
| lost in time - like tears in rain. Time to die. Roy Batty glenn@heaven.woodside.ca.us (Glenn Reid) (03/12/91)
A couple of very minor details, for the curious and intrepid: In article <Qbr2bdK00VQs40k49S@andrew.cmu.edu> jj1h+@andrew.cmu.edu (Joseph Jackson) writes: > "pscomm" looks at the first few bytes of the input stream looking for > the "%!" PostScript magic. If it doesn't find it, it will call > "enscript" to convert the (assumedly text) file to PostScript. You can > change what program is called by setting the PSTEXT variable in the > .options file which is located in the spool directory for the given > queue. > > Another feature allows TranScript to handle both face-up and face-down > printers. "pscomm" can be configured to call a page reversal filter for > selected printers. It uses the same "psrev" command which is normally > made available to users. This is almost right, with the caveat that "pscomm" does not call "enscript" and "psrev", it calls special-purpose (and less-fully-featured) similar programs called "pstext" and "psrv", respectively. See the man page for "pscomm" for more details. -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us NeXT/PostScript developers ..{adobe,next}!heaven!glenn 415-851-1785 (fax 851-1470)
tfabian@falcon.lerc.nasa.gov (Teddy Fabian) (03/13/91)
In article <487@appserv.Eng.Sun.COM> henry@angel.Eng.Sun.COM (Henry McGilton) writes: >In article <1448@vidiot.UUCP>, brown@vidiot.UUCP (Vidiot) writes: > > * %! on the first line is required by LaserWriter printers and compatibles. >In my opinion, this statement is false. The %! serves to identify >a file as PostScript to utilities such as the UNIX file command, >and for utility packages such as TranScript to do the Correct Thing >with the file. To the very best of my knowledge, %! is a >PostScript comment that is ignored by the printer's PostScript >interpreter. I am willing to admit I am wrong if somebody out there >can come up with a definitive test case to prove otherwise. > based on what was taught at the Intro and Advanced Postscript classes last week in Burlington Mass. at the Adobe office there, I agree with you.. the %! is ignored by the interpreter.. it's a simple comment.. > * It is NOT part of the definition for EPSF or EPSI. >From Encapsulated PostScript File Format--Version 3.0, section 2.1: > > The two required DSC Header comments are: > %!PS-Adobe-3.0 EPSF-3.0 > %%BoundingBox: llx lly urx ury this was confirmed in the class as well... these statements define the page area to other application packages that may want to "grab" the EPS file for use as an insert... or more directly, they define the boundries on the page that'll be used by the EPS file if it's included... > > * If that special comment line is missing, the LaserWriter series > * printers will change to Diablo emulation mode and the PostScript > * program will print out as a source listing, i.e., the PostScript > * code will print as normal text and the program will not run. no idea about this since we don't have LaserWriters... however, I tend to think that the printer would not be intellegent enough to determine what format the file is in... >TranScript software makes the decision to print a PostScript lacking >%! as simple text via a program called pstext which sends the >contents of the text file to the printer in 11-point Courier. >TranScript DOES NOT switch the printer to Diablo emulation mode. no comment. > > ........ Henry ---------------------------------------------------- Thanks, Ted Fabian NASA Lewis Research Center tfabian@falcon.lerc.nasa.gov *my opinions tfabian@mars.lerc.nasa.gov *are my own.. -- ---------------------------------------------------- Thanks, Ted Fabian NASA Lewis Research Center tfabian@falcon.lerc.nasa.gov *my opinions tfabian@mars.lerc.nasa.gov *are my own..
anw@maths.nott.ac.uk (Dr A. N. Walker) (03/14/91)
In article <Qbr2bdK00VQs40k49S@andrew.cmu.edu> jj1h+@andrew.cmu.edu (Joseph Jackson) writes: >"pscomm" looks at the first few bytes of the input stream looking for >the "%!" PostScript magic. If it doesn't find it, it will call >"enscript" to convert the (assumedly text) file to PostScript. Just so. What leaves me feeling slightly uneasy about this is that I now have to do something special to *list* a PS file. If file A contains a Pascal (say) program, and B contains a PostScript "program", then "lpr A" will list the Pascal, but "lpr B" will *obey* the PostScript. > this feature provides some degree of >compatibility with the old days of simple line printers. Think of how >many things would break if you suddenly needed to specify an lpr switch >when queuing straight text. Just so. Now think how many things break if "lpr B" lists B if the printer is a simple lineprinter but produces a fancy graphic if we upgrade it to a LaserWriter. What's more, there is a similar potential problem with every different printer language. We could find ourselves with 10 different printers on our network, each with a different [or, worse, the same] magic marker, so that all sorts of files must be "enscripted" by one of 10 different programs to print on some printers, and must not be to print on all the others. I don't know if there's a complete answer. Here, we simply shovel whatever comes to the LW spooler direct to the LW, and it's hard cheddar if it isn't PS (at least it usually fails quickly). If people want listings, they have to call an ASCII -> PS program. Since this can be packaged up into a short command, there's no hardship in practice. Indeed, there's an advantage in that the command can do clever things (like printing many lines per page) automatically, with no alteration to the spooler, which makes it easier to divert output to remote printers when necessary. Very few of our users ever call "lpr" directly any more -- I do it perhaps once a month, the rest of the time working through the packaged commands. -- Andy Walker, Maths Dept., Nott'm Univ., UK. anw@maths.nott.ac.uk
pjnesser@mbunix.mitre.org (Nesser) (03/14/91)
Does anyone have a program that can tell if a file is not postscript
and put it in postscript(assuming the original file was ascii). If not
is just checking for %! good enough to ensure a postscript file?
thanks.
Rob Montjoy - Rob.Montjoy@UC.Edu
Computer Engineer - montjoy@ucbeh.BITNET
University of Cincinnati - montjoy@babbage.ece.uc.edu
Electrical and Computer Enginering - uunet!uceng!rmontjoy
I have just plowed through about 30 messages about the PS format etc, yet
no one has attempted to answer the question or at least posted anything.
So here is a bit of an answer, it may not be completely correct but it
works for me (so far).
To translate some text to ps there are a good number of PD things that you
can get from uunet.uu.net in the comp.sources.{misc,unix} archives or you
can buy the transcript software(I don't remember who makes it off hand but
I could dig it up). Here is a bit of a shell hack which has always been
able to distinguish(sp?) .ps files for me:
set PS = `grep -n "%\\!" $k | awk '{print substr($1,1,4)}'`
if ($PS =~ "1:%\!") then
set POSTSCRIPT = "yes"
else
set POSTSCRIPT = "no"
endif
and if anyone see something that will cause it to break please let me know.
---> Phil
--
---> Philip J. Nesser
Member of the Technical Staff
The MITRE Corporation
ARPA: pjnesser@mbunix.mitre.org
UUCP: ...!mit-eddie!pjnesserken@csis.dit.csiro.au (Ken Yap) (03/14/91)
Along similar lines, I once saw a line printer listing of 100 pages of PS output. It was an accident (the user forgot the -P or $PRINTER in BSD lpr).
robmack@ii.uib.no (Robert MacKinnon ) (03/14/91)
In article <1991Mar13.160331.25024@maths.nott.ac.uk> anw@maths.nott.ac.uk (Dr A. N. Walker) writes: > I don't know if there's a complete answer. Here, we simply >shovel whatever comes to the LW spooler direct to the LW, and it's >hard cheddar if it isn't PS (at least it usually fails quickly). >If people want listings, they have to call an ASCII -> PS program. We're running IBM RISC System/6000's here at BSC. They have the ability to define 'virtual' printers. The solution for us is to define two virtual printer queues each for our LW and QMS printers. One queue, ps<whatever>, will take PostScript, interpret it and printout the graphic. The other queue, lp<whatever>, will take any input, call pstext from TranScript and print the input as a text stream. If a user were to submit PostScript to ps1 for instance, the PostScript would be interpreted and their graphic image would result. If they submit the same PostScript to lp1, a listing of the PostScript code results. The effect of the virtual queues is consistent and predictable. The users seem to like it as well. > Robert MacKinnon Bergen Scientific Centre Bergen Norway.
richard@pegasus.com (Richard Foulk) (03/14/91)
> >The QMS PS-410 automatically senses if the print job is PostScript, HP PCL, >or HP-GL. One of the ways (but not the only way) that it senses a PostScript >print job is if the print job begins with a %!. As this auto-sensing >ability will become more common in the future we should all now begin our >PostScript files with %!, even if it isn't an EPS file. > Is the algorithm that the PS-410 uses to select between the various formats documented? (I think it also switches to Diablo emulation when presented with ASCII text.) Sounds like a bit of a job to do it reliably. -- Richard Foulk richard@pegasus.com
glenn@heaven.woodside.ca.us (Glenn Reid) (03/15/91)
In article <1991Mar14.045607.948@csis.dit.csiro.au> ken@csis.dit.csiro.au (Ken Yap) writes: > Along similar lines, I once saw a line printer listing of 100 pages of > PS output. It was an accident (the user forgot the -P or $PRINTER in > BSD lpr). I have seen this happen (by similar accident) on a phototypesetter at high resolution, generating maybe fifty pages of program listing in Courier at 2540 dots per inch, instead of the one page of nice graphic output. I think it might have been a result of some font-proofing software I was writing in which I forgot the initial %! That's the kind of thing you forget only once. Actually, I vaguely remember TranScript getting an option added to it to deal with things like typesetters where you NEVER want the program listed in Courier. Maybe it was the $PSTEXT environment variable, so you could at least do the null filtering operation rather than convert it to text for listing. Gee, this has really become a tangent, hasn't it? I like it when that happens.... Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us NeXT/PostScript developers ..{adobe,next}!heaven!glenn 415-851-1785 (fax 851-1470)
des@frogland.inmos.co.uk (David Shepherd) (03/15/91)
In article <1991Mar13.160331.25024@maths.nott.ac.uk>, anw@maths.nott.ac.uk (Dr A. N. Walker) writes: > Just so. Now think how many things break if "lpr B" lists B > if the printer is a simple lineprinter but produces a fancy graphic > if we upgrade it to a LaserWriter. > > What's more, there is a similar potential problem with every > different printer language. We could find ourselves with 10 different > printers on our network, each with a different [or, worse, the same] > magic marker, so that all sorts of files must be "enscripted" by one > of 10 different programs to print on some printers, and must not be > to print on all the others. 1) if two different printer languages use the same "magic marker" then at least of of the language designers is being pretty dumb and then you're probably stuck. Answer: assume language designers have some intelligence and won't do anything as crass as this. Perhaps you could also assume that one of them will claim infringement on look and feel of their magic marker and let their lawyers sort it out. 2) assuming all printer languages have differnt magic markers your printer filter just needs to identify the files that that printer can print and process it appropiately. If if it can't then either return an error message or mail a message back. If a printer can't handle a file then, probably it was a mistake to send it there! On the system i adminstrate I wrote a filter that can handle PostScript, TeX DVI, troff C/A/T or ASCII text (printable chars only in file). Another system adminstrator here didn't like the restriction on printable chars only is ASCII files so removed it. The result is that occasionally you see his printer struggling to print a binary file! Perhaps we should be seeing lpr in a more <warning: buzzword approaching> object orientated manner. Rather than copying the file to the printer it should be seen as the print action taken from the class of the given file. If you object to files starting with %! being treated different from others that don't, what is your view on executable files that start with #! /bin/sh ????? -- -------------------------------------------------------------------------- david shepherd: des@inmos.co.uk or des@inmos.com tel: 0454-616616 x 529 inmos ltd, 1000 aztec west, almondsbury, bristol, bs12 4sq Leland says, you're going back to Missoula ... MONTANA
clewis@ferret.ocunix.on.ca (Chris Lewis) (03/19/91)
In article <13109@wraxall.inmos.co.uk> des@frogland.inmos.co.uk (David Shepherd) writes: >In article <1991Mar13.160331.25024@maths.nott.ac.uk>, anw@maths.nott.ac.uk (Dr A. N. Walker) writes: >> Just so. Now think how many things break if "lpr B" lists B >> if the printer is a simple lineprinter but produces a fancy graphic >> if we upgrade it to a LaserWriter. On the contrary, I'd suggest that it was no longer broken. >> What's more, there is a similar potential problem with every >> different printer language. We could find ourselves with 10 different >> printers on our network, each with a different [or, worse, the same] >> magic marker, so that all sorts of files must be "enscripted" by one >> of 10 different programs to print on some printers, and must not be >> to print on all the others. A truly smart spooler would figure out what printers are appropriate for a given magic cookie, and route the results there. Otherwise, you're expecting everybody to remember which printers can handle a given format and/or remember lots of obscure options to tell the printer to go into the correct mode. Users want to print in the inherent format of the print file. They don't want to have to remember what format the file is, or what magic contortions they have to go to get it printed properly. Postscript is a special case, in that you *can* list the postscript on a plain ascii printer. But I would contend that someone generating postscript usually doesn't want to see the postscript listing, they want to see the "graphic" that the postscript listing represents. In those rare occasions where the user wants to see the internal language, it makes more sense to expect the user to know how to "convert" it to a another format suitable for viewing. In the case of postscript, it's easy. Run the bare postscript thru "pr" - not only do you get the output nicely paginated with page numbers, the "%!" doesn't even get recognized because it's no longer first in the file. In the more general case, it's even more obvious that this is the correct approach. For example, "DVI" (TeX), C/A/T phototypesetter, ditroff output, GIF's, TIF's, HPPCL etc. These formats are binary. And will blow the brains out of a printer in the "wrong mode". Rather than expecting the user to know *which* printer is the C/A/T, or what magic "lpr" incantations are needed to invoke dvips, it makes a LOT of sense to have the spooler recognize the magic cookies (all of these formats can be easily disambiguated) and "do the right thing". Which might be rejecting them. Or, rerouting to something capable of handling it. Or, knowing what filters to invoke. If the user *really* wants to see these formats themselves, they have to run them through conversion programs of one variety or another (perhaps just "od -c") no matter what format they want out. Fortunately, most of the binary formats will be easily detectable as being non-ascii. ASCII is a special case in that it's one of the few formats without an easily detectable magic cookie, and that occasionally, someone might accidentally trip over some other format's magic cookie. But I suggest that this problem is far less than having to remember all of the options neccessary to print the other multitude of formats a given machine may be able to generate. And finally, any format that has the same magic cookie as another is broken. Period. The "file" program can usually be parameterized to detect what format is being used. (In fact, with later versions of file, you could modify its database to contain the actual command lines neccessary, such as being able to say: eval "`file $printfile` $printfile" >If you object to files starting with %! being treated different from >others that don't, what is your view on executable files that start >with #! /bin/sh ????? More to the point, what about when "file" says: executable (RISC System/6000 V3.1) or object module not stripped Blindly routing it to a printer is stupid. -- Chris Lewis, clewis@ferret.ocunix.on.ca or ...uunet!mitel!cunews!latour!ecicrl!clewis Psroff support: psroff-request@eci386.uucp, or call 613-832-0541 (Canada) (If this message has a ".bitnet" return address, please send me a copy!)
les@chinet.chi.il.us (Leslie Mikesell) (03/20/91)
In article <1991Mar19.052103.9026@ferret.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes: >A truly smart spooler would figure out what printers are appropriate >for a given magic cookie, and route the results there. Otherwise, >you're expecting everybody to remember which printers can handle a given >format and/or remember lots of obscure options to tell the printer to >go into the correct mode. Ah, but the appropriate thing to do with a particular type of data may depend on who sent it and what command line options were given as well. I have DOS users connected to a network so the print jobs are passed off to the unix print spooler. We can connect any of LPT1, LPT2, and/or LPT3 to arbitrary unix processes, but it is just too complicated for the users to (a) make an appropriate device link first, then (b) set their application to use the same device with corresponding output. I ended up writing a front-end program that first tries to identify the input by matching codes found in a "codes" file. Then it looks (in order) for a file for the user, the destination (passed with a -d on the command line), or the default "commands" file, where the name found in the codes lookup is associated with a command to execute to properly print the file. An assortment of command line options for the program and %-escape substitution in the final command expansion allow passing along the original parameters from the DOS spooler if desired. I can post this if anyone else has the same problem. Les Mikesell les@chinet.chi.il.us
anw@maths.nott.ac.uk (Dr A. N. Walker) (03/22/91)
In article <1991Mar19.052103.9026@ferret.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes: [I wrote] >>> Just so. Now think how many things break if "lpr B" lists B >>> if the printer is a simple lineprinter but produces a fancy graphic >>> if we upgrade it to a LaserWriter. > >On the contrary, I'd suggest that it was no longer broken. Bleeah! If you've been listing a project to the lineprinter, as it develops, for weeks, months, years; and you come in one morning to find a shiny new printer in place; and you type "lpr myfile" just as you always used to; and you get an abstract greyish bitmap instead of your listing; where then is the break? >A truly smart spooler would figure out what printers are appropriate >for a given magic cookie, and route the results there. Otherwise, >you're expecting everybody to remember which printers can handle a given >format and/or remember lots of obscure options to tell the printer to >go into the correct mode. But this is backwards from the original problem. Should a file with *no* cookie be cooked automagically? For which printer? Should I have to remember lots of cookies, so that when I have a file which, by chance, starts with a magic cookie for some remote printer, I remember to encapsulate it by hand to that it gets listed locally instead of graphiced [:-)] remotely? Why does anything need to be so smart? *My* files don't usually have the magic cookies -- the cookies are put in by the programs that create the formats, and those programs can equally well direct the results to the appropriate printer [at least as an option]. The spooler should look after just one activity -- shovelling files, correctly sequenced and separated, out to printers [etc]. Serious smarts should be handled by conversion programs (equivalently, by virtual printers). > But I would contend that someone generating postscript >usually doesn't want to see the postscript listing, they want to see >the "graphic" that the postscript listing represents. In those rare >occasions where the user wants to see the internal language, [...] PostScript gets generated two ways -- by program, and by hand. When it is generated by program, you're right. But when I write PS, certainly I want to test it, but I also want to get file listings. >Run the bare postscript thru "pr" - not only do you get the output >nicely paginated with page numbers, the "%!" doesn't even get recognized >because it's no longer first in the file. So: you say "lpr file" to get graphics or some listings, and "pr file | lpr" to get other listings. I say "lpr file" to get graphics, and "list file" to get listings [or I would, except that the actual commands are more mnemonic for our actual devices]. I know which I prefer! >>If you object to files starting with %! being treated different from >>others that don't, what is your view on executable files that start >>with #! /bin/sh ????? I don't much care for it. But I can live with it, recognising it as an efficiency hack for the kernel; note that the actual behaviour (eg on SunOS) is the opposite way round from your spooler. If I try to run a shell script that doesn't begin "#! /bin/sh", it fails, rather than calling up some mythical ensheller. >More to the point, what about when "file" says: > > executable (RISC System/6000 V3.1) or object module not stripped > >Blindly routing it to a printer is stupid. Better than blindly turning it into PostScript! -- Andy Walker, Maths Dept., Nott'm Univ., UK. anw@maths.nott.ac.uk
clewis@ferret.ocunix.on.ca (Chris Lewis) (03/22/91)
In article <1991Mar19.171530.6904@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1991Mar19.052103.9026@ferret.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes: >>A truly smart spooler would figure out what printers are appropriate >>for a given magic cookie, and route the results there. Otherwise, >>you're expecting everybody to remember which printers can handle a given >>format and/or remember lots of obscure options to tell the printer to >>go into the correct mode. >Ah, but the appropriate thing to do with a particular type of data may >depend on who sent it and what command line options were given as well. I was presuming, but left unsaid, that certain things like printing location, user environment etc. should also be taken into account. -- Chris Lewis, clewis@ferret.ocunix.on.ca or ...uunet!mitel!cunews!latour!ecicrl!clewis Psroff support: psroff-request@eci386.uucp, or call 613-832-0541 (Canada) **** somebody's mailer is appending .bitnet to my From: address. If you see this, please use the address in the signature, and send me a copy of the headers of the mail message with the .bitnet return address. Thanks!
tneff@bfmny0.BFM.COM (Tom Neff) (03/26/91)
When you want a line printer listing of a PostScript program, just prepend a "----cut here--------cut here----..." line before spooling. Or filter the file through something that'll pretty-print it for you. Why people expect printers and spoolers to also be mind-readers is beyond me...