Created attachment 469 [details]
The file

Also look at the window title - it does not shows the file name in it.

Reassigned to Michael.

MRU->CMC:
The graphic at the top is page-anchored, though it has the "move with
text" attribute
First table is not broken; the line break is due to the different
evaluation of font metrics between word and OpenOffice
There is an excel object anchored in the third table; I think it is a
problem of the Writer-Layout, that we cannot display it in original
size below the table, isn't it?
I do not think, that the table borders are too black... in Word they
are also black (automatic color on white page background).

2. Yeah, the graphic is anchored incorrectly, that's fixed now.

3. The first table and the linebreak is the kind of problem I've been
looking at for a while, it turns out that when word has a table
(similiar things happen to graphics etc) it records the width of the
object (e.g. a table cell) as 'X', but the width of any border for the
cell is not counted in. But writer considers the width of the border
as part of the width of a cell. So think of a table in word that has
two cells, each cell set to 1cm wide and then a 1 cm side border is
placed around every cell. Word will tell me that there is a 2cm side
table and every cell is 1 cm wide, so we create such tables in writer
and then afterwards set the border properties, but the border
properties eat into the size of the cell in writer, making them
smaller than they were in word, and so we end up with 2 cells with a
total width each of 1cm, but a printable region inside the cell far
smaller than the word original, and wrapping occurs.

In theory we need to find the width of the border and add it to the
width of the table cells to get an exact match, but this is really
hard as the word border and shading dialog can do *so* many different
things of different (and some undefined) widths that to know how large
the cell/graphic really is, is very tricky. 

4. Very difficult.
4.1 For a start the table grows to swallow the object because its
height is not fixed, because we need it to grow to contain text that
is line wrapped because of 3. So we'd need a fixed height row, so
perfectly correct borders and widths would need to be done.
4.2 Secondly in word I cannot recreate such an example, if you start
from scratch and try and duplicate the example word will clip the
object along a line drawn down from the right side of the table that
it is anchored to. We scale the object in a similar situation so we'd
need the stuff mentioned in issue 1560 implemented to do that instead
so as to handle the common "anchored in cell" case.
4.3 Finally I believe that the reason that this example is not clipped
at the right side of the cell is because it makes use of an
undocumented compatabiity feature in word for importing older
versions. It seems to describe some layout options for each table
cell. So we'd need to implement that in the filter, and then add
another compatability option to the layout to neither clip or scale at
the edge of the cell.

5. At least this is straightforward, the border in word is 0,75pt, the
nearest available in writer is 1pt

Whats fixable by the filter is fixed. i.e. Logo placement is fixed.
Nothing can be done about the two lines instead of one in the second
cell by the filter, hopefully that will get fixed in the future when
general starwriter font handling is revisited. The excel table issue
is issue 1560. Nothing can be done with the too thick border by the
filter until that particular border width is implemented in the core.

The fixalble things all look good in our internal 641.

Great fix. OO641 shows the result.

Do you think? Look at issue 2393.