Path: utzoo!attcan!uunet!cs.utexas.edu!usc!ucsd!network.ucsd.edu!moreland
From: moreland@network.ucsd.edu (John Moreland)
Newsgroups: comp.sys.mac.programmer
Subject: PICT (version 2) files
Summary: PICT file question
Keywords: PICT files
Message-ID: <2582@network.ucsd.edu>
Date: 26 Jun 90 23:30:59 GMT
References: <9006251132.aa25836@ICS.UCI.EDU>
Organization: University of California, San Diego
Lines: 34

I am writing code on a UNIX system which outputs images in PICT format.
The problem is, at times I need to write the PICT data to a pipe and I thus can
not "back up" to re-write the pictSize information which has already
whized by hundreds of bytes ago.  Does anybody know of a workaround ?
I thought, perhaps, there might be a "magic number" (0, -1, FFFF, etc..) that
might tell the Mac to ignore the pictSize field and just read till EOF or
until it sees the "opEndPic" opcode...

All of the programs I have tried get quite upset (with FFFF for example).

FLAME ON (Apple?)

  This "pictSize" info is pretty silly anyway.  I have written a PICT parser
  that does just fine without needing to know how much data is in the PICT
  file.  All you have to do is read PICT opcodes until you hit the "opEndPic"
  (0x00FF) opcode !  [even EOF would do just fine if you think about it.]
  Even if you need to know how big the picture is (for memory allocation for
  example), why not just see how many bytes are in the file instead of using
  the "pictSize" information ?  Even so, files get "munched" and the pictSize
  info could LIE.  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).

  Apple tends to be a little shortsighted about such closed designs. Almost all
  documentation on PICT/QuickDraw, for example, suggests that one would have
  little reason to know the "guts" of PICT files since "OBVIOUSLY" PICT files
  are always written on a mac...

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

FLAME OFF

Thanks,
John