Struct ItemTree

Source

pub struct ItemTree {
    pub items: Vec<TreeItem>,
    pub body: Vec<usize>,
}

Expand description

docling’s item tree in creation order (see the module docs).

Fields§

§items: Vec<TreeItem>

Every item, indexed by creation order — which is how docling numbers #/texts/N, #/groups/N, … within each bucket.

§body: Vec<usize>

The body’s children, as item indices.

Implementations§

Source §

impl ItemTree

Source

pub fn place_note_calls( &self, first_new: usize, full_text: &str, offsets: &[usize], ) -> Vec<Option<(usize, usize)>>

Where each note call of one paragraph lands (#538): full_text is the paragraph’s text, offsets the calls’ positions in it (chars), and the paragraph’s items are those created from first_new on. Each text item is a trimmed slice of the paragraph (a formatting run, a link, or the whole heading / list item), matched in order; a call inside an item lands there, one between items ends the earlier (or starts the first). When no item matches, the call ends the paragraph’s last text item; with no text item at all it is None.

Source §

impl ItemTree

Source

pub fn add( &mut self, parent: Option<usize>, layer: Option<ContentLayer>, kind: TreeKind, ) -> usize

Append an item under parent (None = body) on layer, registering it as its parent’s last child — docling’s add_* calls do exactly that.

Source

pub fn add_with_prov( &mut self, parent: Option<usize>, layer: Option<ContentLayer>, kind: TreeKind, prov: TreeProv, ) -> usize

add with the item’s provenance — docling’s add_text(…, prov=prov).

Source

pub fn append(&mut self, other: ItemTree)

Append every item of other after this tree’s, renumbering its indices (parents, children, comments, table/picture caption and rich-cell refs) and adding its body children to this body — so a backend can build independent fragments in parallel (one per PPTX slide) and still hand the export one tree in creation order, exactly as if it had been built sequentially.

Source

pub fn reparent(&mut self, id: usize, new_parent: Option<usize>)

Move id under new_parent, dropping it from its current parent’s children and appending it to the new one’s — docling’s group_cell_elements re-parenting of a rich cell’s items.

Source

pub fn renumber_in_traversal_order(&mut self) -> Vec<Option<usize>>

Re-number the items in traversal order — a pre-order walk of the body through every layer, which is how docling’s DoclingDocument.concatenate (and _normalize_references) re-creates a document’s items: a group created after the content it was later wrapped around comes before that content afterwards. Items the walk does not reach (deleted ones) are dropped. Returns each old id’s new id.

Source

pub fn delete(&mut self, id: usize)

Remove id from the tree — docling’s delete_items, which the DOCX backend uses to drop the empty text item a blank spacer paragraph left between two items of a resumed list. The item leaves its parent’s children and is neither numbered nor written; its slot stays so the indices held elsewhere stay valid.

Source

pub fn wrap_misplaced_list_items(&mut self)

docling-core’s DoclingDocument.validate_misplaced_list_items (a model validator, so it runs whenever docling-core serializes or loads a document): every list_item whose parent is not a list group is re-homed into a new one. A pre-order walk of the body (groups included) collects them; consecutive misplaced items directly on the body share one group, any other misplaced item gets its own. Working from the last run back, each run gets a ListGroup (name group) inserted where its first item stood, the items are deleted — with any children — and re-added under the group as fresh items, so they move to the end of the text numbering (#527: the DOCX backend leaves such items in rich table cells). A no-op for a well-formed tree.

Source