kent@xanth.UUCP (Kent Paul Dolan) (11/07/87)
Having seen two groups of well intentioned people, trying to do the best job that they can, get furious with each other, and ignoring any justice in the other's cause, I'd like to extend my sympathies to both Keith Doyle and the CATS crew. The sad part is, both sides are right. CATS is completely correct. If access to "unsupported" hooks is sanctioned by CBM, then the operating system gets frozen in whatever the state (possibly buggy) in which it was last released, or development of upgrades is made multiple times more expensive for trying to step around the non-standard accesses without breaking them. This is undesirable from everyone's viewpoint, including Keith's and mine (just a customer). Keith is ALSO completely correct. When you work in a marketplace, your potential customers won't even LOOK at your product until it is at least as good as the competition. When the sales of a package make it a "defacto standard", as is the case here, the competition is even more intense. Customers are rarely, if ever, technically sophisticated enough to understand your reasons for not doing something non-standard, when they can see it being done and being useful in your competition's package. Your management is not interested in hearing excuses, however "motherhood", from you, the developer, when the success of the product is on the line. So, rather than having the good guys fight the good guys, I suggest ganging up on the villains of the piece, the folks whose use of unsupported AmigaDOS hooks has made the whole mess what it is. All of this has to be done from CBM's side, unfortunately, but it might make all the well intentioned members of the situation happy. It does take (work = ) money, which perhaps Keith's side could supply in part. I suggest a two pronged approach. First, CBM should make an effort, with malice aforethought, in each release, to break software whose disregard of standards causes problems like this. The third or so complete rewrite of a major package should convince the bad guys to pay more attention to the rules. This does require that releases of AmigaDOS be responsive to performance problems identified by developers, and that CBM be willing to consider and, where reasonable, include, third party developed improvements to AmigaDOS, and provide a standard path for requesting those inclusions. Second, for a fee, Commodore should be willing to certify that a package meets all known CBM software standards. A sticker with this certification on the cover of a software package would (in print) inform the potential software buyer that Commodore will use this software in testing new operating system releases, and will strongly endeavor _not_ to break it with new operating system releases. (I think "guarantee not to break" might be a bit too strong, but consider it.) By requiring and rewarding truly _professional_ software development for the Amiga, Commodore immediately benefits by improving its stature as a vendor of professional quality hardware for which professional quality software is available and easily recognized as such. Folks such as Keith can now make a reasoned choice between releasing a package that will probably die in the next release, but that attracts the customers by nonstandard bells and whistles, or releasing a package with a very high probability of being useful through many AmigaDOS releases, and which uses _that_ as a feature with which to attract customers. I have no illusions that this will be easy to implement, or even easy to agree upon, but I do think it offers a workable path out of an ugly situation in which persons of good will are reduced to name calling. Good luck to all concerned. Even if you don't like these suggestions, take them as an indication that, when tempers cool, a path out of the current troubles may well exist that will be acceptable to all parties, and that it would be more fruitful to spend the present time looking for it, than continuing the current exchanges. Love to the lot of you. You _all_ make my machine the joy it is. Kent, the (occasionally rather rational) man from xanth.
jimm@mitsumi.UUCP (Jim Mackraz) (11/09/87)
In article <3258@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes:
)
)Having seen two groups of well intentioned people, trying to do the
)best job that they can, get furious with each other, and ignoring any
)justice in the other's cause, I'd like to extend my sympathies to both
)Keith Doyle and the CATS crew. The sad part is, both sides are right.
)
)CATS is completely correct.
)Keith is ALSO completely correct. When you work in a marketplace,
)your potential customers won't even LOOK at your product until it is
)at least as good as the competition.
)
)So, rather than having the good guys fight the good guys, I suggest
)ganging up on the villains of the piece, the folks whose use of
)unsupported AmigaDOS hooks has made the whole mess what it is.
)
)I suggest a two pronged approach. First, CBM should make an effort,
)with malice aforethought, in each release, to break software whose
)disregard of standards causes problems like this.
)
)Second, for a fee, Commodore should be willing to certify that a
)package meets all known CBM software standards.
)[ ... ] and will strongly
)endeavor _not_ to break it with new operating system releases.
)(I think "guarantee not to break" might be a bit too strong, but
)consider it.)
)
)Love to the lot of you. You _all_ make my machine the joy it is.
)
)Kent, the (occasionally rather rational) man from xanth.
I agree that there are two sides to these issues, and as a major flame
contributor on this topic, I acknowledge the problems that the facts
give to all concerned. The issue that gathered so much heat from
former and current C-A employees regards the causes of "buggy programs"
and a "threatening tone."
It isn't realistic to really try to break programs which rely on side
effects. In spite of the fact that some programs broke under 1.2,
the rules were that existing programs were to be "guaranteed not to break."
For unavoidable reasons, and mistakes by programmers outside and inside
C-A, some broke. I am sure the situation of any future releases will
be exactly the same: same guarantee, same problems.
An interesting note about programs and v1.2 compatibility: although
there were some disappointing compatibility problems, almost all programs
which we blew up needed to be revised to handle expansion RAM
in the same time frame, anyway. I hope nothing this major happens again.
The issue I isolate on and which troubles me is that we (when I was at C-A)
had an official position on overscan which time and resources forced us into:
it was that programs should use their own View structure to present overscan
visuals, but should attempt no interaction in this mode. This is, I believe,
exactly what DPaintII does. We also provided advice on detecting/preventing
interaction. We hoped that this was helpful, given that we felt true overscan
screens were an important hole in our capabilities.
Then we made two mistakes, it seems. One, I elected to publish, for debugging
reasons, system-private fields from IntuitionBase. Second, on free time for
Truth and Beauty, MoreRows was written and support made for it in Intuition.
It is hard for me to reckon with the fact that these resulted in people's
problems. It has changed my vote on providing Intuition source code to
registered developers. I had honestly thought that no programmer would
release a product which contained the line:
#define DONTYOUDAREMESSWITHTHESE
much less threaten to release such a program if CATS didn't provide
a suitably competitive alternative.
By the way, has anyone tried changing GfxBase->NormalDisplayRows/Columns?
GfxBase is entirely public, I believe.
jimm
--
Jim Mackraz
Mitsumi Technology, Inc. 408/980-5422
{amiga,pyramid}!mitsumi!jimmsam@utcsri.UUCP (11/11/87)
In article <3258@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes: >I suggest a two pronged approach. First, CBM should make an effort, >with malice aforethought, in each release, to break software whose >disregard of standards causes problems like this. The third or so >complete rewrite of a major package should convince the bad guys to >pay more attention to the rules. This does require that releases of I like this idea, but alas, I don't think it will work. The result will be rashes of programs that crash. For some reason, the average guy on the street does not seem to blame the program for crashing, but rather the computer itself. The Amiga had a bad reputation for crashing when it first came out, even though the major problems were due to STUPID programmers. Let's face it, a lot of companies out there do not produce very well written products. Even something as simple as closing all of your libraries after you are finished escapes many of them (Balance Of Power opens the DOS library THREE more times than it closes it!!). End result: LOTS of program crashes. Bad reputation for the Amiga Poor Amiga sales Conclusion: We will forever be in the position of trying not to hurt the people who purposely break the rules. *sigh* -- -Sam Weber "As long as people will accept crap, it will be financially profitable to dispense it" --Dick Cavett UUCP: {ihnp4 utzoo decwrl uw-beaver}!utcsri!sam ARPA: sam@csri.toronto.edu CSNET: sam@toronto
ranjit@eniac.seas.upenn.edu (Ranjit Bhatnagar) (05/11/88)
The problem: We don't have a standard for the transfer of "structured graphics," that is, pictures described as sets of drawing commands rather than as bitmaps. The primary motivation for such a standard is to allow charts, diagrams, etc. to be imported into word-processors or other programs and still be printed at the maximum resolution of a given output device. For the right sorts of pictures, this method gives not only better output, but also more efficient storage. Such a standard should provide, at a minimum, the following: arbitrary text lines and patterned lines (arbitrary thickness) rectangles and filled rectangles ovals and filled ovals polygons and filled polygons support for color inclusion of bitmaps By some coincidence, there already is such a standard: Apple QuickDraw. So called "PICT" images consist of, effectively, a script recording a sequence of calls to the graphics library. An additional potentially useful feature is the ability to insert arbitrary comments, which can be used to notate the file for human consumption, or to pass system-exclusing information. See Inside Macintosh for more details - I'm not that well informed myself. Why QuickDraw? Because it's there, already in use on millions of machines. I'll be the first to admit that it's limited - for instance, there is no support for splines, and color support is minimal. However, for a very large number of common tasks, this standard provides all the necessary power. For example: statistical or scientific graphs and charts, diagrams, simple tricks with text (for posters, letterhead, and such), simple cartoons, electronic schematics, fancy signatures, borders, many architectural plans, and more - think of anything you can do with MacDraw. There certainly should be work on a more powerful standard, one which can take advantage of more of the power of PostScript, but meanwhile, QuickDraw could come in handy. How? We would need to implement those graphics primitives available in the Mac libraries but not in the Amiga libraries: rounded rectangles, clipping to arbitrary regions, and such. There would still be a lot of function without these features, in fact, but it would be nice to have compatibility. We may also want to extend it to support operations to which we have grown accustomed on the Amiga, such as minterm block operations, and those which are supposedly coming, like Color Fonts, and expand color support. (If I'm not mistaken, Color Quickdraw has a limit of 8 colors - which isn't bad, still. It could be it was 8 bitplanes, which is more than we need (for now!).) It would be nice to have a quickdraw.library which, as a layer over the graphics.library, provides the functionality to "record" and "playback" QuickDraw images in a Mac compatible way. Given such a library, a program with the functionality of MacDraw would not be far behind. (Not to malign such programs as Aegis Draw - but sometimes these are too powerful for many uses - and besides, they can't export their graphics to a word-processor as structured graphics, which is the whole point.) QuickDraw could easily be given an IFF wrapper: take the QD data and call it 'PICT' or something like that. For purists, QuickDraw could even be stored in an IFF-like way, containing chunks like MOVE, x, y, or CIRC, x, y, r. The recursive nature of IFF would accomodate the heirarchical grouping possible in QuickDraw. But that seems like more than we need. SO: whaddya think? Please send comments to me or to c.s.amiga (or c.s.a.tech?) as you see fit. This is our chance to nip a new Standards Committee (i.e. four people flaming each other on the net) in the bud... - Ranjit (ranjit@eniac.seas.upenn.edu) === === === Pa! Molly's dead! She ate some leaves! === === === "Trespassers w" ranjit@eniac.seas.upenn.edu ucbvax!rutgers!super!eniac!... Ranjit Bhatnagar, Graduate Student Molly's not dead, she's only sleeping.
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (05/12/88)
In article <4607@super.upenn.edu> ranjit@eniac.seas.upenn.edu.UUCP (Ranjit Bhatnagar) writes: >The problem: > We don't have a standard for the transfer of "structured >graphics," that is, pictures described as sets of drawing commands >rather than as bitmaps. [ ... ] > Such a standard should provide, at a minimum, the following: > [ handwave, handwave... ] > By some coincidence, there already is such a standard: Apple >QuickDraw. [ ... ] I've got a better idea: NAPLPS. QuickDraw is a crock. QuickDraw is also Apple's puppy, and any attempt to clone it will get you sued real fast. Further, to get any details on QuickDraw or PICT format, you have to buy the _Inside Macintosh_ books, which aren't cheap. QuickDraw is standard only with respect to Apple's line of "computers", and nowhere else. On the other hand, NAPLPS will address every need for portable structured graphics you'll ever need. NAPLPS will work on CRT's or paper. NAPLPS is resolution independent, which means your drawings can be rendered at 320 x 200, or 640 x 400 overscan, or on a 3' x 6' chart at 600 dpi, and it will come out looking correct. NAPLPS is also system-independent. NAPLPS readers and writers exist for a wide variety of computer systems, including those with vector-based output devices. What's more, NAPLPS is public domain. It also happens to be an established and registered standard. You can obtain a copy of the standard for $25 from ANSI, I believe. This document will tell you everything you need to know to read and write NAPLPS files. Also, you can obtain test files to see if your reader is working correctly. There are also a number of NAPLPS bulletin boards which you can use to test your software (Prodigy isn't one of them). In short, if you want to do portable structured graphics, QuickDraw is not the way to go. It's proprietary, and far from general. You should at least look at what NAPLPS can offer you. [ Dave Hughes converted me... ] _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!pacbell -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
elg@killer.UUCP (Eric Green) (05/12/88)
in article <4607@super.upenn.edu>, ranjit@eniac.seas.upenn.edu (Ranjit Bhatnagar) says: > > The problem: > We don't have a standard for the transfer of "structured > graphics," that is, pictures described as sets of drawing commands > rather than as bitmaps. The primary motivation for such a standard > is to allow charts, diagrams, etc. to be imported into word-processors > or other programs and still be printed at the maximum resolution of > a given output device. One motivation is for interfacing with laser printers and, especially, plotters. My brother recently laid out a PC board. He used an IBM PC clone. It was the only machine around that had a program that supported his company's plotter (his company doesn't have any CAD workstations -- heck, they were laying out PC boards by hand until recently, times are tough in the oil business!). So adding an additional device to the Amiga, such as, hmm, "PLT:", which prints these vector-oriented "plottings" to a high resolution device, may be a necessity. I don't know if the printer.device could handle such output in such a manner as to not lose resolution. Another reason would be incorporation of graphics images into text files, a' la' Macintosh. This is one of the problems impeding the success of the Amiga (and PC Drones) in the desktop publishing industry. It seems immediately obvious that such files would consist of text hunks, picture hunks, and formatting hunks. And, in order to interface with high-resolution output devices, the picture hunks would need scaling information -- they most probably would not fit on a screen (I am currently working with a frame grabber card that returns full RGB pictures, and displays a HAM-mode or hires reduction of it to let you know what it generally looks like -- if there was a suitable output device, you could process camera-ready copy quite readily). I don't think that QuickDraw is the solution to the graphics images/text files problem. IFF would seem to solve that quite readily, with a couple more imbellishments. Another problem: Data transfer between CAD programs. Unfortunately, I don't think it'll happen. A drafting program has little business talking to a PC board layout program. One talks in terms of x,y and lines connecting them, along with text here and there. The other talks in terms of nodelists and such. A QuickDraw-like language might be good for data interchange between drafting programs, but I haven't seen much of a hue and cry for it. > QuickDraw could easily be given an IFF wrapper: take the > QD data and call it 'PICT' or something like that. For purists, > QuickDraw could even be stored in an IFF-like way, containing chunks > like MOVE, x, y, or CIRC, x, y, r. The recursive nature of IFF would > accomodate the heirarchical grouping possible in QuickDraw. But that > seems like more than we need. Hmm. A possibility. It does seem that we do need some IFF extensions to deal with CAD programs and desktop publishing. I'm not sure that QuickDraw is the answer, though. -- Eric Lee Green {cuae2,ihnp4}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509 "Is a dream a lie that don't come true, or is it something worse?"
karl@sugar.UUCP (Karl Lehenbauer) (05/13/88)
In article <4607@super.upenn.edu>, ranjit@eniac.seas.upenn.edu (Ranjit
Bhatnagar) writes that we need an IFF standard for images defined as
display lists and proposes Quickdraw. In Apple's litigious mood, I
believe this would guarantee a lawsuit. The request for more graphics
operations such as rounded rectangle seems reasonable. I also agree
that adherence to and support of some kind of display list-based drawing
standard is desirable, for all the reasons that have made PostScript so
popular. Perhaps Display PostScript is the answer, as Steve Jobs thinks?
On the other hand, too, the idea of knocking something out and having it,
soon, is appealing. It would have to be display resolution independent
of course.
Aegis Draw has a display list based, pannable, zoomable environment (and
file format, tho' I don't know if it's published or anything) and one
only needs to try it out to discover the down side of all this: Display
list based drawing is s l o w.
--
"Now here's something you're really going to like!" -- Rocket J. Squirrel
..!{bellcore!tness1,uunet!nuchat}!sugar!karl, Unix BBS (713) 438-5018doug-merritt@cup.portal.com (05/14/88)
Eric Green writes: >Another problem: Data transfer between CAD programs. Unfortunately, I don't >think it'll happen. A drafting program has little business talking to a PC >board layout program. [...] >A QuickDraw-like language might be good for data interchange between >drafting programs, but I haven't seen much of a hue and cry for it. Depends on who you talk to, I guess...I've heard a great *deal* of hue and cry for such a thing. Note for instance, the EDIF standard (a parser for which was released in a source newsgroup not long ago). Roger March, the author, says that it's a good partial solution, but that we still need more such standards, since EDIF is limited in scope. And from a purely logical perspective, if you're doing electronic design, you're going to want *all* of your CAD programs to be able to talk to each other. And you want them to use a standard so that you can get each component from different vendors if you want to. Which conversely is why the vendors would prefer to stick to a proprietary format if they can get away with it. Which they mostly have, until recently. Consider IFF on the Amiga. What if your digitizer image file format was incompatible with your image enhancement program, which was incompatible with your paint program, etc? I claim that compatible interchange standards *always* make sense! Except to vendors trying to practice "lock out". Doug --- Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt or ucbvax!eris!doug (doug@eris.berkeley.edu) or ucbvax!unisoft!certes!doug
lphillips@lpami.van-bc.UUCP (Larry Phillips) (05/15/88)
In <4607@super.upenn.edu>, ranjit@eniac.seas.upenn.edu (Ranjit Bhatnagar) writes: > We don't have a standard for the transfer of "structured >graphics," that is, pictures described as sets of drawing commands >rather than as bitmaps. The primary motivation for such a standard and... > Such a standard should provide, at a minimum, the following: > arbitrary text > lines and patterned lines (arbitrary thickness) > rectangles and filled rectangles > ovals and filled ovals > polygons and filled polygons > support for color > inclusion of bitmaps and... > By some coincidence, there already is such a standard: Apple >QuickDraw. So called "PICT" images consist of, effectively, a script >recording a sequence of calls to the graphics library. An additional By further coincidence, PostScript is an established standard, fits all the criteria, and in addition, is supported on a great many more machines than 'PICT'. Wouldn't it make more sense to use PostSript as the structured graphics standard of choice? I think we are going to see some amazing things this year at SIGGRAPH that will fit right in with this. -larry -- Janus? Well, look at it this way. If you squint a little, the J could be Amiga checkmark, and the rest of the word describes MsDos. +----------------------------------------------------------------+ | // Larry Phillips | | \X/ {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------+
kent@xanth.cs.odu.edu (Kent Paul Dolan) (05/15/88)
In article <5930@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >In article <4607@super.upenn.edu> ranjit@eniac.seas.upenn.edu.UUCP (Ranjit Bhatnagar) writes: >>The problem: >> By some coincidence, there already is such a standard: Apple >>QuickDraw. [ ... ] > > I've got a better idea: NAPLPS. > In short, if you want to do portable structured graphics, QuickDraw >is not the way to go. It's proprietary, and far from general. You should >at least look at what NAPLPS can offer you. I said most of this before (SLOW NEWS FEED again), so I'll be brief. Leo was right, QuickDraw is not a standard, it is a manufacturer's specification, and Apple is free to change it just to make Commodore's life miserable. Leo is also right, NAPLPS is a "blessed" standard. It's also pretty nice, some of the folks who designed it were friends of mine, so I have a copy of the draft that went for vote. But, NAPLPS is not a useful standard for a product to be sold outside North America, because it is a regional standard, not a worldwide standard. Europe and Canada/The U.S. agreed to disagree on what constituted a standard for drawing output to a TV style display. The "blessed" standard that does have the ISO world use kiss is the Computer Graphics Metafile, from ANSI X3H3. If we want the most useful one in terms of a world market, that is the one to be looking at. Kent, the man from xanth.
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (05/16/88)
In article <1760@van-bc.UUCP> lphillips@lpami.van-bc.UUCP (Larry Phillips) writes: > >In <4607@super.upenn.edu>, ranjit@eniac.seas.upenn.edu (Ranjit Bhatnagar) writes: > > By some coincidence, there already is such a standard: Apple > >QuickDraw. So called "PICT" images consist of, effectively, a script > >recording a sequence of calls to the graphics library. An additional > >By further coincidence, PostScript is an established standard, fits all the >criteria, and in addition, is supported on a great many more machines than >'PICT'. [ ... ] And. by an even more amazing coincidence, PostScript is just as inappropriate a choice as QuickDraw. "PostScript: The Inefficient Document Layout Specification Language for The Masses. Yes, PostScript is just the thing for you "power-users" with disk space, transfer bandwidth, and money just begging to be needlessly consumed. Why be efficient or clever, when you can have PostScript?" Enough immature flamage (something I'm trying to cut down on). Here's some concrete minuses for PostScript: o It's not public domain. o Adobe charges what I understand to be a hefty licensing fee for the use of PostScript in any product. o PostScript files, from what I understand, can get very large very quickly, even for relatively simple documents. o PostScript, from what I understand, doesn't know about color yet. o PostScript **may** not properly address the "structured graphics" need we're looking for, since PostScript was designed as a document layout language (font creation, manipulation, etc.). o Adobe is coming out with something called "Display PostScript". This implies that Display PostScript and vanilla PostScript found in laser printers aren't quite the same thing. We want something that works the same on all output devices. I still think NAPLPS is a better choice, if only that it will be cheaper. I'm going to order the standard from ANSI, and check it out more thoroughly. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!pacbell -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
mp1u+@andrew.cmu.edu (Michael Portuesi) (05/17/88)
> *Excerpts from ext.nn.comp.sys.amiga: 14-May-88 A Modest Proposal (IFF* > *Quic.. Larry Phillips@lpami.van (1633)* > By further coincidence, PostScript is an established standard, fits all the > criteria, and in addition, is supported on a great many more machines than > 'PICT'. Wouldn't it make more sense to use PostSript as the structured > graphics standard of choice? I think we are going to see some amazing > things this year at SIGGRAPH that will fit right in with this. And I think using PostScript as a structured graphics standard is stupid, for the following reasons: 1) PostScript is incredibly difficult to interpret. This will make using programs that use PostScript for an intermediate file storage format much more difficult to write, since you will have to interpret PostScript into a data structure that the computer can efficiently use, then reinterpret the whole thing back again when you save the picture. It makes much more sense just to save the data structure using a standardized format. 2) Often, programs will want to do intelligent things with the output of a structured graphics program. For example, a circuit analysis program can directly read a standardized file format and prepare parts lists, generate wire-wrap diagrams, and even provide circuit simulation. A chemical analysis program may be able to read an output file and translate the diagrams into chemical notation or English names. If you save the data as PostScript, how do you encode the semantic structure of these diagrams in a standardized manner so that a post-processor can make sense of it? With a structured graphics standard, it is easy to encode "objects" such as NAND gates or benzene rings. With PostScript, trying to interpret such semantic information would be next to impossible. 3) Saving an intermediate representation of an image as its printed output will be quite limiting when you want to output the picture on a device that doesn't understand that printed representation. For example, let's say you save the drawing in PostScript. Now what do you do when your application has to produce this output on the plotter? You essentially have to write a PostScript compiler whose output is the language the plotter understands. And you either have to write one of these compilers for every output device you want to support, or else write an incredibly complex "portable compiler" that can interpret PostScript and produce output for a grammar describing an output device. It is much, much simpler to simply encode the objects as geometric forms and generate the output device commands from that (which is what Aegis Draw does, if I understand correctly). Note that I am *not* belittling PostScript as a standard for graphics output. I think *any* structured graphics program worth using had better produce PostScript output. But it should also be able to adapt itself to other output devices, and using the PostScript paradigm to represent structured graphics is going to get you in big trouble in this regard. Deflector shields up, photon torpedoes standing by. --M Michael Portuesi / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "Memories are uncertain friends, when recalled by messages" -- OMD, "Messages"
mp1u+@andrew.cmu.edu (Michael Portuesi) (05/17/88)
Despite the fact my last message popped up on comp.sys.amiga (we all make
mistakes), could we move this discussion to .tech? That's exactly the reason
the newsgroup was created in the first place, we might as well use it for that
purpose.
--M
Michael Portuesi / Carnegie Mellon University
ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas
"Memories are uncertain friends, when recalled by messages" -- OMD, "Messages"paolucci@snll-arpagw.UUCP (Sam Paolucci) (05/17/88)
In article <5967@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >In article <1760@van-bc.UUCP> lphillips@lpami.van-bc.UUCP (Larry Phillips) writes: >> >>In <4607@super.upenn.edu>, ranjit@eniac.seas.upenn.edu (Ranjit Bhatnagar) writes: >> > By some coincidence, there already is such a standard: Apple >> >QuickDraw. So called "PICT" images consist of, effectively, a script >> >recording a sequence of calls to the graphics library. An additional >> >>By further coincidence, PostScript is an established standard, fits all the >>criteria, and in addition, is supported on a great many more machines than >>'PICT'. [ ... ] > > And. by an even more amazing coincidence, PostScript is just as >inappropriate a choice as QuickDraw. > > "PostScript: The Inefficient Document Layout Specification Language >for The Masses. Yes, PostScript is just the thing for you "power-users" with >disk space, transfer bandwidth, and money just begging to be needlessly >consumed. Why be efficient or clever, when you can have PostScript?" > > Enough immature flamage (something I'm trying to cut down on). >Here's some concrete minuses for PostScript: I guess we will now have to list hearsay presented as fact. > o It's not public domain. TRUE. So what? > o Adobe charges what I understand to be a hefty licensing fee for > the use of PostScript in any product. Definitely TRUE. > o PostScript files, from what I understand, can get very large very > quickly, even for relatively simple documents. Maybe or maybe not. If you include bitmaps in them, then they are definetely larger, but if you include only structured graphics then it is not true. > o PostScript, from what I understand, doesn't know about color yet. Definitely FALSE. > o PostScript **may** not properly address the "structured graphics" > need we're looking for, since PostScript was designed as a > document layout language (font creation, manipulation, etc.). False. PostScript handles structured graphics very well, thank you. > o Adobe is coming out with something called "Display PostScript". > This implies that Display PostScript and vanilla PostScript found > in laser printers aren't quite the same thing. We want something > that works the same on all output devices. FALSE. The only difference is that one outputs to displays while the other to printers. > > I still think NAPLPS is a better choice, if only that it will be >cheaper. I'm going to order the standard from ANSI, and check it out more >thoroughly. > >_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ >Leo L. Schwab -- The Guy in The Cape ihnp4!pacbell -\ > \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac >O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") >"Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor Leo, NAPLPS may be the better choice (I don't now very much about it), but certainly NOT because of your arguments. I suggest that before making such criticisms (that show that you do not know the first thing about PostScript) you should educate yourself a little about it, and then make an informed evaulation. -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (05/17/88)
In article <5967@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > "PostScript: The Inefficient Document Layout Specification Language >for The Masses. Yes, PostScript is just the thing for you "power-users" with >disk space, transfer bandwidth, and money just begging to be needlessly >consumed. Why be efficient or clever, when you can have PostScript?" > > [ obvious line noise deleted ] This moron obviously hasn't read the specs for NAPLPS *or* PostScript, so what gives him the right to say one is better than the other. I won't even dignify your "concrete minuses" for PostScript by refuting them. If you want to comment on structured graphics, then kindly read the specification for the standard you're supporting or refuting. Otherwise, you're just spouting drivel. Personally, I think you should stick to demos and animations, since that's all you seem to be qualified for... >_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ >Leo L. Schwab -- The Guy in The Cape ihnp4!pacbell -\ > \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac >O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") >"Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
doug-merritt@cup.portal.com (05/18/88)
Michael Portuesi writes:
<With a structured graphics
<standard, it is easy to encode "objects" such as NAND gates or benzene rings.
<With PostScript, trying to interpret such semantic information would be next to
<impossible.
This is a great point; very insightful and forward thinking. Thanks
Michael!
<Note that I am *not* belittling PostScript as a standard for graphics output.
<I think *any* structured graphics program worth using had better produce
<PostScript output.
Sounds perfectly reasonable. PostScript is useful, but we'd be better
off with something like a high level object oriented description language.
Benzene rings...ah, that would be great.
Doug
---
Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt
or ucbvax!eris!doug (doug@eris.berkeley.edu)
or ucbvax!unisoft!certes!douglphillips@lpami.van-bc.UUCP (Larry Phillips) (05/18/88)
In <5967@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >In article <1760@van-bc.UUCP> lphillips@lpami.van-bc.UUCP (Larry Phillips) writes: >> >>In <4607@super.upenn.edu>, ranjit@eniac.seas.upenn.edu (Ranjit Bhatnagar) writes: >> > By some coincidence, there already is such a standard: Apple >> >QuickDraw. So called "PICT" images consist of, effectively, a script >> >recording a sequence of calls to the graphics library. An additional >> >>By further coincidence, PostScript is an established standard, fits all the >>criteria, and in addition, is supported on a great many more machines than >>'PICT'. [ ... ] > > And. by an even more amazing coincidence, PostScript is just as >inappropriate a choice as QuickDraw. Well, it would appear that we are both all wet. It has been pointed out in few other messages that as a structured graphic standard, a display protocol such as PostScript or NAPLPS falls somewhat short of the mark. I don't know if QuickDraw is only a display protocol or a structured graphics description standard, so I don't have much to say about that, but do have more to say about NAPLPS vs. PostScript. > "PostScript: The Inefficient Document Layout Specification Language >for The Masses. Yes, PostScript is just the thing for you "power-users" with >disk space, transfer bandwidth, and money just begging to be needlessly >consumed. Why be efficient or clever, when you can have PostScript?" Disk space and transfer bandwidth? You wouldn't be confusing the resources required to store/send a bitmap with the interpreter to build it would you? If I were you, I'd check out the NAPLPS spec before coming down too hard on PostScript for these reasons. One of the biggest drawbacks of NAPLPS is that is it not a language. You can tell the display what to show, but there are no control structures or calculating abilities. This feature alone in PostScript makes it a better choice for bandwidth savings. > Enough immature flamage (something I'm trying to cut down on). Good idea. My IFF reader doesn't understand the FLAM chunk. >Here's some concrete minuses for PostScript: > o It's not public domain. No, it isn't, but any derivative work is. You can't call it PostScript, but what's in a name anyway? > o Adobe charges what I understand to be a hefty licensing fee for > the use of PostScript in any product. I don't know the details of Adobe's licensing fee, but you get what you pay for. With NAPLPS, it works out to at least the same proce/performance ratio. For your NAPLPS fee, you get a limited, fairly primitive, standard that not only is unacceptable to the rest of the world, but that has been tried and dropped by bigger outfits than CBM, Apple or Adobe. Last I heard there were probably three special purpose information services left in Canada, and maybe one in the US that still piss against the wind with NAPLPS, and perhaps a half dozen BBS's that still have some NAPLPS picture files hanging around. With PostScript, you get a fairly well thought out presentation protocol that is in wide use, and getting more popular all the time, on both hard media and video. > o PostScript files, from what I understand, can get very large very > quickly, even for relatively simple documents. Depends on what you're doing. Yes, a bitmap can get huge, but then so can the raw, or even the compressed representation of that same bitmap. Most PostScript files are quite small. I wrote a small PostScript program to output a PCB layout consisting of three, three-slot XT backplanes (just the bus connections and pads. I can't remember the exact figure, but the program was around 250 bytes. Try that in NAPLPS, where you would have to describe each individual element in the display. With PostScript, it was simply a matter of defining a pad (circuit board pad), two traces, and algorithmically drawing as many as I needed, where I needed them. > o PostScript, from what I understand, doesn't know about color yet. PostScript knows about colour. NeWS is effectively PostScript with extensions, and colour is included in the part of it that's compatible with PostScript. The reason you don't see colour mentioned much is for the same reason that you don't see IFF mentioned much. Apple and IBM users don't have much use for it. Be sure to attend SIGGRAPH this year and wander by the Ameristar stuff. Ask to see a typical NeWS program. Strap your socks on. > o PostScript **may** not properly address the "structured graphics" > need we're looking for, since PostScript was designed as a > document layout language (font creation, manipulation, etc.). NAPLPS does not support 'structured graphics', unless you limit yourself to the graphic primitives like arc, cirle, line, etc. PostScript at least allows you to define a procedure which describes a graphic object. Since we are speaking of a display protocol here only, it's sort of a moot point within the whole discussion of what's needed in a structured graphic standard. NAPLPS was designed as a TV display language. > o Adobe is coming out with something called "Display PostScript". > This implies that Display PostScript and vanilla PostScript found > in laser printers aren't quite the same thing. We want something > that works the same on all output devices. Don't know much about Display PostScript, except to say that since Apple rejected it, it can't be all bad. :-) > I still think NAPLPS is a better choice, if only that it will be >cheaper. I'm going to order the standard from ANSI, and check it out more >thoroughly. It will be cheaper alright. But then so are character set graphics. I have the spec right here beside me. I haul it out once in a while and attempt to wade through it. It's ANSI X3.110-1983, or CSA T500-1983. When you do get it, let me know when you are about to read it, so I can get out of the way when you barf. :-) -larry -- Janus? Well, look at it this way. If you squint a little, the J could be Amiga checkmark, and the rest of the word describes MsDos. +----------------------------------------------------------------+ | // Larry Phillips | | \X/ {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------+
lphillips@lpami.van-bc.UUCP (Larry Phillips) (05/18/88)
In <AWXpWzy00Uo6A0QEVI@andrew.cmu.edu>, mp1u+@andrew.cmu.edu (Michael Portuesi) writes: >And I think using PostScript as a structured graphics standard is stupid, for >the following reasons: > <a lot of good reasons deleted> You're probably right. I wasn't thinking of going the other way, from a PostScript file back to data useful within the program that generated it. >Deflector shields up, photon torpedoes standing by. Why? -larry -- Janus? Well, look at it this way. If you squint a little, the J could be Amiga checkmark, and the rest of the word describes MsDos. +----------------------------------------------------------------+ | // Larry Phillips | | \X/ {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------+
tws@beach.cis.ufl.edu (Thomas Sarver) (05/18/88)
In article <4607@super.upenn.edu> ranjit@eniac.seas.upenn.edu.UUCP (Ranjit Bhatnagar) writes: |The problem: | We don't have a standard for the transfer of "structured |graphics," that is, pictures described as sets of drawing commands |rather than as bitmaps. The primary motivation for such a standard |is to allow charts, diagrams, etc. to be imported into word-processors |or other programs and still be printed at the maximum resolution of |a given output device. | | - Ranjit (ranjit@eniac.seas.upenn.edu) I think HP has a standard for their plotters which does quite a few of the things you are talking about. Also Postscript is great for describing pics. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ But hey, its the best country in the world! Thomas W. Sarver "The complexity of a system is proportional to the factorial of its atoms. One can only hope to minimize the complexity of the micro-system in which one finds oneself." -TWS Addendum: "... or migrate to a less complex micro-system."
scott@applix.UUCP (Scott Evernden) (05/18/88)
In article <15634@uflorida.cis.ufl.EDU> tws@beach.cis.ufl.edu () writes: >In article <4607@super.upenn.edu> ranjit@eniac.seas.upenn.edu.UUCP (Ranjit Bhatnagar) writes: >|The problem: >| We don't have a standard for the transfer of "structured >|graphics," > >I think HP has a standard for their plotters which does quite a few of the >things you are talking about. Also Postscript is great for describing pics. I was waiting for someone to say HPGL. Pleez, you CANNOT describe a picture with HPGL; you can merely render it. The same is true of CGM and NAPLPS and PostScript and many others mentioned here. There is no concept of "objects" in any of these. Attempting to derive structured graphics data from these formats is an exercise in AI. If you study something like Adope Illustrator, you will see that even the inventors of PostScript do not use it, per say, to store structured graphics information. Illustrator cannot import random PostScript files. What they use are a set of PostScript DEFs made up to cutely "contain" the structured graphics info which they have decided they needed. You would have to clearly define these if you intend to promulgate PostScript as the interchange vehicle. The problem with attempting to come up with a universally accepted standard is that you need to get everyone to agree to it- if the standard doesn't account for the types of information which are critical to my CAD application (say 3D or sheared bitmaps, for example), then I'm likely not to use it. This is why ANSI and ISO have had so much trouble agreeing on and getting everyone to use CORE, GKS, PHIGS, etc., etc. etc. You need facilities to describe grouping, layers, fillets, constraints, etc. This is the stuff of Modelling. Information regarding clipping, viewports, etc., is the stuff of Viewing/Imaging, which is a very different beast. The folx in comp.graphics would probably be able to enlighten us all... -scott
doug-merritt@cup.portal.com (05/19/88)
Leo 'Bols Ewhac' Schwab writes: > "PostScript: The Inefficient Document Layout Specification Language >for The Masses. Yes, PostScript is just the thing for you "power-users" with >disk space, transfer bandwidth, and money just begging to be needlessly >consumed. Why be efficient or clever, when you can have PostScript?" Leo then flames himself: >This moron obviously hasn't read the specs for NAPLPS *or* PostScript, >so what gives him the right to say one is better than the other. [...] >Personally, I think you should stick to demos and animations, since >that's all you seem to be qualified for... I have mixed feelings about this. On the one hand, if in addition to the standard flaming of *other* people, everyone also starts flaming *themselves*, then the amount of net bandwidth consumed could rise exponentially. On the other hand, maybe if everyone flames themselves, other people won't bother, since it's already been done so well, so maybe it'll actually cut *down* on the amount of wasted bandwidth. What do you think? Oh, Leo says "yes.". Now Leo says "no." Now Leo says, "Leo, you ignorant sl*t..." Hey guys, could you straighten this out with yourself/yourselves via email??? :-) :-) Doug --- Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt or ucbvax!eris!doug (doug@eris.berkeley.edu) or ucbvax!unisoft!certes!doug
pds@quintus.UUCP (Peter Schachte) (05/19/88)
In article <162@snll-arpagw.UUCP>, paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: > In article <5967@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > > o It's not public domain. I don't know what domain postscript is in, but last I heard there was nothing to stop anyone from writing their own postscript interpreter. I don't believe Adobe OWNS postscript, they just invented it. There is a set of books defining the language. > > o Adobe charges what I understand to be a hefty licensing fee for > > the use of PostScript in any product. Adobe does charge, I'm told, a hefty fee for the use of THEIR postscript interpreter. If you write your own, they don't. I'm not positive of this, can anyone confirm it? -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
richard@gryphon.CTS.COM (Richard Sexton) (05/19/88)
In article <703@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes: >In article <15634@uflorida.cis.ufl.EDU> tws@beach.cis.ufl.edu () writes: >>I think HP has a standard for their plotters which does quite a few of the >>things you are talking about. Also Postscript is great for describing pics. > >I was waiting for someone to say HPGL. Pleez, you CANNOT describe a picture >with HPGL; you can merely render it. The same is true of CGM and NAPLPS and >PostScript and many others mentioned here. There is no concept of "objects" >in any of these. Attempting to derive structured graphics data from these >formats is an exercise in AI. While this is true, it's not germain to the issue. It was my understanding that we were just trying to get an object oriented IFF standard, and while ones definitionof an object can vary, any of the mantioned standards will fit the bill. You sounf like you're waiting for phigs, which is far far beyond the scope of what I understand we are trying to accomplish here. >If you study something like Adope Illustrator, you will see that even the >inventors of PostScript do not use it, per say, to store structured graphics >information. Illustrator cannot import random PostScript files. What they >use are a set of PostScript DEFs made up to cutely "contain" the structured >graphics info which they have decided they needed. You would have to clearly >define these if you intend to promulgate PostScript as the interchange vehicle. I'm no expert on Illustrator, but cant it import Encapsulated PostScript files ? >The problem with attempting to come up with a universally accepted standard >is that you need to get everyone to agree to it- if the standard doesn't >account for the types of information which are critical to my CAD application >(say 3D or sheared bitmaps, for example), then I'm likely not to use it. >This is why ANSI and ISO have had so much trouble agreeing on and getting >everyone to use CORE, GKS, PHIGS, etc., etc. etc. Sheesh. Somebody else want Dore, or Tek 4125. >You need facilities to describe grouping, layers, fillets, constraints, etc. >This is the stuff of Modelling. Information regarding clipping, viewports, >etc., is the stuff of Viewing/Imaging, which is a very different beast. Uhhh, PS does this. >The folx in comp.graphics would probably be able to enlighten us all... The group is dead. While it used to be about graphics, people have all gone out anf bought their own graphics machines and all that comp.graphics does any more is: 1) Answer a) where can I get refereces to ray tracing b) how do I convert RGB --> CMY c) can somebody tell me about fractals 2) Answer questions about computational geometry. The group is all but useless; there is no significantly greater level of experise there than here. -- Have a nice day or Klortho will rip your nuts off. richard@gryphon.CTS.COM rutgers!marque!gryphon!richard
keithd@cadovax.UUCP (Keith Doyle) (05/20/88)
In article <5979@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: .In article <5967@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: .> "PostScript: The Inefficient Document Layout Specification Language .>for The Masses. Yes, PostScript is just the thing for you "power-users" with .>disk space, transfer bandwidth, and money just begging to be needlessly .>consumed. Why be efficient or clever, when you can have PostScript?" .> [ obvious line noise deleted ] . This moron obviously hasn't read the specs for NAPLPS *or* .PostScript, so what gives him the right to say one is better than the other. .I won't even dignify your "concrete minuses" for PostScript by refuting .them. Leo, you're talking to yourself! Maybe you should seek the assistance of a good Eliza program! :-) Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170 -------------------------------------------------------- "Stay calm. Everything will be all right." -THX 1138 --------------------------------------------------------
bakken@hrsw2.UUCP (David E. Bakken) (05/20/88)
In article <5967@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > Here's some concrete minuses for PostScript: I'm certainly no PostScript expert or evangalist, but I'd like to respond to a few of Leo's points. > o It's not public domain. That's an interesting question - see the thread in comp.lang.postscript from March if you still have it around. People have been complaining about Adobe's practices. The most interesting point I saw made on that was from message <4240@hoptoad.uucp> (25 Mar 88) }} However, in the prospectus from their public stock offerring of }} August 13, 1987, they said, "Since one of the company's goals is to }} promote the PostScript language as a standard for the representation of }} the printed page, the company placed the PostScript language in the }} public domain and the company therefore derives no revenue from the use }} of the PostScript language by third parties." > o Adobe charges what I understand to be a hefty licensing fee for > the use of PostScript in any product. I've read that the cost of licensing PostScript and adding the extra computational horsepower to deal with it adds $2K to the price of a laser printer. But at the GNU BOF at February's Dallas USENIX Len Tower (I think that was his name) mentioned something about a postscript interpreter. That would be really nice as it shouldn't be that hard to write a back end to the postscript-bitmap for an Epson compatible or even an HP Deskjet or Paintjet. > o PostScript, from what I understand, doesn't know about color yet. Yes it does, and I understand it has from the beginning. The command is setrgbcolor. > o Adobe is coming out with something called "Display PostScript". > This implies that Display PostScript and vanilla PostScript found > in laser printers aren't quite the same thing. We want something > that works the same on all output devices. Its my understanding that Display Postscript is Adobe's answer to NeWS. It is a PostScript interpreter and will be used by many vendors that offer The X Window System and I think also by Steve Jobs' NEXT. The people I have talked to that are very knowledgable with both NeWS and X like NeWS better because it is a much more complete windowing environment. And this seems to be the general (although certainly nowhere near unanimous) sentiment that has come out of the "X vs NeWS" wars in the appropriate newsgroups. Yes, PostScript is slow. -- Dave Bakken Boeing Commercial Airplanes (206) 277-2571 uw-beaver!apcisea!hrsw2!bakken Disclaimer: These are my own views, not those of my employers. Don't let them deter you from buying the 747 you've been saving hard for.
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (05/21/88)
[ Surf Nazis Must Die! ] In article <5589@cup.portal.com> doug-merritt@cup.portal.com writes: >Leo 'Bols Ewhac' Schwab writes: >>[ handwave, handwave ] > >Leo then flames himself: >>[ blah blah blah mother was a computer blah blah blah father was a >>librarian blah blah blah weird dress habits blah blah blah ] > >I have mixed feelings about this. On the one hand, if in addition to >the standard flaming of *other* people, everyone also starts flaming >*themselves*, then the amount of net bandwidth consumed could rise >exponentially. [ ... ] > >What do you think? Oh, Leo says "yes.". Now Leo says "no." Now Leo >says, "Leo, you ignorant sl*t..." > There is actually a reason for this strange behavior. Shortly after posting my anti-PostScript message, I received a call from Richard "His toilet works fine now" Sexton :-). He calmly, coherently, and civilly (if you can believe it) refuted every point I made against PostScript. After the conversation, it struck me rather clearly that if I'm going to go around and rant and rave (something I enjoy doing from time to time), I'd damn well better know what I'm ranting and raving about. Richard made it quite clear to me that, other than knowing about its FORTH-like syntax, I don't know the first thing about PostScript. Further introspection revealed that I don't know much about NAPLPS, either, except was was imparted to be my Dave Hughes at the West Coast Computer Faire. See, Dave showed me what NAPLPS was, and to illustrate a point, brought up a NAPLPS drawing program and proceeded to create a picture. I watched him use the program, and thought to myself, "Gee, this looks a lot like MacDraw. Maybe NAPLPS can address our need for structured graphics." Now Richard informs me that NAPLPS isn't nearly as general as PostScript, and someone else further asserted that PostScript may not be what we're looking for, either. So I'm going to shut up and watch you guys for a while. However, I may emerge in a little while and tell you all how wonderful Pixar's new RenderMan (tm) specification is, since I just picked up a copy of it and am still reading it... Totally Unrelated Point: We recently passed article #20000 on comp.sys.amiga here on The WELL. Kinda mind boggling, in a way... _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!pacbell -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
david@ms.uky.edu (David Herron -- One of the vertebrae) (05/24/88)
In article <995@sandino.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >In article <162@snll-arpagw.UUCP>, paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >> In article <5967@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >> > o It's not public domain. >I don't know what domain postscript is in, but last I heard there was >nothing to stop anyone from writing their own postscript interpreter. >I don't believe Adobe OWNS postscript, they just invented it. There >is a set of books defining the language. I suggest you read up a little bit. PostScript is definitely owned by Adobe. The set of books was written by Adobe. etc, etc. On the other hand. There are two PD postscript interpretors which I know of. The first was written in 68k assembly language specifically for Amiga's. It's supposedly slow and incomplete, but I've never used it. The other came through the comp.sources.unix group late last fall. It's the same sort of thing as Display Postscript, but I see no reason why a driver couldn't be written for it which drove some sort of printer. It's somewhat portable, but is written for Unix. I don't know if it's portable enough to run on an Amiga. It's written to be able to support a variety of displays. It's a large package ... I don't know offhand if it's very complete or not. >I'm not positive of this, can anyone confirm it? I'm certain of what I just said. -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- SKA: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <---- <---- Goodbye RAH.
nfs1675@dsacg2.dsac.dla.mil (Michael Figg) (04/06/90)
In article <1990Apr04.230225.6232@csuchico.edu>, mrush@csuchico.edu (Matt Rush) writes: > In article <1990Apr4.211334.173@caen.engin.umich.edu> chrisl@caen.engin.umich.edu (Chris Lang) writes: > >In article <3482@pikes.Colorado.EDU> dchilds@pikes.Colorado.EDU (David W. Childs) writes: > >"UNIX is a registered footnote of AT&T Bell Labs." > > Gee, in a systems design book I had last semester, 'Unix' was a > registered trademark of Digital Equipment Corporation. My, how things change > :-) :-) :-) I checked eight different 'C' and UNIX books that I have and they all credit UNIX to AT&T Bell Labs, as expected. Are sure this wasn't ULTRIX that was credited to DEC? Mike