I found same issue on ASPOSE .NET 24.7.0
questions-all-heights.docx (9.2 KB)
questions-all-heights.pdf (42.3 KB)
@Md_Ashraful_Islam
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): WORDSNET-27254
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.
@alexey.noskov Same problem was shown in aspose java, and the problem was solved. Can you apply the same technique to solve this problem quickly in .NET. Thank you.
@Md_Ashraful_Islam The problem mentioned in the linked thread is not the same problem you have encountered. .NET version of Aspose.Words is the main version, so all fixes are first implemented in .NET version and then ported to Java. So the issue mentioned in another thread has been fixed for both .NET and Java versions.
Hello,
I see that the issue is in a postponed state. I feel very bad to see this. Because i need this feature in my app. I am not going to buy license until the issue is fixed. Please cooperate. Thank you.
@Md_Ashraful_Islam The issue occurs because incorrect table column width data stored in the document are not re-calculated by Aspose.Words.
The problematic tables are auto-fit tables, and they have incorrect column widths stored in tblGrid element. Aspose.Words does not apply the “new” table layout logic that re-calculates tblGrid, because of OfficeMath elements inside the tables. There were issues with using OfficeMath metrics for table re-calculation as the metric may not match MS Word precisely. With metrics unreliable, Aspose.Words falls back to the “old” table layout logic that mostly relies on tblGrid. So the issue has been postponed until issues with OfficeMath metrics are resolved.
Please accept our apologies for your inconvenience.
Hello,
Is there anyone way to bypass this limitation?