Created attachment 39132 [details]
The affected document

Created attachment 39133 [details]
Screenshot WW; table starts at page 1

Created attachment 39134 [details]
Screenshot WW; table continues to page 2

As a workaround, set the number of repeated rows in Writer's "table properties"
to 0. 

MRU->FME: I do not know exactly what's going on here, but it looks, that MS Word
has an algorithm which prevents a situation as in W'riter with this table. All
rows in this table are decclared as "Header to be repeated on each page". That
this won't work on a table with 94 rows does not surprise anyone...
But Ms Word seems to calculate if such a number of header rows makes sense, and
if not, the header rows won't be applied to the document view.

I have another good example at http://www.kmprojekt.ee/sodi/Spetsifikatsioon.doc
Here OO.o shows repeating rows count as 174 (it is total count of rows in
table). Setting this number to 1 will let OO.o display document properly.
Apparently poor Word user had all the table selected, when setting repeating
rows... Alas, Word displays this document like only one row was repeated - i.e.
as user ment. Dont understand why Word fixes invalid things by displaying but
saves the crap...

I found this bug from a question I had on the forum here:
http://www.oooforum.org/forum/viewtopic.phtml?t=54644

The following document has one repeating header row that opens fine in WW but 
not in OOo:
http://www.mytempdir.com/1262580

My suggestion for a fix would be the following: If all available rows are 
selected as header rows, then only use first row as a header row. I'm not 
certain how WW does it, but it would seem to me that if a user selected an 
entire table and made it a header row, then they obviously want a header row.

Also, just based on my observations of how font and style changes work (typing 
after a bolded character makes more bolded characters) it would seem to me that 
the entire table being saved as a header row (in WW) is likely due to creating 
the first row, making it a header row, and then continuing on with a new row, 
oblivious to the fact that it is still checked as a header row.

A check could likewise be made on the first row in the table to express a 
different font size (weight, style, etc) from the other previous rows.

Lastly, how often is more than one row needed as a header row? I haven't seen 
WW -- in any observation where all rows are specified as header rows -- default 
anything more than the first row as a header row.

Thanks to whoever takes a look into this for us.

Created attachment 48701 [details]
A simple fix for this issue.

Hi there,

   I have made a patch for this issue. It works quite well for us. It's really
simple to explain. The file made with Ms Word is incorrectly written, there's no
one on earch who wants to repeat _all_ rows of its table. So this small fix just
restore the normal human behaviour.
   It fixes the problem for my sample files and for the affected document of
this issue.
   
   Please integrate it as soon as you can,

Thanks,

switch type to patch, update milestone etc.

*** Issue 82431 has been marked as a duplicate of this issue. ***

fme->mloiseleur: Thank you for your submission. I'll have a look at your patch.

fme->mloiseleur: Looks good. Added this issue to cws swqbf105, committed file
ww8par2.cxx rev. 1.133.30.1. Thank you for your contribution!

FME: Ready for QA.

Yeah, with the patch it of course looks much better now.
Only thing is, that MS Word internally seems to use "no rows to repeat" as
fall-back in such a case. Maybe we should fine-tune this in the future, because
the patch uses "one row to repeat". If desired, we could handle this in a new
issue for a future version.

Checked in DEV300m24 build - but should also be available in OO3 beta / beta2.