Conversation
Signed-off-by: Christoph Auer <[email protected]>
Merge ProtectionsYour pull request matches the following merge protections and will not be merged until they are valid. 🔴 Require two reviewer for test updatesThis rule is failing.When test data is updated, we require two reviewers
🟢 Enforce conventional commitWonderful, this rule succeeded.Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
|
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
Signed-off-by: Christoph Auer <[email protected]>
Signed-off-by: Panos Vagenas <[email protected]>
Signed-off-by: Panos Vagenas <[email protected]>
Signed-off-by: Christoph Auer <[email protected]>
|
|
||
| doc = _construct_doc() | ||
|
|
||
| html_pred = doc.export_to_html() |
There was a problem hiding this comment.
similar to other tests (see here for example) we could simplify the test results removing the styling
| html_pred = doc.export_to_html() | |
| html_pred = doc.export_to_html(html_head="") |
| """TableCell.""" | ||
|
|
||
| bbox: Optional[BoundingBox] = None | ||
| row_span: int = 1 |
There was a problem hiding this comment.
Do we need a variable here? I think this can be a method computing end_row_offset_idx-start_row_offset_idx?
There was a problem hiding this comment.
We can do something about this but it is unrelated to the changes of this PR, and we cannot break backwards-compatibility.
|
|
||
| bbox: Optional[BoundingBox] = None | ||
| row_span: int = 1 | ||
| col_span: int = 1 |
There was a problem hiding this comment.
Do we need a variable here? I think this can be a method computing end_col_offset_idx-start_col_offset_idx?
There was a problem hiding this comment.
We can do something about this but it is unrelated to the changes of this PR, and we cannot break backwards-compatibility.
| row_span: int = 1 | ||
| col_span: int = 1 | ||
| start_row_offset_idx: int | ||
| end_row_offset_idx: int |
There was a problem hiding this comment.
can we check somewhere that end_*>start_*?
There was a problem hiding this comment.
We can generally put a model validator for such things.
|
superseded by #368 |
Feature
This PR introduces changes to allow table cells to contain any rich content instead of a basic text string. To enable this, the
TableCellmodel now inherits fromNodeItem. In order to remain backward compatible, theTableCell.textfield is still present (default = "") and theself_refuses a relative JSON pointer ("0") to refer itself as long as the TableCell is constructed in isolation before belonging to a table in a doc (as in previous usage conventions). A new methodTableCell.has_rich_content()reports if the table cell contains child nodes.New methods in
TableItemallow to modify a table's cells after adding the table to aDoclingDocument, which ensures proper reference handling of table cells:TableItem.update_cellis used to insert or overwrite a cell in a table, which allows to useDoclingDocument.add_textand other APIs with the returned cell asparentargument.TableItem.delete_cellsallows to delete cells in a given row/col index rangeTable cells with valid
self_refare created by theupdate_cellmethod and will look like this example:#/tables/0/data/table_cells/2The serializers are updated to consider table cells with rich content to ensure the
textfield is not considered when children are present. Children are serialized like any other subtree in a document.