Hello @sarfraz.ahmad ,
Yes, we have received a response from our developers regarding this issue. Please allow me to quote it verbatim:
The issue occurs because the “Page break before” paragraph rule is not processed inside floating tables. The layout of the original document in MS Word is also incorrect — but in a different way. This complicates accurate imitation of MS Word’s layout when handling paragraph rules.
The document contains a single floating table with 49 rows. It appears that the same 9-row sequence is repeated 5 times. In the first row of each sequence, the “Page break before” rule is applied to the first paragraph of the first cell. MS Word forcibly starts a new page when it encounters such a row. Unfortunately, our layout engine currently does not support processing paragraph rules inside floating tables.
As a result, in the GroupDocs.Conversion output, the entire table is treated as continuous, and all 49 rows are placed on the first page.
To fix this issue, we would need to implement support for paragraph rules inside floating tables, which is a non-trivial task.
As a temporary workaround, the problematic table can be made inline (non-floating). However, this reveals another issue related to the original document’s layout in MS Word. When the table is inline, Word displays only 5 pages instead of the 25 pages shown in the original floating layout.
Inspecting the document.xml confirms that there are only 49 rows — 5 groups of 9 rows, each with a “Page break before” applied at the start. So, 5 pages with 9 rows each accurately reflect the XML structure, and a 5-page layout for the inline table is technically correct.
It seems that MS Word duplicated the same floating table 5 times (as evidenced by its different vertical positions on pages 1, 6, 11, etc.), resulting in a 25-page layout.
Postponing as handling paragraph rules inside floating tables is not straightforward and precise reproducing of a faulty MS Word layout is not feasible anyway.
To summarize the above, our developers have concluded that it is currently not feasible to implement a fix for this issue in the short term, as we would ideally prefer. Moreover, it is not possible to provide any estimated timeline for its resolution at this stage. As a temporary workaround, the only available option is to modify the document by removing floating tables and ensuring that proper page breaks are applied.