Hey support,
the cell merge features seems to not be working. I have used the example from the documentation ( https://reference.aspose.com/words/java/com.aspose.words/cellmerge/) but the output is not the expected one.
Source code here. Please advice if there is any error in this code:
@Test
public void testMerge() throws Exception
{
Document doc = new Document();
DocumentBuilder builder = new DocumentBuilder(doc);
builder.startTable();
builder.insertCell();
builder.getCellFormat().setHorizontalMerge(CellMerge.FIRST);
builder.write("[1,1] Colspan=2");
// This cell is merged to the previous and should be empty.
builder.insertCell();
builder.getCellFormat().setHorizontalMerge(CellMerge.PREVIOUS);
builder.endRow();
builder.insertCell();
builder.getCellFormat().setHorizontalMerge(CellMerge.NONE);
builder.write("[2,1]");
builder.insertCell();
builder.write("[2,2]");
builder.endRow();
builder.endTable();
doc.save("d:\tmp\testMerge.pdf");
doc.save("d:\tmp\testMerge.doc");
}
Regards,
Dragos
I’d appreciate a quick reply and a solution to have the merge working correctly on both Word and PDF as this is now preventing us from releasing our product. Please note that using the “document.updateTableLayout” seems to solve this issue but we cannot use that method due to the other problems it introduces ( see the table layout issues I reported before).
Thanks and regards,
Dragos
Hi Dragos,
Thank you for inquiry. Please follow up the code snippet as below:
static void testMerge() throws Exception
{
Document doc = new Document();
DocumentBuilder builder = new DocumentBuilder(doc);
builder.startTable();
builder.insertCell();
builder.getCellFormat().setHorizontalMerge(CellMerge.FIRST);
builder.write("[1,1] Colspan=2");
// This cell is merged to the previous and should be empty.
builder.insertCell();
builder.getCellFormat().setHorizontalMerge(CellMerge.PREVIOUS);
builder.endRow();
builder.insertCell();
builder.getCellFormat().setHorizontalMerge(CellMerge.NONE);
builder.write("[2,1]");
builder.insertCell();
builder.getCellFormat().setHorizontalMerge(CellMerge.NONE);
builder.write("[2,2]");
builder.endRow();
builder.endTable();
doc.save("c:\\temp\\test086\\testMerge.doc");
doc.save("c:\\temp\\test086\\testMerge.pdf");
}
I have attached output files for your reference. In case of any ambiguity, please let me know.
Hey Imran,
the only difference I see in my code vs yours is that you save the doc before pdf. It looks like saving to Word first does something to the document model that fixes the PDF save to. But removing the doc save breaks the PDF so this is not an acceptable solution.
Regards,
Dragos
Hi Dragos,
Thank you for additional details. While using latest Aspose.Words 11.1.0. I managed to reproduce this problem on my side. I have logged your issue as WORDNET-6117 into our bug tracking system. Your request has also been linked to the appropriate issue. Once we sort it out, we will let you know. Sorry for inconvenience.
Moreover In your case, you may first save the doc object in output stream and then export the data to PDF file. Please follow up the code snippet as workaround.
ByteArrayOutputStream docStream = new ByteArrayOutputStream();
doc.save(docStream, SaveFormat.WORD_ML);
Document dd = new Document(new ByteArrayInputStream(docStream.toByteArray()));
dd.save("c:\\temp\\test086\\testOut.pdf", SaveFormat.PDF);
I hope this will help.
Thanks Imran. This solution works but it seems to impact performance ( testing still in progress), which is already impacted compared to the previous Aspose versions. See https://forum.aspose.com/t/65123
Is there any other solution that will not impact performance?
Regards,
Dragos
Hi Dragos,
Thanks for your inquiry.
Have you tried calling the infamous Document.UpdateTableLayout method instead? Does this help this table but break others in your document?
Thanks,
Hey Adam,
updateTableLayout works for this scenario but as mentioned above it was removed as it caused a lot of other issues and we cannot introduce it back. There are several threads in which your colleagues explicitly specify that the method is not to be used.
Have you identified what saving the doc does to fix the document layout? Can that method be isolated and used when saving PDF?
Regards,
Dragos
Hey support,
just a reminder that this is now blocking our release and we need a good solution for it. Saving in doc format first ( and thus doubling the save time) or using the updateTableLayout are not acceptable solutions.
Regards,
Dragos
Hi Dragos,
Thanks for the inquiry. Please note that there is no guarantee that there is such a work around at the moment, you may need to wait for the original fix.
Hi Dragos,
The developer responsbiel has made an analysis and found it is a problem with how this partiuclar situation is represented in the model.
As a work around you can useTable.autoFit(AutoFitBehavior.AUTOFIT_TO_WINDOW); which should avoid the issue.
Thanks,
Hi Dragos,
I’m a developer working on the issue attached to this thread. I analyzed the issue. It occurs because the situation when cell width is not specified explicitly is handled differently for .doc and the other formats, in presence of the merged fields.
The same issue is observed when saving to docx: the merged cell in the first row is lost.
You can work the issue around by telling Aspose.Words to update the table layout explicitly. If the current .doc output is what you are trying to achieve, you can do it by adding the call below to your snippet:
Table tbl = builder.EndTable();
tbl.AutoFit(AutoFitBehavior.AutoFitToWindow);
The proper fix for this issue would be a unified table layout algorithm for all supported formats. Unfortunately, it is quite a big issue and I cannot promise you it will be resolved in the nearest releases. We will surely implement it eventually, but as far as I understand, it is not currently a top priority. This is because the current implementation works well for most cases. It handles most of documents created by MS Word and other applications satisfactory.
Unfortunately, your document builder scenarios uncover some cases normally not occurring with documents created via MS Word. For example, MS Word usually does not create horizontally merged cells, it just replaces the merged cells with a single cell. Actually, an attempt to emulate this behavior in Aspose.Words before the cell width was calculated is leading to the issue you submitted via this thread.
So, in document builder scenarios it is always best to explicitly tell Aspose.Words what you are trying to achieve. Table.AutoFit() is one of the ways you can use.
Hope this helps.
Thanks && Best Regards,
Thanks for the suggestion but setting the autofit is not an acceptable workaround either. Some tables need a very precise layout and that includes the dimensions of the cells,dimensions that would be modified by the autofit.
One more question on this: besides the performance impact is there any known side effect of saving the document first as Word and than PDF versus saving it directly as PDF?
Regards,
Dragos
Thank you for the additional information.
The issue with a disappearing horizontally merged cell in your case occurred exactly because no cell widths were specified. So it should not affect you if you are going to set cell sizes explicitly.
If you need precise cell sizes, you can use CellFormat.Width and CellFormat.PreferredWidth properties in combination with Table.AutoFit(AutoFitBehavior.FixedColumnWidths).
This way the cell sizes should be exactly as you specify both in doc and pdf.
However, in this case you’ll have to control the total row width so that it does not exceed the page width.
Also, if you specify cell sizes explicitly, you could consider an approach without horizontally merged cells at all. Just use a single wider cell instead of several merged cells.
Currently, I do not know of other side effects caused by saving first to doc and then to pdf. The one we are discussing occurs because merged cells are handled differently when saving to these formats and in the situation when no cell width was specified it leads to a loss of the merged cell when saving to pdf.
Hope this helps.
Thanks && Best Regards,
The issues you have found earlier (filed as WORDSNET-6117) have been fixed in this .NET update and this Java update.
This message was posted using Notification2Forum from Downloads module by aspose.notifier.
(1)