I have a similar problem. I have upgrade to Aspose 25.10 and the problem is still not solved. The exporting in pdf generates a different table than the one in word. If I save in PDF using the Word application the pdf is exported ok.
I have attached the word document that was exported with Aspose.Words.
DLA_DunningLetter_Exported.docx (818.1 KB)
@lanton The problem is not reproducible on my side using the latest 25.11 version of Aspose.Words and the following simple code:
Document doc = new Document(@"C:\Temp\in.docx");
doc.Save(@"C:\Temp\out.pdf");
Here is the output produced by Aspose.Words: out.pdf (44.3 KB)
Here is the output produced by MS Word on my side: ms.pdf (117.1 KB)
As I can see output PDF document produced by Aspose.Words and MS Word on my side look the same.
Could you please attach the problematic output document produced on your side for our reference?
Hi @alexey.noskov, doing this also work on my side. It seems the issue is related with how I build the Aspose in memory Document object. I am processing a template and creating programmatically the two tables that look like one table in the final document.
Saving the Document in both in word and pdf produces different results. It helps if I give you a small app that will reproduce the problem?
@lanton Yes, please create a simple console application that will allow us to reproduce the problem. We will check it on our side and provide you more information.
AsposeWordIssue.zip (1016.3 KB)
I have attached a console application that mimicks the way we create tables in word documents using Aspose. The final Document object is saved as both a word file and a pdf file.
@lanton Tank you for additional information. I have managed to reproduce the problem on my side with the following simplified code:
Document doc = new Document();
DocumentBuilder builder = new DocumentBuilder(doc);
builder.MoveToDocumentEnd();
// First table
Table t1 = builder.StartTable();
for (int i = 0; i < 3; i++)
{
Cell cell1 = builder.InsertCell();
cell1.CellFormat.Width = 70;
builder.Write("test");
Cell cell2 = builder.InsertCell();
cell2.CellFormat.Width = 185.35;
builder.Write("test");
Cell cell3 = builder.InsertCell();
cell3.CellFormat.Width = 70;
builder.Write("test");
Cell cell4 = builder.InsertCell();
cell4.CellFormat.Width = 120;
builder.Write("test");
builder.EndRow();
}
builder.EndTable();
t1.AllowAutoFit = true;
// Second table
Table t2 = builder.StartTable();
Cell cell21 = builder.InsertCell();
cell21.CellFormat.Width = 325.35;
builder.Write("test");
Cell cell22 = builder.InsertCell();
cell22.CellFormat.Width = 120;
builder.Write("test");
builder.EndRow();
builder.EndTable();
t2.AllowAutoFit = true;
doc.Save(@"C:\Temp\out.pdf");
doc.Save(@"C:\Temp\out.docx");
If change document saving order the table is rendered properly in both documents. As a temporary workaround you can save document as DOCX first and then save it as PDF.
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-28849
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.
Thank you very much
@lanton We have completed analyzing the issue. The issue is with your code. The issue occurs because the code does not specify the number of columns spanned by wider cells and relies on “consecutive table merge” trick instead. The code should be modified to compute cell spans from the assigned widths.
The code actually creates not one but two consecutive tables. There is MS Word behavior that merges such tables into a single table. Aspose.Words tries to imitate that behavior.
The logic that merges the tables relies on known table column widths. MS Word merges consecutive tables based on column widths stored in tblGrid element which is missing for generated tables. MS Word logic that merges the table does not rely on individual cell widths (there are actually no individual cell widths in MS Word format, only preferred widths). So default widths are assigned to all columns during table merging, which results in a jagged table where the last row has 2 columns and not 4. This is the expected behavior for the document model generated by your code.
The behavior is different when saving to .docx because in absence of column widths data, docx writer implicitly generates cell spans from the cell widths in the model. Though the result is acceptable to you in this scenario we would rather discourage you from using this trick and modify the code to specify the necessary actions explicitly.
The code below will generate consistent results regardless of the saving order, because the number of table columns spanned by a cell is computed from the cell widths assigned by the customer’s code explicitly:
Document doc = new Document();
DocumentBuilder builder = new DocumentBuilder(doc);
builder.MoveToDocumentEnd();
// First table
Table t1 = builder.StartTable();
for (int i = 0; i < 3; i++)
{
Cell cell1 = builder.InsertCell();
cell1.CellFormat.Width = 70;
builder.Write("test");
Cell cell2 = builder.InsertCell();
cell2.CellFormat.Width = 185.35;
builder.Write("test");
Cell cell3 = builder.InsertCell();
cell3.CellFormat.Width = 70;
builder.Write("test");
Cell cell4 = builder.InsertCell();
cell4.CellFormat.Width = 120;
builder.Write("test");
builder.EndRow();
}
// <<<<<<<<<<<<<<< Do not end the table
// builder.EndTable();
// t1.AllowAutoFit = true;
// Second table
// Table t2 = builder.StartTable();
// >>>>>>>>>>>>>>>
Cell cell21 = builder.InsertCell();
cell21.CellFormat.Width = 325.35;
builder.Write("test");
Cell cell22 = builder.InsertCell();
cell22.CellFormat.Width = 120;
builder.Write("test");
builder.EndRow();
builder.EndTable();
// >>>>>>>>>>>>> Do not set auto-fit yet.
// t2.AllowAutoFit = true;
// This will produce correct cell column counts from the cell widths assigned by the above code
t1.AutoFit(AutoFitBehavior.FixedColumnWidths);
// All cells will get fixed preferred width from the current cell width.
// Table width will be auto, which for a fixed layout table means it will be computed from cell widths.
// The next step is optional.
// The table can be made auto-fit after that.
// Column widths might become different as in an auto-fit table they depend on cell contents.
// Table width will be set from the container column width which can cause cell stretching or squeezing as well.
// t1.AutoFit(AutoFitBehavior.AutoFitToWindow);
//<<<<<<<<<< Saving in any order should not affect the result now.
doc.Save(@"C:\Temp\out.pdf");
doc.Save(@"C:\Temp\out.docx");