mp1u+@andrew.cmu.edu (Michael Portuesi) (05/12/88)
[this discussion thread moved to .tech from .amiga] ranjit@eniac.seas.upenn.edu (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. Amazing, isn't it, that no such standard exists? Are there any structured graphics editors for the Amiga besides Aegis Draw and the commercial version of mCAD (I forget its name)? > By some coincidence, there already is such a standard: Apple > QuickDraw. See Inside Macintosh for more details - I'm not that well > informed myself. The Macintosh PICT format is documented, but for debugging purposes only. PICT is to be used by applications insofar as the Apple ROMS provide support for them. Applications are advised not to write their own PICT files directly, as Apple can (and does) change the format with successive releases of the System file. (no, I am not a fountain of information on macintoshes -- I just have lots of friends who are) > Why QuickDraw? Because it's there, already in use on millions > of machines. For the above reason, an Amiga drawing editor cannot be compatible with Macintosh PICT files. So we're probably better off designing something from scratch. > 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. Let's do it right the first time. > (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!).) Color QuickDraw has support for more than eight colors. A recent color board for the Mac SE supports 16 out of 4096 colors (sound familiar?) and uses Color QuickDraw. I am not exactly sure what the capabilities of Color QuickDraw are; time to go seek out one of my MacFriends. > (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.) Aegis Draw also has no notion of what PostScript is, which makes it doubly useless since your output options are terribly limited. > 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... I for one would like to see some discussion on this topic. This topic is much less nebulous than IPC; perhaps a flame war will not ensue. I am currently starting work on a draw program to meet the course requirements for a Computer Graphics class I took; it occurs to me that this program could actually be a useful tool, given enough work. I would like to see it incorporate some sort of structured-graphics standard and offer PostScript output as well. --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"
rminnich@udel.UUCP (05/12/88)
In article <4WWCvzy00VoDA-hXlh@andrew.cmu.edu> mp1u+@andrew.cmu.edu (Michael Portuesi) writes: >Amazing, isn't it, that no such standard exists? Are there any >structured graphics editors for the Amiga besides Aegis Draw and the >commercial version of mCAD (I forget its name)? There was a discussion of the Aegis internal format about a year ago. You could try to use that. I think Leo is on the money with the NAPLPS suggestion. Check out the Byte issues of circa 1982/1983 for their two-part article on NAPLPS. It is a real nice design. Should we call it NPLP or NAPL or ... ? Infinite resolution would be a nice way to go ... -- ron (rminnich@udel.edu)
plav@cup.portal.com (05/14/88)
In message <2512@louie.udel.EDU> rminnich@udel.EDU (Ron Minnich) writes: > There was a discussion of the Aegis internal format about > a year ago. You could try to use that. I think Leo is on the > money with the NAPLPS suggestion. Check out the Byte issues of circa > 1982/1983 for their two-part article on NAPLPS. It is a real nice > design. Should we call it NPLP or NAPL or ... ? > Infinite resolution would be a nice way to go ... The articles in question make excellent reading: February 1983, vol 8, no 2, "NAPLPS: A New Standard for Text and Graphics, Part 1: Introduction, History, and Structure" and March 1983, vol 8, no 3, "NAPLPS: Part 2: Basic Features". Also, July 1983, vol 8, no 7, "NAPLPS Standard Graphics and the Microcomputer." > ron (rminnich@udel.edu) Rick Plavnicky plav@cup.portal.com
root@sbcs.sunysb.edu (SBCS Systems Staff) (05/15/88)
In article <969@sandino.quintus.UUCP>, pds@quintus.UUCP (Peter Schachte) writes: > How about postscript? If the amiga spoke postscript directly to screen, > you'd have resolution-independence, and compatibility with a popular > page description language for printers. Sure would make laser printer > previewers easier to write! > -- > -Peter Schachte > pds@quintus.uucp > ...!sun!quintus!pds Ameristar will be marketing a version of Sun Microsystems NeWS network window system starting this Summer. NeWS is based on the Postscript imaging model, and has a PostScript interpreter built into it. I will not say much more, as I really don't want this posting to get too commercial. Rick Spanbauer Ameristar, Inc
paolucci@snll-arpagw.UUCP (Sam Paolucci) (05/16/88)
In article <969@sandino.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >In article <2512@louie.udel.EDU>, rminnich@udel.EDU (Ron Minnich) writes: >> ... I think Leo is on the >> money with the NAPLPS suggestion. ... It is a real nice >> design. > >How about postscript? If the amiga spoke postscript directly to screen, >you'd have resolution-independence, and compatibility with a popular >page description language for printers. Sure would make laser printer >previewers easier to write! >-- >-Peter Schachte >pds@quintus.uucp >...!sun!quintus!pds Sounds like to me that you would like to see NeWS on the Amiga. It's possible that someone may announce it in the not too far future :-). -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
richard@gryphon.CTS.COM (Richard Sexton) (05/16/88)
In article <5251@xanth.cs.odu.edu> kent@xanth.UUCP (Kent Paul Dolan) writes: > >I suggest, rather than using a non-standard such as Postscript (what Non standard ? Just get back from Mars, Kent ? Did you bring me anything ? >Good does it do you going to a flatbed plotter, for example), you >choose the actual international structured graphics standard from ISO >and ANSI, the Computer Graphics Metafile, and let a CGM to Postscript >cconverter (there are sure already to be several available) take care >of those microcomputer add-ons that grok Postscript. I'm not terribly >familiar with Postscript, but I don't have the impression that it is >designed to be invertible back to a useful form for internal display >list processing, as is CGM. I've looked at CGI/CGM and PostScript. The sheer size of the CGI spec almost virtually guarentees nobody will read it. It's SOOOO comprehensive, it almost requires being split up into a dozen volumes. Graphics 'standards' are fun. You have your formal standards, like SIGGRAPH core, GKS, CGI/CGM, which cover everything, but almost nobody uses. Look at CORE. It was agreed upon by all of SIGGRAPH, and you would think that would guarentee all the industry graphics weenines would use it. How many graphics applications were written for CORE ? Now look at how many graphics applications were written for IBM PC EGA. Not much of a standard, but people have it and people use it. It's a de facto standard. Just like PostScript. EGA is dying, PS is doing quite well, and doing better all the time. >"Standardization" on a >non-standard like Postscript is just a way for the Amiga community to >paint itself into a corner and isolate itself from the mainstream >workstation market toward which the hardware line seems to be aiming >itself. PostScript is virtually the only reason the Mac has done so well. Lots of peripherals speak PS, from lowly 300 dpi lasers to 2500+ dpi phototypesetters and now there are even color thermal and color laser PS printers. Given that an IFF/PS file could be generated on an amiga and transported to any of these devices, I just cant see how we would be "painting ourselves in a corner". Maybe you could explain this to me, Kent ? >One of the players with whom we must compete eventually, Sun, has >itself poised squarely in the mainstream, with product efforts in GKS, >CGM, CGI, PHIGS, and perhaps PHIGS+; I'm not aware of any IGES work Thats great, Kent, but how many packages under $5000 use any of those standards ? Bugger all. How many devices speak those languages ? Bugger all. >mention my too often mentioned IRA! ;-) Right now this looks like a >trireme that finally hired on a drummer, so all the oars are stroking >in rhythm and the vessel is moving ahead fairly quickly, but has not >yet gotten itself either steersman or lookout. You sound like you spent too much time in a submarine, Kent :-) My main objection of CGI/CGM (IMHO the most managable of the standards Kent mentioned) is that its a "standard by comittee", and has a function for everything - lessee, whats the opcode dor set a transparent dashed border for convex pink polygones on surface 1, priority 4, warp 6, captain to enterprise, 2 to beam up Mr. Scott. In covering ALL the bases, they built something so goddamn bloated you need a Sun 4 to run it. Combine that with the fact that the standard isn't finished yet, and there are ZERO devices that speak it, and ZERO screen display systems that use it directly it seems like a poor choice. What is attractive about the PS imaging model is that it embodies a rich set of primatives upon which anything can be built. Several people seem to think I'm advocating NeWS and/or incorperating postscript commands into IFF files. No. Just developing an IFF format that has a direct 1 to 1 correspondence to postscipt primitives, such as line type, clipping paths, translation, scaling, rotation and the such. -- And other people run red lights, too. richard@gryphon.CTS.COM rutgers!marque!gryphon!richard
u-jmolse%sunset.utah.edu@utah-gr.UUCP (John M. Olsen) (05/18/88)
There are a couple of points that have not been mentioned as everyone has
been lining up on one side of the fence or the other with regard to the
usability of PostScript.
It is in fact a complete language, and you can write ANY program in PS if
you want to. For example, it would be possible to write a ray tracer that
ran inside the printer and generated output directly. If you have a PS
printer that accepts color commands (MUCH $$) and has better than 300 dpi
(MUCH MORE $$) then you could generate high quality images without the use
of a crt.
PostScript is a postfix language (hence, the name) so it is interpreted
instead of compiled, but I will leave the pros/cons of this alone for now.
The fact that PS is a fairly reasonable page layout language should not
trick you into thinking that it is *only* a page layout language. How many
times have you had to explain that the Amiga is not *just* a neat game
machine?
It is expensive, and it can be slow under some conditions (just like some
computers...) but it deserves a bit more attention than "Oh, yea. I've
heard about PostScript."
/| | /||| /\| | John M. Olsen
\|()|\|\_ |||. \/|/)@|\_ | 1547 Jamestown Drive
| | Salt Lake City, UT 84121-2051
u-jmolse@ug.utah.edu or ...!ihnp4!utah-cs!utah-ug!u-jmolseJulian@cup.portal.com (05/18/88)
Is anyone familiar with the object oriented graphics standard called
DXF? I have used many CAD packages in my work (mainly IBM packages) and
most of them seem to support the DXF standard. As I understand the format,
it seems so support many of the features that this discussion seems to be
looking for.
I am not sure if it is in the public domain, or if some company owns
the rights to the source. AutoDesk heavily supports the standard in all
of its software.
I hope this helps.
Julian L. Brown
sun!portal!cup.portal.com!julian
DJULE@TUCC.BITNETrichard@gryphon.CTS.COM (Richard Sexton) (05/19/88)
In article <53552@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <132@amtfocus.UUCP> jeffle@amtfocus.UUCP (Jeff Leitheiser) writes: >> I agree that there NEEDS to be ONE standard for storing semi-intelligent >> graphics....is postscript the answer? I'm not an expert on postscript, >> but what about 3D objects? Yes, most of what people do today is 2D, but >> the real power of computer graphics is the use of 3D models that you >> can build, rotate, and analyze BEFORE you worry about the traditional >> 1,2,3 or 4 view drawing... > >Whoa! There are several problems here that everyone is trying to solve >with *one* solution. (You may recall during the IPC discussion the same >phenomena occurred). The two big ones in Jeff's message are "rendering >to the screen" and "storing object definitions". > >Rendering to the Screen : > >The Amiga screen rendering routines are raster based and fast. This >works well with the screen because they operate at the full resolution >of the screen. This is not true for printers because chances are that >the routines do *not* work at the printers resolution. Apple's solution >to this (which is the current yardstick) was to define a set of >graphic primitives that were implemented in *both* the machine and >the printer. Each rendering to the hosts resolution. They also included >a quickdraw to PostScript translation scheme so that the images could be >sent to the LaserWriter as well. (Anyone remember InterPress?) Anyway, >the problem is to provide a set of graphics calls that can be directed >at *any* device and they will render on that device at the maximum >resolution of that device. The sub problems come in the form : Are these >commands or are they simple values? Can you define the appropriate >subset of commands that give you the require capabilities? etc. > >PostScript was suggested as the drawing language but in case you haven't >noticed, even Apple doesn't use native PostScript on the Macintosh because >it cannot be rendered quickly enough. So the goal becomes to come up with >a flexible drawing language that can be rendered quickly, but contains >sufficient flexibility that most (where most is arbitrarily set to 85%) >of the things you want to render, can be, without resorting to 'going >around' the language. NOTE : For screens and printers etc two dimensions >are sufficient. Thank god. Somebody else understands this too. For inclusion into IFF files, I propose that types (or hunks or whatever the appropos terminology is) be invented that correspond directly to PS primitives. What we end up with then, is essentially Amiga quickdraw, except we dont call it quickdraw. To render an 'amiga quickdraw/PS/IFF' file: 1) To the screen: there already exists an Amiga PostScript previewer. Thats the hard part. The conversion from 'amiga quickdraw/PS/IFF' file to PostScript commands is trivial. 2) To a plotter: Fancy text manipulations, and clipping is the most problematic issue here, as I see it. The rest is trivial. 3) To bitmapped printers: Use the output of 1) 4) Object oriented printers: Right now this means PostScript printers. Again. The conversion to PS is trivial. Besides printers there are phototypesetters, and soon there will be a PostScript color film recorder. If you look at the trend in peripheral, over the last 10 years, and where the peripherals industry is going, you will notice that more and more intelligence is being built into peripherals, and this is especially true of printers. It will not be long before PostScript dot matrix printers appear, but that would be telling. The single biggest advantage to PostScript (besides the fact it precludes the mac weenies from jibing us any further on it) is that THE PERIPHERAL DOES THE RASTERIZATION. If there were any NAPLPS or CGI/CGM or what have you peripherals, that "spoke" these standards, they might be worthy of consideration. But there arn't, and it's not. And despite what K*nt thinks, PostScript is more of a standard (via encapsulated PostScript) than CGI/CGM simple because of installed base. Applications that can handle EPS abound on EVERY computer, they have to - thats where the industry is moving. NAPLPS is a joke. Is has a very limited domain, and conforming with it buys us nothing. >Storing Objects and such : > >This is the area that Jeff expounds upon and I agree it could use some >standardization. The Videoscape 3D and Sculpt 3D people seem to have >the most to gain at the moment however all of us would benefit if one >3D object specification format existed. Jeffs 'scaled' integers is an >excellent approach and it would make 3d objects *much* easier to use. >Consider a 3d format that consisted of one floating point number >(the "units") and all other numbers in integers. All packages could >scale the object to the precision of the floating point format they >used. Oh please. Lets get 2D objects working first. While the temptation is great to standardize 3D, I think it is a bad idea for two reasons: 1) Lets get some feedback with our experience with 2D. 2) There is a line of reasoning that says: "Well shoot, if we're gonna do 2D, we may as well do 3D". "And if we're gonna do 3D we may as well render it fully as a solid not just as a wireframe". "And if we're gonna render solids, we may as well have shading". "And if we've got shading, we may as well have light sources" Pretty soon we end up trying to implement Dore, when all we wanted to do in the first place was do have a simple standard for sharing 2D objects. One thing at a time please. It's much easier that way. -- Have a nice day or Klortho will rip your nuts off. richard@gryphon.CTS.COM rutgers!marque!gryphon!richard
paolucci@snll-arpagw.UUCP (05/19/88)
In article <2542@utah-gr.UUCP> u-jmolse%sunset.utah.edu.UUCP@utah-gr.UUCP (John M. Olsen) writes: > >There are a couple of points that have not been mentioned as everyone has >been lining up on one side of the fence or the other with regard to the >usability of PostScript. > >It is in fact a complete language, and you can write ANY program in PS if >you want to. For example, it would be possible to write a ray tracer that >ran inside the printer and generated output directly. If you have a PS >printer that accepts color commands (MUCH $$) and has better than 300 dpi >(MUCH MORE $$) then you could generate high quality images without the use >of a crt. As a matter of fact, somebody just posted a ray tracing program in PostScript that does exactly that. -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
kent@xanth.UUCP (05/19/88)
Just to cut through all the BS Richard is shoveling (again);
1) Sure CGM is complex; for the very same reasons, so is Intuition. Computer
Graphics is a very, very big subject, and a format that promises to capture
a whole drawing session and let you pick it up again later is bound to have
a lot of structure. Doing the job right takes time and money. Doing it
wrong first takes more and longer.
2) When we say Amiga and Workstation, we're not talking about an "under $5000"
system either, according to the previous arguments here.
3) A workstation puts drawings on the customer's choice of output devices.
How is Postscript at flatbed plotter driving? An awful lot of the small
shop drafting applications that might see an Amiga as a low cost way to
get into computer aided drafting or extend an existing system are doing
output on pen plotters.
4) A drawing session doesn't necessarily finish a drawing. How is Postscript
at storing the segment, visibility, symbol and other structure in a way
that makes it easy to read back in and resume the session as if it had
never been interrupted.
5) All ANSI standards are made by committee; it is in the rules.
I don't want to claim to be the final authority on this stuff. I left
the standards racket in 1981, and have been only an observer and
occasional commentator since then. It is certainly possible that the
whole universe of graphics has turned over once or twice since then.
I have seen (and helped procure) GKS drawing packages since then, and
I know that the standards activity continues hot and heavy to bind the
set {GKS,CGM,CGI} of standards to additional languages.
However, to the best of my knowledge, Postscript is _not_ a standard,
merely very popular, and this means there are going to be a lot of
portability and interoperability problems that have never been looked
at for Postscript. It is a nice manufacturer's format, and GKS
drawing packages will (most of them) write to a "Postscript device,"
since Adobe was nice enough to make the definition of Postscript
public.
That makes it suitable for an output format, but not for a "store and
recover" metafile format; it was not designed to be one, and my bet
(without knowing the language) is that it is not one, simply because
it is a huge amount of work to design a metafile that is functional.
It happened that "metafile" was my subcommittee when I was part of ANSI
X3H3.
Anyway, you guys carry on; I've used about as much bandwidth sniping
about this as is likely to be productive, so I'll watch for a while,
and play unemployed graphics programmer a bit more.
Kent, the man from xanth.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
cunniff@hpesoc1.HP.COM (Ross Cunniff) (05/20/88)
In article <4083@gryphon.CTS.COM>, richard@gryphon.CTS.COM (Richard Sexton) writes: >For inclusion into IFF files, I propose that types (or hunks or whatever >the appropos terminology is) be invented that correspond directly to >PS primitives. What we end up with then, is essentially Amiga quickdraw, >except we dont call it quickdraw. OK! Now we're talking. A quick perusal of the PostScript Language Reference Manual reveals the following primitives: arc arcn arcto curveto lineto moveto rcurveto rlineto rmoveto show How these are displayed may be modified by the following primitives: (path primitives) newpath closepath flattenpath reversepath strokepath charpath clippath pathforall clip fill eofill stroke (style primitives) setlinewidth setlinecap setlinejoin setmiterlimit setdash setflat setgray sethsbcolor setrgbcolor (transformation primitives) initmatrix setmatrix translate scale rotate concat A filled polygon would then be represented as: 1.0 1.0 0.0 setrgbcolor % Set the fill color to yellow 0 0 moveto 5 5 lineto 0 5 lineto 5 0 lineto gsave fill grestore % Fill, saving the path for later 1.0 0.0 0.0 setrgbcolor % Set the edge color to red [3 1 1 1] 0 setdash % Set '._._.' lines stroke % Trace the edge The equivalent DR2D object would be: CPLY [F_COLOR 3 E_DOT_DASH 2] 8 0 0 5 5 0 5 5 0 We can define equivalent DR2D objects for the rest of PostScript's primitives. I propose, however, that we don't use the full power of PostScript's clipping and imaging model, just because it is *SUCH* a pain to implement (especially for vector-only displays, such as plotters), and is far too general for a drawing format. I think that we should limit ourselves to fairly straightforward transformations and clips (i.e. clipping to a rectangular window and only allowing translation, rotation, and scaling as transformations; we shouldn't bother with text along arbitrary curves, that sort of stuff). Also, for you PostScript purists out there, looking at the above, which do YOU think would be easier to parse and group into appropriate objects for manipulation by the user? Remember, we are trying to design a format for CAD-type programs that the user will be able to modify after she's saved it. High-level objects are a much easier paradigm to handle than a series of interpreted move/draw/fill type commands (oh, sure, you could say, 'Well, we would just write a PS procedure for each high-level object type'. Fine. Now we need the full-blown interpreter. No thanks). Ross Cunniff ...{ucbvax,hplabs}!hpda!cunniff cunniff%hpda@hplabs.ARPA
mwm@eris.UUCP (05/20/88)
[Warning - I'm going pedantic.....]
In article <2542@utah-gr.UUCP> u-jmolse%sunset.utah.edu.UUCP@utah-gr.UUCP (John M. Olsen) writes:
<PostScript is a postfix language (hence, the name) so it is interpreted
<instead of compiled, but I will leave the pros/cons of this alone for now.
That PostScript is postfix has nothing to do with it being
interpreted. BASIC is infix, LISP is prefix, and both interpreters and
compilers can be found for both languages. Since converting from
(post|pre|in)fix to (post|pre|in)fix is easy (doing all those
translators in a single program is a standard undergrad programming
exercise), doing a compiler for a postfix language is no harder than
any other language. Maybe even easier, as you don't have to deal with
parens and operater precedence.
No, the reason you don't see many postscript compilers is because
there aren't many applications where they make sense. Take a typical
postscript printer - it runs a program, then throws it away. It would
probably do the same if it had compiled it to a binary. The point of a
postscript program is to generate a display. After that's done, the
program is usually discarded. Why waste time compling it?
With things like NeWS starting to appear, we may start seeing some
postscript compilers. But I expect smarter inerpreters (i.e. - compile
each line as you execute it, then you can run the compiled version
later) to appear instead.
<mike
--
Lather was thirty years old today, Mike Meyer
They took away all of his toys. mwm@berkeley.edu
His mother sent newspaper clippings to him, ucbvax!mwm
About his old friends who'd stopped being boys. mwm@ucbjade.BITNETpaolucci@snll-arpagw.UUCP (Sam Paolucci) (05/20/88)
In article <4083@gryphon.CTS.COM> richard@gryphon.CTS.COM (Richard Sexton) writes: > >To render an 'amiga quickdraw/PS/IFF' file: > >1) To the screen: there already exists an Amiga PostScript previewer. Thats >the hard part. The conversion from 'amiga quickdraw/PS/IFF' file to >PostScript commands is trivial. Where is an Amiga PostScript previewer? If you are referring to that on one of the Fish disks, that is a joke. Don't misunderstand me, it may be a start but so much is missing that I have yet been able to preview any of the files that I generate. The examples given by the author work ok though :-). > Have a nice day or Klortho will rip your nuts off. >richard@gryphon.CTS.COM rutgers!marque!gryphon!richard -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
richard@gryphon.UUCP (05/20/88)
In article <5279@xanth.cs.odu.edu> kent@xanth.UUCP (Kent Paul Dolan) writes: > >Just to cut through all the BS Richard is shoveling (again); Coming from an expert on the subject. >1) Sure CGM is complex; for the very same reasons, so is Intuition. Computer > Graphics is a very, very big subject, and a format that promises to capture > a whole drawing session and let you pick it up again later is bound to have > a lot of structure. Doing the job right takes time and money. Doing it > wrong first takes more and longer. Ok, K*nt, knock yourself out. Go ahead and wait for CGI to be finalized, and then go code the thing. Let us all know when you finish. But, given the record of "graphics standards" as soon as they are done, they will go and make one so supercede it. Rememebr VDI ? >2) When we say Amiga and Workstation, we're not talking about an "under $5000" > system either, according to the previous arguments here. No we're not. We're talking about under $2000 in the vast majority of cases. The Over $5000 people can probably afford to pay you to write CGI for 10 years, or go buy it from GSS for $1500. >3) A workstation puts drawings on the customer's choice of output devices. > How is Postscript at flatbed plotter driving? An awful lot of the small > shop drafting applications that might see an Amiga as a low cost way to > get into computer aided drafting or extend an existing system are doing > output on pen plotters. This is not a problem. >4) A drawing session doesn't necessarily finish a drawing. How is Postscript > at storing the segment, visibility, symbol and other structure in a way > that makes it easy to read back in and resume the session as if it had > never been interrupted. This is not a problem. >5) All ANSI standards are made by committee; it is in the rules. This is a problem. >I don't want to claim to be the final authority on this stuff. I left >the standards racket in 1981, and have been only an observer and >occasional commentator since then. It is certainly possible that the >whole universe of graphics has turned over once or twice since then. >I have seen (and helped procure) GKS drawing packages since then, and >I know that the standards activity continues hot and heavy to bind the >set {GKS,CGM,CGI} of standards to additional languages. Sure they are. The only problem is applications writers look at the spec for GKS or CGI and go: "Oh god, forget it, I'll just write to the hardware". And as you said, K*nt, you don't know what you are talking about. Why dont you go and get a postscript book, read it, understand the difference between the imaging model and the programming model and then come back and attempt sentient thought. >However, to the best of my knowledge, Postscript is _not_ a standard, Fortunately, the best of you knowledge amounts to less than a hill of beans by your own admission. PostScript is a de facto standard (you know, the ones that people USE) and more applications read and write PostScript than CGI/CGM, and I honestly believe this will always be the case. Rememebr SIGGRAPH CORE ? >merely very popular, and this means there are going to be a lot of >portability and interoperability problems that have never been looked >at for Postscript. Like you said K*nt, you dont know anything about PostScript. Now Leo had the good taste to retract HIS bogus statements when it was pointed out to him he didnt know what he was talking about. The world waits for your apology, K*nt. >It is a nice manufacturer's format, and GKS >drawing packages will (most of them) write to a "Postscript device," >since Adobe was nice enough to make the definition of Postscript >public. There are also "Encapsulated PostScript Files" that are READ by other applications, analagous to CGM. >That makes it suitable for an output format, but not for a "store and >recover" metafile format; it was not designed to be one, and my bet >(without knowing the language) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ When you know about what you speak of, come back and post again. Until then you are just tilting at windmills. > is that it is not one, simply because >it is a huge amount of work to design a metafile that is functional. >It happened that "metafile" was my subcommittee when I was part of ANSI >X3H3. This explains a lot. >Anyway, you guys carry on; I've used about as much bandwidth sniping >about this as is likely to be productive, so I'll watch for a while, >and play unemployed graphics programmer a bit more. No, K*nt, this is a mere pittance to the bandhwidth waste compared to your damn "pledge lists". At least now the net.gods have seen fit to give you a place where you can play without hurting yourslf. See you in alt.birthright. >K*nt, the electronic villiage idiot from xanth. -- Have a nice day or Klortho will rip your nuts off. richard@gryphon.CTS.COM rutgers!marque!gryphon!richard
richard@gryphon.UUCP (05/20/88)
In article <5550@megaron.arizona.edu> rogerh@arizona.edu (Roger Hayes) writes: >The fact that PostScript is a complete language makes it unsuitable >for an interchange format. In order to decipher a PostScript file, >you have to implement a PostScript interpreter -- not a trivial task, >and certainly not something we want to put inside every program. >For an example of the kinds of problems it causes, look at the difficulty >of printing Mac-generated file on a Unix machine (you have to find the >right preface, twiddle it to work as a preface, twiddle it again to >survive the spooling software,...). Duh. PostScript the language, should not, IMHO be adapted as an IFF type. The imaging model should be followed as we invent our own "quickdraw". >The advantage of PostScript for this use is its device-independance. >Other formats share that advantage and are simpler to decode. "Other standards" shouldnt be IFF types either. -- Have a nice day or Klortho will rip your nuts off. richard@gryphon.CTS.COM rutgers!marque!gryphon!richard
peter@sugar.UUCP (Peter da Silva) (05/20/88)
In article ... richard@gryphon.CTS.COM (Richard Sexton) writes: > For inclusion into IFF files, I propose that types (or hunks or whatever > the appropos terminology is) Chunks. > be invented that correspond directly to > PS primitives. What we end up with then, is essentially Amiga quickdraw, > except we dont call it quickdraw. I would like to suggest a chunk type "OBJ " that can map to a PostScript subroutine or to a drawing program's "object". It would contain a bunch of PS/IFF chunks. This would do much to close the gap between a rendering standard and a storage standard. There's nothing that says FooDraw needs to use DR2D (or whatever) files for internal use (DMCS doesn't use SMUS by default, for example), just so long as it can import and export it. > To render an 'amiga quickdraw/PS/IFF' file: > 1) To the screen: there already exists an Amiga PostScript previewer. Thats > the hard part. The conversion from 'amiga quickdraw/PS/IFF' file to > PostScript commands is trivial. It would be desirable to have a library that would take PS/IFF chunks and render them directly into a bitmap, though. That way you could do a very close map between your rendering code and your "save as PSIFF" code. > 3) To bitmapped printers: Use the output of 1) Please, no. Most bitmapped printers *do* support a higher resolution than the screen. You yourself note: > ... THE PERIPHERAL DOES THE RASTERIZATION. While we can't get that right now, you'd get much better results generating rasters at the printer's resolution. And you could do it on a scan-by-scan basis and save a considerable amount of memory. > >Storing Objects and such : > Oh please. Lets get 2D objects working first. While the temptation > is great to standardize 3D... Agree. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These may be the official opinions of Hackercorp.
ali@polya.STANFORD.EDU (Ali T. Ozer) (05/21/88)
In article <2542@utah-gr.UUCP> John M. Olsen writes: >PostScript is a postfix language (hence, the name) so it is interpreted >instead of compiled, but I will leave the pros/cons of this alone for now. The speed of the interpreter is sometimes the problem. In most of the Postscript programs I've written, usually the speed of clipping, the scaling/rotation of fonts, and the download time of binary images have been the limiting factors. In any case, you can pretty much eliminate most of the interpreter overhead with the use of the often-ignored "bind" operator: It causes all the executable operators in a Postscript procedure to be replaced by the actual addresses, thus avoiding the time the interpreter would have take looking up the name. The gain is immense if you happen to be looping many times, using the same set of names. The disadvantage is a loss in flexibility. Postscript is great --- gives you device independence, any size fonts, arbitrary scaling, rotation, etc. The biggest problem is that it requires a bit too much CPU. Other problems people point out (such as "difficult to program" or "is interpreted") aren't really problems; you can solve the first one through a layer of translation, and the second one as shown above... Ali Ozer, ali@polya.stanford.edu
jeffle@amtfocus.UUCP (Jeff Leitheiser) (05/24/88)
In article <4083@gryphon.CTS.COM>, richard@gryphon.CTS.COM (Richard Sexton) writes: > > In article <53552@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: > >In article <132@amtfocus.UUCP> jeffle@amtfocus.UUCP (Jeff Leitheiser) writes: > >> I agree that there NEEDS to be ONE standard for storing semi-intelligent > >> graphics....is postscript the answer? I'm not an expert on postscript, > >> but what about 3D objects? Yes, most of what people do today is 2D, but > > > >Whoa! There are several problems here that everyone is trying to solve > >with *one* solution. (You may recall during the IPC discussion the same > >phenomena occurred). The two big ones in Jeff's message are "rendering > >to the screen" and "storing object definitions". > > > >Rendering to the Screen : > > > >The Amiga screen rendering routines are raster based and fast. This > >works well with the screen because they operate at the full resolution > >of the screen. This is not true for printers because chances are that > >the routines do *not* work at the printers resolution. Apple's solution . . . > >the problem is to provide a set of graphics calls that can be directed > >at *any* device and they will render on that device at the maximum > >resolution of that device. The sub problems come in the form : Are these > >commands or are they simple values? Can you define the appropriate > >subset of commands that give you the require capabilities? etc. > > > >PostScript was suggested as the drawing language but in case you haven't > >noticed, even Apple doesn't use native PostScript on the Macintosh because > >it cannot be rendered quickly enough. So the goal becomes to come up with > >a flexible drawing language that can be rendered quickly, but contains > >sufficient flexibility that most (where most is arbitrarily set to 85%) > >of the things you want to render, can be, without resorting to 'going > >around' the language. NOTE : For screens and printers etc two dimensions > >are sufficient. > > Thank god. Somebody else understands this too. I agree that most instances of graphics are simple, and 2D....most usages are too. In those cases only simple commands will do nicely. What I'm afraid of is the simplicity of these files will cause MANY dedicated storage formats to be developed and all of them being incompatable. The example of Apollo's domain 2D and 3D graphics formats was brought up as in support for seperation. I think its better for the inclusion argument: - different naming conventions. - locations in 2D are in frations-of-bitmap vs 3D's logical device coord. - different color definition methods - 3D supports only 1 font Why are they different? Why can't you build one format and let it be extendable to include other types of information? an example of this type of format is IGES or EDIF. Both of these formats are clumzy, but they have entity types such as 2d_strings , 3d_strings, sub_figure_def and sub_figure_loc that can be used or ignored by a client program. Later additions come in the form of new entity types, these are not supported and therefore not used by older routines. > For inclusion into IFF files, I propose that types (or hunks or whatever > the appropos terminology is) be invented that correspond directly to > PS primitives. What we end up with then, is essentially Amiga quickdraw, > except we dont call it quickdraw. > I agree, we should define a header file that maps entity types to integer valuesso that a select case statement can easily be used to seperate the usage code blocks.....the default will catch the unknown entity types if you want to report/log them. I think the entity type should be stored in the front of the entity description so the rest of the entity doesn't need to be parsed if you can't understand or want to ignore it. This does mean that a simple interpreter/reformater will always be needed to keep other devices from barfing ( stripping/expanding higher level entities, adding the postscript entity type text to the end of the string, and scaling the stored ( compressed to scaled integer ) locations to the proper size. The format of all the interpreters will be the same shell with unique code to render the graphic primititives to the device. This also allows the reduction of 3D to 2D: ignore an axis for any on std view or use transform equations for special angles. > If you look at the trend in peripheral, over the last 10 years, and > where the peripherals industry is going, you will notice that more > and more intelligence is being built into peripherals, and this > is especially true of printers. By first writing a generic interpretter, new device drivers become a simple matter of "what do I send it to do this". If the device has new features we can add support for them with a new entity type. Older drivers can then be easily retrofitted with a new case clause for the feature. Note that other graphical standards can be looked at as devices, It would be easy to write an IGES or CGM format converter. > If there were any NAPLPS or CGI/CGM or what have you peripherals, > that "spoke" these standards, they might be worthy of consideration. I wrote a graphics displayer for a CGI graphics card for a VME system, It was nice to off load the main CPU but there is very little feedback for when the graphics were ready....impossible to do some of the current Amiga twiddles. Also there is no support for rendering multiple copies of an object without actually coping the full object description. > >Storing Objects and such : > > > >This is the area that Jeff expounds upon and I agree it could use some > >standardization. The Videoscape 3D and Sculpt 3D people seem to have > >the most to gain at the moment however all of us would benefit if one > >3D object specification format existed. Jeffs 'scaled' integers is an I'm glad you agree. The time savings are just as true for 2D objects. If I take my storage scaling factor and multiply it by my display scaling factor I then get an int * int (+ int offset ) operation for finding pixel locations. What could be faster and still resolution independant? > One thing at a time please. It's much easier that way. One final implementation at a time......but lets keep an eye on the big picture.If we need to create a format lets try and make it short, fast, and expandable. Jeff Leitheiser (312) 576-0836 chinet!mcdchg!amtfocus!jeffle