Page break not working correctly in word to PDF conversion

When I try converting the MS Word document to PDF, the output doesn’t match the original formatting. In the Word document, tables are properly placed on each page, but in the PDF, they appear continuously without page breaks.

I’ve attached both the Word and PDF files for your reference. Please take a look—this issue is impacting many of our customers.

@sarfraz.ahmad

Can you please provide the version of the GroupDocs.Conversion library you are using and any specific settings you have applied during the conversion process?

TestDocument.pdf (44.0 KB)

TestDocument.docx (17.6 KB)

GroupDocs.Conversion library version : 25.3.1

Setting :
converterSettings.setFontDirectories();
((WordProcessingLoadOptions) loadOptions).setPreserveDocumentStructure(true)

@sarfraz.ahmad
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): CONVERSIONJAVA-2839

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

Hi @atir.tahir, is there any update on this?

@sarfraz.ahmad

This issue is still under investigation.

Hi @atir.tahir ,

Could you please provide the updates on this? Is there any ETA for the fix?
It’s been long this issue was raised.

Hello @sarfraz.ahmad ,

We sincerely apologize, but our team has not yet been able to resolve this issue. At the moment, we do not have any estimated timeframe that we can share with you.

Hi @atir.tahir, it’s been 3 months I had raised this issue. Could you please let me know, by when should I expect the fix?

Hello @sarfraz.ahmad ,

We sincerely apologize once again for the delay in resolving this issue.
We have contacted the development team and requested a more accurate timeline for when the fix might be implemented.
As soon as we receive their response, we will immediately update you here.

Hi @evgen.efimov , is there any update on this?

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.