[comp.sys.next] BAD NEWS FOR MAC -> NEXT PEOPLE

hodges@toaster.SFSU.EDU (John Hodges) (12/01/90)

Hello NeXT-Land. Regarding my posting last night I have not-so-good news

I just spoke with everyone at Adobe and MediaLogic regarding importing editable
graphics created on a Macintosh to the NeXT. I have been told, by both of these
companies, and by Frame Technologies, that there is NO support for graphics
generated on the Macintosh as editable files for ANY application on the NeXT.

So, if you are reading this newsgroup thinking you might switch to the NeXT, then
be forewarned that any graphics you may have created (like the many Megs I have)
on a Macintosh are stuck there unless you are willing to import them as TIFF or
EPS (uneditable) formats. That works just fine and has since the beginning.

If ANY of you know of a reasonably priced PICT or quickdraw parser for the NeXT,
then please speak up.

Those of you reading from Redwood City, PLEASE decide on a graphic interchange
standard NOW. It is going to hurt you, because there are many Apple lovers who
would like to jump boat, given a good home for their text and graphics.

Jack Hodges,
San Francisco State University

flank@ccwf.cc.utexas.edu (Brett Jacobson) (12/01/90)

In article <1040@toaster.SFSU.EDU> hodges@toaster.SFSU.EDU (John Hodges) writes:
>companies, and by Frame Technologies, that there is NO support for graphics
>generated on the Macintosh as editable files for ANY application on the NeXT.
[alot of stuff about his horrible place in life removed]
>on a Macintosh are stuck there unless you are willing to import them as TIFF or
>EPS (uneditable) formats. That works just fine and has since the beginning.


If I may interject a little reality:

EPS is editable (by Adobe Illustrator), and is much more versitile than
PICT or anything else (short of NFF, IFF formats), since it allows you to
do ANYHING your printer or screen (in the case of the NeXT can do).  I am
sorry that you have chosen to use PICT for work, but don't blame NeXT
(or FrameMaker) becuase they do not support 100s of file types.  In my
humble opinion 2 or 3 are enough (NFF, TIFF and EPS) for any machine,
regardless of who makes it.

Chris Petrilli
(forwarded by Brett Jacobson)

scott@mcs-server.gac.edu (Scott Hess) (12/01/90)

In article <1040@toaster.SFSU.EDU> hodges@toaster.SFSU.EDU (John Hodges) writes:
>Those of you reading from Redwood City, PLEASE decide on a graphic
>interchange standard NOW. It is going to hurt you, because there are
>many Apple lovers who would like to jump boat, given a good home for
>their text and graphics.

Maybe you should rephrase this as "PLEASE decide on a graphic interchange
standard _compatible_with_what_I_want_to_interchange_ NOW".  I believe
TIFF _is_ a graphic interchange standard, _much_ more so than QuickDraw
or PICT, that much is for certain, because it's not proprietary (the
specs are widely published).
--
scott hess
scott@gac.edu
Independent NeXT Developer	(Stuart)
GAC Undergrad			(Horrid.  Simply Horrid.  I mean the work!)
<I still speak for nobody>

mingo@cup.portal.com (Charles Hawkins Mingo) (12/02/90)

scott@gac.edu (Scott Hess) writes:
>hodges@toaster.SFSU.EDU (John Hodges) writes:
>>Those of you reading from Redwood City, PLEASE decide on a graphic
>>interchange standard NOW. It is going to hurt you, because there are
>>many Apple lovers who would like to jump boat, given a good home for
>>their text and graphics.
> 
>Maybe you should rephrase this as "PLEASE decide on a graphic interchange
>standard _compatible_with_what_I_want_to_interchange_ NOW".  I believe
>TIFF _is_ a graphic interchange standard, _much_ more so than QuickDraw
>or PICT, that much is for certain, because it's not proprietary (the
>specs are widely published).

	Maybe you should learn a bit more about the mac before expressing an
opinion.  PICT and QuickDraw specs were published five years ago (Tech Note 
#21), when NeXT was just a glimmer in Steve's eye.

scott@next-5.gac.edu (Scott Hess) (12/02/90)

In article <36428@cup.portal.com> mingo@cup.portal.com (Charles Hawkins Mingo) writes:
   >Maybe you should rephrase this as "PLEASE decide on a graphic interchange
   >standard _compatible_with_what_I_want_to_interchange_ NOW".  I believe
   >TIFF _is_ a graphic interchange standard, _much_ more so than QuickDraw
   >or PICT, that much is for certain, because it's not proprietary (the
   >specs are widely published).

	   Maybe you should learn a bit more about the mac before expressing an
   opinion.  PICT and QuickDraw specs were published five years ago (Tech Note 
   #21), when NeXT was just a glimmer in Steve's eye.

But, you might add, TIFF was specifically designed to be used as an
independant interchange format.  Tag Image File Format, and from the
specification memorandum:

This memorandum has been prepared jointly by Aldus and Microsoft in
conjunction with leading scanner vendors and other interesting parties.

Which sounds to me like a standard, eh?  I very much doubt that Apple
had this in mind when they created PICT and QuickDraw.  NeXT had nothing
to do with the defining of TIFF, but they use it because it is an
"industry" standard, at least to the point where most programs on the
Mac and PC which are designed to handle bitmap images handle TIFF
images just fine.

Now, for an answer to your problem (sorry, I should really have put this
in my first post, it just didn't occur to me):  Get pbmplus off the
internet.  This set of utilities allows you to convert between a wide
range of bitmap formats.  From the manual pages:

NAME
     picttopbm - convert a PICT file into a portable bitmap

SYNOPSIS
     picttopbm [-extraskip <n>] [pictfile]

DESCRIPTION
     Reads a PICT file as input.  Produces a portable bitmap as
     output.

     Note that PICT is a drawing format, not an image format, so
     this program interprets a very small subset of the opera-
     tors.  However, this subset includes the operators used by
     such programs as SuperPaint and AppleScan when writing out
     bitmap images so it's not totally useless.

...

and

NAME
     pgmtops - convert a portable graymap into Encapsulated
     PostScript

SYNOPSIS
     pgmtops [-rle] [-scale <x>] [<pgmfile>]

DESCRIPTION
     Reads a portable graymap as input.  Produces Encapsulated
     PostScript as output.

[It's trivial to convert pbm to pgm].  I have a version which
writes NeXT-acceptable eps files (Preview doesn't complain
about them with my version).  I don't think there's a pgmtotiff
in the package itself, but I think I've seen one floating around
the internet somewhere . . .

And all this runs swell on the NeXT.
--
scott hess
scott@gac.edu
Independent NeXT Developer	(Stuart)
GAC Undergrad			(Horrid.  Simply Horrid.  I mean the work!)
<I still speak for nobody>

dan@gacvx2.gac.edu (12/02/90)

In article <SCOTT.90Dec1135317@next-5.gac.edu>, scott@next-5.gac.edu (Scott Hess) writes:
>
> Which sounds to me like a standard, eh?  I very much doubt that Apple
> had this in mind when they created PICT and QuickDraw.  NeXT had nothing
> to do with the defining of TIFF, but they use it because it is an
> "industry" standard, at least to the point where most programs on the
> Mac and PC which are designed to handle bitmap images handle TIFF
> images just fine.

I am sure that Apple just wanted something.  The only common "drawing
standards" that existed at the time were raw bitmaps.

> Now, for an answer to your problem (sorry, I should really have put this
> in my first post, it just didn't occur to me):  Get pbmplus off the
> internet.  This set of utilities allows you to convert between a wide
> range of bitmap formats.  From the manual pages:
> 
> NAME
>      picttopbm - convert a PICT file into a portable bitmap
> 
> SYNOPSIS
>      picttopbm [-extraskip <n>] [pictfile]
> 
> DESCRIPTION
>      Reads a PICT file as input.  Produces a portable bitmap as
>      output.
> 
>      Note that PICT is a drawing format, not an image format, so
>      this program interprets a very small subset of the opera-
>      tors.  However, this subset includes the operators used by
>      such programs as SuperPaint and AppleScan when writing out
>      bitmap images so it's not totally useless.
> 
> ....
> 
> and
> 
> NAME
>      pgmtops - convert a portable graymap into Encapsulated
>      PostScript
> 
> SYNOPSIS
>      pgmtops [-rle] [-scale <x>] [<pgmfile>]
> 
> DESCRIPTION
>      Reads a portable graymap as input.  Produces Encapsulated
>      PostScript as output.
> 
> [It's trivial to convert pbm to pgm].  I have a version which
> writes NeXT-acceptable eps files (Preview doesn't complain
> about them with my version).  I don't think there's a pgmtotiff
> in the package itself, but I think I've seen one floating around
> the internet somewhere . . .
> 
> And all this runs swell on the NeXT.

PICT to BITMAP is all fine and good, but PICT is an object oriented drawing
language, in the terms of: it describes the image on the screen, but individual
parts can be moved by changing a few coordinates.  A more direct PICT to EPS
converter would be best.  If such a program existed then former PICT drawings
could still be edited on a NeXT using a program that can manipulate EPS images.

-- 
Dan Boehlke                    Internet:  dan@gac.edu
Campus Network Manager         BITNET:    dan@gacvax1.bitnet
Gustavus Adolphus College
St. Peter, MN 56082 USA        Phone:     (507)931-7596

jmunkki@hila.hut.fi (Juri Munkki) (12/02/90)

In <36428@cup.portal.com> mingo@cup.portal.com (Charles Hawkins Mingo) writes:
>scott@gac.edu (Scott Hess) writes:
>>Maybe you should rephrase this as "PLEASE decide on a graphic interchange
>>standard _compatible_with_what_I_want_to_interchange_ NOW".  I believe
>>TIFF _is_ a graphic interchange standard, _much_ more so than QuickDraw
>>or PICT, that much is for certain, because it's not proprietary (the
>>specs are widely published).
>
>	Maybe you should learn a bit more about the mac before expressing an
>opinion.  PICT and QuickDraw specs were published five years ago (Tech Note 
>#21), when NeXT was just a glimmer in Steve's eye.

The original PICT format (PICT 1) was described in that technical
note and all important parts of it are quite possible to decipher
on a non-Mac. Of course it can contain region data and Apple doesn't
officially document regions, so unless you know how regions work,
you can't really transfer pictures to a machine without QuickDraw.

Then came Color QuickDraw and Apple saw a need for a new PICT format
(called PICT 2). PICT 2 is is described in Inside Macintosh V. If you
try to read a PICT 2 with a PICT 1 reader, you get a blank picture.
Tough luck. PICT 2 could be read with the documentation in IM V, except
that there is no documentation on pixel maps are packed and stored (if
they are packed). So unless you know how they are stored, you can't have
pixel maps.

The latest thing is 32 bit QuickDraw. I don't have the documentation
for that, but I seem to remember that it had some new things to add
to PICT 2.

The best way to get Macintosh graphics to a NeXT would seem to be
PostScript. After all, Apple supplies a QuickDraw to PostScript
converter in its laserwriter printer drivers. Of course it needs
a largish library file, since it doesn't produce native PostScript,
but at least it is possible (with some editing, I think) to move
QuickDraw files to the NeXT as PostScript.

As you see, one could argue that QuickDraw pictures are documented,
but then again they somehow forgot to document everything and clearly
say that PICTs are for Macs only, since only Macs really know how
read and draw them.

Don't take wrong...PICTs are great...if you have a Macintosh.

   ____________________________________________________________________________
  / Juri Munkki	    /  Helsinki University of Technology   /  Wind  / Project /
 / jmunkki@hut.fi  /  Computing Center Macintosh Support  /  Surf  /  STORM  /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

robertw@informix.com (Rob Weinberg) (12/03/90)

In article <40477@ut-emx.uucp> flank@ccwf.cc.utexas.edu (Brett Jacobson) writes:
>>there is NO support for graphics
>>generated on the Macintosh as editable files for ANY application on the NeXT.
>>. . .on a Macintosh are stuck there unless you are willing to import them as TIFF or
>>EPS (uneditable) formats.
>
>EPS is editable (by Adobe Illustrator)

>Chris Petrilli
>(forwarded by Brett Jacobson)

How do you edit EPS in Adobe Illustrator? I don't think this is possible -
you can import into Illustrator and do a few manipulations on the
object as a whole (rotate, resize), but Illustrator only really edits
its own highly-defined PostScript code. 

I don't really think it is a good idea for NeXT to create a PICT
transporter. The reason is that in the Mac world itself, PICTs created
in various draw programs are not easily transported from one Macintosh
application to another. Try experimenting with transporting a file
created in MacDraw into Canvas, for instance. It is very cludgy - 
a lot of inaccuracies result. And if you save a file from
a Macintosh draw program as a PICT, a good deal of the information that
went into the drawing is lost, and cannot be recovered later.

Many times, when importing a PICT from MacDraw into Microsoft WORD,
I have seen a disappointing loss of quality - the lines become
spikier where they should be smooth. And some of the lines may be
moved a bit, resulting in a figure that is not of acceptible quality.
I have had to have MacDraw and WORD open at the same time, so that
I could cycle into MacDraw, modify a drawing, save as a PICT,
reimport it into WORD, and print it out, again and again, until I
got a result that looked like my original MacDrawing. I have not
had this problem with Adobe Illustrator's graphics, which are
strictly PostScript code. They do not change when they are imported
into another program.

PICT is a cludge. The only real standard is PostScript, and the
real solution is a program that draws in PostScript, as directly
as possible.  Perhaps Illustrator for the NeXT, when it is released,
will generate files that are completely transportable between the
the Mac and NeXT (I have no idea if this is planned).

Sorry to sound negative. I just really had my fill of trying to
make PICTs work in Macintosh desktop publishing. They are not very
transportable on the Mac, and I hope we don't get invaded by them
on the NeXT.


-- 
* Rob Weinberg, graphics & publishing ***** Does a falling tree make a sound *
*  {uunet,pyramid}!infmx!robertw      *****   if  1: no one hears it         * 
*  => Ask me about me.                *****   BUT 2: it is not known that    * 
*  => Ask Informix about Informix     *****          no one hears it?        * 

glang@Autodesk.COM (Gary Lang) (12/03/90)

>	Maybe you should learn a bit more about the mac before expressing an
>opinion.  PICT and QuickDraw specs were published five years ago (Tech Note 
>#21), when NeXT was just a glimmer in Steve's eye.

These are metafile formats; tiff is for bitmaps. TIFF is a standard on
the Mac as well as every other platform. There's little likelihood
that Quickdraw will ever be an "interchange" format which is what
is being asked about here.

Don't worry - the native file formats on the cube are well-supported
on the Mac, PC and Sun machines as well. I interchange fonts,
RTF files, sound files and other such materials all the time. 
get your cube now.

mingo@cup.portal.com (Charles Hawkins Mingo) (12/03/90)

jmunkki@hila.hut.fi (Juri Munkki) writes: 

>Tough luck. PICT 2 could be read with the documentation in IM V, except
>that there is no documentation on pixel maps are packed and stored (if
>they are packed). So unless you know how they are stored, you can't have
>pixel maps.

	Check out Tech Note 171:  "Things you want to know about PackBits"
for a discussion of how PICT2 packs bits.
> 
>The latest thing is 32 bit QuickDraw. I don't have the documentation
>for that, but I seem to remember that it had some new things to add
>to PICT 2.

	The QuickDraw Release notes and Tech Note 275 document it fairly
completely.

	I do agree with you observation that PICT's are really for Mac's only:
in order to interpret them you either need to have a Mac ROM present (to 
supply the routines), or emulate the ROM routines (not easy to do well).
Apple doesn't like the idea of people cloning bits of the ROM (even legally).

glenn@heaven.woodside.ca.us (Glenn Reid) (12/04/90)

In article <1040@toaster.SFSU.EDU> hodges@toaster.SFSU.EDU (John Hodges) writes:
>Hello NeXT-Land. Regarding my posting last night I have not-so-good news
>
>I just spoke with everyone at Adobe and MediaLogic regarding importing editable
>graphics created on a Macintosh to the NeXT. I have been told, by both of these
>companies, and by Frame Technologies, that there is NO support for graphics
>generated on the Macintosh as editable files for ANY application on the NeXT.

Too strong.  Transportation of editable files is not, and has never been, a
system-wide feature.  It is cooperation between applications on the two
platforms.  I'll make a brief concession to PICT as an editable form, but
it also indicates what is wrong with this scheme, since most serious
graphics applications have abandoned it in favor of the full expressive
power of PostScript.

At the application level, The Adobe Illustrator file format can be
opened by Adobe Illustrator on the NeXT platform.  This also means it
can open Aldus Freehand and Adobe Streamline files and edit them, and
there are quite a few other apps on the Mac that support this format.

Furthermore, Adobe Illustrator for the Mac ships with an application called
DrawOver that can convert MacDraw files (PICT) to Adobe Illustrator format,
which can then be opened and edited on the NeXT.

Also, as more and more Mac applications are ported to NeXT, the file
format issue will be reduced.

As a final (and admittedly editorial) point, if you really have
megabytes of graphics in PICT format, the best thing that could happen
to you would be to be forced to recreate them as real artwork, with
line thicknesses less than 1/72 inch, Bezier curves instead of arcs of
circles, real grayscale and halftoning, etc., etc.

>Those of you reading from Redwood City, PLEASE decide on a graphic interchange
>standard NOW. It is going to hurt you, because there are many Apple lovers who
>would like to jump boat, given a good home for their text and graphics.

Deciding on a graphic interchange format would help.  Adobe is working
on doing this with their Illustrator file format, and now that they have
shipped Illustrator 3.0 maybe they'll document the file format so we
can use it as an editable format.

But you're painting a black-and-white picture in which NeXT owners are
unable to open any files from the Mac.  In truth, the NeXT is already
far ahead of *any* non-Mac platform at supporting Macintosh documents,
due to its full support of PostScript.  A possible exception might be
DOS/Windows, about which I steadfastly refuse to learn anything.

glenn@heaven.woodside.ca.us (Glenn Reid) (12/05/90)

In article <SCOTT.90Dec1135317@next-5.gac.edu> scott@next-5.gac.edu (Scott Hess) writes:
>But, you might add, TIFF was specifically designed to be used as an
>independant interchange format.  Tag Image File Format, and from the
>specification memorandum:

TIFF is useless as a general-purpose interchange format, because it
only handles image data (bitmaps and halftones).  It does not support
text, line art, or anything else.

Besides, TIFF originated on the Mac, so it's a little silly to claim
that NeXT has this standard that the Mac doesn't have.

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).  The closest
thing I've seen so far to this is the Illustrator file format, which is
supported by several applications on the Mac. There are, of course, other
standards, like GKS and PHIGS and stuff like that, but these are not
useful for Mac/NeXT portability, and besides, they have their limitations.
-- 
 Glenn Reid				RightBrain Software
 glenn@heaven.woodside.ca.us		PostScript/NeXT developers
 ..{adobe,next}!heaven!glenn		415-851-1785

baffico@adobe.COM (Tom Baffico) (12/05/90)

In article <1040@toaster.SFSU.EDU> hodges@toaster.SFSU.EDU 
(John Hodges) writes:
>Hello NeXT-Land. Regarding my posting last night I have not-so-good news
>I just spoke with everyone at Adobe and MediaLogic regarding importing 
>editable graphics created on a Macintosh to the NeXT. I have been told, 
>by both of these
>companies, and by Frame Technologies, that there is NO support for graphics
>generated on the Macintosh as editable files for ANY application on the NeXT.

Wait, you forgot to speak to me... I would have told you that while there
may not be a general solution to all graphics interchange, you will be 
able to exchange graphics between a Mac and a NeXT using Adobe Illustrator
as a common file format. Illustrator on the Mac and Illustrator on the NeXT
will be able to interchange files, no problem. Any work you do with Adobe
Illustrator on the Macintosh will not be lost if you then choose to move to 
a NeXT. And this interchange is not limited to work done with Adobe 
Illustrator, many applications on the Mac and the PC such as Aldus FreeHand, 
MicroGrafx Designer and Corel Draw are able to parse Illustrator based 
graphic files.

For scanned images TIFF files are an accepted file interchange standard for
editable sampled image data and NeXT is providing better support for TIFF 
in its system than the support you will find in Macs or PCs.
(or any other platform that I know of.)

>Those of you reading from Redwood City, PLEASE decide on a 
>graphic interchange standard NOW.

A graphic interchange standard is a great idea, and we do need an industry
champion to bring it about, but to be successful an interchange standard
will need the backing of more than one company.

>Jack Hodges,
>San Francisco State University

Tom Baffico
Adobe Systems

scott@mcs-server.gac.edu (Scott Hess) (12/05/90)

In article <351@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) writes:
   In article <SCOTT.90Dec1135317@next-5.gac.edu> scott@next-5.gac.edu (Scott Hess) writes:
   >But, you might add, TIFF was specifically designed to be used as an
   >independant interchange format.  Tag Image File Format, and from the
   >specification memorandum:

   TIFF is useless as a general-purpose interchange format, because it
   only handles image data (bitmaps and halftones).  It does not support
   text, line art, or anything else.

From the way it sounds here on the net, PICT barely supports it in a
readable format :-).

   Besides, TIFF originated on the Mac, so it's a little silly to claim
   that NeXT has this standard that the Mac doesn't have.

Who's claiming that?  _I'm_ claiming that it's a standard on _both_,
so, can be used (albeit primitively) to exchange graphics between
machines.

   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).  The closest
   thing I've seen so far to this is the Illustrator file format, which is
   supported by several applications on the Mac. There are, of course, other
   standards, like GKS and PHIGS and stuff like that, but these are not
   useful for Mac/NeXT portability, and besides, they have their limitations.

Yes, that is the real problem.
--
scott hess
scott@gac.edu
Independent NeXT Developer	(Stuart)
GAC Undergrad			(Horrid.  Simply Horrid.  I mean the work!)
<I still speak for nobody>

new@ee.udel.edu (Darren New) (12/06/90)

>   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).  

Sounds like Amiga's IFF to me.  It's the only file format I've heard of
that supports sampled sound, bitmap graphics, structured graphics,
musical scores, animation, and core dumps in the same format. -- Darren

-- 
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, 
      Formal Description Techniques (esp. Estelle), Coffee, Amigas -----
              =+=+=+ Let GROPE be an N-tuple where ... +=+=+=

jtc@latcs1.oz.au (John Catsoulis) (12/06/90)

What about painttoppm, picttoppm, ppmtops etc? This SPARCstation is full of
such utilities and I believe they are public domain. I convert images from
one form to another and back again all the time! 

John.
jtc@eesun3.ee.latrobe.edu.au

mikec@wam.umd.edu (Michael D. Callaghan) (12/06/90)

>Illustrator on the Mac and Illustrator on the NeXT
>will be able to interchange files, no problem. Any work you do with Adobe
>Illustrator on the Macintosh will not be lost if you then choose to move to 
>a NeXT. And this interchange is not limited to work done with Adobe 
>Illustrator, many applications on the Mac and the PC such as Aldus FreeHand, 
>MicroGrafx Designer and Corel Draw are able to parse Illustrator based 
>graphic files.
>
>Tom Baffico
>Adobe Systems

Tom, 

the big question is: When are we going to see Illustrator NeXT? I called
Adobe last week, and was told there is no planned release date! Some of
us can't wait that long.

I have a lot of Illustrator-format clip art that I would love to use
on my Cube. 

MikeC


--
___________________________________________________
Michael D. Callaghan,MDC Designs, University of Merryland
mikec@wam.umd.edu

amanda@visix.com (Amanda Walker) (12/08/90)

In article <38224@nigel.ee.udel.edu>, new@ee.udel.edu (Darren New) writes:
|> Sounds like Amiga's IFF to me.  It's the only file format I've heard of
|> that supports sampled sound, bitmap graphics, structured graphics,
|> musical scores, animation, and core dumps in the same format. -- Darren

There's always ISO ODA (Open Document Architecture).  The spec is tough
reading, but boy is it a generalized format...

I don't think there's a standard core dump content type, though... :).

--Amanda

davis@groucho.ucar.edu (Glenn P. Davis) (12/14/90)

In <351@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) writes:

>In article <SCOTT.90Dec1135317@next-5.gac.edu> scott@next-5.gac.edu (Scott Hess) writes:
>>But, you might add, TIFF was specifically designed to be used as an
>>independant interchange format.  Tag Image File Format, and from the
>>specification memorandum:

>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).  The closest
>thing I've seen so far to this is the Illustrator file format, which is
>supported by several applications on the Mac. There are, of course, other
>standards, like GKS and PHIGS and stuff like that, but these are not
>useful for Mac/NeXT portability, and besides, they have their limitations.

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" ??

Glenn P. Davis
UCAR / Unidata
PO Box 3000                   3300 Mitchell Lane, Suite 170
Boulder, CO 80307-3000        Boulder, CO  80301

(303) 497 8643

minich@d.cs.okstate.edu (Robert Minich) (12/14/90)

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

izumi@fugitive.berkeley.edu (Izumi Ohzawa) (12/14/90)

In article <1990Dec14.000607.16279@d.cs.okstate.edu> 
	minich@d.cs.okstate.edu (Robert Minich) writes:
>Does anyone know of a popular graphics editor
>that was designed around a specific file format?

Adobe Illustrator with the Adobe Illustrator file format.
This format is public (although copyrighted, anyone can obtain it
for free).
[Sigh, why does it take for Adobe so long to release a NeXT version?]

This is probably the best graphics file format for NeXT, because
files are already in PostScript or EPS, or they can be made into
one by prepending several proc set definitions.  And the graphics 
can be edited by AI or other programs which understands the format.
The specification has grouping operators which can define editable
objects within a file.

I hope that all NeXT programs, such as Mathematica, TopDraw
will be able to produce graphics files in AI format.

You can get the file format specification by sending a mail to
"adobe!ps-file-server@decwrl.dec.com" with a single line
message

send Documents AIformat.ps.Zba

This can be in the Subject: line or in the body of the message
with empty subject line.
(Don't put it in both.)

(This is a PostScript file compressed and binary-to-ascii encoded
by 'btoa', so you need 'atob' to decode it.  This again
can be obtained from ps-file-server by "send Programs btoa.shar".)

Izumi Ohzawa, izumi@violet.berkeley.edu

glenn@heaven.woodside.ca.us (Glenn Reid) (12/17/90)

In article <9534@ncar.ucar.edu> davis@groucho.ucar.edu (Glenn P. Davis) writes:

[ lots of stuff about document interchange file formats deleted ]

>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" ??

I can't remember much about CGM, to tell you the truth, but I think it
lacks features.  You would know better than I, but is there support for:

	* Bezier curves
	* line widths of essentially infinite variation?
	* dashed lines
	* true grey and color halftoning (as opposed to pattern filling)
	* rotated text
	* full CMYK color model
	* clipping

It wouldn't take very many of these features missing to make it unsuitable
for document interchange, especially from/to environments that use
PostScript regularly (like the Mac and the NeXT).

-- 
 Glenn Reid				RightBrain Software
 glenn@heaven.woodside.ca.us		PostScript/NeXT developers
 ..{adobe,next}!heaven!glenn		415-851-1785

glenn@heaven.woodside.ca.us (Glenn Reid) (12/17/90)

In article <1990Dec14.015629.16172@agate.berkeley.edu> izumi@fugitive.berkeley.edu (Izumi Ohzawa) writes:
>In article <1990Dec14.000607.16279@d.cs.okstate.edu> 
>	minich@d.cs.okstate.edu (Robert Minich) writes:
>>Does anyone know of a popular graphics editor
>>that was designed around a specific file format?

>Adobe Illustrator with the Adobe Illustrator file format.
>This format is public (although copyrighted, anyone can obtain it
>for free).

Illustrator wasn't designed around its own file format.  Obviously,
the file format grew out of the functionality of the program, as it
does with any other application's file format.  And the file format
certainly didn't exist before the application.  The original question
was asking about file formats that existed for the purpose of
portability; he mentioned CGM, but there are others, like SGML
(standardized general markup language or something like that).

>This [AI format] is probably the best graphics file format for NeXT,
>because files are already in PostScript or EPS, or they can be made into
>one by prepending several proc set definitions.  And the graphics 
>can be edited by AI or other programs which understands the format.
>The specification has grouping operators which can define editable
>objects within a file.

It is actually a bad file format for document interchange because the
support for text is almost non-existent and what is there has way too
much overhead to be practical.  Also, you can't represent compound
paths (disjoint subpaths, as in a donut shape).  The PostScript code
is also sort of, well, convoluted, to put it politely, and there are
way too many prologue definitions to fake CMYK color and spot color
and other things that don't really exist in PostScript (yet).

The new, improved Illustrator 3.0 file format (also supported in the
NeXT version) should be closer to the mark, and Adobe is actively
trying to position it as an editable file format.  There is much
better text support, and it looks somewhat promising, although there
is still no spec for it that I know of.

The Illustrator file format is a good general approach (making it both
a file format and a valid PostScript program) but it needs work and
it needs more support from other apps and/or translators to make it
practical to fill the need for a more universal editable representation.

Our TouchType product uses a similar approach, where the file format is
actually a valid EPS file, but it's not compatible with Illustrator for
the simple reason that the Illustrator text format wasn't up to the
task, and because we needed some extra semantics for our own purposes.

By the way, rumor has it that there is a group of "industry leaders"
forming to work on a revisable format, but nobody has invited a
representative from RightBrain Software yet :-)

/Glenn

-- 
 Glenn Reid				RightBrain Software
 glenn@heaven.woodside.ca.us		PostScript/NeXT developers
 ..{adobe,next}!heaven!glenn		415-851-1785

edwardj@microsoft.UUCP (Edward JUNG) (12/20/90)

In article <twaxacjoja@visix.com> amanda@visix.com (Amanda Walker) writes:
>In article <38224@nigel.ee.udel.edu>, new@ee.udel.edu (Darren New) writes:
>|> Sounds like Amiga's IFF to me.  It's the only file format I've heard of
>|> that supports sampled sound, bitmap graphics, structured graphics,
>|> musical scores, animation, and core dumps in the same format. -- Darren
>
>There's always ISO ODA (Open Document Architecture).  The spec is tough
>reading, but boy is it a generalized format...
>
RIFF, the file format recently introduced at the Multimedia Developer's
Conference, endorsed by IBM and Microsoft, and appearing in products
for MS/DOS, Windows, OS/2, and Macintosh, seems to be the emerging
standard. It is based upon IFF, which was a standard from Electronic
Arts, not from Commodore-Amiga (although it was most heavily leveraged
on the Amiga computers).

I believe that Corel is actually planning to use RIFF to wrap multiple
rendering/editable formats into a single file for platform-neutral
file formats. If/when editable postscript or similar formats become
widely-accepted open standards, it seems likely that these will appear
in RIFF (which can accept any serializable format).

--
Edward Jung
Microsoft Corp.

My opinions do not reflect any policy of my employer.

dan@gacvx2.gac.edu (12/20/90)

In article <59938@microsoft.UUCP>, edwardj@microsoft.UUCP (Edward JUNG) writes:
> In article <twaxacjoja@visix.com> amanda@visix.com (Amanda Walker) writes:
>>In article <38224@nigel.ee.udel.edu>, new@ee.udel.edu (Darren New) writes:
>>|> Sounds like Amiga's IFF to me.  It's the only file format I've heard of
>>|> that supports sampled sound, bitmap graphics, structured graphics,
>>|> musical scores, animation, and core dumps in the same format. -- Darren
>>
>>There's always ISO ODA (Open Document Architecture).  The spec is tough
>>reading, but boy is it a generalized format...
>>
> RIFF, the file format recently introduced at the Multimedia Developer's
> Conference, endorsed by IBM and Microsoft, and appearing in products
> for MS/DOS, Windows, OS/2, and Macintosh, seems to be the emerging
> standard. It is based upon IFF, which was a standard from Electronic
> Arts, not from Commodore-Amiga (although it was most heavily leveraged
> on the Amiga computers).
> 
> I believe that Corel is actually planning to use RIFF to wrap multiple
> rendering/editable formats into a single file for platform-neutral
> file formats. If/when editable postscript or similar formats become
> widely-accepted open standards, it seems likely that these will appear
> in RIFF (which can accept any serializable format).
> 
> --
> Edward Jung
> Microsoft Corp.
> 
> My opinions do not reflect any policy of my employer.

Does anyone know where RIFF specs exist?

-- 
Dan Boehlke                    Internet:  dan@gac.edu
Campus Network Manager         BITNET:    dan@gacvax1.bitnet
Gustavus Adolphus College
St. Peter, MN 56082 USA        Phone:     (507)933-7596