Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!apple!uokmax!d.cs.okstate.edu!minich
From: minich@d.cs.okstate.edu (Robert Minich)
Newsgroups: comp.sys.next
Subject: Re: BAD NEWS FOR MAC -> NEXT PEOPLE
Message-ID: <1990Dec14.000607.16279@d.cs.okstate.edu>
Date: 14 Dec 90 00:06:07 GMT
References: <9534@ncar.ucar.edu>
Organization: Oklahoma State University
Lines: 27

glenn@heaven.woodside.ca.us (Glenn Reid) writes:
| The real issue is a file format that allows graphics, text, images, and
| so forth to be stored without any significant limitations, yet still
| be editable (which means that any application should be able to open
| the file and read the data into its own data structures).
| useful for Mac/NeXT portability, and besides, they have their limitations.

by davis@groucho.ucar.edu (Glenn P. Davis):
| What about CGM? (Computer Graphics Metafile). It handles text, images,
| polylines, polymarkers and polygons (filled or unfilled) with a
| variety of attributes. It was designed and standardized to solve just
| this problem. "Too limiting" or simply "Not invented here" ??

 The real problem is that people (well, the subset known as programmers)
like to have their own formats for various reasons. CGM is nice but
usually the format of files is a secondary (at best) thought while the
program itself comes first. Does anyone know of a popular graphics editor
that was designed around a specific file format?
  I assert that we will always necessarily have differing files formats
and often the best to be hoped for is a conversion that can achieve
equivalent output. This is not the same as having equivalent files to
edit. Usually, internal structure is lost or approximated.
-- 
|_    /| | Robert Minich            |
|\'o.O'  | Oklahoma State University| "I'm a newcomer here, but does the
|=(___)= | minich@d.cs.okstate.edu  |  net every lay any argument to rest?"
|   U    | - Ackphtth               |                    -- dan herrick