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)
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)
