Incorrect doc to pdf rendition

@rnara Unfortunately, the issue is still postponed, so there is no estimate available right now.

Hi Team,
Any Update on this issue?
Thanks,
Krishna

@rnara I am afraid, there are still no news regarding the issue.

Hi @alexey.noskov ,
Any update on this?
Can you please provide ETA?
Thanks,
Krishna

@rnara Unfortunately, there are no estimates yet. The issue is still postponed and is not scheduled for development.

Hi Team,
Any update on the issue?
Thanks,
Krishna

@rnara I am afraid, there are no news regarding the issue yet.

Hi Team,
Any Update on this?
Can you please provide ETA?
Thanks,
Krishna

@rnara Unfortunately, there are no updates regarding the issue. It is still postponed and is not yet scheduled for development.

Hi,
Any update on this?
Thanks,
Krishna

@rnara Unfortunately, there are no updates regarding the issue.

Hi @alexey.noskov ,

Any reason this is postponed for long time?
Can you assure that the issue will be addressed if paid support ticket is raised?

Thanks
Rama

@rnara The issue is reproducible with a simplified 26901s.docx (141.8 KB) where the it happens on page 2. The issue occurs because Aspose.Words does not emulate (apparently faulty) MS Word logic when handling repeated header row bottom border height. There is a table with a repeated header row. The header row has a wide thinThickThin bottom border. When conflicting with the top border of the first table row on page 2, wider header row border wins. MS Word renders the winning border, but apparently it does not account for a greater winning border height when computing the height of the row. Because of that, height of the first row after the repeated header on page 2 is less in MS Word layout and it allows to fit one more row at the bottom of the page.
If table rows before the problematic row are removed, so that it goes right after the first header row instance on page 1, MS Word accounts for the bottom header border correctly, and the height of the problematic row is greater, matching Aspose.Words layout. See 26901s1.docx (139.9 KB)


The issue becomes more obvious if space before the first paragraph in the problematic row is removed:
26901s2.docx (141.7 KB). If also remove the wide border in one of the header row cells. It can be seen that pink paragraph shading overlaps the border area above the paragraph in MS Word layout:

The logic does not appear correct, and such overlapping does happen in MS Word layout with a regular row above that is not a repeated header instance.

So in order emulate MS Word layout Aspose.Words should imitate the faulty repeated table row border width handling as described above. On the other hand, there is a possibility MS will correct the faulty logic some day. So it was decided to postpone the issue.

@alexey.noskov ,Thanks for the update. Do we know if MS is considering this as bug? Is there any MS ticket ?

Is there a workaround to mimic the MS Word behavior as customers will match output with MS Word.

@rnara Unfortunately, we are not aware whether MS is considering this as a bug.

I am afraid, there is no workaround we can propose to mimic this MS Word behavior.

Hi @alexey.noskov ,
As mentioned aspose has not accepted this as a bug then we need to align our output with microsoft with same behaviour where we don’t see this issue.
I have attached a pdf rendition done by microsoft.

MicrosoftOutput.pdf (501.3 KB)

Can you look into some fix for this?
Thanks,
Krishna

@rnara Yes, we noticed this difference in rendering between Aspose.Words and MS Word. Actually, this is what was the initial issue about. The above provided analysis explains why the issue has been postponed. I am afraid, currently the issue is not scheduled for development due to the reasons explained above.
At the moment, you can consider raising the issue in paid support. This will push the issue upper in the queue.

The issues you have found earlier (filed as WORDSNET-26901) have been fixed in this Aspose.Words for Java 25.7 update.