Path: utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!agate!darkstar!ssyx.ucsc.edu!sirkm
From: sirkm@ssyx.ucsc.edu (Greg Anderson)
Newsgroups: comp.sys.mac.programmer
Subject: Re: PICT (version 2) files
Keywords: PICT files
Message-ID: <4724@darkstar.ucsc.edu>
Date: 27 Jun 90 03:50:30 GMT
References: <9006251132.aa25836@ICS.UCI.EDU> <2582@network.ucsd.edu>
Sender: usenet@darkstar.ucsc.edu
Reply-To: sirkm@ssyx.ucsc.edu (Greg Anderson)
Organization: Organization?  Me?
Lines: 26

In article <2582@network.ucsd.edu> moreland@network.ucsd.edu (John Moreland) writes:
>  ...............  The main problem with this info is that it is the only
>  "after-the-fact" data that "needs" to be generated after all opcodes have
>  been writen out.  This causes great pain on systems like UNIX (with pipes).

And I suppose that Unix lacks a malloc() function?  Try building the entire
PICT in memory, then send it to the pipe.

>  Apple tends to be a little shortsighted about such closed designs.

It does appear that Apple programmers are not the only ones who overlook
obvious solutions.  :>

>  APPLE, THE WHOLE WORLD IS *NOT* A MAC !

Nor is the whole world perfect.  Writing code that works with existing
standards is almost always harder than doing an equivalent function using
your own data structures.  You might not like the way the standard was
implemented, but if you want to be compatible, you have to figure out how
to code to spec.

That, as they say, is life in the big city.
  ___\    /___               Greg Anderson              ___\    /___ 
  \   \  /   /                                          \   \  /   /
   \  /\/\  /                                            \  /\/\  /
    \/    \/              sirkm@ssyx.ucsc.edu             \/    \/