I had a look at tdf#166978 attachments. They are very badly designed (if at all). They mix objects which don’t interact. For example, the header contains frames and a table. Frames and tables can’t be automatically adjusted with wrap properties. A frame can eventually constraint text to be flushed but has no effect on a table. The table itself has been created only to draw a line at bottom of header. This can (and should) be done in the page style configuration.
Author tried to fix the issue by inserting several empty paragraphs to force header height. Once again, this should have been done in the page style configuration (giving a fixed size to the header).
Even the frames are a bad idea. A correctly designed table in the header would have replaced both frames with a more controllable object.
Another flaw is to use Heading n styles in frames and, more seriously, in headers. If a TOC is ever generated, data will be faulty.
The text itself is made of a single-column table. 1-column tables are complete nonsense in the majority of cases. A style with appropriate indents would have been better (and it can also have borders if needed to imitate a table.
To end with the analysis, the attachments suffer from chronic direct formatting.
Before trying to fix an possible unexpected behaviour, the documents should be redesigned in a proper way without trying to resort to advanced unmastered features. As always, the simpler the document, the easier to tune and maintain.
@abhishah4444: if your document is as unstructured as those in tdf#166978, it could be wise to review it to isolate what is due to its state and what is due to Writer. Attach a sample file if you’d like an analysis.
