March 95 - Getting Started With OpenDoc Graphics
Getting Started With OpenDoc Graphics
Kurt Piersol
The layout and imaging services offered by OpenDoc, Apple's compound-document
architecture, provide extremely powerful support for document layout. However, with
power comes a certain amount of complexity. The introduction to OpenDoc graphics
given in this article reduces some common graphics operations to simple recipes. By
following these recipes, you'll get a sense of how to use OpenDoc that you can later
build on as you learn about its more sophisticated capabilities.
OpenDoc's layout and graphics model is designed to allow maximum flexibility at
imaging time. You can use it to create very complex displays that include real-time
motion, offscreen rendering and compositing, and more. But at first glance, it can
appear complicated and bewildering. Don't despair: the good news, as you'll learn in
this article, is that you can use it for simple tasks without much trouble.
I touched on some of the basics of the OpenDoc layout model and drawing code in my
article "Building an OpenDoc Part Handler" in develop Issue 19 (which you need not
have read before reading this article). Here I reiterate a little of that and add to it as I
explain the basic terminology and concepts of OpenDoc graphics. Then I present a
series of simple recipes (also provided on this issue's CD) that illustrate the use of
OpenDoc graphics objects. You'll learn how to draw a part, scroll the part, zoom or
rotate the part's content, make an embedded part visible, alter the coordinate system
scaling, and do simple printing under QuickDraw.
THE BASICS OF OPENDOC GRAPHICS
OpenDoc objects work together to lay out and draw each piece of content (eachpart) in
a compound document. We'll take a look at the layout model here before focusing on
each of its constituent objects and how the objects relate to one another.
THE LAYOUT MODEL
OpenDoc's layout model includes both a persistent representation and a runtime
representation of a document's state. Persistent information is represented in objects
called frames, while runtime information is captured in objects called facets. The two
sets of objects, working together, produce the structure of the displayed or printed
document.
Frames are arranged in a lattice (speaking in mathematical, not geometric, terms).
Any frame can contain any other, but in practice they almost always fall into a strict
hierarchy, with each frame contained in only one other frame. Frames always contain
a pointer to their containing frame but not directly to their embedded frames. Some
applications -- like Personal Information Managers, which handle lots of
unstructured information -- have more sophisticated data models, however, so
OpenDoc is built to accommodate these applications.
Facets are always arranged in a strict hierarchy, and every facet has pointers to every
contained facet as well as to the containing facet. OpenDoc walks this structure at run