Where our needs are similar, we borrow from existing standards. Our basic
need to move data between independently developed programs is similar to
that addressed by the Apple Macintosh desk scrap or "clipboard" [Inside
Macintosh chapter "Scrap Manager"].  The Scrap Manager works closely with
the Resource Manager, a handy filer and swapper for data objects (text
strings, dialog window templates, pictures, fonts?) including types yet to
be designed [Inside Macintosh chapter "Resource Manager"].  The Resource
Manager is akin to Smalltalk's object swapper.

We will probably write a Macintosh desk accessory that converts IFF files
to and from the Macintosh clipboard for quick and easy interchange with
programs like MacPaint and Resource Mover.

Macintosh uses a simple and elegant scheme of four-character "identifiers"
to identify resource types, clipboard format types, file types, and file
creator programs.  Alternatives are unique ID numbers assigned by a
central authority or by hierarchical authorities, unique ID numbers
generated by algorithm, other fixed length character strings, and variable
length strings.  Character string identifiers double as readable signposts
in data files and programs. The choice of 4 characters is a good tradeoff
between storage space, fetch/compare/store time, and name space size.
We'll honor Apple's designers by adopting this scheme.

"PICT" is a good example of a standard structured graphics format
(including raster images) and its many uses [Inside Macintosh chapter
"QuickDraw"]. Macintosh provides QuickDraw routines in ROM to create,
manipulate, and display PICTs.  Any application can create a PICT by
simply asking QuickDraw to record a sequence of drawing commands.  Since
it's just as easy to ask QuickDraw to render a PICT to a screen or a
printer, it's very effective to pass them betweenprograms, say from an
illustrator to a word processor.  An important feature is the ability to
store "comments" in a PICT which QuickDraw will ignore.  (Actually, it
passes them to your optional custom "comment handler".)

PostScript, Adobe System's print file standard, is a more general way to
represent any print image (which is a specification for putting marks on
paper) [PostScript Language Manual].  In fact, PostScript is a
full-fledged programming language.  To interpret a PostScript program is
to render a document on a raster output device.  The language is defined
in layers: a lexical layer of identifiers, constants, and operators; a
layer of reverse polish semantics including scope rules and a way to
define new subroutines; and a printing-specific layer of built-in
identifiers and operators for rendering graphic images.  It is clearly a
powerful (Turing equivalent) image definition language.  PICT and a subset
of PostScript are candidates for structured graphics standards.

A PostScript document can be printed on any raster output device
(including a display) but cannot generally be edited.  That's because the
original flexibility and constraints have been discarded.  Besides, a
PostScript program may use arbitrary computation to supply parameters like
placement and size to each operator.  A QuickDraw PICT, in comparison, is
a more restricted format of graphic primitives parameterized by constants.
So a PICT can be edited at the level of the primitives, e.g., move or
thicken a line.  It cannot be edited at the higher level of, say, the bar
chart data which generated the picture.

PostScript has another limitation: not all kinds of data amount to marks
on paper.  A musical instrument description is one example.  PostScript is
just not geared for such uses.

"DIF" is another example of data being stored in a general format usable
by future programs [DIF Technical Specification].  DIF is a format for
spreadsheet data interchange.  DIF and PostScript are both expressed in
plain ASCII text files.  This is very handy for printing, debugging,
experimenting, and transmitting across modems.  It can have substantial
cost in compaction and read/write work, depending on use.  We won't store
IFF files this way but we could define an ASCII alternate representation
with a converter program.

InterScript is the Xerox standard for interchange of editable documents
[Introduction to InterScript].  It approaches a harder problem: How to
represent editable word processor documents that may contain formatted
text, pictures, cross-references like figure numbers, and even highly
specialized objects like mathematical equations?  InterScript aims to
define one standard representation for each kind of information.  Each
InterScript-compatible editor is supposed to preserve the objects it
doesn't understand and even maintain nested cross-references.  So a simple
word processor would let you edit the text of a fancy document without
discarding the equations or disrupting the equation numbers.

Our task is similarly to store high level information and preserve as much
content as practical while moving it between programs.  But we need to
span a larger universe of data types and cannot expect to centrally define
them all. Fortunately, we don't need to make programs preserve information
that they don't understand.  And for better or worse, we don't have to
tackle general- purpose cross-references yet.

[Back to Amiga Developer Docs]