ranjit@eniac.seas.upenn.edu (Ranjit Bhatnagar) (09/08/88)
As long as we're bringing up old ideas like PATH:---
4 or 5 months ago I posted a message suggesting that we need a
structured graphics standard for SIMPLE graphics - lines, filled
polygons and ellipses, and multi-font text. I suggested that as long
as Apple already invented Quickdraw, we might as well use that -it's
simple, relatively easy to implement (all we're missing is RoundRects
and arbitrary regions - ok, the latter ain't so easy) - and there's
400 zillion people out there using MacDraw. The overall net response
was "nawww, we can do better than that."
Months later, we still don't have a standard for structured 2d graphics,
and there are now 525 zillion people who already use the QuickDraw standard
whether they know it or not, over in the Mac community. All we need
("all," he says!) is a quickdraw.library and a QUIK form for IFF, which
just contains a binary duplicate of an apple qd file. Heck, I'd do
it myself, if I were not an Extremely Busy Person, and, more to the
point, an inept programmer.
Well, so whaddya think? If the prevailing opinion is that the subject
is dead, I apologize abjectly, and when I want to make a poster or
graph for a laser printer, I will hide my face and sneak over to my
roommate's Mac.
thanks...
-Ranjit
"If beginner's luck, then absolute beginners luck absolutely."
"Trespassers w" ranjit@eniac.seas.upenn.edu ucbvax!rutgers!super!eniac!...dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/09/88)
:simple, relatively easy to implement (all we're missing is RoundRects
:and arbitrary regions - ok, the latter ain't so easy) - and there's
:400 zillion people out there using MacDraw. The overall net response
:was "nawww, we can do better than that."
:
:Months later, we still don't have a standard for structured 2d graphics,
:and there are now 525 zillion people who already use the QuickDraw standard
:whether they know it or not, over in the Mac community. All we need
:("all," he says!) is a quickdraw.library and a QUIK form for IFF, which
:just contains a binary duplicate of an apple qd file. Heck, I'd do
:it myself, if I were not an Extremely Busy Person, and, more to the
:point, an inept programmer.
:
:Well, so whaddya think? If the prevailing opinion is that the subject
:is dead, I apologize abjectly, and when I want to make a poster or
:graph for a laser printer, I will hide my face and sneak over to my
:roommate's Mac.
:
:thanks...
: -Ranjit
I wish there were too, but there isn't any single format that
is suitable for the job. There are a thousand data structures and a
thousand storage formats for lines alone, and each is well suited to
a given range of applications (in terms of efficiency).
For instance, some applications will want to store the points
as real numbrs (pick a format!), or as integers... but how big an integer?
Several applications need 32 bits / value, others need only 16. Others
even less! What kind of data structure? Quad Tree? Simple List? Are
coordinates stored relative to local origins for objects? What kind of
objects should be supported? etc...
-Mattranjit@eniac.seas.upenn.edu (Ranjit Bhatnagar) (09/10/88)
In article <8809090717.AA15695@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > I wish there were [a structured graphics standard] >too, but there isn't any single format that >is suitable for the job. There are a thousand data structures and a >thousand storage formats for lines alone, and each is well suited to >a given range of applications (in terms of efficiency). My feeling is that QuickDraw is good for a lot of things, and it would be nice to use it RIGHT NOW while waiting for the more general or more interesting standards to arrive. QuickDraw (from my experience) fills just about all the needs for business graphics (charts & graphs), posters (text + borders and bitmap pictures), line illustrations, and such. I have also used it for simple electronic diagrams, illustrating experiment records for physics labs (pictures of the equipment, etc.), and making logos for stationery. (Of course, I should reiterate that the main advantage of a simple standard like this over bitmaps like you get out of DPaint or DigiPaint is that the resulting images can be rendered at any resolution, so look killer on a laser printer. Oh, and, being structured, you can manipulate pieces without having to worry about erasing and redrawing stuff.) > > For instance, some applications will want to store the points >as real numbrs (pick a format!), or as integers... but how big an integer? >Several applications need 32 bits / value, others need only 16. Others >even less! What kind of data structure? Quad Tree? Simple List? Are >coordinates stored relative to local origins for objects? What kind of >objects should be supported? etc... Answer to all these is - do it the way Apple did it. They obviously put a lot of thought into QuickDraw, and it's pretty nice. I'd better say this loud - [turn volume up one notch]: I'm not suggesting that QuickDraw is a good all-purpose standard, nor that settling on QuickDraw as a standard should preclude the further development of more complex, specialized standards for drafting, pc-board layout, etc. Simply that it's a useful standard for a lot of things, and the fact that it's compatible with a zillion macintoshes doesn't hurt. [volume down again] Thanks for your opinions... -ranjit "Trespassers w" ranjit@eniac.seas.upenn.edu ucbvax!rutgers!super!eniac!...
Arved@cup.portal.com (09/10/88)
On this subject, here's my two cents worth:
We already have such graphic standards used in PC and MAC programs. My
preference is to either adopt the AutoCAD file standard (first choice), or
the MACDraw format. While we're at it, how about a program to convert HPGL
or otherwise facilitate printing of HPGL files through AmigaDOS printer
devices?
Yes, I know, we're talking two seperate things here, but you get what
I pay for ;'D.
- Arved Arved@cup.portal.competer@sugar.uu.net (Peter da Silva) (09/11/88)
In article <8934@cup.portal.com>, Arved@cup.portal.com writes: > We already have such graphic standards used in PC and MAC programs. Unfortunately, they're not IFF formats. One nice thing about IFF is that even if you can't understand the format, you can at least browse it and look at '(c) ', AUTH, and other such chunks. You can even manipulate IFF files to some extent without knowing the first thing about their contents... see, for example, the IFF CAT archiver. It is, however, reasonable to ask how the IFF drawing and CAD formats are doing... -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
ain@s.cc.purdue.edu (Patrick White) (09/12/88)
In article <8809090717.AA15695@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >:simple, relatively easy to implement (all we're missing is RoundRects >:and arbitrary regions - ok, the latter ain't so easy) - and there's >:400 zillion people out there using MacDraw. The overall net response >:was "nawww, we can do better than that." But just do we want to do that is better? higher resolution? object oriented? color? >:Months later, we still don't have a standard for structured 2d graphics, >:and there are now 525 zillion people who already use the QuickDraw standard There was one posted that was fairly nice, but when I tried to reply to the author, I found his account had evaporated.. anyone know where to find: % Ross Cunniff % ...{ucbvax,hplabs}!hpda!cunniff % cunniff%hpda@hplabs.ARPA > I wish there were too, but there isn't any single format that >is suitable for the job. There are a thousand data structures and a >thousand storage formats for lines alone, and each is well suited to >a given range of applications (in terms of efficiency). Line and points alone are not the best thing we can do though, although you can do anything most devices can do, the programs end up driving essencially a virtual dumb device rather than driving a virtual (or real) intelligent graphics engine -- I'd rather write code for an intelligent graphics engine. > For instance, some applications will want to store the points >as real numbrs (pick a format!), or as integers... but how big an integer? As big as you can handle efficiently -- can always throw away part of it if you don't need it all, but it will be much harder to expand to more bits after the initial design. >Are coordinates stored relative to local origins for objects? Objects are pretty useless if they don't reside in their own individual coordinate space since you can't transform them easily otherwise (or use them more than once). >What kind of objects should be supported? Lines, points, rectangles (squares?), ellipses (circles?), different fonts, area fills, perhaps clipping rectangles and windows, ability to build more complex objects from less complex ones... in general, all the "built-in" capabilities of the Amiga and more? How about color? Want to be able to support only the Amiga's capabilities, or do we want to do more and hope it catches on or the Amiga becomes more sophisticated in that respect? Pat White (ain@s.cc.purdue.edu)
jmdavis@ihlpm.ATT.COM (Davis) (09/14/88)
I have long wanted a MACDraw like package for my Amiga, without having to buy a CAD package. And this has been where this thread has been going. Let's not forget about color. MacDraw is easier to implement since it is in black and white, on a color machine and with color printers I think a true structured graphics standard would do to colors what vector drawing packages do for various display devices. Let me elaborate with an example. Suppose I was working with a color version of MacDraw and I had access to a shadow like device as DPaint II has. In the underlying database for this picture I would expect the shadow to be stored not as "color these bits thusly" since that is in the raster rendering paradigm, but I would rather expect the picture to be stored as "cut the intensity of objects and portions of objects in this region by half" or something. This could then be rendered in a variety of means, which ever is best suited to the displaying device (dithering for printers, HAM or HBRITE for Amigas, 256 colors for MacIIs, etc.). -- ________________________________________ | Mike Davis | ..!att!ihlpm!jmdavis |_________________________
ranjit@eniac.seas.upenn.edu (Ranjit Bhatnagar) (09/14/88)
In article <2336@ihlpm.ATT.COM> jmdavis@ihlpm.ATT.COM (Davis) writes: >I have long wanted a MACDraw like package for my Amiga, without >having to buy a CAD package. And this has been where this thread >has been going. Let's not forget about color. This just occurred to me: Aegis Animator is a color structured graphics editor. Add a grid, larger-than-screen-size workspace, and measurements, and you pretty much have MacDraw in color. A heck of a lot cheaper than most CAD programs, too. Why it's not REALLY a substitute for MacDraw: the interface is clumsy; it runs in low resolution only; it's missing the above mentioned features. But it's close! If it could output its scene data in PostScript, I would probably use it as a draw program despite the problems... Gives me a chance to plug my idea for a S.G. standard again! If there were a standardized format for these things, we would only need one postscript translator... - Ranjit Unremarkable was I ere I saw Elba Kramer, nu? "Trespassers w" ranjit@eniac.seas.upenn.edu ucbvax!rutgers!super!eniac!...
cunniff@hpfcdc.HP.COM (Ross Cunniff) (09/14/88)
In article <3550@s.cc.purdue.edu> ain@s.cc.purdue.edu (Patrick White) writes: >>:Months later, we still don't have a standard for structured 2d graphics, >>:and there are now 525 zillion people who already use the QuickDraw standard > There was one posted that was fairly nice, but when I tried to reply to the >author, I found his account had evaporated.. anyone know where to find: >% Ross Cunniff >% ...{ucbvax,hplabs}!hpda!cunniff >% cunniff%hpda@hplabs.ARPA Well, I am here; hpda has (for some reason) decided to stop forwarding my mail. A new address to use is in my signature. I've been relatively busy the past month so I haven't had time to change much in the DR2D format. I would suggest, however, that comp.sys.amiga.tech would be a more appropriate place to hold this discussion. Pat White (ain@s.cc.purdue.edu) Ross Cunniff Hewlett-Packard Colorado Language Lab ...{ucbvax,hplabs}!hpfcla!cunniff cunniff%hpfcla@hplabs.ARPA
sewilco@datapg.MN.ORG (Scot E. Wilcoxon) (09/15/88)
In article <5152@netnews.upenn.edu> ranjit@eniac.seas.upenn.edu.UUCP (Ranjit Bhatnagar) writes: ... >Gives me a chance to plug my idea for a S.G. standard again! If there >were a standardized format for these things, we would only need one >postscript translator... Anyone remember NAPLPS? Text, device-independent graphics (bit and/or object) with variable precision (for more detail, use more bits), macros of anything, and standard characters for all Romance languages. NAPLPS is great for input/output with an intelligent graphics device, but not for storing data. For example, NAPLPS doesn't provide for labelled objects in the data (it can put a text label on a screen, but a CAD program can't look in the data for object "WIDGET1"). NAPLPS is also not 3D. -- Scot E. Wilcoxon sewilco@DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco Data Progress UNIX masts & rigging +1 612-825-2607 uunet!datapg!sewilco "COSMOS 1900 is falling down, falling down, falling down..."
ain@s.cc.purdue.edu (Patrick White) (09/16/88)
In article <2336@ihlpm.ATT.COM> jmdavis@ihlpm.ATT.COM (Davis) writes: >Suppose I was working with a color version of MacDraw and I had >access to a shadow like device as DPaint II has. In the underlying ... >paradigm, but I would rather expect the picture to be stored as >"cut the intensity of objects and portions of objects in this region >by half" or something. This could then be rendered in a variety of But where do you want the light source for the shadows... and how many? Sounds like you are starting to want a picture renderer.. and although I haven't seen anything of the Renderman file format, it is probably a better idea to go with than invent our own. -- Pat White ARPA/UUCP: k.cc.purdue.edu!ain BITNET: PATWHITE@PURCCVM PHONE: (317) 743-8421 U.S. Mail: 320 Brown St. apt. 406, West Lafayette, IN 47906
mp1u+@andrew.cmu.edu (Michael Portuesi) (09/18/88)
> *Excerpts from ext.nn.comp.sys.amiga: 8-Sep-88 Structured Graphics Standard* > *Ranjit Bhatnagar@eniac.s (1411)* > 4 or 5 months ago I posted a message suggesting that we need a > structured graphics standard for SIMPLE graphics - lines, filled > polygons and ellipses, and multi-font text. I suggested that as long > as Apple already invented Quickdraw, we might as well use that -it's > simple, relatively easy to implement (all we're missing is RoundRects > and arbitrary regions - ok, the latter ain't so easy) - and there's > 400 zillion people out there using MacDraw. The overall net response > was "nawww, we can do better than that." My response at the time (after checking with my MacFriends) was that the Quickdraw PICT format was documented by Apple for debugging purposes only. The actual code to manipulate PICTS is part of the Apple ROMs and is subject to change without notice. Developers are actively discouraged from writing code to manipulate PICTS directly. Hence, it is impossible to write an Amiga PICT reader and guarantee it to be compatible with Apple PICTS present and future. If you wish to use PICT as a basis for an Amiga standard, then do so. But don't try to push PICT on us for compatibility reasons, which (in my opinion) are the only really compelling arguments for using PICT. --M Michael Portuesi / Information Technology Center / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "if you ain't ill it'll fix your car"
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (09/18/88)
In article <3563@s.cc.purdue.edu> ain@s.cc.purdue.edu.UUCP (Patrick White) writes: >In article <2336@ihlpm.ATT.COM> jmdavis@ihlpm.ATT.COM (Davis) writes: > Sounds like you are starting to want a picture renderer.. and although >I haven't seen anything of the Renderman file format, it is probably a better > ^^^^^^^^^^^^^^^^^^^^^ >idea to go with than invent our own. > I spoke to someone inside LucasFilms who appears to be very familiar with the RenderMan specification. I've also glazed over it myself. RenderMan is a library interface specification for rendering software. That is to say, the document declares that, if thou art creating a renderer, then thou shalt name thy functions this, and they shall accept these parameters. There currently is no file format specification for RenderMan scenes, though one is said to be in development. As it stands now, you have to write a program to take a given vendor's scene/object storage format and pass it to RenderMan. Evidently (#define RUMOR_MODE), one or two people inside Pixar or LucasFilms who are also Amiga owners have written routines to take scenes created with Sculpt-3D and VideoScape-3D, and pass them to RenderMan renderers using a Pixar as the target. Allen Hastings is also said to be working on a RenderMan-conforming renderer. Scott Peterson of Byte-by-Byte has said that they will be supporting RenderMan. The standard appears to be taking off. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{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
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/20/88)
I did NOT write this, somebody else did and I included it in my response. I suppose this sort of thing happens all the time (applying the right quote to the wrong person), but I like to correct mistakes associated with myself. Besides, I need to write enough here so the inews line eater doesn't get upset ... or is it pnews, I forget. >In article <8809090717.AA15695@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>:simple, relatively easy to implement (all we're missing is RoundRects >>:and arbitrary regions - ok, the latter ain't so easy) - and there's >>:400 zillion people out there using MacDraw. The overall net response >>:was "nawww, we can do better than that." -Matt
mikb@stcns3.stc.oz (Mike Benson) (09/21/88)
In article <wXAhz4y00VsfM300ty@andrew.cmu.edu> mp1u+@andrew.cmu.edu (Michael Portuesi) writes: >> *Excerpts from ext.nn.comp.sys.amiga: 8-Sep-88 Structured Graphics Standard* >> *Ranjit Bhatnagar@eniac.s (1411)* > >> 4 or 5 months ago I posted a message suggesting that we need a >> structured graphics standard for SIMPLE graphics - lines, filled >> polygons and ellipses, and multi-font text. I suggested that as long >> as Apple already invented Quickdraw, we might as well use that -it's >> simple, relatively easy to implement (all we're missing is RoundRects >> and arbitrary regions - ok, the latter ain't so easy) - and there's >> 400 zillion people out there using MacDraw. The overall net response >> was "nawww, we can do better than that." > > >My response at the time (after checking with my MacFriends) was that the >Quickdraw PICT format was documented by Apple for debugging purposes only. The >actual code to manipulate PICTS is part of the Apple ROMs and is subject to >change without notice. Developers are actively discouraged from writing code >to manipulate PICTS directly. > >Hence, it is impossible to write an Amiga PICT reader and guarantee it to be >compatible with Apple PICTS present and future. > >If you wish to use PICT as a basis for an Amiga standard, then do so. But >don't try to push PICT on us for compatibility reasons, which (in my opinion) >are the only really compelling arguments for using PICT. > > --M It would appear from this that using Quickdraw PICT is inappropriate as a "standard" for structured graphics, because it's proprietary. OK, what about one of the internationally approved graphics standards, like GKS? GKS, via something called Workstation Independent Storage, and using a related standard called the Computer Graphics Metafile provides a device-independent way of handling graphic structures (called segments) which can be stored, transferred, printed, transformed, combined (a segment can consist of a combination of primitives and instances of other segments) and (even) displayed. It handles lines, areas and text in different colours and patterns, and best of all, most of the basic drawing primitives are already available as ROM kernel routines. Why not go with a real standard for once, instead of running to the first vendor who happens to define a format? The idea of a structured graphics standard is not a bad one, but I think that it would be better to use a non-proprietary standard, which will, I think, do most of what you want, rather than make yourself a slave to the whims of a vendor. > >Michael Portuesi / Information Technology Center / Carnegie Mellon University >ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas > Mike Benson Newsgroups: comp.sys.amiga Subject: Re: Structured Graphics Standard Summary: Expires: References: <5053@netnews.upenn.edu> <wXAhz4y00VsfM300ty@andrew.cmu.edu> Sender: Reply-To: mikb@stcns3.stc.oz (Mike Benson) Followup-To: Distribution: Organization: Alcatel-STC Australia, North Sydney, AUSTRALIA Keywords: -- Mike Benson +---------------+ mikb@stcns3.stc.OZ.AU Alcatel-STC Pty Ltd | CAVEAT | 11th Floor, 5 Blue St | LECTOR | Any clod can have the facts, North Sydney NSW 2060 AUSTRALIA +---------------+ but having opinions is an art.
mikhe@mystefix.liu.se (Mike Henry) (09/21/88)
In article <925@mystefix.liu.se> mikhe@mystefix.liu.se (Mike Henry) writes:
[Munch, Munch, Munch... BURP!!]
I would just like to take the opportunity and add a few comments:
1. I believe that 400-525 zillion people use MacDraw and CricketDraw
because they are EASY to learn and use (and also because
they have Mac's, yucc B^). Not to say that our beloved isn't,
but I believe that we sometimes forget how important it is to
really make it easy for the beginner. Things like online help
an iconification helps. There is a HELP button right in the
middle of the keyboard, is it OFTEN used?? Don't you think
programs should be self explanatory?? This adds size to the
program of course. Copy protection requirements have forced
developers to make the program (to say the least) cryptic
without the manual which is also a detriment to the EASY
program concept. (OK I got a little carried away)
2. I don't know of one Laserprinter (with or without PostScript)
that outputs hardcopies in COLOR. Also few copying machines
duplicate color print in color! OK other color printers
are improving their output quality, but I feel that a nice
and ordinary Draw program that outputs in Black and White
(so that you can run it through your Xerox copier and
actually DUPLICATE and DISTRIBUTE it) would do the trick.
Any flames ??
--Mike
Disclaim ? ME ? I don't even have an employer !! ///
-----------------------------------------------------------------------` ///
UUCP : mikhe@majestix.liu.se OR ///
{seismo,mcvax,munnari}!enea!liuida!majestix!mikhe \\\ ///
ARPA : mikhe%majestix.{ida.liu.se,UUCP}@seismo.CSS.GOV \\X//
SNAIL: Mike Henry, Alsattersg. 3C:20, S-582 51 Linkoping SWEDEN VVV
------------------------------------------------------------------------------smann@watdcsu.waterloo.edu (Shannon Mann - I.S.er) (09/22/88)
In article <5053@netnews.upenn.edu> ranjit@eniac.seas.upenn.edu.UUCP (Ranjit Bhatnagar) writes: >As long as we're bringing up old ideas like PATH:--- > >4 or 5 months ago I posted a message suggesting that we need a >structured graphics standard for SIMPLE graphics - lines, filled >polygons and ellipses, and multi-font text. I suggested that as long - much deleted to conserve bandwidth > -Ranjit I believe that the standard already exists. I read a couple of years ago in B*TE about a graphics standard called _North American Presentation Level Protocol Syntax_ (NAPLPS). The standard was to be used as on both high level graphics machines as well as lo-res terminals, included ways of encoding lines, areas, colours, etc. The standard's way of handling graphics so that both high res and lo-res machines could use the same information seemed particularly intriguing. (The standard included multiple fonts to boot.) Please note; it has been a considerable time since I read the article, so the information may be dated. If I come across the issues, I will post them too. I have the original articles, but, not being electronic, they are buried at the bottom of a filing cabinet somewhere... P.S. Last I heard, DEC was supporting the standard on some of their terminals. This is a rumour. I don't remember where I read this last bit. -=- -=- Shannon Mann -=- smann@watdcsu.UWaterloo.ca -=-
peter@sugar.uu.net (Peter da Silva) (09/22/88)
Yet another reason it should be an IFF standard: FORM xxxx DRAW FORM yyyy ; Here's where you put the texture maps... ILBM ... FORM zzzz ILBM ... -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
dave@dms3b1.UUCP (Dave Hanna) (09/23/88)
In article <wXAhz4y00VsfM300ty@andrew.cmu.edu> mp1u+@andrew.cmu.edu (Michael Portuesi) writes: > >> 4 or 5 months ago I posted a message suggesting that we need a >> structured graphics standard for SIMPLE graphics - lines, filled >> polygons and ellipses, and multi-font text. I suggested that as long >> as Apple already invented Quickdraw, we might as well use that -it's >> simple, relatively easy to implement (all we're missing is RoundRects >> and arbitrary regions - ok, the latter ain't so easy) - and there's >> 400 zillion people out there using MacDraw. The overall net response >> was "nawww, we can do better than that." : >My response at the time (after checking with my MacFriends) was that the >Quickdraw PICT format was documented by Apple for debugging purposes only. The >actual code to manipulate PICTS is part of the Apple ROMs and is subject to >change without notice. Developers are actively discouraged from writing code >to manipulate PICTS directly. : >Hence, it is impossible to write an Amiga PICT reader and guarantee it to be >compatible with Apple PICTS present and future. : >If you wish to use PICT as a basis for an Amiga standard, then do so. But >don't try to push PICT on us for compatibility reasons, which (in my opinion) >are the only really compelling arguments for using PICT. : --M >Michael Portuesi / Information Technology Center / Carnegie Mellon University Okay, I've said this before, but it's embarrassing to have what we all consider to be the world's greatest computer, but have to look to a Mac if we want to do some documentation that's got some simple graphics in it. We've got a secretary up the hall that uses a Mac II and MacDraw ALL DAY LONG to turn out marketing presentations full of very complicated line graphics, but I can't find a package on the Amiga that will let me do a simple flow chart, structure chart, org chart, block diagram, or what have you in any kind of reasonable time. ( I tried once. Took one of my hand-drawn documents up to the dealer and played with two or three paint packages, which was the best they could recommend. It took me about 45 minutes to manipulate the drawing (which had about 5 bubbles and some label text) to the point where it was anywhere near presentable. At that, it wasn't high enough resolution. ) So how come we don't have the equivalent of a MacDraw program on Ami? As for compatibility with the PICT structures, I find it difficult to believe, even given some of the stupid stunts that Apple can pull, that they would be stupid enought to make changes to the structure that would render all the existing MacDraw files unuseable. I would think that we could build a useable program on that file structure and be fairly safe. -- Dave Hanna, Daltech MicroSystems | "Do or do not -- There is no try" P.O. Box 584, Bedford, TX 76095 | - Yoda (214) 358-4534 (817) 540-1524 | UUCP: ...!killer!gtmvax!dave |
shadow@pawl6.pawl.rpi.edu (Deven T. Corzine) (09/23/88)
In article <8809200601.AA22100@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > I did NOT write this, somebody else did and I included it in my >response. I suppose this sort of thing happens all the time (applying the >right quote to the wrong person), but I like to correct mistakes associated >with myself. Besides, I need to write enough here so the inews line eater >doesn't get upset ... or is it pnews, I forget. > >>In article <8809090717.AA15695@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>>:simple, relatively easy to implement (all we're missing is RoundRects >>>:and arbitrary regions - ok, the latter ain't so easy) - and there's >>>:400 zillion people out there using MacDraw. The overall net response >>>:was "nawww, we can do better than that." > > -Matt Um, Matt... did it ever occur to you that such confusions occur mostly because of people who quote other articles without noting where the article quoted is, or who wrote it? You do the same thing yourself, after all... (not a flame) -Deven (aCk... need new .sig) /*********************************************************************\ * #include <std/disclaimer> * * Deven T. Corzine USnail: 2346 15th St. * * <<The Shadow>> Troy, NY 12180 * * * * Internet: BITNET: * * shadow@pawl.rpi.edu USERFXB6@RPITSMTS.BITNET * * shadow%pawl.rpi.edu@itsgw.rpi.edu * * shadow@{uruguay,paraguay,brazil}.acm.rpi.edu * \*********************************************************************/
pds@quintus.uucp (Peter Schachte) (09/24/88)
In article <141@dms3b1.UUCP> dave@dms3b1.UUCP (Dave Hanna) writes: >Okay, I've said this before, but it's embarrassing to have what we all >consider to be the world's greatest computer, but have to look to a Mac >if we want to do some documentation that's got some simple graphics in it. >... >Took one of my hand-drawn documents up to the dealer and played with >two or three paint packages, which was the best they could recommend. >It took me about 45 minutes to manipulate the drawing (which had about >5 bubbles and some label text) to the point where it was anywhere >near presentable. At that, it wasn't high enough resolution. ) ^^^^^^^^^^ You said the magic woid! If someone DOES come up with a structured graphics standard for the Amiga, it had better be resolution- independant. This is really hard if you include text (which is necessary), since the Amiga doesn't come with any fonts in a very wide variety of sizes. Once that problem is solved, an IFF form for structured graphics shouldn't be very hard. -Peter Schachte pds@quintus.uucp ..!sun!quintus!pds
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/25/88)
:Um, Matt... did it ever occur to you that such confusions occur :mostly because of people who quote other articles without noting where :the article quoted is, or who wrote it? You do the same thing :yourself, after all... : :(not a flame) : : -Deven True enough. I always stick quoted stuff in '>', or ':' to defeat the news filtering program, and in about 5% of such responses I do not quote the originator's name. I do this on purpose for several reasons. (1) If the quote taken alone is easily misinterpreted by people who have not been following the conversation. I.E. so they don't flame the guy and to maybe force them to go back a bit and find the thread. (2) If the quote is general or if my message is not directly related to the quote. In such cases it (the quote) has already been discussed to death so I like to disassociate my reply as much as possible from it. I.E. make people concentrate on what I'm saying instead of what the quote said. I've always assumed that the '>' or ':' makes it obviously a quote. -Matt
stevex@ziebmef.uucp (Steve Tibbett) (09/26/88)
Maybe I'm getting into this conversation too late, but has anybody looked at Professional Draw from Gold Disk? It's an Adobe Illustrator-style program that should (and will) provide resolution-independant drawing capabilities, which output best to Postscript but will probably be adapted to give nice results off any output device. I'm not sure if they are still sticking to the Aegis Draw "Standard", but a new version of Pro Page will be required to work with it. ...Steve (stevex@ziebmef.UUCP)
ain@s.cc.purdue.edu (Pat-bob White) (09/26/88)
In article <471@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >>near presentable. At that, it wasn't high enough resolution. ) > ^^^^^^^^^^ >You said the magic woid! If someone DOES come up with a structured >graphics standard for the Amiga, it had better be resolution- >independant. This is really hard if you include text (which is Yes, it needs resolution independence, but if someone ever wants to include any kind of bit mapped pictures (like fonts), then it *must* have a resolution or one can't possibly know how close to put the dots. Best way I can think of to deal with this, is to allow a "resolution" relative to the size of the resolution-independant screen to be specified (call them virtual pixels), for use in rendering the bit mapped stuff. ie. be able to tell it that the screen is, say, 10x10 pixels when you want to render your bit image -- the drawing program will scale the virtual pixels accordingly such that 10x10 fills the entire device screen. -- Pat White ARPA/UUCP: k.cc.purdue.edu!ain BITNET: PATWHITE@PURCCVM PHONE: (317) 743-8421 U.S. Mail: 320 Brown St. apt. 406, West Lafayette, IN 47906
peter@sugar.uu.net (Peter da Silva) (09/27/88)
In article <3583@s.cc.purdue.edu>, ain@s.cc.purdue.edu (Pat-bob White) writes: > Best way I can think of to deal with this, is to allow a "resolution" > relative to the size of the resolution-independant screen to be specified (call > them virtual pixels), for use in rendering the bit mapped stuff. Better would be a field in the 'bitmap' chunk telling the renderer how big the bitmap is in the virtual co-ordinate system. It would be scaled, dithered, antialiased, whatever to make it fit in this region. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
sewilco@datapg.MN.ORG (Scot E Wilcoxon) (09/28/88)
In article <5079@watdcsu.waterloo.edu> smann@watdcsu.waterloo.edu (Shannon Mann - I.S.er) writes:
:
:I believe that the standard already exists. I read a couple of years ago in
:B*TE about a graphics standard called _North American Presentation Level
:Protocol Syntax_ (NAPLPS). The standard was to be used as on both high level
:graphics machines as well as lo-res terminals, included ways of encoding lines,
...
NAPLPS is very nice for what it is intended, which is input and output of
graphics and text. But it is not intended for storage. Why is this a problem?
Well, how are you going to send your NAPLPS image to me? There's no provision
for labeling pages, images, nor objects. I suppose we could agree on some
standard meaning for certain NAPLPS macro definitions.
I have the preliminary spec around here someplace.
--
Scot E. Wilcoxon sewilco@DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco
Data Progress UNIX masts & rigging +1 612-825-2607 uunet!datapg!sewilco
"When Hurricane Gilbert comes through, I'll stay here to experience it."
CBS:"What if you experience death?" "Well, I'll worry about that later."