We’re using Aspose Words Java 23.11. As part of our processing we support deleting columns of cells in tables. To make deleting a column of cells easier, we transform long cells into a series of merged cells. This makes each row have the same number of cells, all lined up. So when a column is deleted, we can just delete all cells in that column. However, after expanding long cells into a series of merged cells, when we then either call document.updateFields() or document.save(), the vertical merge flag is lost for cells that come after the newly created merge cells. In the attached project, see the cells in column 8. After expanding the long cells into merged cells, the first row has it’s vertical merge flat to FIRST and the second row has it’s vertical merge flag as PREVIOUS.
cell: 8 width: 91.0 prefWidth: 1820 hMerge: NONE vMerge: FIRST colStop: 608.25
…
cell: 8 width: 91.0 prefWidth: 1820 hMerge: NONE vMerge: PREVIOUS colStop: 608.25
But, after calling document.updateFields() or document.save(), (A) the merged cells are re-combined into long cells and (B) the vertical merge flags are cleared.
cell: 7 width: 91.0 prefWidth: 1820 hMerge: NONE vMerge: NONE colStop: 608.25
…
cell: 8 width: 91.0 prefWidth: 1820 hMerge: NONE vMerge: NONE colStop: 608.25
It looks like save() is calling updateFields(). Is there a way to keep them from re-combining the merged cells and maintaining the vertical merge flags? AsposeTableTest.zip (70.1 KB)
So I suspect the problem occurs because internal structure of the table is broken and upon validation Aspose.Words tries to recover the table structure validity.
I would suggest you to use a built-in method for converting wide cells to merged cells Table.convertToHorizontallyMergedCells. You can use the following simple code to convert wide cells to horizontally merged cells:
for (Table t : (Iterable<Table>)document.getChildNodes(NodeType.TABLE, true))
{
t.convertToHorizontallyMergedCells();
}
In this case vertical merge is preserved properly.
Thanks for the quick response. The convertToHorizontallyMergedCells() call fixes the enclosed test case. But breaks others in our automated tests. Specifically, convertToHorizontallyMergedCells() does not seem to preserve column stops across the table. For example, in a table with column stops every 10 pixels, if a cell takes up 20 pixels we want it split into two merged cells that are 10 pixels wide each. But we are seeing two merged cells: one 20 pixels wide and the second 0 pixels wide. We are also seeing cases where the column stops are not preserved (new cell widths do not line up with the column stops).
You mentioned “the internal structure of the table is broken.” In our old code we are adding a new merged cell to a row using:
Cell newCell = new Cell(curCell.getDocument());
newCell.getCellFormat().setWidth(newCellWidth);
newCell.getCellFormat().setHorizontalMerge(CellMerge.PREVIOUS);
row.insertAfter(newCell, curCell);
Is there some other way we should be adding the new cells that will preserve the table’s internal structure?
@GlennM Yes, you are right, convertToHorizontallyMergedCells method creates merged cells with zero width. This is an expected behavior. You can use this method with your own code to change merged cells width to line up them with columns stops. I.e. you can use convertToHorizontallyMergedCells to add the required merged cells and then postprocess the table to change width of the added cells.
Ok, we’ve updated the code to use convertToHorizontallyMergedCells and things are better. But when we wind up deleting a column in a table and then save out the document the tables are different after the document is saved. Specifically the cell widths change in the saved document. Logs of what’s happening are below. For example, in the first cell in the first row in the table the width is 41.4 and the preferred width is also 41.4. But after the table is saved the width jumps to 149.4 even though the preferred width remains 41.4. This worked back in Aspose Words for Java 21.1. Is there something we’re missing to be able to maintain the table cell widths across a save? We’re deleting the cells from the table with row.removeChild(cell). Thanks.
CellFormat.getWidth() is cell width calculated by Aspose.Words on document loading and saving. Currently, not every combination of table, cell and document properties is supported. The returned value may not be accurate for some documents. It may not exactly match the cell width as calculated by MS Word when the document is opened in MS Word. See remarks in our documentation for more information.
Thanks again for the fast responses. Calling table.autoFit(AutoFitBehavior.FIXED_COLUMN_WIDTHS);
before any cells are deleted did not change the behavior. When deleting a column, we are calling cell.remove()
on all cells in the column (per How to delete a column in a word table?). Should we instead be calling: row.removeChild(cell);
If that is not the case I’ll work on creating a new example to show the current behavior.
@GlennMcell.remove() and row.removeChild(cell) do the same, so there is no difference which to use.
Yes, please attach the problematic document and provide simple code that demonstrates the problem. We will check the issue and provide you more information.
The document’s fields are updated (should be a no-op, removing this does not change the final outcome).
The third column (index == 2) is removed.
Merged cells are joined back into long cells.
The document is saved.
If we save the document between the steps then the merged cells are re-joined, which confuses the column removal. So we just save the document at the end.
Before the document is saved everything lines up fine. The rectangular table remains a rectangle. When the document is saved some cells get wider, breaking the columns.
The expected table (pulled from our test cases) is the ExpectedTableTestDocument.docx file in “src/resources”. Thanks.
@GlennM Thank you for additional information. The step Merged cells are joined back into long cells. is actually not required. If remove this step the output table looks fine. In MS Word both cases are perfectly valid for horizontally merged cells - simply wide cells and actually horizontally merged cells.
If this step is required for some reason, you can modify visitTableEnd in DocumentJoinTableLongCellsVisitor like this to get the expected output:
@Override
public int visitTableEnd(Table table) throws Exception {
joinMergedCellsIntoLongCells(table);
table.autoFit(AutoFitBehavior.FIXED_COLUMN_WIDTHS);
return super.visitTableEnd(table);
}
Thanks for the help. The table.autoFit() call helped. But we’ve now got another test that’s failing. In the AsposeTableTest3 example, columns C and D are removed. The desired output is to have the columns to the right (E and F) just slide over. Again, when outputting the table and cell widths before the document is saved everything looks as expected. But after the document is saved the cells in columns E and F ignore their preferred widths and grow to fill the original table size. Setting the table’s preferred width to the new row widths didn’t help. It feels like a table width value is still being cached that is not cleared in the table.autoFit() call. Are there other calls we should try?
Again, the starting document is in resources/OriginalTableTestDocument.rtf. The expected content is in resources/ExpectedTableTestDocument.rtf. The output document is in target/TableTestDocument_04_LongCellsJoined.rtf.
To call table.autoFit(), set AsposeTableTest.AUTO_FIT_TABLE_TO_FIXED_COLUMN_WIDTHS to “true”. To set the table width to be the max row size, set AsposeTableTest.SET_TABLE_PREFERRED_WIDTH_TO_MAX_ROW_WIDTH to true.
@GlennM It looks like a problem with table grid.
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-26681
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.
