ib@apolling (Ivan N. Bach) (02/24/90)
jeynes@adobe.COM writes: >UltraScript is not an Adobe product; it is a clone PostScript interpreter >made by Imagen/QMS. I am getting tired of reading about PostScript "clones." The word "clone" had never been used to describe the implementation of a procedural language until Adobe started using it to refer to the implementations of the PostScript language by other companies. Have you ever heard of a COBOL or FORTRAN clone? Have you ever heard of a proposal for a new world standard for the storing and transmitting of image data that wastes up to 90% of the communication channel's capacity? Have you ever heard of a modern procedural language whose deficiencies are covered up by extending it with specific versions of comment statements? Have you ever heard of a procedural language in public domain whose most important component has been encrypted? Have you ever heard of a procedural language in public domain whose name you are not allowed to use when you implement that language? Intel says that by year 2000 microprocessor chips will contain 100 million transistors and operate at 250MHz. If we leave it to Adobe to design our page and document description languages, by year 2000 we will still have to waste our time preprocessing arithmetic expressions from the usual format supported by the first high-level procedural language into the Reverse Polish notation in order to make it easier to interpret such expressions. The general-purpose programming part of our page description languages will be at the level of a programmable calculator, and we will still have to worry about doing our own gargabe collection, so that we do not run out of virtual memory. We will still have printer drivers that convert compact image descriptions in binary format into very readable long words that are never seen by a human being. We will keep waiting for that readable data to be sent over a 9600-baud communications link to a printer controller that will take so long to process even these preprocessed statements that mechanical parts of a modern printer will wait on the electronic parts, so that we will still not be able to drive our printers at full speed. Ivan N. Bach Tel (408) 986-9400, x508 QMS, Inc. Fax (408) 727-3725 2650 San Tomas Expressway arpa: ib@imagen.com Santa Clara, CA 95051 uucp: decwrl!imagen!ib
kchen@Apple.COM (Kok Chen) (02/24/90)
ib@apolling (Ivan N. Bach) writes: >jeynes@adobe.COM writes: >> >>UltraScript is not an Adobe product; it is a clone PostScript interpreter >>made by Imagen/QMS. > >I am getting tired of reading about PostScript "clones." The word "clone" >had never been used to describe the implementation of a procedural language >until Adobe started using it to refer to the implementations of the PostScript >language by other companies. Have you ever heard of a COBOL or FORTRAN clone? You are right, "clone" is too good a word, since it used to mean organisms that have the same *genetic* origins, which, obviously, PostScript(R) and UltraScript(TM) don't share :-). More recently, "clone" has been used to imply a copy of a product that was reversed engineered without benefit of the original design documents. Perhaps this is what Mr. Jeynes meant. >Have you ever heard of a proposal for a new world standard for the storing >and transmitting of image data that wastes up to 90% of the communication >channel's capacity? YES! ==> NTSC !!!! :-):-):-):-) > [Then the anti-PostScript flames started to get really hot...] > >Ivan N. Bach Tel (408) 986-9400, x508 >QMS, Inc. Fax (408) 727-3725 PostScript(R) became successful because it satisfied the needs of a lot of folks with sufficiently deep pockets. Instead of griping about what a sicko procedural language it is, perhaps Ivan would care to propose one of his favourites, and let the free market decide? Cheers, Kok Chen kchen@apple.com, AA6TY(ex-KK6DP) Apple Computer, Inc. --- Disclaimer: This is my personal opinion and I do own a small chunk of AQM due to some affiliations in a past life. Furthermore, I may not even like PostScript. :-)
louie@sayshell.umd.edu (Louis A. Mamakos) (02/24/90)
In article <9447@imagen.UUCP> ib@apolling (Ivan N. Bach) writes: > If we leave it to Adobe to design our >page and document description languages, by year 2000 we will still have to >waste our time preprocessing arithmetic expressions from the usual format >supported by the first high-level procedural language into the Reverse >Polish notation in order to make it easier to interpret such expressions. Gee, I generally use programs to write most of the PostScript that I print. I don't see that this is a terrible problem. I don't usually write in assembly code, except when I need to program to the metal; much the same as my PostScript code. >We will keep waiting for that readable data >to be sent over a 9600-baud communications link to a printer controller >that will take so long to process even these preprocessed statements that >mechanical parts of a modern printer will wait on the electronic parts, so >that we will still not be able to drive our printers at full speed. My DEC LPS-40 running real Adobe PostScript is ethernet attached. I don't know why people harp on the 9.6 kbs speed limit; if this is a problem for you, it is easily solved by spending money for a high performence printer. Performance costs money. And I like speaking TCP/IP to my PostScript printers so that its easily shared by multiple printing platforms. No one is holding a gun to your head forcing you to serially attach your printers. While PostScript is indeed a programming language, it intended purpose is a <<Page Description Language>>, which it seems to do quite nicely. Louis A. Mamakos
amanda@intercon.com (Amanda Walker) (02/24/90)
In article <9447@imagen.UUCP> ib@apolling (Ivan N. Bach) writes a
heated flame about how "if we leave it to Adobe to design our page and
document description languages," all sorts of evil nasty things will
happen.
Maybe. PostScript may well become the COBOL of page-oriented graphics
formats. That's not such a bad thing, as much as I hate to defend
COBOL :-). For those applications where it is more effective to still
be using PostScript instead of cutting over to some newer "standard"--
and there will always be newer "standards," have no fear--we may well
be still translating into postfix notation and spitting ASCII files at
our printers. So?
Adobe cannot control technology. They leapfrogged the rest of the
industry with PostScript, but nothing says someone else won't do the
same thing with something better than PostScript, perhaps addressing
some of the very issues we argue about here. However, I don't think
we're all in as much danger as all that.
PostScript was designed with some very specific goals and design
constraints. Many of us here on this newsgroup have found ways to
"push the envelope" of that design, but the farther you get away from
the laser printer/laser recorder design center, the less appropriate
PostScript is right now. If you have an ion-deposition printer that
prints at 50 pages a second, or a full-motion video display, or
whatever people come up with in the next ten years, PostScript, at
least as it currently exists, may not be able to make effective use of
your hardware. Then again, maybe it will be. If you can drop a
150-200 MIPS processor with graphics hardware into your printer
controller, you may be able to interpret PostScript at 50 pps for most
jobs, just as you can now interpret PostScript at 5-8 ppm for most
jobs with a 1 MIPS processor.
One of the characteristics of PostScript's design center is that the
speed of the marking engine is the major bottleneck. For some
combinations, that isn't true. I would argue that given the speed
over time curves of the controller circuitry are much steeper than
that of the mechanical portions of any printer.
PostScript is like Lisp in that it's a "ball of mud" in some ways.
Lisp was invented over 30 years ago, and it's still going strong.
PostScript isn't doing too bad of a job of following in its footsteps,
although it's still pretty early to second-guess future history.
--
Amanda Walker
InterCon Systems Corporation
--
"Many of the things we hold true depend greatly upon our own point of view."
--Obi-Wan Kenobi in "Return of the Jedi"glenn@heaven.woodside.ca.us (Glenn Reid) (02/24/90)
In article <38910@apple.Apple.COM> kchen@Apple.COM (Kok Chen) writes: >ib@apolling (Ivan N. Bach) writes: >>Have you ever heard of a proposal for a new world standard for the storing >>and transmitting of image data that wastes up to 90% of the communication >>channel's capacity? >>Ivan N. Bach Tel (408) 986-9400, x508 >>QMS, Inc. Fax (408) 727-3725 > >PostScript(R) became successful because it satisfied the needs of a lot >of folks with sufficiently deep pockets. Instead of griping about what >a sicko procedural language it is, perhaps Ivan would care to propose one >of his favourites, and let the free market decide? >Kok Chen kchen@apple.com, AA6TY(ex-KK6DP) >Apple Computer, Inc. I think it's a lot simpler and a lot less pure than the free market system or communications bandwidth. I do think PostScript is successful because it is an elegant design and it's wonderful and all that, but that is neither necessary (unfortunately) nor sufficient for anything to be successful, as we are all painfully aware. No, I think PostScript succeeded mainly because it is ASCII. People can understand something that they can see. People like that. A lot of the software in the world is screwed up in one way or another, and people love to be able to fix things that are broken. And they can fix them if they are expressed in ASCII. Or at least they can see them and know that there is something broken in there that they can't quite understand, so they want to know more about it. So they learn it, and have fun with it, and tell somebody else about it. A hell of a lot more people know how to work text editors than know how to read octal dumps. You can drag graphic designers and sales people (not to slight them, of course, but to pick some folks who probably have never written any programs) into a classroom and get them to print their names on a sheet of paper in 100 point Times Roman in about 15 minutes. Try to do that with a binary-encoded token stream with packed arrays, 0-padded bytes, run-length encoded bits, checksums, and end-of-file indicators. Throughout the history of the computer industry, the computer people start out designing something that is very clean, simple, elegant, and efficient on the bottom, and by the time it gets to the user, it is inconsistent, quirky, slow, incomprehensible, and ugly. But people buy it because there's nothing better, learn to live with it because people are good at adjusting to things, and the computer people think they've done something wonderful, so they turn around and do it again, from scratch, and make it totally different than the last one. That's because computer people love the work they are doing, and they would never want to do the same thing over and over again, and besides, it can be made more wonderful! I know that, because I am a computer person. But I've also watched people try to use computers for years, and there's not a computer system on earth that's as useful to a human being as a Makita cordless drill is to the average carpenter. Or if it is, somebody will suddenly change the software on her to make it more wonderful, but it may not be able to read all of her data files; sorry. Anyway, PostScript is great because you can see it, edit it, write more of it, and even complain about it. Most of us couldn't do any of these things if it weren't ASCII. So what if it takes a little longer to get where it's going? Besides, there are more MIPS and megabytes every time you wake up. There are people who care about whether a 100-page-per-minute printer keeps up to its rated speed, and there are specialized solutions for those people. I value reliability and consistent output about 100 to 1 over speed. That is, I'd rather have a 1 ppm printer that always got the right answer, because I could go to sleep and have it print the draft of my book, than have a 100 ppm printer that couldn't print page 3 and wanted me to click "OK" when I woke up in the morning. Glenn Reid (My own late-night thoughts, of course)
jbw@unix.cis.pitt.edu (Jingbai Wang) (02/25/90)
In article <147@heaven.woodside.ca.us> glenn@heaven.UUCP (Glenn Reid) writes: |>|>PostScript(R) became successful because it satisfied the needs of a lot |>|>of folks with sufficiently deep pockets. Instead of griping about what |>|>a sicko procedural language it is, perhaps Ivan would care to propose one |>|>of his favourites, and let the free market decide? |>|>Kok Chen kchen@apple.com, AA6TY(ex-KK6DP) |>|>Apple Computer, Inc. ... |>No, I think PostScript succeeded mainly because it is ASCII. People |>can understand something that they can see. People like that. A lot |>of the software in the world is screwed up in one way or another, and |>people love to be able to fix things that are broken. And they can |>fix them if they are expressed in ASCII. Or at least they can see |>them and know that there is something broken in there that they can't |>quite understand, so they want to know more about it. So they learn |>it, and have fun with it, and tell somebody else about it. |> ... ... |>There are people who care about whether a 100-page-per-minute printer |>keeps up to its rated speed, and there are specialized solutions for |>those people. I value reliability and consistent output about 100 |>to 1 over speed. That is, I'd rather have a 1 ppm printer that always |>got the right answer, because I could go to sleep and have it print |>the draft of my book, than have a 100 ppm printer that couldn't print |>page 3 and wanted me to click "OK" when I woke up in the morning. |> |>Glenn Reid |> (My own late-night thoughts, of course) I tend to agree with Glenn (at least on ASCII part). Adobe is one of the few successful computer companies founded by advanced degree holders. It could affort to use ASCII output format of commands, strings and integer as well as floating point numbers, instead of the traditional <ESC>+[+??? +integer + strings, because the designers knew disk space, ROM and RAM would not be a restriction in a long run, and CPU would catch up soon. With that, device independency could be conceived, because the PostScript output file describes the image analytically instead of hard-coded the output in bitmap and strings. The final bitmap image relies on the interpretor and the available font libraries. ASCII format is good in the sense you can edit, transmit and store in very convenient and standard ways. But they are also bad in that there are no flags, escapes and others that can allow a programmer to interprete the results into other output formats. A full feature parser is nothing but a PostScript interpreter which can't be built trivially. On the other hand, any other printing languages in other types of printers can be interpreted and/or translated to another at very low cost. This made cloning difficult and enabled Adobe stokes to mushroom. Among other things, most of graphics description algorithms in PostScript are also standard and visible in competitors, except, maybe, closepath, fill, setgray, scale, clippath and the such. But they were not so difficult to design. Vector fonts had been available ever since plotters were born. B-spline is really nothing but a standard scheme, kerning and font metrics were known to all, but without closepth, setgray, setlinewidth, and fill an outline font would never be as presentable, as scaleable and as flexible as Adobe type 1 fonts. In a word, Adobe is successful because the founder could see farther than others in the computer industry. ASCII is only a minor point. Actually, besides <ESC> DEC LN03 plus also uses ASCII format. Stack is also a feature in PostScript programming language, but it is not unique to it. Forth language also uses stacks. JB Wang Research Associate, Ph.D. Stevens Institute of Technology p.s.: I am normally active in comp.lang.postscript, comp.text, comp.text.tex Chinese computing network -- ccnet-l@uga.bitnet, and I have products in all of these fields.
woody@rpp386.cactus.org (Woodrow Baker) (02/25/90)
In article <147@heaven.woodside.ca.us>, glenn@heaven.woodside.ca.us (Glenn Reid) writes: > In article <38910@apple.Apple.COM> kchen@Apple.COM (Kok Chen) writes: > >ib@apolling (Ivan N. Bach) writes: > >>Ivan N. Bach Tel (408) 986-9400, x508 > >>QMS, Inc. Fax (408) 727-3725 > > > > I think it's a lot simpler and a lot less pure than the free market > system or communications bandwidth. I do think PostScript is successful > because it is an elegant design and it's wonderful and all that, but I'm not so sure about elegant design. I don't like thinking backwards. I'm getting used to it sort of, but have seriously considered writing a front end that takes normal syntax, and mungs it around for postscript. I think that moveto 100,100 is somewhat more intuitive than 100 100 moveto.. > > No, I think PostScript succeeded mainly because it is ASCII. People > can understand something that they can see. People like that. A lot Absolutely, but I think it should be full 8 bits.... > > A hell of a lot more people know how to work text editors than > know how to read octal dumps. You can drag graphic designers I get more and more amazed as the world goes 'round. OCTAL DUMPS? I thought we buried octal decades ago. g > and sales people (not to slight them, of course, but to pick some folks > who probably have never written any programs) into a classroom and > get them to print their names on a sheet of paper in 100 point Times > Roman in about 15 minutes. Try to do that with a binary-encoded > token stream with packed arrays, 0-padded bytes, run-length > encoded bits, checksums, and end-of-file indicators. Yep. This is a well taken point. I have sold many POSTSCRIPT printers, and with the exeption of 3 or 4, have taught the purchasers of them to program in Postscript. In the IBM world, at the time, MS Word was the only way to use Postscript, and if you wanted to do graphics, it was grab your text editor and learn postscript. Actually, you probably could do it in less than 15 min. (get them printing thier name). Yes, postscript is wordy. The stream is large. The bandwidth gets wasted. BUT, If it is written CORRECTLY, it is easy to fix and easy to maintain. Postscript is slow. very slow....In comparison to what?.... Part of that is due to it's wordyness, part is due to it's interpreted nature, and part of it is due to the fact that it uses software floating point in most implementations... > > Throughout the history of the computer industry, the computer people > start out designing something that is very clean, simple, elegant, > and efficient on the bottom, and by the time it gets to the user, it > is inconsistent, quirky, slow, incomprehensible, and ugly. But > people buy it because there's nothing better, learn to live with > it because people are good at adjusting to things, and the > computer people think they've done something wonderful, so they turn > around and do it again, from scratch, and make it totally different > than the last one. That's because computer people love the work they > are doing, and they would never want to do the same thing over and > over again, and besides, it can be made more wonderful! I know that, > because I am a computer person. But I've also watched people try to > use computers for years, and there's not a computer system on earth > that's as useful to a human being as a Makita cordless drill is to the > average carpenter. Or if it is, somebody will suddenly change the > software on her to make it more wonderful, but it may not be able to > read all of her data files; sorry. > > Anyway, PostScript is great because you can see it, edit it, write > more of it, and even complain about it. Most of us couldn't do any of > these things if it weren't ASCII. So what if it takes a little longer > to get where it's going? Besides, there are more MIPS and megabytes > every time you wake up. > > There are people who care about whether a 100-page-per-minute printer > keeps up to its rated speed, and there are specialized solutions for > those people. I value reliability and consistent output about 100 > to 1 over speed. That is, I'd rather have a 1 ppm printer that always > got the right answer, because I could go to sleep and have it print > the draft of my book, than have a 100 ppm printer that couldn't print > page 3 and wanted me to click "OK" when I woke up in the morning. My current POSTSCRIPT printer does that to me, under windows....:-}
woody@rpp386.cactus.org (Woodrow Baker) (02/25/90)
In article <22520@unix.cis.pitt.edu>, jbw@unix.cis.pitt.edu (Jingbai Wang) writes: > > I tend to agree with Glenn (at least on ASCII part). Adobe is one of the > few successful computer companies founded by advanced degree holders. It > could affort to use ASCII output format of commands, strings and integer > as well as floating point numbers, instead of the traditional <ESC>+[+??? > +integer + strings, because the designers knew disk space, ROM and RAM > would not be a restriction in a long run, and CPU would catch up soon. You truly think that it requires advanced degrees to figure this out????!!! Gimme a break, the degrees mean nothing. I'm sure that you know the old saw about BS degrees, MS degrees( more of the same) and PHD degrees (Piled High and Deep).. I'm not running the founders down here, it is just that the degree bit has no relation whatsoever to success. Just look around you. There are LOTS of successful visionaries that never got out of grade school. > > ASCII format is good in the sense you can edit, transmit and store in very > convenient and standard ways. But they are also bad in that there are no > flags, escapes and others that can allow a programmer to interprete the > results into other output formats. A full feature parser is nothing but > a PostScript interpreter which can't be built trivially. On the other hand, > any other printing languages in other types of printers can be interpreted > and/or translated to another at very low cost. This made cloning difficult Certainly. But can you tell me *RIGHT NOW* without having to go grab a manual, what the escape sequence for causing an HP Laserjet to move to coordinates 100 100 and draw a linet to 112.5 301.89? or howabout telling me how to image a bit map *RIGHT NOW* in Epson or HP mode? > > In a word, Adobe is successful because the founder could see farther > than others in the computer industry. ASCII is only a minor point. Actually, True, but the degrees didn't necessarily enable them to do it. Remember, the concept was NOT original with them. It came from PARC..... :
kchen@Apple.COM (Kok Chen) (02/26/90)
woody@rpp386.cactus.org (Woodrow Baker) writes: >True, but the degrees didn't necessarily enable them to do it. Remember, >the concept was NOT original with them. It came from PARC..... I agree about the bit on formal diplomas (but, if more diplomas don't hinder your innovative thinking, they really don't do any harm :-); but Woody, you may want to trace the Interpress history back a little to find out who some of the people in that Xerox/PARC project were. Granted, you may contend that it all started further back at PARC with PRESS (Sproull et. al.). But PRESS, if I remember correctly, was a flat langauage (I do remember vividly, however, crashing the Dover at Stanford numerous times by trying to send my own graphics PRESS commands to it - I can admit that, now that the statute of limitations has passed :-) :-). PRESS, by my recollection, was akin to something like PCL and imPRESS. Oh yes, Jingbai, Interpress has all the closepath, fill, etc. features that you deemed so important to PostScript's success and yet it has never attained the position PostScript holds (whoops, now I will have the folks at Webster labs on my back :-). Gosh, even PRESS (ca. 1976?) and imPRESS (ca. 1980) have closepath and fills way back when, in real- world printers that you can touch (and even program, if you are among the lunatic frindge :-). Quick, Woody - what gets returned on the stack with a PostScript "cachestatus" command? *RIGHT NOW*(TM), no fair looking at the manual! :-) :-) (Just kidding.) Wow, and all this started with Ivan giving the hex (pun intended) to PostScript. Regards, Kok Chen kchen@apple.com, AA6TY Apple Computer, Inc.
jbw@unix.cis.pitt.edu (Jingbai Wang) (02/26/90)
In article <18028@rpp386.cactus.org|> woody@rpp386.cactus.org (Woodrow Baker) writes: |>In article <22520@unix.cis.pitt.edu|>, jbw@unix.cis.pitt.edu (Jingbai Wang) writes: |>|> |>|> I tend to agree with Glenn (at least on ASCII part). Adobe is one of the |>|> few successful computer companies founded by advanced degree holders. It |>... |>You truly think that it requires advanced degrees to figure this out????!!! |>Gimme a break, the degrees mean nothing. I'm sure that you know the |>old saw about BS degrees, MS degrees( more of the same) and PHD degrees |>(Piled High and Deep).. |> |>I'm not running the founders down here, it is just that the degree bit |>has no relation whatsoever to success. Just look around you. There are |>LOTS of successful visionaries that never got out of grade school. I don't want to engage in a degree war with computer world, because I realized in my job hunting effort that 95% of computer jobs are offered to BS or below, MS might find a job, Ph.D. almost no way. But, if you turn back to educational systems, you can clearly see that the more advanced the degree program you are in the further you are from reality of today. In other words, many technologies to be used 10-50 years later, are today's research topics in advanced degree programs. Actually, advanced degree programs are designed to train a student the ability to look far forward instead teaching you how to design a specific steam engine. It is well known that many inventions were made by ones with little formal education, and many great enterpricer have not got enough education. In I.E. classes, people often talk about Lotus Development founder and Basic language creator, or former Apple Computer founders. Seldom do people talk about Adobe founders. By advanced degrees here, what I want to say is really they are not only technically excellent and trained to see at least 10-20 twenty years down the road in such a rapidly developing industry, but they also could guide the market and other developers successfully in long term point of view. On the other hand, IBM forced other smaller computer manufacturers to use DOS and Intel chips just because they are strong and big. Do you see long term views in Lotus? and Apple computers then? I am not saying that everybody has to get advanced degrees, but advanced degree training did bring computer industry good, and Adobe is a good example. By the way, TeX's author Don Knuth and Scribe's inventor Brian Reid are also Ph.D.'s. I definitely do not agree to the ways the stories of Lotus are told in the class to encourage people to quit BS to start a company to become a millionair. |>|> |>|> ASCII format is good in the sense you can edit, transmit and store in very |>|> convenient and standard ways. But they are also bad in that there are no |>|> flags, escapes and others that can allow a programmer to interprete the |>|> results into other output formats. A full feature parser is nothing but |>|> a PostScript interpreter which can't be built trivially.On the other hand, |>|> any other printing languages in other types of printers can be interpreted |>|> and/or translated to another at very low cost. This made cloning difficult |> |>Certainly. But can you tell me *RIGHT NOW* without having to go grab a |>manual, what the escape sequence for causing an HP Laserjet to move to |>coordinates 100 100 and draw a linet to 112.5 301.89? |>or howabout telling me how to image a bit map *RIGHT NOW* in Epson or |>HP mode? No, I can't. You can't do it with PostScript either. I did not say traditional escape manner was good for output, PostScript is certainly much more powerful. But, ten years ago, with only 16k RAM in a Radio Shark TRS 80, and a tape recorder to store data at 300 baud, those formats might be the most compact and economic ones. |>|> |>|> In a word, Adobe is successful because the founder could see farther |>|> than others in the computer industry. ASCII is only a minor point. Actually, |> |>True, but the degrees didn't necessarily enable them to do it. Remember, |>the concept was NOT original with them. It came from PARC..... |> |>: I thought I did point out that most of PostScript ideas and algorithms existed before its birth. But who really put them in market step by step? Why did not they hesitate when so many people were shouting that PostScript printing was so slow and expensive? Why did they not change ASCII format into space-saving binary+flag+escape format when everybody was complaining that network and disk spaces are jammed? No, I don't think their degrees directly brought them to that point, but the way they were trained in the advanced degrees did. Folks, it is not steam engine's age now. Even if degrees are not important, formal trainning and education are important. This does not mean Ph.D.'s are more important than BS's. They are important in their own different aspects, otherwise is not it redundant to have different levels of education? It has become manditory to go through high school in many nations, but it won't become true to Ph.D. in 1000 years. JB Wang
lihan@walt.cc.utexas.edu (Bruce Bostwick) (02/26/90)
I must disagree about 'thinking backwards.' I grew up programming in algebraic-notation languages too, and originally had the same problem with FORTH, PostScript, and my HP-41CX. Then I discovered that RPN is actually SIMPLER than algebraic notation. Sounds weird, but think about it: _EVERY_ operation is simply a matter of doing something to the numbers on the stack. They can all be precisely defined very easily, which makes proving your code much easier. Variables are a necessary evil which introduce more complication into your definitions. It all depends, I guess, upon one's point of view. I prefer RPN now, mainly because I use it a lot and find algorithms easier to formulate in it. You may not -- but remember one is not necessarily 'forward' or 'backward' ... or even 'right' or 'wrong' as some say it. :-) =============================================================================== Internet: lihan@vondrake.cc.utexas.edu :-) aka BB/CIV (-: BellNet: (512)346-2744 SlowNet: varies chaotically, e-mail for current value nothing cute to say or disclaim -- sorry... ===============================================================================
amanda@intercon.com (Amanda Walker) (02/27/90)
In article <147@heaven.woodside.ca.us> glenn@heaven.UUCP (Glenn Reid) writes: >Anyway, PostScript is great because you can see it, edit it, write >more of it, and even complain about it. To paraphrase Alan Kay, perhaps PostScript is the first printer interface method good enough to criticize (although I'd say Interpress is a close second... :-)). -- Amanda Walker InterCon Systems Corporation -- "Many of the things we hold true depend greatly upon our own point of view." --Obi-Wan Kenobi in "Return of the Jedi"
glenn@heaven.woodside.ca.us (Glenn Reid) (02/27/90)
In article <18028@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: | True, but the degrees didn't necessarily enable them to do it. Remember, | the concept was NOT original with them. It came from PARC..... So did the founders, silly, along with the original concept for PostScript.
amanda@intercon.com (Amanda Walker) (02/27/90)
In article <147@heaven.woodside.ca.us> glenn@heaven.UUCP (Glenn Reid) writes: >No, I think PostScript succeeded mainly because it is ASCII. I'd even go one step farther--I think PostScript succeeded mainly because it's *source code*. An ASCII format that isn't human readable isn't really much better than a binary format. Putting a real live interpreter inside the printer was a stroke of genius. -- Amanda Walker InterCon Systems Corporation -- "Many of the things we hold true depend greatly upon our own point of view." --Obi-Wan Kenobi in "Return of the Jedi"
zben@umd5.umd.edu (Ben Cranston) (02/27/90)
In article <147@heaven.woodside.ca.us> glenn@heaven.UUCP (Glenn Reid) writes: > No, I think PostScript succeeded mainly because it is ASCII. People > can understand something that they can see. People like that. A lot > of the software in the world is screwed up in one way or another, and > people love to be able to fix things that are broken. And they can > fix them if they are expressed in ASCII. Or at least they can see > them and know that there is something broken in there that they can't > quite understand, so they want to know more about it. So they learn > it, and have fun with it, and tell somebody else about it. > A hell of a lot more people know how to work text editors than > know how to read octal dumps. You can drag graphic designers > and sales people (not to slight them, of course, but to pick some folks > who probably have never written any programs) into a classroom and > get them to print their names on a sheet of paper in 100 point Times > Roman in about 15 minutes. Try to do that with a binary-encoded > token stream with packed arrays, 0-padded bytes, run-length > encoded bits, checksums, and end-of-file indicators. > Anyway, PostScript is great because you can see it, edit it, write > more of it, and even complain about it. Most of us couldn't do any of > these things if it weren't ASCII. So what if it takes a little longer > to get where it's going? Besides, there are more MIPS and megabytes > every time you wake up. People are very inconsistent and silly, and so the things they create tend to be the same way. One of the really nice things about PostScript is that you can explain the Show operator and the Translate operator and even let them write some toy programs (like those in the Blue Book) that really do some amazing things. They fool themselves into thinking they know the silly language, but that's just fine, because when they finally buy the printer and look at the work involved in writing their next book in Postscript (:-) they fall back to TEK or Runoff or whatever, which could just as easily emit Interpress or Impress or Linotron Cora as Postscript, maybe even easier. So their fantasy that they know the language is never tested against reality. I wrote a program that printed Linotron Binary Byte out in readable format, and I wrote a program that printed Imagen Impress out in readable format, and these satisfied my need to read and debug output from Real Programs just fine, thank you. Agreed that expressing PS in readable ASCII allows people not capable of doing this the ability to debug program output. Maybe. You read a Macintosh control-f dump sometime. This is akin to buying a new computer based on its array of fancy CISC instructions like "Insert in Balanced Binary Tree and Balance" then when you get the damn thing using only higher level language compilers like C that never generate an instruction more complicated than "Move Register to Memory". Typical Human inconsistency. Oops, jumped track to the RISC diatribe -- back to the PS diatribe. IMHO PS was successful because it became a de-facto standard at a time when a standard was desparately needed but the existing standards organizations were piddling around with CGM/GKS versus (well, insert your own acronyms here). People needed a standard, PS was 90% of what they needed and it was here (i.e. people thought Apple would produce LW for a reasonably long time) and they couldn't afford to wait for GKS or something like it to give them that last 10%. -- Sig DS.L ('ZBen') ; Ben Cranston <zben@Trantor.UMD.EDU> * Network Infrastructures Group, Computer Science Center * University of Maryland at College Park * of Ulm
ib@apolling (Ivan N. Bach) (02/27/90)
There have been several emotional responses to my recent posting about
the deficiencies of PostScript, but nobody disputed my claims by
offering some technical counter arguments.
So most of you seem to like PostScript, and you think that one of its
best features is that it supports only a readable format. You describe
PostScript as it was some new version of BASIC or LEGO, and you like to
code in that language.
The only problem is that PostScript was not designed for that purpose,
and most of the time it is not used the same way as, for example, BASIC.
John Warnock described PostScript as a "hidden layer" between a printer
driver and a printer. Most of the time (99.99% of the time) people are
using desktop-publishing applications, such as PageMaker or Ventura-
Publisher, to indirectly generate PostScript. They are not directly
writing PostScript code. When you request a printout, the application
calls a driver for your printer, the driver generates PostScript code,
and PostScript code is sent to a PostScript interpreter or stored in a
file. Most of the time PostScript code is automatically generated,
interpreted, and discarded, without ever being seen by a human being.
Sometimes PostScript is transmitted to another computer, or to a
remote PostScript printer. Only occassionally somebody looks at the
PostScript code because something goes wrong, or an adjustment has to
be made, and that adjustment cannot easily be made by using an
application program.
The fact is that the readable format is NEEDED only when you have
to manually change or debug a PostScript program, or when you have to
transmit it over a communications channel that does not transmit
binary data reliably. To insist that a readable format is needed all
the time is like insisting that all computer applications should be
distributed in a much longer, debugging version that preserves the
line numbers in source code, because somebody someday may want to
debug them.
Have you ever stopped to think why do you have to code directly in
PostScript? Most of the time the problem is that an application
does not give you access to the full power of PostScript, and the
only way you can achieve a particular special effect is to code
it yourself.
If PostScript was used only by a small number of people, I would
understand your lack of concern about how efficiently page descriptions
are encoded in PostScript, and how the efficiency of PostScript
compares with other methods of encoding the same data.
I have to remind you that PostScript was proposed as the ONLY method
for encoding page descriptions in all countries of the world, because
that will facilitate the transmission of page descriptions to remote
computers and printers. When you propose a new world standard for
storing and transmitting image data, you may want to check the
efficiency of your encoding, not to please me, but to avoid wasting
billions of dollars.
Let us assume that there are 1,000,000 people in the world who use
PostScript, and that each person on average wastes 1MB of disk
storage and 1 hour of time each year because of inefficient encoding.
The total waste would be huge year after year. I think that the
actual numbers are much greater, and growing each year. Not to
mention the Kanji version of PostScript.
I find it ironic that the users of USENET, who are used to the
warnings about wasting the bandwidth on our network, do not seem to
be very concerned about the efficiency of PostScript.
Just how inefficient is the PostScript readable format? I had the
opportunity to compare page descriptions in PostScript with the
corresponding page descriptions in a language that supported both
a readable and binary format. Depending on what kind of statements
you use, and how many bytes are taken by comment statements, you
can reduce the number of bytes needed to encode a given image by
as much as 90%. You people are telling me that this does not
matter, and that the fact that PostScript supports only a readable
format is of minor importance.
It is true that a PostScript program is usually more compact than
a bitmap that can be produced from that code, but nobody can tell
me that a statement such as:
/Helvetica-BoldOblique findfont 20 scalefont setfont
is the most compact way of specifying that you want a particular
20-point font. What do you think a PostScript interpreter does
with these long names as it scans the input stream of characters?
It immediately replaces them with more compact codes.
Some of you suggested that I should simply pay more if I wanted
to transmit page descriptions faster. That is like saying that
I should simply buy more gas if the engine in my car is not
designed to be very efficient. I was hoping that at least some
people from California would be concerned about unnecessary wasting
of scarce resources.
There are many programs which can be used to compress PostScript
code. The problem is that such code cannot be transmitted
directly to a PostScript printer. You have to implement some
program or device at the printer side that will decompress the
PostScript code before it is sent to the PostScript interpreter.
Some of the QMS interpreters accept a binary format just as
easily as the corresponding readable format. You do not have
to specify any options or set any switches. You just send
your code to the interpreter in one of the supported formats.
By default, the driver for a PostScript printer should generate
PostScript in a compact, binary format. The driver should
generate PostScript in a readable format upon request. A couple
of years ago, I implemented such a feature in one of my Windows
printer drivers.
Which binary format should we use for PostScript? It could
be proposed by Adobe. I understand that Adobe already uses a
binary format in its Display PostScript. Alternatively, we
could design an efficient binary format in this newsgroup and
submit our proposal to the companies which have developed
PostScript interpreters. We could implement the proposed
format in the QMS UltraScript interpreter to see how it works.
I think that it is about time that we make a substantial contribution
to the PostScript language in this group, instead of quarelling
about less important things.
When we finish designing the PostScript binary format, we could
design the user interface for an application like the Adobe
Illustrator that will give us access to the full power of
PostScript. Then we could implement such an interface under
Microsoft Windows, OS/2 Presentation Manager, X windows, etc.
We should also do something about the executive or interactive
use of PostScript. Have you ever tried to use a PostScript
interpreter in interactive mode? Most user interfaces for this
mode are worse than BASICA. You cannot load a PostScript program,
submit it for interactive interpretation, edit it, or resubmit
it the way you can do that with a program written in BASIC. We
could assign some line numbers to PostScript statements, so that
we can easily refer to them. Those line numbers would not become
part of the source code. Such a user interface would be much
more useful for learning PostScript than the current interfaces
which scroll the statements off the top of the screen, and force
you to reenter all statements if you make a slightest mistake.
Ivan N. Bach Tel (408) 986-9400, x508
QMS, Inc. Fax (408) 727-3725
2650 San Tomas Expressway arpa: ib@imagen.com
Santa Clara, CA 95051 uucp: decwrl!imagen!ib gillies@p.cs.uiuc.edu (02/28/90)
> Putting a real live interpreter inside the printer was a stroke of > genius. Remark: Too bad they didn't consider putting a compiler in the printer. I agree that "clone" is a stupid term to use. PC's don't execute C clones, the 2nd PASCAL compiler was not a PASCAL clone, etc etc ad infinitum. Adobe has set a dangerous precedent by releasing a language that was part proprietary, part public-domain. Too bad they didn't have the smarts to make the entire language public-domain. Interpress failed because Xerox sat on it for several years ( >3). Postscript forced Xerox to wake up and smell the coffee, too late. Interpress theoretically has an ascii form, but the language went further and specified a compiled binary form, which was a case of the designers being too sure of themselves for their own good 8-). This is probably a case of the fabled "second system" effect, where they second version of something does *everything* and becomes a hulking behemoth. Don Gillies, Dept. of Computer Science, University of Illinois 1304 W. Springfield, Urbana, Ill 61801 ARPA: gillies@cs.uiuc.edu UUCP: {uunet,harvard}!uiucdcs!gillies
munck@chance.uucp (Robert Munck) (02/28/90)
In article <9457@imagen.UUCP> ib@apolling (Ivan N. Bach) writes: >Let us assume that there are 1,000,000 people in the world who use >PostScript, and that each person on average wastes 1MB of disk >storage and 1 hour of time each year because of inefficient encoding. >The total waste would be huge year after year. I think that the >actual numbers are much greater, and growing each year. Wow! Suppose there were 10,000,000, and they each waste 20MB and 40 hours! Or even 1,000,000,000 and each wastes 2,000MB and 9,000 hours a year! That would be even huger. > Not to mention the Kanji version of PostScript. Yeah! Not to mention it! >... Such a user interface would be much >more useful for learning PostScript than the current interfaces >which scroll the statements off the top of the screen, and force >you to reenter all statements if you make a slightest mistake. Or how about this crummy TTY that you have to use to do PostScript, where the paper keeps getting tangled out the back and the ribbon runs out of ink? That was a really stupid way for Adobe to design PostScript. I've had to type this note in from the beginning over a hundred and fifty times because I keep making slight mistakes. Boo! -- Bob Munck -- Bob <Munck@MITRE.ORG>, linus!munck.UUCP -- MS Z676, MITRE Corporation, McLean, VA 22120 -- 703/883-6688
philip@minnie.Stanford.EDU (Philip Machanick) (02/28/90)
This discussion is on the point of becoming silly. Meta-points about whether it's a good discussion or not need be no longer than this. Some good points HAVE come out of it. Let's not stifle debate, but on the other hand a bit of brevity would not be out of place either. Philip Machanick philip@pescadero.stanford.edu
ib@apolling (Ivan N. Bach) (02/28/90)
munck@chance.UUCP (Robert Munck) writes: >Wow! Suppose there were 10,000,000, and they each waste 20MB and 40 hours! >Or even 1,000,000,000 and each wastes 2,000MB and 9,000 hours a year! >That would be even huger. Since you work for a defense contractor, you must be so used to wasting our tax dollars that we could not possibly expect you to be interested in any cost saving measures. The rest of us have to pay our bills ourselves. I am almost certain that you have never used a PostScript interpreter in the executive or interactive mode, and have no idea what I am talking about. Ivan N. Bach Tel (408) 986-9400, x508 QMS, Inc. Fax (408) 727-3725 2650 San Tomas Expressway arpa: ib@imagen.com Santa Clara, CA 95051 uucp: decwrl!imagen!ib
les@chinet.chi.il.us (Leslie Mikesell) (03/01/90)
In article <9465@imagen.UUCP> ib@apolling (Ivan N. Bach) writes: >I am almost >certain that you have never used a PostScript interpreter in the executive or >interactive mode, and have no idea what I am talking about. It's a pretty safe bet that he doesn't use it in the way that you implied (i.e. by typing raw postscript directly at a printers input port) since no one in their right mind would do that. What's wrong with using a computer editor (which most people would already have and know how to use) to manipulate the postscript code instead of expecting the printer to provide one? Les Mikesell les@chinet.chi.il.us
woody@rpp386.cactus.org (Woodrow Baker) (03/01/90)
In article <1990Mar1.055001.13273@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: > It's a pretty safe bet that he doesn't use it in the way that you implied > (i.e. by typing raw postscript directly at a printers input port) since > no one in their right mind would do that. What's wrong with using a computer First of all, the PS printer does not provide any kind of editor, with the exception of destructive backspace. That makes it tough to enter code directly in executive mode. In general, I use a editor to do the work. However, there is no substitte for being able to toggle into executive and watch and experiment with what things do. It's the simplest way to get a complex stack manipulation working. Cheers Woody
rcd@ico.isc.com (Dick Dunn) (03/02/90)
In article <9447@imagen.UUCP>, ib@apolling (Ivan N. Bach) writes: > >UltraScript is not an Adobe product; it is a clone PostScript interpreter > >made by Imagen/QMS. ... > I am getting tired of reading about PostScript "clones." The word "clone" > had never been used to describe the implementation of a procedural language > until Adobe started using it to refer to the implementations of the PostScript > language by other companies. Have you ever heard of a COBOL or FORTRAN clone? Without judging whether "clone" is really appropriate, let's consider why it is used here. "Clone" is used to refer to a (presumably) workalike product which is based on an existing product. Thus we speak of an "AT clone" when we're talking about "a personal computer which is intended to be a workalike to an IBM PC/AT"--where the "IBM PC/AT" part is a trademark. We don't speak of FORTRAN or COBOL clones because they are not trademarks. Cutting it a bit finer, we don't speak of Ada clones even though Ada is a trademark, because the trademark isn't based in a product. PostScript is a trademark, and there's a specific set of products behind it, and the use of the name is licensed to the creator of the original product. Certainly there are clones of other software products, and they're called "clones." It shouldn't be taken as pejorative; there certainly exist products which have been bettered by their "clones." > Have you ever heard of a proposal for a new world standard for the storing > and transmitting of image data that wastes up to 90% of the communication > channel's capacity?... No I haven't. Let's dodge the innuendo and get to the point: Is this directed at PostScript? I assume so since it was posted to this newsgroup. I'll assume that for the other innuendoes as well. But PostScript is not a "world standard for the storing and transmitting of image data." It is a page description language. Although it provides one mechanism for accepting transmitted image data, it does not preclude others. In fact, by its very programmable nature, it allows others. It says absolutely nothing about storing image data. For what PostScript is really intended to do, it might waste as much as a factor of two. Where do you get 90%? >...Have you ever heard of a modern procedural language > whose deficiencies are covered up by extending it with specific versions > of comment statements?... Wrong. If the language were extended by these comments, they wouldn't be comments, would they? The comment conventions provide information which is explicitly outside the scope of PostScript. And this IS something which has been done in other procedural languages. It is most commonly called a "pragma," although pragma covers more than that. >...Have you ever heard of a procedural language in > public domain whose most important component has been encrypted?... What part of the language is encrypted? Consider the answer carefully; I said "language," not "implementation." In fact, what is encrypted is the descriptions of the fonts, for the very simple reason that if Adobe hadn't agreed to encrypt them, they wouldn't have gotten the licenses from the typeface "manufacturers". Is this the issue? I admit I may be missing the point. >...Have > you ever heard of a procedural language in public domain whose name you > are not allowed to use when you implement that language? Yes, I have. If I go back as far as I can remember for the beginnings of such issues...I think the name you want is TRAC? Look for references to articles by/about Calvin Mooers, if I'm not mistaken...although that's a very old one, which is why I'm having trouble remembering it. Or look for work by Doug Ross way back in the early '60's. Look carefully at the terms under which "Simula" can be used. For something more modern, how about Eiffel--isn't that owned by Interactive Software (no relation to my employ- er, BTW)? If you're not hung up on procedural languages for the example, look at the various database languages with protected names. There are probably more language names which *are* trademarks than not. The designers of languages often try to protect the name from abuse until the language is established...because software products are still products and still carry issues like "brand identification." Finally, what do you mean by "public domain"? Is the definition of Post- Script in the public domain? I claim ignorance on the finer points there; I'm only trying to point out that "published" and "generally available" are not the same as "public domain." > ...If we leave it to Adobe to design our > page and document description languages, by year 2000 we will still have to > waste our time preprocessing arithmetic expressions from the usual format > supported by the first high-level procedural language into the Reverse > Polish notation in order to make it easier to interpret such expressions. But most PostScript is machine generated anyway...and normal machine trans- lation of arithmetic expressions goes through a transformation which is computationally equivalent to the transformation to postfix. Who's leaving it to Adobe, anyway? If you sit and watch, I'm sure Adobe will keep going, but what's holding you back? > The general-purpose programming part of our page description languages > will be at the level of a programmable calculator... (What's wrong with that, given where programmable calculators will be in 2000?:-) What is the PostScript language missing? >...and we will still have > to worry about doing our own gargabe collection, so that we do not run out > of virtual memory... How does this apply to PostScript? It doesn't. It is neither possible nor necessary to do garbage collection in a PostScript program, as far as I can tell. (If it were, you couldn't print a document of arbitrary length.) >...We will still have printer drivers that convert compact > image descriptions in binary format into very readable long words that are > never seen by a human being... This is confusing at best. If you're sending image descriptions to a PostScript printer, they're not terribly readable. If you don't like the level of encoding, re-encode it and let a PostScript program decode on the other end. That way you can choose whatever encoding fits. If you meant descriptions of text, line drawings, and such, and you're referring to the PostScript operators, the solution to getting rid of long names is trivial--bind short names to them (or more likely, to the specific code sequences you need which contain them). >...We will keep waiting for that readable data > to be sent over a 9600-baud communications link to a printer controller.. Maybe you will. I won't. I don't even now. My PostScript printer gets data a whole bunch faster than 9600 baud, since I hung it off the parallel port. Talk to QMS; get them to show you the PS-810...nice printer. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Don't lend your hand to raise no flag atop no ship of fools.
rodgers@csc.wcc.govt.nz (03/02/90)
In article <18027@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) writes: > In article <147@heaven.woodside.ca.us>, glenn@heaven.woodside.ca.us (Glenn Reid) writes: >> No, I think PostScript succeeded mainly because it is ASCII. People >> can understand something that they can see. People like that. A lot > > Absolutely, but I think it should be full 8 bits... Given that a) ASCII is only a 7 bit code, and b) some communication channels are only 7 bits wide, it seems like a good idea from a device independence point of view to restrict PostScript to 7 bits. It stops people with 8 bits writing code that is useless to people with only 7 bits. The reason that most people complain is because most PostScript images tend to be transmitted in hex resulting in twice as much data. What people forget is that the format of the image is not defined by PostScript. It's just that because most people are too lazy to code there own routine to read the data (readsevenbitstring??) and use readhexstring that the image is so big. We often see discussion in this newsgroup about the merits of run length encoding for images. Mostly the people who hae tried it say that it doesn't gain you anything. But on what processors? On an old 68000 based printer this is probably e true but what about the 68020 based printers? What about the 68030 or 68040 or whatever else printers that will probably come out in the future? Printer controllers are getting faster and faster while baud rates are remaining constant so it won't be long before a PostScript printer can print an image much faster than a HP-PCL printer. Unless of course HP come out with PCL level n (n > 5) that supports run length encoded images. But PostScript doesn't need any new features. We can implement whatever we like now. The strength of PostScript and why I think it has caught on is that it is a full computer language and we can do anything we like with it. -- Mark Rodgers Computer Services Section rodgers@wcc.govt.nz Wellington City Council Telephone (04) 733-130 P.O.Box 2199, Wellington, New Zealand #! rnews 1607 Relay-Version: VMS New
hwt@.bnr.ca (Henry Troup) (03/03/90)
In article <9457@imagen.UUCP> ib@apolling (Ivan N. Bach) writes: >...would be concerned about unnecessary wasting of scarce resources. I'm not aware that the resources involved are particularly scarce - in my environment. We don't generally store PostScript on disk devices - so disk space, which is not scarce here anyway, is not a wasted resource. The time to download PostScript is generally neglible with regard to the time to image it - so we don't waste a lot of time. The AppleTalk networks are multi-access, but the printers aren't, so users time is not particularly wasted either. The Unix attached PostScript engines are on dedicated serial lines that aren't used for anything else. What could be regarded as a waste is the 20K or so of PostScript preamble that most desktop publishing software (especially on Unix) includes because the imaging model of the software is not PostScript, and so a new virtual machine must be defined. That annoys me a little - but not as much as this discussion does. -- Henry Troup - BNR owns but does not share my opinions ..utgpu!bnr-vpa!bnr-fos!hwt%bmerh490 or HWT@BNR.CA
libacct@ms.uky.edu (Library Account) (03/03/90)
In article <149@heaven.woodside.ca.us>, glenn@heaven.woodside.ca.us (Glenn Reid) writes: > | True, but the degrees didn't necessarily enable them to do it. Remember, > | the concept was NOT original with them. It came from PARC..... > > So did the founders, silly, along with the original concept for PostScript. Well, the original concept for PostScript began when John Warnock was working for Dave Evans and Ivan Sutherland. E & S designed a simulator of New York harbor with full color 3-D representations of everything in it for the Maritime Academy. Rather than hard-code the database of 3-D objects in the harbor, they designed a language that would allow them do describe the objects in a text file, then compile it for use by the simulator imager. When Warnock moved to PARC, the harbor simulator design was reimplemented in a interpreted graphics experimentation workbench which they called JaM (John and Martin Newell). This system was the foundation for Interpress. After leaving PARC and starting Adobe, PostScript became Warnock's third implementation of the design. John Coppinger University of Kentucky
ifarqhar@mqccsunc.mqcc.mq.OZ (Ian Farquhar) (03/05/90)
In article <1990Feb27.215310.962@Neon.Stanford.EDU> philip@pescadero.stanford.edu writes: >This discussion is on the point of becoming silly. Meta-points about >whether it's a good discussion or not need be no longer than this. > >Some good points HAVE come out of it. Let's not stifle debate, but on >the other hand a bit of brevity would not be out of place either. I agree that this is a fascinating discussion, but it is getting out of the bounds of this newsgroup. May I suggest that a mailing group be formed (someone, preferably in the US, would moderate) to discuss PostScript extensions. I would be very interested, and I am sure that someone from Adobe would also join (Ross maybe?) Comments, please. "AI is also an acronym for Artificial Ignorance" Ian Farquhar Phone : (612) 805-7420 Office of Computing Services Fax : (612) 805-7433 Macquarie University NSW 2109 Also : (612) 805-7205 Australia Telex : AA122377 ACSNet ifarqhar@macuni.mqcc.mq.oz.au ifarqhar@suna.mqcc.mq.oz.au D