IFF Document Outline v0.1 Beta What is this format for? This document contains a proposed IFF Document FORM. This structure is in it's early days and still requires some pampering. While I can easily ensure that this document structure will fill the needs of Soft-Logik products (and I will ensure that future versions of PageStream are compatible) I can not speak for others. While it would be nice to get other information programs to support this format in the future, a more immediate need is to ensure they CAN support this format in the future. Other points of interest would be add on products. For example Grammar Checkers, Indexers, Automated Layout, etc... What spurred this one? HotLinks! For those of you who are unaware of what HotLinks is, let me explain. It's the exchange of Live Data. It's the ability to do work group editing. It's the ability to edit pieces of a large project in smaller pieces and have them assembled automatically. It's Publish/Subscribe on the Mac. It's DDE/OLE on the IBM. It's neat. What exactly does it do? It merely is a database of sorts of all project pieces, keeping track of owner, privileges, name, description, version, who is editing the piece, etc. When one program wants to edit a piece, it asks for permission to edit, edits it if it got the write lock and then updates the piece if desired, and then frees the lock. If that piece is in use elsewhere, then that copy will be updated instantly if it's loaded, or updated the next time it's loaded. What does this have to do with the document structure? Everything! For this to work, then programs must write everything they read, and agree on a format to exchange. If a user writes out a publication, edits in another program, and then goes back to the originating program and it can't read the file or changes that he had made (formatting, colorizing, sound score, whatever) is gone, the whole thing failed and should be thrown in the trash. This applies to all information passed about. The DOC structure contained below also contains several subFORMs, and these FORMS are generally pieces that can be edited in other programs wanting to deal with those piece types. For example, subFORM ILBM of course can be published from within PageStream, edited in a bitmap editor, and then updated automatically in PageStream. Same for FORM DTXT and text editors, FORM DR2D and drawing programs, and standards not yet proposed such as Graphs, Tables, Crossword puzzles.... The current FORMs that are well on their way are ILBM (of course :-) and DTXT. These are supported by BME and PageLiner respectively, and PageStream supports both. Do to the nature of IFF and the way text commands and tags are implemented in DTXT, these formats can and will be extended to support new data. However, they must be backwards compatible with the following chunks. The current ILBM chunks that are considered legal and valid are: BMHD - this has been extended to include picture type (CMYK, RGB, Greyscale,etc) and x&ydpi. CMAP BODY HLID - this is only used when writing a local copy of the data that has also been published via HotLinks. it is valid inside a HotLinks file, but redundant, and possible outdated. XBMI - this also is only used when writing a local copy of the data for compatibility with naughty ILBM readers. It is redundant considering that this info is now inside the BMHD (where it should be !) The current DTXT chunks that are considered legal are valid are: CSET DTAG DTXT HLID - same as above for ILBMs Now, let's get on with some round one definitions. If you run across something you have a problem with, post it on BIX, fax me, what ever. I will try and sort everything out so that everyone can support everything. Also, if it's not in this document, others won't know to support it. EVERYTHING must be here, and as accurate as possible. Deron Kazmaier Soft-Logik Publishing Corp. BIX: dKazmaier GEnie: Deron.K CIS: 76317,3633 Soft-Logik BBS: 1-314-894-0057 Account #1 U.S.Mail: 11131 F South Town Sq., St. Louis MO 63123 IFF Standard's 101: The basics This document structure tries to adhere to as much of the IFF 85 standard as possible. If you notice something that is wrong or being done by someone else in a different way, let us know. I am not trying to reinvent the wheel, only extend it! each chunk is defined as follows: ChunkType 4 byte ID that is unique within a specific FORM Length 4 byte length of the data inside this block Data series of bytes with a pad byte at the end if the length is odd Forms are a special chunk where the ID is FORM and the first 4 bytes of the data in the FORM is the FORM type. ChunkType is a four byte ID that is unique within the specific FORM definition. In other words, in a FORM of TYPE_TEXT, a chunk of ID "CMAP" might be a character map of some sort, where in a FORM of TYPE_PIC, a chunk by the same ID of "CMAP" but contain a color table. If length is odd, an extra byte should be written at the end of the data so that the next ID would padded out to fall on a word boundary. The length of the chunk should not reflect this pad byte, but all FORMS that encapsulate the chuck should count it in their lengths. Also, in chunks that have punks (smaller yet chunks with a 2 byte ID and a 2 byte Length), they too would not include the pad length in the punk, but would include the pad byte(s) in the chunk. Inside the data should be a group of closely related items. Also, it would be very verbose to define point size and attribute changes such as those as a new chunk when they would take up less data then the 8 byte header. And to break things like invisible hyphens or kerning amounts into their own chunks might cause some text to increase dramatically in size. However, some items, such as possible Rulers or Graphics contained inside of a text block to indicate their location should probably be broken into something like TextBlock, RuleBlock, TextBlock. You get the idea. If your HotLinks Read routines finds something that it doesn't understand, don't throw the data out. The data should be wrapped up in the same position it was in the original, and should be saved with the document to disk, as well as re-output by the HotLinks Write routines. (Note: this non-standard IFF as defined in the EA IFF 85, but important if the user wishes to get back everything he put in!!!!) All defined chunks should be extensible. Remember that even if you have fully processed a chunk, you should respect it's chunks size, even if it's larger than you expected. (Page 3 from the EA IFF 85 intro) One problem through out this is managing relationships between Forms or Chunks or even just data. For example, we are calling tags up by their name, and this is fine because they are created by the user visually. Also, by using a name and looking it up, we can guarantee indexing to the right tags without having to worry about offsets that need fixing up. Reason for this is that if an applications is editing the file that does not support tags and it's related indexing, then and index would get out of sink with the data and would corrupt the data. Now you ask why do I mention this? It's because some indexes need to be done visually or internally, and to ask the user to enter a unique name would be a bit tedious. We need some way of dolling out unique numbers. Problem is if you break a file off and edit it and then bring it back, you have problems with duplicate numbers. Very bad also. Anybody got an elegant solution I'm missing? Document Structure FORMs These forms may need to be LISTs. There purpose is often to define the scope of the sub-forms/objects. For example, the PAGE FORM will contain objects that are on that page, and could be in a chapter/section form. The MasterPage FORM contains Objects, and can be defined in a Document,Section or Chapter Form, and this defines it's scope. The Page Forms defined within it's scope must be able to reference a MasterPage by it's unique name. This allows several master pages to be defined, and used nearly randomly (as long as its scope is valid) Those chunks in braces {} (or italics) below are optional. This mean that they would use the previously defined chunk in the layer above or use a default that is defined for the chunk. Document Form (DOC ) {Publish Chunk} {Desc Chunk} {Section # Style Chunk} {Chapter # Style Chunk} {Page # Style Chunk} {PageDim Chunk} {ColumnGuides Chunk} {Guides Chunk} {Grid Chunk} Document Name The DOC FORM contains all sub forms. (Section,Chapter,MasterPage,Page,Objects) Section Form (SECT) scope: Document {Publish Chunk} {Desc Chunk} {Section # Style Chunk} {Chapter # Style Chunk} {Page # Style Chunk} {PageDim Chunk} {ColumnGuides Chunk} {Guides Chunk} {Grid Chunk} Section Name Section Number Flag (AutoNumberSections) Flag (OddPageAlignment) Chapter Range (begin,#) Chapter Form (CHAP) scope: Document,Section {Publish Chunk} {Desc Chunk} {Chapter # Style Chunk} {Page # Style Chunk} {PageDim Chunk} {ColumnGuides Chunk} {Guides Chunk} {Grid Chunk} Chapter Name Chapter Number Flag (AutoNumberChapters) Flag (OddPageAlignment) Page Range (begin,#) MasterPage Form (MPAG) scope:Document,Section,Chapter {Publish Chunk} {Desc Chunk} {ColumnGuides Chunk} {Guides Chunk} {Grid Chunk} {PageDim Chunk} {Page # Style Chunk} Type (Left / Right / Single) MasterPage Name Page Form (PAGE) scope: Document,Section,Chapter {Publish Chunk} {Desc Chunk} {ColumnGuides Chunk} {Guides Chunk} {Grid Chunk} {PageDim Chunk} {Page # Style Chunk} From MasterPage Name Page Number Document/Page Layout Chunks PageDim Chunk Upper Left Coordinate Lower Right Coordinate Flag (orientation (Landscape/Portrait)) extend DRHD chunk. Perhaps should call it as such ColumnGuide Chunk Inside Margin Outside Margin Top Margin Bottom Margin Horizontal # of Columns Horizontal Space Between Columns Vertical # of Columns Vertical Space Between Columns this is to define a magnetic guides around the column locations. Perhaps this should just be a list of boxes? At the least, this definition should be repetitive so you can create newspaper format where the top half will have a different layout than the bottom (pure randomness actually) Grid Chunk XOffset YOffset Grid Width Grid Height Snap Strength Flag (On/Off) grid snap definition. Perhaps a box range this exists in. ie deferent grids in different locations. what about diagonal grids.(ha ha) Guide Chunk # Horizontal X1,X2,X3,X4...,XN # Vertical Y1,Y2,Y3,Y4...,YN Snap Strength Flag (On/Off) guide snap locations. similar to column but for non-columnar layout portions. diagonal? General Chunks Publish Chunk Hotlink I.D. Version # ULONG type,HLID ULONG chunk length STRUCT,8 lock, 0=unpublished ULONG version Description Chunk Creation Date Modification Date Name Comment Author ULONG type,DESC ULONG chunk length ULONG creation date ULONG mod date STRING name,0 STRING comment,0 STRING author,0 NAME Chunk ULONG type,NAME ULONG chunk length STRING name,0 ANNO Chunk ULONG type,ANNO ULONG chunk length STRING annotations,0 AUTH Chunk ULONG type,AUTH ULONG chunk length STRING author,0 (C) Chunk ULONG type,(C) ULONG chunk length STRING copyright text, 0 by the way, (c) is not a legal representation for copyright. Tag Chunk Definitions Tag Chunk (scope: Document, Section, Chapter, MasterPage, Page) Tags can recursivly call previously defined tags. ULONG type,DTAG ULONG chunk length UWORD length UBYTE type UBYTE flag STRING name, 0 STRING attribute data Types are of the groups: TAG_TEXT 0 ;used for text tags TAG_FILL 1 ;used for filling objects TAG_LINE 2 ;used for stroking objects TAG_COLOR 3 ;used for coloring text/fills/lines TAG_WITHTEXT 4 ;for text insertion (chap heads/db merge) TAG_TEXTMACRO 5 ;should be flag for a true insertion? These are attributes that can be defined for text & objects. To name them just put them in a DTAG and assign the DTAG. This can be for any of these effects. Display Attributes Fill Attributes Style Solid Pattern Graduated Fill Log Fill Radial Fill Fractal Complex Color Halftone PutMode Line Offset (>o = to the right) Width Style (dash pattern) BeginStyle EndStyle Fill Attributes LineEnd (arrows,rounded, tapered, etc...) polygon shape need distance to subtract from end of line need scale method/factor (width/height min./max.) extend DR2D structure? Color Type Gray RGB HLS HSV CMYK CIE YCC TekColor Pantone CMYK Equivalent value for display & 4 color sep Transparency Flag (Spot color) ??Halftone (for Yellow,Magenta,Cyan,Black,Custom) SpotFunction TrueSpot Round Elliptical Square Cross Line Custom Frequency Angle DotGain Function Trapping Spreads/Chokes Auto/Manual Amount (.0001 increments) .003-.006 good defaults Trap Type No Trap No Knockout (specific) Trap with common Trap with uncommon Trap with Black (with color?) Need provisions for: gamma correction / UCR / GCR max. ink coverage (300% usually 250-260% for web presses) Object Types These are some of the forms one can expect to find on a page. These forms may have chunks that could be defined outside the scope of the form. For example, tags for a documents DTXT could be stored in the first nest level of the DOC structure. This would then be used by all subsequent DTXT forms. Same for others. Also, all drawn object on a page do not need to belong to a drawing. For example a simple rule drawn across or down a page. This would belong to the page form as part of it's description? Also, each of these forms can stand by its self as a file. For example, a DTXT form is used by PageLiner for it's native file format as well as the means of exchange text with PageStream. The DTXT would contain copies of all chunks whose scope is valid within the DTXT and are/could be used by the DTXT. Text Form This is DTXT. The chunks CSET, DTAG, & DTXT are currently defined and valid. Bitmap Form This is ILBM. The chunks BMHD, CMAP, & BODY are currently defined and valid. Drawing Form This is DR2D. We need a LOT of extensions to build this into something that can represent a drawing even created in PageStream, much less one done in ArtExpression. Needed extensions include box/circle/arc objects, pattern fill, CMYK & named colors, etc... DTAG chunks are also includable to allow named fills/etc. Music Form Since I know so little about this, I will leave this alone. Sound Form Hey, why not 8SVX? :-) Animations Form Hey, why not ANIM? :-) Equations Form This is a must if we are to get products like TeX to write out in this format. Should contain the actual formula, as well as the information needed to regenerate the formula. (as a CAT with DR2D to provide display info?) Table Form For spreadsheets and other forms of columnar data. Should be full form enough that spreadsheets can save in this format as their native format. Graph Form For spreadsheets and other forms of columnar data. Should contain the actual graph , as well as the information needed to regenerate the graph. (as a CAT with DR2D to provide display info?) EPS Form Encapsulated PostScript. Not very useful, but it's a must for DTP applications that support non-Amiga drawing programs. It would be nice if ANY eps drawing/effect could be converted in an IFF structure. That to me would indicate success in the drawing field. Scale Bitmap Chunk ComplexPolygon Chunk EPS Data Chunk Notes: In review of the above, it seems imperative that we have a standard that allows for generic drawing/descriptions to be attached to complex data that will allow any program to provide basic display/manipulation (sizing/moving/etc...) while still keeping the original body of info. For data of a complex nature, this display info should be better then a generic bitmap. If someone does a graph in a spreadsheet, and print it out from another program to a lino, they probably want something better than a bitmap. Same if it's a presentations package displaying on a 24-bit device. The user would be unhappy with a B/W or 8 color dithered picture. Note: Most of the forms that follow will need addition info if they are inside of another drawing/document. For example, the text alone is enough for some word processors, but a complex WP/DTP program will need to know where it is on which pages, etc. Which brings up an interesting problem. Text can exist on several pages in PageStream, but would generally be place on a single page like any other form. Perhaps DTXT should exist outside of the pages scope if it spans more than one page. IFF DTXT Form Columns Chunk scope: Masterpage,Page Publish Chunk AnchorTo Chunk TextFlow Chunk (standoff / posted flow polygon) Bounding Box Rotation Line Chunk Fill Chunk Flag (floating right edge) Article Chunk Article Chunk Text Chunk List of Object Chunks to flow in Outlines Chunk Index Chunk TableOfContents Chunk CSET Chunk This chunk is to define the character set used in text. Any 1 byte character set you choose will not have certain special characters in it. This is guaranteed due to the fact that their are more than 256 unique glyphs used through out the world. To overcome this, we have created a sort of mapping table that will take an arbitrary character number, and map it to a fixed number. This fixed number is the Unicode character set right now. As luck would have it we needed this for PageStream right away as the Amiga character set does not support many of the typographical characters that PageStream does like , , em and en ­ dash, bullets, etc. So, if you intend on reading PageLiners native DTXT files, or HotLinking text with PageStream, better support this! Note: This table is to help a program determine how to display and edit the text. A program reading this data should NOT throw out character it doesn't understand or can't display. Either make a good guess as to what to use (for example, if you lookup a character in the table and determine that it is an open quote, display it as inch marks) or display a character reserved for unknown characters. (for example, PageLiner uses the box character) Note: You do not need to scan this table every time the user enters a character or you display a character. We build a 256 byte array to go from internal to Amiga, and another 256 byte array to go from Amiga keyboard entries to internal. You may also want them to be able to enter standard Unicode numbers, and then search the table for the appropriate character. The CSET chunk is comprised of several Punks or small chunks. These punks are like a chunk but they use 2 bytes for the ID, and 2 bytes for the length, as opposed to chunks which use 4 bytes for both. NM Punk character set name (null terminated C string) string\0 To reference defaults for Amiga / IBM / Mac / ST / Adobe Standard Encoding how about character set names of Amiga Latin1 IBM IBM Mac Mac Adobe Adobe Example: NM,0x0007,Latin1,0x00, followed by a pad byte 0x00 UC Punk Internal character set to Unicode mapping table. source / destination size number of entries array of source character to destination Unicode UBYTE CharSize; UBYTE UnicodeSize; UWORD NumberEntries; where (source/destination) type is 0- vnum 1- 1 byte 2- 2 byte 3- 3 byte 4- 4 byte (hey, it sounds crazy, but ANSI / ISO was talking about it) A character set which uses only 1 byte to depict it's glyphs will have a CharSize of 1. Anyone using the current Unicode standard will be using a CharSize of 2 (or possible vnum, which will save you a few bytes in size, but this is unsupported in the current release of PageStream/PageLiner) Example: UC,0x0000+4+252*3 0x01,0x02,0x00fc 0x01,0x2625 0x20,0x0020 .... 0x7e,0x007e 0x7f,0x00a0 0x80,0x221a .... LI Punk Because Unicode does not support Ligatures (they are typographical glyphs, not language glyphs is their reasoning) we needed a way to depict ligatures that are representing in a character set. (such as fi or fl ligatures) source / destination size number of entries array of struct { character number number of Unicode entries array of Unicode entries } UBYTE CharSize; UBYTE UnicodeSize; UWORD NumberEntries; CharSize Character number UBYTE number of Unicode entries UnicodeSize*number of Unicode entries Unicode entries where (source/destination) type is same as for UC Punk. Example: LI,0x0016 0x01,0x02,0x0003 0xb0,0x02,0x0066,0x0069 0xb1,0x02,0x0066,0x006c 0xb2,0x02,0x0050,0x0074 You need the current Unicode specs! Get it! We realize it's still changing, but not where it counts. The details are: The Unicode Standard: Worldwide Character Encoding, Version 1.0, Volume 1 by The Unicode Consortium published by Addison-Wesley ISBN 0-201-56788-1 $32.95 US $42.94 Cnd Font Chunk Full Name String Family Name String Attributes String Desc (Serif, SanSerif, Block, etc?) Type (Adobe Type 1, CompuGraphic Intellifont, BitStream Speedo, etc..) character map (important!) kerning pair table composition table This chunk would normally be to indicate which fonts the document uses, and any pertinate info for the document. Most programs would need to interpret the font anyway, and could derive most of this info that way. Full Name is the complete name of the font. This would be the FontName in Adobe Type 1 fonts. (ex, Helvetica-Bold) Family Name is the same for all fonts in the same family (ex, Helvetica) Attributes is the styles specific to this font (ex, Bold) characterset map would be mapping from internal numbers to Unicode. similar to Character Map chunk. from internal to Unicode Kerning pair table DTXT Chunk This chunk is the actual text data filled in with characters and commands. Basically, if you grab a byte in the data stream, and it's not a 0, then you can display it, assuming you take into account the CSET. If it is a zero, then to just skip the command, you read the next 3 vnums and then skip the last vnums worth of bytes. If you don't even care about the command or it's flags, you can skip those vnums without actually processing them. Just skip until you come to a character <0x80 (high bit is not set) and you have that last character in the vnum. Text/Tag Attributes Attribute Commands follow the format: (BYTE) 0, (VNum) Command, (VNum) Flags, (VNum) Length, (Length) Data where VNum is a number encoded as, value=0 while (*byte>127) value<<7 value+= *byte++ - 128 ; value+=*byte++ SVNum is like VNum, only that bit 6 of the first byte indicates whether or not the number is negative. If this bit is set, then negate the number after processing it. Bit 7 always indicates whether or not to get another byte just like another VNum. flags are xxx00 - no displayable data xxx01 - non-editable displayable data xxx10 - editable displayable data x00xx - keep last occurance of command x01xx - delete it x10xx - leave it 0xxxx - not white space 1xxxx - white space (possible word break) TEXT_TAB 1 ;tab (data is position?) TEXT_NEWLINE 2 TEXT_EOC 3 ;forced end of column TEXT_EOP 4 ;forced end of page TEXT_BCCB 5 ;begin conditional column break TEXT_ECCB 6 ;end conditional column break TEXT_BCPB 7 ;begin conditional page break TEXT_ECPB 8 ;end conditional page break TEXT_PARANUM 9 ;paragraph number command (auto inc?) TEXT_PAGENUM 10 ;page number command (text of #,format) TEXT_CHAPNUM 12 ;chapter number command (text of #,format) TEXT_SECTNUM 13 ;section number command (text of #,format) TEXT_MARK 14 ;mark point TEXT_BRANGE 15 ;begin range point TEXT_ERANGE 16 ;end range point TEXT_FOOTNOTE 17 ;footnote. (data includes #, location,(&text?)) TEXT_RULER 18 ;ruler. (data is tab stop locations & type) (vnum)type,(vnum),offset TEXT_AKERN 19 ;auto kern (data is table#?) TEXT_AHYPHEN 20 ;auto hyphen (data is languagetable#?) TEXT_TRACKRANGE 21 ;tracking range (10000em, Min,Max,Opt) TEXT_DROPCAP 22 ;drop cap. (mode,lines tall) Date (flag, DATA) Time (flag, DATA) TEXT_CSET 23 ;set character set (name) TEXT_MULTIBYTE 24 ;multibyte mode (0=vnum,1=1byte,2=2 byte...) TEXT_TAG 30 ;tag. (tag name) TEXT_FONT 31 ;font (font name) TEXT_ATTRB 32 ;attribute (chars identifing attribute) TEXT_POINT 33 ;point size (point,{ypoint}) TEXT_JUSTIFY 34 ;justification ( mode) TEXT_PARAGRAPH 35 ;paragraph format (VNUM) 1/10000pt TEXT_INDENT 36 ;left/right indent (VNUM) Left,(VNUM) right) TEXT_LEADING 37 ;leading (VNUM) flag-auto/fixed, (VNUM) value) TEXT_PARALEAD 38 ;paragraph leading (VNUM) flag- auto/fixed, (SVNUM) value TEXT_TRACKING 39 ;intercharacter tracking (SVNUM) 1/10000em TEXT_BASELINE 40 ;super/subscript (SVNUM) offset,(SVNUM) % size TEXT_MKERN 50 ;manual kern. (SVNUM) 1/10000em TEXT_AKERN 51 ;auto inserted kern. (SVNUM) 1/10000em TEXT_MHYPHEN 52 ;manual soft hyphen. {(VNUM) priority value} TEXT_AHYPHEN 53 ;auto soft inserted kern. { (VNUM) priority value} ATTRB_NORMAL "N" ATTRB_BOLD "B" ATTRB_LIGHT "L" ATTRB_ITALIC "I" ATTRB_SHADOW "S" ATTRB_OUTLINE "O" ATTRB_UNDERLINE "U" ATTRB_WEIGHT "w" ;following byte is weight value ATTRB_SPECIAL \ ;string of style ending with \ JUSTIFY_LEFT 0 JUSTIFY_CENTER 1 JUSTIFY_RIGHT 2 JUSTIFY_CHAR 3 JUSTIFY_WORD 4 JUSTIFY_AUTO 5 Some things left to sort out and define: Tab Ruler Left,Center,Right,Decimal Leader Footnote Continued From/On Line Attributes Fill Attributes directions (up/down/left/right) multibyte systems IFF ILBM Form Some generic chunks that could be part of it. Publish Chunk AnchorTo Chunk TextFlow Chunk (standoff / posted flow polygon) Bounding Box Rotation Line Chunk Fill Chunk Scale Translation Flag (mechanical) Clip Chunk Halftone Transformation Function (contrast/inversion/tonal boost...) This stuff is part of the standard bitmap header. X/Y Dpi Width in Pixels Width in Bytes Height in Pixels Bitplanes Compression Type (RGB PALETTE, B/W, RGB, RGBW, CMY, CMYK) Palette Bitmap Bitmap Header (BMHD) Chunk ULONG type, BMHD ULONG chunk length UWORD w,h WORD x,y UBYTE nPlanes UBYTE masking UBYTE compression UBYTE picType UWORD transparentColor UBYTE xAspect,yAspect WORD pageWidth,pageHeight UWORD xdpi,ydpi where picType is: 0 = ILBM_PALETTE - this makes for backward compatability since this byte was supposed to have been written as a zero anyway. This type will also have a CMAP in the file. 1 = ILBM_GREY - This is used for grey scale images. No CMAP is needed in the file. Number of shades will be 2^nPlanes. 2 = ILBM_RGB - This is used for rgb images, that is images that have no CMAP and are defined as triplets as rgb in the data. 3 = ILBM_RGBA - This is used for rgb images that also have some alpha data included int the BODY. No CMAP is needed. 4 = ILBM_CMYK - This is used for cmyk images. No CMAP is needed. 5 = ILBM_CMYKA - This is used for cmyk images that also have some alpha data included in the BODY. CMAP ULONG type, CMAP ULONG chunk length CLUT ULONG type, CLUT ULONG chunk length BODY ULONG type, BODY ULONG chunk length IFF DR2D FORM Group List scope: Masterpage, Page Publish Chunk AnchorTo Chunk TextFlow Chunk (standoff / posted flow polygon) Bounding Box Rotation Scale Flag (Drawing?) Lines Chunk scope: Masterpage,Page Line Chunk Flag (maintain horizontal/vertical) Begin X,Y / End X,Y Boxes Chunk scope: Masterpage,Page Line Chunk Fill Chunk Flag (Maintain Box) Upper Left / Lower Right Rounded Corner X / Y Radius Circles Chunk scope: Masterpage,Page Line Chunk Fill Chunk Flag (Maintain Circle / Pie lines) Center X,Y Radius X,Y Beginning / Ending Angle Polygons Chunk (Masterpage,Page) Publish Chunk AnchorTo Chunk TextFlow Chunk (standoff / posted flow polygon) Bounding Box Rotation Line Chunk Fill Chunk Original Width / Height Current X/Y scale (relative to actual size) Current X/Y offset Clip Polygon (usually fullsize box) Article Chunk # of Commands Commands Newpath Moveto (x,y) Lineto (x,y) Curveto (cx1,cy1,cx2,cy2,x,y) ArcTo (cx,cy,ba,ea,rx,ry) ArcNTo (cx,cy,ba,ea,rx,ry) Closepath Fillpath Strokepath cubic b-spline Drawing Form (Masterpage,Page) Should be DR2D, or some such Publish Chunk AnchorTo Chunk TextFlow Chunk (standoff / posted flow polygon) Bounding Box Rotation Line Chunk Fill Chunk Original Width / Height Current X/Y scale (relative to actual size) Current X/Y offset Clip Polygon (usually fullsize box) # of Commands Commands SetLine (Line Chunk/Style) SetFill (Fill Chunk/Style) SetRotation (Twist/Slant/cx/cy) Box (ulx,uly,lrx,lry) RBox (ulx,uly,lrx,lry,rx,ry) Line (x1,y1,x2,y2) Circle (cx,cy,r) Ellipse (cx,cy,rx,ry) Arc (cx,cy,r,ba,ea) EllipticalArc (cx,cy,rx,ry,ba,ea) Polygon Newpath Moveto (x,y) Lineto (x,y) Curveto (cx1,cy1,cx2,cy2,x,y) ArcTo (cx,cy,ba,ea,rx,ry) ArcNTo (cx,cy,ba,ea,rx,ry) Closepath Fillpath Strokepath Definitions Coordinate 2 Long Words, x DPI? 2 Long, Fixed point, measure 2 Long, IEEE (egads, yuk, barf, but then again it is in DR2D) NumberStyle (for section, chapter, page numbers) Style Arabic Roman One,Two,Three.... (language dependent) A,B,C,D,...,AA,AB,AC... what about user definable? foreign? Case UPPER lower Capitilized Measure Inches Centimeters Millimeters Points Picas Decipoints Millipoints Language American English French German Spanish Italian Swiss-German Swiss-French ...