Document Question Issues

Transcription

1 Document Question Issues In paragraph Directory Sectors (page 4): Length of ulsizehigh is specified as 2 bytes; length seems to have 4 bytes In header definition (page 2): minor version of the format: specification says 33, in file : 3E In header definition (page 2): _ubyte Order: only specified, how intel byte ordering is indicated. It seems that DOCX files saved with Word2007 don't have the correct value 0xFFFFFFFE but instead 0xFFFFFFFF in the last 4 bytes of the last DiFat sector in the chain of DiFat sectors.

2 Section properties can have a definition of columns for the sections. In OpenXML can these definitions have seperate values for column spacing for each column. In binary format there seems to be one value for all column spacings? Document Typography Info has a flag named folddefinelinebasedongrid. This flag should be bitfield 0x5F. This cannot be because 5F is not a single bit. I think this flag is bitfield 0x40 (7th bit). The sprm sprmtdeftable stores in bytes 2 and 3 the length for the following sprm argument. This length is always 1 bigger than it should be. I think the reason for this is that in normal sprms the length is specified by 1 byte, not by two. Word seems to compensate this additional byte by adding 1 to the length of the argument. So the length stored in byte 2 and 3 is not really the length of the following argument, it is the count of byte following to the normal sprm "header". A Font Family Name (FFN) structure has a sub structure called "FONTSIGNATURE". This structure isn't described by the specification. I found a PAPX in a file that has only one SPRM. The opcode of this SPRM is 0x6646. This opcode doesn't exist in the specification, neither in the list of Paragraph SPRMs nor elsewhere in the document. But there is a SPRM with opcode 0x6645 (sprmphugepapx) which means that this PAPX has nomore SPRMs and all SPRMS of this paragraph are stored elsewere in the file. The value of SPRM 0x6645 is an offset to this location in the file. I can only suppose that SPRM 0x6646 is a newer version of 0x6645 or that it is the corresponding SPRM for storing huge TAPX. Accordingly to the binary specification, the default linespacing of a paragraph is "single" (240 dya). Is this default line spacing saved in a.doc file? OOXML seems to have another default line spacing. If no line spacing is specified in a OOXML file (neither in styles.xml nor in document.xml), Word 2007 displays the document with multiple spacing of 1,15 (276 dya). - How does Word 2007 know, that it has to create a document default paragraph line spacing of 240 for older.doc files when converting from.doc to.docx? Is this default value saved in a.doc files (where?) or does Word 2007 perform a version check? We assume that PICF.rgb consists of a number of drawing group objects. Is this correct? There seems to be a padding byte between two drawing group objects when storing a floating picture in a Word document (cf. Picture Translation -- A Challenge). Is this correct? The border properties in the PICF structure are 4 bytes instead of 8 bytes, i.e. the length of the PICF structure is 0x44 bytes instead of 0x54

3 Record ID 31h is not specified. BiffView shows this as FONT record which is specified to use ID 231h Same for record ID 27Eh used for RK records (ID value should be 7Eh according to spec. The description for the Continue BiffRecord and the SST BiffRecord is too short. The SST could end with a string or a number. If it is a number the ContinueRecord begins directly without a compressed string bit otherwise it begins with this bit. Theres no description in the specification about this issue. Another issue is, that theres no description about the change between compressed to uncompressed strings at the end of a record.

4 In section 'Physical File Format', page 16, explanation of field Record Version (recver): It says 'If the record is a container, this field has a value of 0xFFFF.' -- it ought to say 'value of 0xF', because recver is only 4 bit wide. (Note: psrinstance isn't affected by this logic at all.) In section 'Physical File Format', page 16, explanation of field Record Length (reclen): It says 'If the record is a container, it refers to the sum of the lengths of the atoms inside it, plus the length of the record headers.' -- this is somewhat misleading. It would be better to write 'it refers to the sum of the lengths of the children inside plus the length of their record headers.' (section has moved to ODRAW spec) In documentation of Record Type 1007 (SlideAtom): The length of this type's records is 24 byte, but only the meaning of the first 22 byte is documented. What are the remaining 2 bytes used for? At page 69 change 'cfansityepface' to 'cfansitypeface' At page 45 change 'List' to 'MainMaster' and 'MainMaster' to 'List' in headers (Elsewhere in the document these record names are correctly used.)?? At page 78 add 'Note that the indent level field of the paragraph run is omitted in this case.' after 'This atom is of variable length, and consists of a character and a paragraph formatting run for each indent level defined in a style.'?

5 Please include Record Type identifiers (e.g. F000) directly with the section headings (e.g. msofbtdggcontainer) inside the document. Jumping to the table at page 11 and back to the main document is quite annoying. typedef for MSODGID is nowhere to be found (found out it's 32 bit unsigned by guessing) In section 'Common Header', page 8, explanation of field Record Version. Replace 0xFFFF with 0xF. In section 'Common Header', page 9, explanation of field Record Length. Replace the last sentence with 'If the record is a container, it refers to the sum of the lengths of the records inside it, plus the length of their headers.' (Which is less misleading.) In section 'Drawing Group Record', page 13: 'The drawing group record is a variable length record consisting of a fixed part followed by an array. The fixed part is defined as follows. [...] ULONG cidcl; // The number of ID clusters (FIDCLs) [...] The fixed part is followed by an array of ID clusters.' -- Mention that the fixed part is followed by exactly cidcl - 1 records; otherwise everyone will expect exactly cidcl records.