MacDraw Files
Volume Number: 3
Issue Number: 10
Column Tag: Programmer's Forum
MacDraw PICT Files from Basic
By Bob Andris, Lockheed Corp.
Why “Draw” a ‘PICT’ File?
This article should really have been titled “ ‘PICT’ing in ZBasic™ “, but that
didn’t sound quite as clear. The ‘PICT’ file format is rapidly becoming the standard for
transferring High Quality graphics between programs, and not just graphics
programs. To name just a few, MacDraw™, MacDraft™, Cricket Draw™, and
SuperPaint™ all will both read and write ‘PICT’ files. However, layout programs like
PageMaker™ will also read ‘PICT’ files in directly with its “Place” command. In
addition to all of the above a word processor like Word™ 3.0 will pass ‘PICT’
information back and forth through the clipboard and retain the individuality of each
‘PICT’ element. Why all of this compatibility? The answer to that one is simply called
the “LaserWriter™”!
The LaserWriter with its PostScript™ language treats all ‘PICT’ elements as
separate objects, not bit maps, and prints (or better yet, “draws”) them vectorially.
That’s why a diagonal line has nice sharp edges, and not the “jaggies” that go with the
individual pixels of a bit map. This even holds true for text! As the quest for higher
and higher quality proliferates, the ‘PICT’ format will become even more prevalent.
The ‘PICT’ format is also inherently faster than most because it is the format that
‘QuickDraw’ in the ROM is using to begin with!
All of the graphics programs mentioned previously also have their own
proprietary file format, including MacDraw. Getting into those formats is not the
purpose of this article. It is “ ‘PICT’ing “ that we’ll be covering in detail. And, as you
will see, “draw”ing a ‘PICT’ file in ZBasic is even easier than “paint”ing a ‘PNTG’
file in ZBasic as I covered in a previous article.
What’s in the ‘PICT’ure?
First of all, there are several good references on the ‘PICT’ file format and
‘QuickDraw’ing a picture, so I’ll give them to you now.
MacDraw’s PICT File Format and Comments, Macintosh Technical Note #27, by
Ginger Jernigan, Aug. 20, 1986.
QuickDraw’s Internal Picture Definition, Macintosh Technical Note #21, by
Ginger Jernigan, June 20, 1986.
Optimizing for the LaserWriter--Picture Comments, Macintosh Technical Notes
#91, by Ginger Jernigan, Mar. 2, 1987.
Inside Macintosh™ Volume I, chapter 6, QuickDraw, in particular Pictures and
Polygons starting on p 158.
As Inside Mac says on page 158, “A picture in QuickDraw is a transcript of calls
to routines that draw something--anything--in a bit image.”. Whoa ! ! ! What
happened to all this elements, objects, and vector stuff this idiot was just talking
about? Well, the bit image they’re talking about on page 158 is the screen. The things
that get stored in the files and also sent to the LaserWriter are those calls friends, not
a bit image!
Since pictures are all of varying size, i.e., length, as we could have guessed a
Picture is really just a variable length record. The record always starts with the
following two fixed-length fields:
picSize: INTEGER; {size of record in bytes}
picFrame: Rect; {picture frame}
Immediately following the two fixed-length fields are the ‘QuickDraw’ calls to
generate the picture. It is important to point out that the size (picSize) includes the
first two fixed-length fields themselves. If we were to write out this picture record to
a file we’d have what we need, right? Wrong! All of the programs mentioned
previously would spit-up something terrible. So, what’s missing? Well, it’s a header
of some kind . . . that’s what makes a picture record into a ‘PICT’ file. So let’s get into
that now.
The MacDraw ‘PICT’ file format
Referring you to tech note #21, MacDraw gives you the option to use two file
formats. They are DRWG and PICT. The DRWG format is the internal one that only
MacDraw understands. The PICT format is the one we’ll look at in MacDraw. Rather
than just drone on and on, it’s time for an example. I went into MacDraw, itself, drew
a simple five-sided ‘closed’ polygon, saved it as a ‘PICT’ file and then went into
Fedit+™ to take a look at it with tech note #27 in hand. Figure 1 shows the polygon as
you normally see it in MacDraw.
Fig. 1 A draw figure created from Basic!
As we can see, there’s not much to it. Just an ordinary polygon. The total file
size, as stored by MacDraw, is just 570 bytes. That’s good, since the actual ‘PICT’ure
part of it is only 58 bytes long. A quick mental calculation tells us the header is our
old friend, 512-bytes, long! Same length as the ‘Paint’ file headers were. Now let’s
view what you find in Fedit+ and take a close look at the header.
Fig. 2 ‘Fedit+’ View of the “MacDraw”ed Polygon File
Figure 2 is the “ Fedit+ ”ed look at both sectors of the MacDraw ‘PICT’ file
called “Polygon”. The breaks in the sector views are where they become all zero from
then on. The numbers in the left halves are the hex representation of the code and to
the right is the ASCII representation. Here’s what we find in the header (refer to tech
note #27):
MacDraw PICT File Header
4452 5747 fType ‘DRWG’ in ASCII for
MacDraw 1.7 & 1.9
4D44 hdrID ‘MD’ in ASCII
0006 version file format version
0003 to prRec 120 byte print record
0000 (ends with position 000079)
0000 0000 xOrigin drawing origin
0000 0000 yOrigin drawing origin
0048 0000 xScale screen res (=72 dots/inch)
0048 0000 yScale screen res (=72 dots/inch)
0000 to atrState state of drwg attributes
0000 (ends with position 0000CD)
0001 lCnt no. of top-level objects
0001 lTot total no. of all objects
0000 0066 lSiz total size of list
000A 0000 top box of all objects (= 10)
0055 0000 left box of all objects (= 85)
0046 0000 bottom box of all objects (= 70)
00E1 0000 right box of all objects (=225)
0007 to filler 282 unused bytes
0000 (ends with position 0001FF)
Creating this header for each different file would be quite time consuming and
also subject to error. Fortunately we’re in luck! Tech note #27 says “If MacDraw
opens a PICT file and finds that it has a different hdrID than MacDraw expects, or that
the first block is zeroed, it ignores the header and uses its own default document
settings.”. So all we will have to do to create a “MacDraw” ‘PICT’ file in ZBasic is to
start it out with 512 bytes of zero (0)! The second part of Figure 2 is the data for the
actual QuickDraw ‘PICT’ure of the polygon. Let’s get into that now.
Pic comments are Helpful
MacDraw makes extensive use of picture comments [CALL PICCOMMENT( . . . ) in
ZBasic] to gain more functions than are available with the standard QuickDraw calls.
They are also used to guide the LaserWriter in “drawing” a complex set of figures and
text. A good example is using piccomments to tie arrowheads and lines together in
order to make the combination a single entity, the arrowhead-line. There are two
types of piccomments available, the so-called ‘shortComment’ and its companion the
‘longComment’. The long one allows you to specify a variable-length data record to be
executed, while the ‘shortComment’ has simply one operation, like “picPlyClo”,
which means we’re drawing a “closed” polygon. The only ones we‘ll be needing here
are the short comments. They are characterized by a one (1) byte ‘opcode’, which is
‘A0’, followed by a two (2) byte ‘kind’ which describes the action desired.
The first item in the QuickDraw picture is always 2 bytes of record size, which
includes the 2 bytes themselves. Then comes the picture frame, of type ‘Rectangle’,
which means 8 bytes (4 words or integers) of rectangle description. This is followed
with the picture definition. What we do now is look at the first byte, the ‘opcode’
(operation code), which tells us what is going to be described and then the descriptions
will follow. Then we look for the next ‘opcode’ and the process keeps repeating until
the picture is finished. Now we can take a look at that “PICT’ure data in the second half
of Figure 2:
Quickdraw Picture Format
003A picSize size of entire picture, in bytes
( 58 decimal, in this case)
0000 picTop loc of top of entire picture
( 0 decimal, in this case)
0000 picLeft loc of left of entire picture
( 0 decimal, in this case)
02D0 picBottom loc of bottom of entire picture
(720 decimal, in this case)
0240 picRight loc of right of entire picture
(576 decimal, in this case)
11 opcode for ‘picVersion’(1 byte )
01 version number for this picture
A0 opcode for ‘shortComment’(2 bytes)
0082 kind for ‘picDwgBegin’
(begin a MacDraw pict)
A0 opcode for ‘shortComment’(2 bytes)
00A0 kind for ‘PolyBegin’
(begin a special polygon)
A0 opcode for ‘shortComment’(2 bytes)
00A5 kind for ‘picPlyClo’
(the poly’n is to be closed)
01 opcode for ‘clipRgn’(10 bytes, or more)
000A rgnSize size of entire region(10 bytes)
0000 top top of ‘clipping’ rgn ( 0 dec)
0000 left left of ‘clipping’ rgn ( 0 dec)
02D0 bottom bottom of ‘clipping’ rgn (720 dec)
0240 right right of ‘clipping’ rgn (576 dec)
22 opcode for ‘short line’ (st.v,st.h,dh,dv)
000A start.v vert start pt for line (10 dec)
0055 start.h horiz start pt for line(85 dec)
00 dh horz line length ( 0 dec)
23 dv vert line length (35 dec)
23 opcode for ‘short line from’(dh,dv)
63 dh horiz line length(99 dec)
19 dv vert line length (25 dec)
23 opcode for ‘short line from’(dh,dv)
29 dh horiz line length(41 dec)
C4 dv vert line length (196-256=-60 *)
Referenced by (2):