Created attachment 730 [details]
Sample

It's not quite as simple a document as you think, but there is a
simple explanation. Go look at your page margins in word or writer,
the page is american letter size, i.e. 21.79cm wide, your page margins
are 13,02cm from the left and 13,02cm from the right, i.e. 26,04cm of
margin which is bigger than the page, there is no width in the
document in which to fit anything.

Openoffice imports these page margins faithfully. Delete the table in
word and try and type something, your space for characters is only one
character wide. Despite your table being visible, this seems to be
only happening in word because their layout engine is setup to work
with pages that have some space between margins and even though there
is none in this document it continues under that assumption and draws
the table on the far right of the left margin, even though the right
margin is truly to the left of that position and it should be invisible

I don't know how you created the document because words menus will
refuse to set the margin space to bigger than the document space in my
versions. They claim that text area page width cannot be less than
1.27cm, i.e. half an inch.

Perhaps we should check the page margins on import and if they are
such that the space between then is less than some tiny amount (0.5cm)
then they should be modified to match the margins that word appears to
use in that circumstance, i.e. left correct, but right changed to be
greater than left. So its not truly a bug where OOo cannot import a
simple document, but more that theres a bug in word where margins can
be set incorrectly and it would be nice if we could provide a work a
round for that bug by modifying the margins.

REassigned to Michael.

My co-worker says:

Just so you know, you can create this document by going to Tools ;
Envelopes and labels ; Select Labels tab; click Options; Select "Avery
Standard" on Label Products pull down menu ; select Ready Index 8 -
Tabs in Product Number list.

This is not a real Bug. Writers layout was not designed to handle page
margins larger than a page itself. So the Product Management has to
decide if a similar feature should be implemented into Writer or if a
workaround like CMC proposed would be enough... 

The workaroud must be sufficient since this behaviour is an exeption
and it hardly makes sense to implement features that are really none.

I'm not an expert on bug tracking, but since the workaround would fix
my problem, I'm not sure this qualifies as a WONTFIX.  Perhaps we
should delay marking this as resolved until the workaround is
committed?  (If we then want to mark it WONTFIX to help remember what
happened, that would make sense...)

As mentioned on the qa dev list on March 5th I will close all resolved duplicate
issues. Please see this posting for details. First step in IssueZilla is
unfortunately to set them to verified.

As mentioned on the qa dev list on March 5th I will close all resolved
<wontfix/duplicate/worksforme/invalid> issues. Please see this posting for details. 

My understanding is that the WONTFIX tag was incorrect, so closing it 
because of WONTFIX is also incorrect.

Well, WONTFIX is most appropiate to what this issue is about. 
But to make it more clear I will set it to INVALID.

Just so the user knows, because of a range of prlblems such as this
(importing the meaningless word true values causes all sorts of
asserts and potential crashes in layout and the dialogs) the
workaround I proposed is in place in the SRX644 series so this
particular bugdocument will look ok in writer

Closing