StarWriter <= 5.x File Format (.sdw)

Overview

The .sdw file format is an OLE2 Stream. libole2 (available as part of wv) can be used to access the different substreams contained in the file.

All numbers given below are decimal, unless prefixed by 0x, in which case they are hexadecimal.

Note that this documentation is far from complete!

The example code given below was used with a C++ Compiler, but should mostly be valid C as well.

While writing the SDW Importer, I found this small utility I wrote (dumpstream.c [requires libole2]) (GPL) very helpful. It can be used to print out the contents of a OLE2 stream. If invoked like "dumpstream filename.sdw", it lists the streams that are part of the file. If invoked like "dumpstream filename.sdw StarWriterDocument", it prints out the contents of that stream (you might want to pipe the output through xxd to get a hexdump). Don't expect too much from this tool - it's a q&d hack I've made to be able to see the contents of a stream.

Filepaths like sw/source/... are paths to the OpenOffice sourcecode, relative to the root.

Data Types

Most types should speak for themselves (e.g. uint16 = unsigned 16 bit integer, sint32 = signed 32 bit integer).

There is, however, at least one special type: The Class ID, also known as ClsId. It's a structure defined a follows:

The elements of the structure are stored in the file without any padding and in the order in which they occur in the above struct definition.

The type bool is a one-byte integer, where 0 means false and all other values true; though usually 1 is stored.

Another important type is the Bytestring,it looks like this: First, there is an uint16, giving the length in bytes of the following string. A char[] follows. It is supposed to be firstly decrypted (if in the StarWriterDocument stream outside the header and if the document is encrypted; see below). Under the same condition, the string is in the character set specified in the document header.

Streams

SwPageStyleSheets

SwNumRules

StarWriterDocument

After the header, the file consists of many sections. Each section starts with a character (char) that indicates of what type it is (hereafter called section id). After that, there are three bytes indicating the length of the section (little-endian). (to convert this to a usable integer, use for example: (buf [0] | (buf[1] << 8) | (buf [2] << 16)) where buf points to the first of the three read bytes). This means that unsupported Sections can easily be skipped.

See below for a list of section types.

File Flags

(from sw/source/core/sw3io/sw3ids.hxx lines 65ff)
#define SWGF_BLOCKNAME  0x0002
Header has textmodule
#define SWGF_HAS_PASSWD 0x0008
Stream is password protected, see below for details.
#define SWGF_HAS_PGNUMS 0x0100
Stream has pagenumbers
#define SWGF_BAD_FILE   0x8000
There was an error writing the file - treat it as unusable.

Document Flags

#define SWDF_BROWSEMODE1 0x1
Show document in browse mode?
#define SWDF_BROWSEMODE2 0x2
Same as above, only one of them need to be set
#define SWDF_HTMLMODE 0x4
Document is in HTML Mode
#define SWDF_HEADINBROWSE 0x8
Show headers in Browse Mode
#define SWDF_FOOTINBROWSE 0x10
Show footers in browse mode
#define SWDF_GLOBALDOC 0x20
Is a global document (a global document can contain chapter documents... I think)
#define SWDF_GLOBALDOCSAVELINK 0x40
Include sections that are linked to the global document when saving
#define SWDF_LABELDOC 0x80
Is a label ("etiketten") document

Redline Mode

(from sw/inc/redlenum.hxx lines 83ff)

 enum SwRedlineMode
 {
         REDLINE_NONE,
No Redline mode
         REDLINE_ON = 0x01,
Redlines are on
         REDLINE_IGNORE  = 0x02,
Don't react to redlines
         REDLINE_SHOW_INSERT = 0x10,
Show all inserts
         REDLINE_SHOW_DELETE = 0x20,
Show all deletes
         REDLINE_SHOW_MASK = REDLINE_SHOW_INSERT | REDLINE_SHOW_DELETE
The Default
};


Password Protection

(from sw/source/core/sw3io/sw3imp.cxx lines 2721ff and sw/source/core/sw3io/crypter.cxx lines 77ff)

Firstly, to be able to en- or decrypt data, the password must be encrypted in memory (see below for the actual algorithm). For this encryption, this password is always used. Also, the password needs to be exactly 16 characters long; if it's shorter, it needs to be padded with spaces:

static const UT_uint8 gEncode[] =
{ 0xab, 0x9e, 0x43, 0x05, 0x38, 0x12, 0x4d, 0x44,
  0xd5, 0x7e, 0xe3, 0x84, 0x98, 0x23, 0x3f, 0xba };


The resulting string will be used as the password for actual en- or decryption. (For both en- and decryption the same algorithm will be used).

Here's the algorithm:

void SDWCryptor::Decrypt(const char* aEncrypted, char* aBuffer, UT_uint32 aLen) const {
        size_t nCryptPtr = 0;
        UT_uint8 cBuf[maxPWLen];
        memcpy(cBuf, mPassword, maxPWLen);
        UT_uint8* p = cBuf;

    if (!aLen)
        aLen = strlen(aEncrypted);

        while (aLen--) {
                *aBuffer++ = *aEncrypted++ ^ ( *p ^ (UT_uint8) ( cBuf[ 0 ] * nCryptPtr ) );
                *p += ( nCryptPtr < (maxPWLen-1) ) ? *(p+1) : cBuf[ 0 ];
                if( !*p ) *p += 1;
                p++;
                if( ++nCryptPtr >= maxPWLen ) {
                    nCryptPtr = 0;
                    p = cBuf;
                }
        }
}

Where:
maxPWLen = 16
mPassword is an array of characters, 16 bytes long, and contains the password which will be used

To verify that the given password is actually correct, these steps should be taken:

A new string, say testString, should be built, consisting of the Date and Time (from the header) next to each other in Hex format, padded with 0 on the left if shorter than 8 characters (can for example be archieved by snprintf(testString, sizeof(testString), "%08lx%08lx", mDate, mTime);)

This string should now be encrypted with the given password, and the result should be compared to the password verification data mentioned above. If they are equal, the password is correct.

Section Types

(the letter in parentheses is the section id)

• SWG_CONTENTS ('N')
  Actual textual content of the document. This section's header looks like this:
  
  • if version >= SWG_LAYFRAMES (5): one byte of flags, where the lower 4 bits give the length of the flag part.
  • if version >= SWG_LONGIDX (0x201): uint32 giving the number of nodes (?) (sw/source/core/sw3io/sw3sectn.cxx lines 181ff)
  • else
    if version >= SWG_LAYFRAMES: uint16 = a dummy section id, can be thrown away (at least that's what openoffice does)
    uint16, same meaning as the nodes from above, just as a 2 byte integer.
  • flag part is over; if the length (taken from the flags as stated above) hasn't been reached yet, skip the rest
  After the section header, SWG_CONTENTS consists of sections like the document itself. Most important seems to be
  
  • SWG_TEXTNODE ('T') (sw/source/core/sw3io/sw3nodes.cxx lines 788ff)
    Firstly, textnodes contain a flag section as above (one byte of flags, lower four bits give the length). I haven't looked at the possible flags yet, so I just skip over them.
    A bytestring (see above) follows, containing a paragraph of text.
    After this, a set of records follow (usually attributes ('A'), which have the following structure)

    offset relative to record start	length	type	description
    0x00	1	flag	Flag record, as above.
    0x01	2	uint16	Which type of attribute this is.
    0x03	2	uint16	Version of the attribute (I don't know details yet) (seems to be 0 usually)
    0x05	2	uint16	offset of the first character to which this attribute applies, relative to the start of the textnode. only exists if flag 0x10 is set. zero-based.
    0x07	2	uint16	offset of the last character. only exists if flag 0x20 is set.

    In addition, there can be an "S"-Record, which contains attributes (as above) which apply to the whole paragraph.
    Known values for the attribute type:
    

    0x100a	Italic
    0x100d	Underline
    0x100e	Bold

    
    
  • SWG_JOBSETUP ('J')
    

    This section contains informations about the selected printer and paper. This only reflects the settings made in File|Printer Setup, not Format|Page!

    Firstly, two defines:
    #define JOBSET_FILE364_SYSTEM (0xFFFF)
#define JOBSET_FILE605_SYSTEM (0xFFFE)
    

    Offset in Hex	Length	Type	Default Value	Description
    0x00	2	uint16	TBD	Length [nLen]
    0x02	2	uint16	TBD	System (?)
    0x04	64	char[]		Printer Name
    0x44	32	char[]		Device Name
    0x64	32	char[]		Port Name
    0x84	32	char[]		Driver Name
    				All further fields are only used if System is JOBSET_FILE364_SYSTEM or JOBSET_FILE605_SYSTEM
    0xA4	2	uint16	TBD	nSize
    0xA6	2	uint16	TBD	nSystem (again??)
    0xA8	4	uint32	TBD	Driver Data Length
    0xAC	2	enum [uint16]		Orientation (0=Portrait, 1=Landscape)
    0xAE	2	uint16		Paper Bin
    0xB0	2	enum [uint16]		Paper Format (0=A3, 1=A4, 2=A5, 3=B4, 4=B5, 5=Letter, 6=Legal, 7=Tabloid, 8=User defined
    0xB2	4	uint32		Paper Width
    0xB6	4	uint32		Paper Height
    0xBA	Driver Data Length	?		Driver Data (?) (vcl/source/gdi/jobset.cxx lines 383ff). Only if the Driver Data Length is > 0.
    	nLen minus already read data			Corresponding Key and Value strings (ByteStrings, in UTF-8 encoding). Only if System == JOBSET_FILE605_SYSTEM

    The encoding of the Printer, Device, Port and Driver name is UTF-8, unless the System is JOBSET_FILE364_SYSTEM, in which case it is the same encoding as the rest of the document.
    
  • SWG_EOF ('Z')
    Marks the end of the SWG_CONTENTS section (zero-len
• SWG_STRINGPOOL ('!')
  There are two variants of the string pool, depending on the document version. The old one is used if Version <= SWG_POOLIDS (0x3), otherwise the new one is used.
• New:
  

  Offset in Hex	Length	Type	Description
  0x00	1	uint8	Character Set for the strings
  0x01	2	uint16	Number of strings

  Now, the strings follow; each one having the following structure:
  

  Length	Type	Description
  2	uint16	ID of the string
  n/a	Bytestring	The string. Not encrypted. If ID == IDX_NOCONV_FF (0xFFFC), then the 0xFF character in the string should be left unconverted; else, a normal conversion can be performed.

  If the version of the file is less than SWG_HTMLCOLLCHG (0x0203) (the version for new HTML Pool-Template IDs), the ID is not zero and below IDX_SPEC_VALUE (0xFFF0) ("from here on reserved for special values"), the ID must be mapped to a new one; but before that, the actual string must possibly be changed, according to this table:
  

  ID	New String
  RES_POOLCOLL_HTML_LISTING_40 (0x3002)	"LISTING"
  RES_POOLCOLL_HTML_XMP_40 (0x3003)	"XMP"

  Afterwards, the ID must be changed according to this table (only if version < SWG_HTMLCOLLCHG)
  

  old ID	new ID
  RES_POOLCOLL_HTML_LISTING_40 / RES_POOLCOLL_HTML_XMP_40	must be or'ed with USER_FMT (1 << 15)
  RES_POOLCOLL_HTML_HR_40 (0x3004)	RES_POOLCOLL_HTML_HR (0x3002)
  RES_POOLCOLL_HTML_H6_40 (0x3005)	RES_POOLCOLL_HEADLINE6 (0x80f)
  RES_POOLCOLL_HTML_DD_40 (0x3006)	RES_POOLCOLL_HTML_DD (0x3003)
  RES_POOLCOLL_HTML_DT_40 (0x3007)	RES_POOLCOLL_HTML_DT (0x3004)

  possibly interesting: sw/inc/poolfmt.hxx#L112
  I don't really know what happens with the strings there, yet.
  
• SWG_EOF ('Z')
  Marks the end of the file and is of zero length. (XXX not sure if this is actually present)
  

SfxWindows

SfxStyleSheets

SfxDocumentInfo

(OpenOffice Tree: sfx2/source/doc/docinf.cxx lines 786ff)

offsets assume a version of 0x0B and default values (for bytestrings and lengths). quotes are from openoffice code or comments

A Timestamp has this structure:

persist elements

(In the OpenOffice tree: so3/source/persist/persist.cxx)

SummaryInformation

\001Ole

(In the OpenOffice tree: class StgOleStream, sot/source/sdstor/stgole.cxx and .hxx)

\001CompObj

(In the OpenOffice tree: class StgCompObjStream, sot/source/sdstor/stgole.cxx and .hxx)

Notes

1. Both strings are stored with a terminating zero, and the length includes this character. If zero, no version/format string is stored in the stream.
   
2. The length of the file format string can either be -1, zero or a positive value. If it is -1, it means that the next 4 bytes should be interpreted as a Windows Clipboard format. If it's zero, see above. If it's greater than zero, the version string follows. See below.
3. Star/Open Office knows about lots of version strings.(see sot/source/base/exchange.cxxandtools/inc/solar.h lines 471ff). OpenOffice uses RegisterFormatName (line 253ff from the first file) to get the version number from the string. (XXX There was another file, but I can't find it right now)
4. Common version strings and their numbers: