Created attachment 598 [details]
Here is the file that doesn't render

Created attachment 599 [details]
Screen dumps showing the difference

This is to confirm the files also render improperly when running Linux
and Win2K.

Reassigned to Michael.

MRU->CMC: Looks like a fast save problem. When I save the document 
newly in Word and import it then, it looks much better.

Have a patch that would fix this. But need to evalulate it in more
detail first. Looks like a simple document but the first 6 rows have
floating properties, while the rest do not. That leads our code to
conclude that the first 6 are part of a floating table and that the
rest are part of a different table. 

Methinks that what word does is assume that once the first row of a
table is floating that all rows that exist after that row are part of
the same table unless some other element exists between them. i.e you
cannot have two tables after eachother in word without something in
between, it will magically all become part of the same table regardless.

No its not a true bug, theres a never seen before undocumented attribute
on the 7th rows downward which must have a complimentaty purpose to 
the known attribute on the first 6 rows. Appears to denote vertical
distance of the table from the top, and horizontal difference from the
left. Turns out to be a largish set of changes required to make this work.

Nasty new table positioning sprm implemented as far as the bits of it
that match up to recognizable dimensions.

requires updates to file versions in sw/source/filter/ww8 of
'ww8par.cxx Rev 1.38'
'ww8par.hxx Rev 1.41'
'ww8par2.cxx Rev 1.28'
'ww8par2.hxx Rev 1.10'
'ww8par6.cxx Rev 1.49'
'ww8scan.cxx Rev 1.32'
'ww8struc.hxx Rev 1.7'

Fix slated for 650

So beautifully fixed it would make you cry in 650b1

Now also SRX642o2

Fix looks ok in src642r. Means, it will reach OpenOffice.org with the
next 642 release.

Works with OO643.