Appendix 1 - The Structure of Draw files

A Draw file consists of a 40-byte header followed by the objects that make up the drawing. If the file contains any text objects (and in some applications, whether it contains any or not.) the first object will be a list of the fonts used (object type 0). If the file originated in a RISC OS 3 version of Draw and contains an options object (object type 11) this will follow the font list or, if none is present, the options object will be the first object in the file. The visible objects in the document follow sequentially, from the bottom of the stack (back of the drawing) to the top (front of the drawing). Groups consist of a 36-byte group header (object type 6) followed immediately by the objects in the group. Path objects in Draw are composed entirely of 4-byte words and all object lengths are constrained to multiples of 4 bytes.

The Draw file header

This begins with the four bytes that make up the ASCII for Draw. It is these that identify the file as a Draw file. If omitted, most software will issue an appropriate error message such as 'This is not a Draw file'. Optionally, beginning at byte 12, the name of the application in which the drawing originated may be inserted. This is 12 bytes long, any excess bytes being made up be spaces (ASCII &20).

Object types used in Draw

All objects begin with a four byte word representing the object type number Although this appears to allow for a maximum of 4,294,967,296 different object type, which might appear rather optimistic, in practice some applications use the object type number for other purposes, as we shall see

The second word represents the length of the object in bytes and therefore provides a pointer to the next object.

Since this is an established convention, it is easy to arrange for software that handles Draw files simply to skip over any object whose type it does not need to recognise. Indeed, some applications deliberately manipulate object type numbers. In DrawPlus, for instance, when an object is moved to a layer, bits 8 to 12 of its object type number are ORed with the layer number. So a sprite object (normally object type 5) on layer 2 will appear to be object type 5 + 512 = 517. When the picture is redrawn, the layer number is extracted from the object type number and, if the layer is visible, the object's original type number is presented to the redraw routine. So only objects on visible layers are redrawn.

• Font list (object type 0). The list begins at the ninth byte. Each entry consists of a single byte representing the number by which the font wall be known; the first entry is 1, the second 2 and so on. This is followed by the path name between /Fonts and the Outlines and IntMetrics files, directory names being separated by full stops. Each entry is terminated by 0. At end of the list up to three extra Os may be inserted to round the length of the object to a multiple of four bytes.
  
• Text object (object type 1). This includes the location and style data followed by the text content in plain ASCII. The font used is represented by a single byte identifying its position in the font list (see above).
  
• Path object (object type 2). The location and style data are followed by the coordinates of the points through which the path passes.
  
• Sprite object (object type 5). The location, orientation and scaling data are followed by the sprite data in standard Acorn sprite format. The sprite may include a palette.
  
  Group (object type 6). A group consists of a header which is 36 bytes long, followed immediately by the objects in the group. The object length word refers to the overall length of the group. The rest of the data include such information as the overall bounding box of the group.
  
• Text area (object type 9). This consists of a header of variable length followed by the text file in the form in which it was imported. The header includes a number of text column (type 10) objects, that is, one for each column requested in the text file.
  
• Text column (object type 10=&OA). These text column objects have a semi-independent existence in that they can be separately selected, sized and moved, but they cannot be copied or sent to the front or back. Since they reside in the header of their parent text area (type 9) object, they behave as though permanently grouped with it. Each text column object is just 24 bytes long, containing only the standard object header and the coordinates of the column it defines. It contains no text data. since this is contained in the initial text area object.
  
• Options object (object type 11=&OB). Used only in RISC OS 3 and higher versions of Draw, this object stores the user's preferences in use when the drawing was saved.

Other packages

Other vector graphics packages use the familiar Draw objects outlined above and some use other object types, peculiar to themselves. Vector, for instance, uses the following:

• Static replicate (object type 102=&66)
  
• Dynamic replicate (object type 103=&67)
  
• Masked object (object type 105=&69)
  
• Radiated object (object type 106=&6A)
  
• Skeleton for replications (object type 107=&6B)

If you load a Draw format file containing objects of these types into any other package than Vector, the objects concerned will usually be ignored. Replicated and radiated objects can be converted in Vector to separate objects which will be reproduced correctly by Draw and other packages accepting Draw-format graphics. In DrawPlus the visible object types are the same as in Drawplus an object type 65637 (=&10065) is also used for storing internal data such as preferred settings.

ArtWorks certainly uses some object types peculiar to itself, but if the drawing is saved as a Draw file, these objects are convened to a Draw compatible form first. For instance, a blend object that has not been expanded to separate objects will be found to consist simply of the two parent objects which are conventional path objects (object type 2).