Issue
Article
Vol.29 No.1, January 1997
Article
Issue
Issue |
Article |
Vol.29 No.1, January 1997 |
Article |
Issue |
A compound document system allows different applications to work together. For example, a word processor need not be forced to implement its own equation editor, instead it could employ compound document technology to co-operate with any equation editor available.
In this paper I present an object-oriented compound document system with a couple of unique features: the system allows embedded objects to be treated as a combination of characters and embedded objects, which can seamlessly be divided into parts and can then be presented on different pages during the pagination process.
Keywords
Compound document systems, object-oriented, OLE, OpenDoc, OOE, NEXTSTEP, PostScript, Objective-C, client-server.
Why bother about compound document systems? The reason why there are several ongoing projects ([2], [12], [19], [20], [21]) concerned with designing compound document systems is that there is a move away from large monolithic applications to smaller co-operating applications. The reason for this is that no single software vendor can develop the best solution for all kinds of computer usage. For example, there is no sense in a word processor application containing its own drawing module, its own charting module etc. We will end up with a much better computing environment if users are able to choose their favourite drawing program and use it in conjunction with whichever word processor they are most comfortable with. Compound document systems are here to improve the quality of the end-user environment -- bringing better tools to the market since the software vendors can concentrate on what they are good at. The best word processor team should develop the best word processor, the best drawing team should develop the best drawing program and not vice versa. The ultimate result is improved productivity -- and isn't that a very important objective for all computer science research?
This paper presents both a model and an implementation of a compound document system. The model has been labelled OOE -- Open Object Embedding -- and is described in detail in [1]. The implementation is based on the NEXTSTEP [10] operating system and application framework.
What is a Compound Document System? This term is not very well defined in the literature. I have decided to base my definition on the following subdefinitions.
A compound document is a document (preferably a word-processor document intended to be printed) containing embedded data presented as pictures. This definition defines any text document as a compound document as soon as it contains any kind of non-textual data such as bitmapped or vector-based pictures.
An editable compound document stores the embedded data in a way so that it is possible to edit the data using, preferably, the application which created it in the first place.
An application is a computer program utilized for creating documents. The typical application, in this context, is the word processor.
A client application is a computer program utilized for creating compound documents. Once again, a typical client application is the word processor.
A server application is a computer program utilized for creating embedded objects (see definition below). In this case, a typical server application is the drawing application.
An embedded object is data created in a server application and presented, preferably, as a picture within a compound document. The typical embedded object is a drawing created with a drawing application.
An editable embedded object is stored within a compound document in a way that it can later be edited using, preferably, the server application is was created with.
A Compound Document System is a framework which defines how server and client applications communicate; how embedded objects are stored within client documents; how to locate available server applications; and how the user interface should be designed.
The OOE model has, as a compound document system, the following characteristics:
Client and server applications communicate both through messages and through a globally shared copy buffer (SCB). When a client needs data from a server, it signals the server and tells it to put data of some kind on the shared copy buffer. This communication is supported by two modules essential to the model: the Server Advertisement Forum (SAF) and the Application Manager (AM).
The SAF is essentially a globally shared database of information about all applications accessible on the local hard disk or on the local network. The database contains information about file system paths to all applications, which applications support the OOE protocols, the application types, and details of how to launch particular applications. The type information is used by the graphical user interface (GUI) of OOE to inform the user whether a chosen server application is a spreadsheet, table editor or something else. The launch information is used to avoid timeouts since some applications can take very long to launch. The SAF is implemented using small "property files" associated which each application executable and a small daemon which scans the accessible disks for these files caching them in a file in the user's home account.
The AM is responsible for launching and terminating applications as well as for informing applications about the accidental termination of other applications.
The communication between client and server applications is based on the Distributed Objects (DO) [4] module of NEXTSTEP. The DO module seamlessly extends the message passing in the Objective-C language and runtime with interprocess messaging.
An embedded object in the OOE model is stored within the client document in different formats. The model assumes at least three: Image Data, Document Data and Source Data.
The Image Data is used when the object is presented on the screen and when it is printed. If PostScript is used as Image Data, as is the case in our implementation of OOE, the server never has to be invoked when the client document is printed. It is my belief that this is a very important property of any compound document system. Systems such as OLE and OpenDoc rely on the server when client documents are printed.
The Document Data contains the internal structures of the object. OOE does not specify the format of this data and the client just stores it as a stream of bytes. Note that the word "object" in the sentence "object embedding" is not really appropriate since no object is embedded, just "dumb" data. The client has no idea of what is embedded.
The Source Data contains information about which application was used when creating the object.
A server application can also emit Interface Data. In a similar manner to the Document Data, this is stored within the client as a stream of bytes with unknown format. The Interface Data can be used by server applications to associate interface-related information such as size and position of palettes and other GUI tools.
Data to and from the client and the server application is transported using the shared copy buffer (SCB) which is implemented using the NEXTSTEP built-in Pasteboard server. The SCB can simultaneously hold data of different types, analogous to a drawer with labelled boxes. A client application tells the server application what kind of data it want to fetch from the SCB by "declaring" the SCB with the desired data types (telling the server which boxes in the drawer to fill). The server application in question queries the SCB for the declared types and outputs the types requested. For example, when a client wants the server to output Image Data to be presented within the client document, it declares the SCB with the Image Data (i.e PostScript) type. The server notices this and outputs PostScript.
The OOE client part has so far been added to one commercial product, the OpenWrite word processor [13], as well as to two demonstration applications -- Patron and Champ -- both which are described in full detail in [1].
Several NEXTSTEP vendors have added OOE server compatibility to their products, such as: Create, a drawing program [3]; Tailor, a WYSIWYG PostScript editor [15]; Questor, a spreadsheet application [15]; Graphity, a 2D and 3D charting application [8]; EquationBuilder, a WYSIWYG equation editor [6]; ChartSmith, a charting application [18]; Tables, a WYSIWYG table editor [16]; Draw++, a free drawing application and Yap++, a free PostScript editor.
OOE allows embedded objects to be created both by initiating the process from within the client (e.g. word processor), selecting a server application to use; or by copy/pasting an object from a server application into a client document. The former way of embedding an object by choosing a server application is also supported by a GUI modal dialog panel (fig. 1), with which the user can choose from the applications the SAF has found on the hard disk.
Figure 1: Selecting an OOE server application
The latter way of embedding an object is supported by a GUI modal dialog panel (fig. 2), which presents the user with options for just inserting a dumb picture or embedding the object using the OOE format.
Figure 2: Pasting an object into an OpenWrite document
The process of editing an embedded object is supported by a small GUI detail -- the OOE Client Button. This green diamond-shaped button is displayed to the right of an embedded picture whenever the user selects it with the mouse (fig. 3).
Figure 3: An OOE Client Button
Pressing the button causes OOE to prompt the user for which representation of the picture should be used to edit (fig. 4).
Figure 4: Selecting a representation to edit
The OOE user interface allows four different representations to be edited: the OOE document, object link, source file or image.
Choosing the OOE document launches the source application (if it isn't already running) and the document data is sent to the source application using the SCB.
The object link representation supports the NEXTSTEP built-in feature which allows pictures to be "hot linked" to their source documents (similar to Apple's "Publish and Subscribe" [14]).
The source file option allows the user to choose a new picture file from the hard disk.
The image option allows the user to edit the image data of any picture, for example TIFF or PostScript, regardless of whether the picture has been created with another server application such as a table editor or a spreadsheet. This option also uses the OOE protocols, but instead of invoking the source server application, the OOE runtime prompts the user to choose an OOE server application which supports TIFF for TIFF-based pictures or PostScript for PostScript-based pictures. This feature allows for example a user to first create an embedded table using a spreadsheet and later to edit the embedded picture as PostScript.
The process of saving an edited embedded object is similarly supported by a small GUI detail: the OOE Server Button, which looks very much the same as the Client Button.
Figure 5: The OOE Server Button
The OOE Server Button is displayed at the top left corner of the server editor window (fig 5). The button is green as long as the object has not been edited but turns red as soon as it has.
Pressing the button tells the OOE runtime to inform the client that the server can output new data. The client will declare the SCB with the desired data types and inform the server to output this data. When the data has been copied successfully to the SCB, the server informs the client that data can be fetched. When the client has copied the data from the SCB, it informs the server which then closes the document used for the embedded object.
So far I've described a quite "common" compound document system -- pictures can be embedded within client documents, while preserving their internal structures. But we cannot stop here: since the canonical client application in any compound document system is the word processor, we need to support both embedding objects which can be treated as characters and embedding objects which can be divided in a predictable manner, so that the pagination machinery of the word processor can lay out the parts on consecutive pages.
The canonical embedded object which needs character support is the equation. An equation has a base line which needs to be aligned to the base line of the surrounding text (fig. 6 and 7).
Figure 6: An embedded equation not using baseline information
Figure 7: An embedded equation with a baseline
Other character properties are distance to the next character, both horizontally and vertically, and a vertical baseline offset. This kind of information is supported by some applications producing Encapsulated PostScript (EPS, [7]) such as EquationBuilder [6], using an ordinary PostScript comment (fig. 8) in the header to inform the PostScript viewer about the character properties of the EPS picture.
Figure 8: Baseline information defined using a PostScript comment
Adding support for character properties to the OOE model is quite straightforward: first the client application must be extended to handle pictures with character properties; then this information can be provided by the server either by using a PostScript comment as described above or by placing this information as a 4-tuple on the SCB.
In the OOE implementation this is implemented as follows: if the client can handle character properties, it declares the SCB with the "OOE Baseline Info" data type when it tells the server to output data. The server then just checks if the SCB has this data type declared, and outputs the information. This strategy also allows TIFF pictures, and not just EPS pictures, to be treated as characters. In short: this extension to OOE simply means using a common format for the information and a common name to use when placing/retrieving the information to/from the SCB.
Another issue in embedding objects is non-rectangular shapes. Text-based clients sometimes want to embed an object within the text so that the text flows around the object.
Adding support for this, similarly to character properties, is quite straightforward. The server and the client have to agree on a common format for describing what I label "clip paths" and agree on a common name when transferring this information through the copy buffer. I have tested a simple format based on a single polyline which was found to be appropriate in the OpenWrite word processor. A more powerful clip path format would allow both ellipses and curves.
Figure 9: Top: Non-rectangular shape clipped against bounding box. Bottom: non-rectangular shape clipped against shape.
The third extension to OOE involves multi-page embedded objects. Since the canonical client is the word processor and the canonical embedded object for multi-pages would be the table, a compound document system must support dividing embedded objects onto sequential pages. Why? Because tables can extend beyond more than one page and because a document may look better if parts of a large table are located on one page followed by the rest on the next page.
Figure 10: An embedded spreadsheet table split onto two pages
Again, this is solved in OOE using a common format and a common copy buffer type. However, the format used for this feature is a little bit more complex as I will explain below.
One strategy a word processor may choose, is to divide the picture into rows at random. However, this is not good enough. For some pictures this may be adequate but for tables which are composed of rows, the split algorithm should take the row divisions into account.
Figure 11: "Incorrectly" dividing a picture of a table
The obvious way would be to inform the client where a picture can be divided to look good, for example by using simple vertical and horizontal offsets. This is however not appropriate in all cases since there is something I call "the shadow problem".
The shadow problem is most conveniently explained using an example. Imagine the table in fig. 12. The table consist of three rows and the table casts a shadow on the background. If we would just split this table into two subpictures, we would partly lose the shadow as depicted in the lower part of fig. 12.
Figure 12: Top: A table incorrectly divided. Bottom: A table correctly divided.
The solution is to allow a picture to be described as a matrix of elements where each element has two sizes: a normal size (the image size) and an element size. When producing elements of a picture of a table, each element gets an image size big enough to permit the shadow to be painted. The element size tells how to concatenate the element with the next, in order to hide the shadow when two elements are combined.
Figure 13: An element with its two sizes
This leads to what I call "the concatenation problem". As before, an illustration best shows this problem. Assume the small graphic object in fig. 14.
Figure 14: A tiny picture
If we zoom into the object in order to see which pixels actually get painted, we'll see something like depicted in fig. 15. In other words: if we just divide the picture into two elements, we will lose the top border of the second element. The solution is to use a one unit overlap, as shown in the lower part of fig. 15.
Figure 15: Top: Details of tiny picture and how it is divided into two elements without using an overlap offset. Bottom: Details of tiny picture and how it is divided using an overlap offset
In the OOE implementation, the format is implemented by a special kind of object: the Image Matrix. An image matrix keeps a matrix of Image Matrix Elements. Each Image Matrix Element holds a PostScript or a TIFF image as well as an element size as described above. Each element knows how to draw itself both to the screen and to a printer. The image matrix object knows how to concatenate itself to a solid image; how to copy itself to the SCB; and how to initialize itself using data in the SCB.
The image matrix concept was tested in the OOE client application OpenWrite. How this was done is explained below.
OpenWrite uses image matrix objects for both floating and fixed graphics. A floating graphic floats with the text, i.e. the graphic is treated as one character in the text stream. A fixed graphic is, as its name indicates, fixed to a particular page. Text can float around fixed graphics.
Before going into details regarding how image matrices are used internally in the OpenWrite text machinery, I will first sketch the basic structure of an OpenWrite document.
An OpenWrite document is essentially a set of paragraphs and a set of pages. Each paragraph contains a stream of characters and an optional set of attributes. Attributes are typed, e.g. "bold" attributes are used for displaying parts of a paragraph in a bold type face and "graphic" attributes point to a graphic which should be treated as a character. For each floating graphic in a paragraph, the character stream contains a special graphic character. A page contains optionally two headers, two footers and a set of graphic objects.
Fig. 16 Internals of an OpenWrite paragraph with a floating graphic.
Adding support for image matrices mainly involved the following factors:
So far I've tested the image matrix ideas in two different applications, the Questor spreadsheet application [15] and the Tables WYSIWYG table editor [16].
Adding image matrix support in Questor was quite straightforward. The application already knew how to copy the selection (a range of cells) as both TIFF and EPS to the SCB. This code had to be extended to be able to also copy an image matrix. This code works as follows:
The Questor code did not have to worry about the element size feature of the Image Matrix concept since spreadsheet cells cannot "cast a shadow".
In the other application -- Tables -- cells can cast shadows, so the image matrix extensions to this application had to use the element sizes. Another problem which had to be solved in Tables, was how to calculate the number of rows to use in the image matrix. This is not as simple as it seems since cells in a Tables table can be merged, as shown in the fig. 17 below.
Figure 17: A Tables document with merged cells, producing three image matrix rows
I've briefly presented the OOE compound document system. As designer and implementor of both the OOE runtime and several client and server applications, I can conclude the following.
1. Backlund, B. Compound Document Systems -- Open Object Embedding. 1996.
2. Brockschmidth, K. Inside OLE 2, Microsoft Press, 1994.
3. Stone Design, Create User's Manual, 1994. ftp://ftp.cs.orst.edu/software/NeXT/demos/graphics/Create_3.0.tar
4. NeXT Publications. Distributed Objects. Chapter 6 in "NEXTSTEP General Reference: Release 3 -- Volume Two", Addison-Wesley.
5. Adobe Systems. Programming the Display PostScript? System with NeXTstep. Addison-Wesley
6. Digital Tool Works. EquationBuilder User's Manual. 1993 ftp://ftp.cs.orst.edu/software/NeXT/demos/editors/EquantionBuilder3.2.307.tar
7. Adobe Systems, PostScript Language Reference Manual, 2nd Edition. Addison-Wesley.
8. Xanthus International, Graphity User's Guide. 1994. ftp://ftp.cs.orst.edu/software/NeXT/demos/graphics/Graphity_1.1.tar.gz
9. Backlund, Björn. Some thoughts about in-place editing in compound document systems. Xanthus Technical Report 95-001. 1995
10. NeXT Publications. NEXTSTEP Operating System Software. Release 3. Addison-Wesley
11. NeXT Publications. NEXTSTEP Object-Oriented Programming and the Objective C Language. Release 3. Addison-Wesley.
12. CILabs. OpenDoc: Shaping Tomorrows Software. ftp://ftp.cilabs.org/pub/cilabs/tech/OD_Overview
13. Xanthus International. OpenWrite User's Guide. 1994. ftp://ftp.cs.orst.edu/software/NeXT/demos/editors/OpenWrite_1.1.tar.gz
14. Apple Computer. Edition Manager. Chapter 2 in Inside Macintosh, Interapplication Communication. Addison-Wesley.
15. Xanthus International. Questor User's Guide. 1994. ftp://ftp.cs.orst.edu/software/NeXT/demos/spreadsheets/Questor_3.2.tar.gz
16. Xanthus International. Tables User's Guide. 1995. ftp://ftp.cs.orst.edu/software/NeXT/demos/editors/OW_Extras_1.1.tar.gz
17. First Class NV. Tailor 2.0 User's Manual, 1995. ftp://ftp.cs.orst.edu/software/NeXT/demos/graphics/Tailor_2.0d_Package.tar
18. Blacksmith Inc. ChartSmith User's Manual. 1994. ftp://ftp.cs.orst.edu/software/NeXT/demos/graphics/ChartSmith_1.2.gnutar.gz
19. Silicon Graphics, Inc.; Fujitsu, Ltd. Fresco Reference Manual. 1995 ftp://ftp.faslab.com/pub/Fresco/doc.tar.gz
20. OMG. Common Facilities, Request for Information. OMG TC Document 94.2.11. ftp://ftp.omg.org/pub/common_facilities/CF_RFI.ps
21. Potel, M., Cotter, S. Inside Taligent Technology. Addison-Wesley.
Björn Backlund is president of Xanthus International AB. He is the designer of the OpenWrite word-processor for NEXTSTEP and of Intranet Writer, an HTML/CSS-based word processor for Windows NT/95.
phone: +46 8 635 30 61
email: backlund@sics.se
Issue |
Article |
Vol.29 No.1, January 1997 |
Article |
Issue |