feat: leverage new list modeling, capture default markers (#1856)
* chore: update docling-core & regenerate test data Signed-off-by: Panos Vagenas <pva@zurich.ibm.com> * update backends to leverage new list modeling Signed-off-by: Panos Vagenas <pva@zurich.ibm.com> * repin docling-core Signed-off-by: Panos Vagenas <pva@zurich.ibm.com> * ensure availability of latest docling-core API Signed-off-by: Panos Vagenas <pva@zurich.ibm.com> --------- Signed-off-by: Panos Vagenas <pva@zurich.ibm.com>
This commit is contained in:
parent
e79e4f0ab6
commit
0533da1923
@ -17,6 +17,7 @@ from docling_core.types.doc import (
|
||||
TableData,
|
||||
)
|
||||
from docling_core.types.doc.document import ContentLayer
|
||||
from pydantic import BaseModel
|
||||
from typing_extensions import override
|
||||
|
||||
from docling.backend.abstract_backend import DeclarativeDocumentBackend
|
||||
@ -48,6 +49,11 @@ TAGS_FOR_NODE_ITEMS: Final = [
|
||||
]
|
||||
|
||||
|
||||
class _Context(BaseModel):
|
||||
list_ordered_flag_by_ref: dict[str, bool] = {}
|
||||
list_start_by_ref: dict[str, int] = {}
|
||||
|
||||
|
||||
class HTMLDocumentBackend(DeclarativeDocumentBackend):
|
||||
@override
|
||||
def __init__(self, in_doc: "InputDocument", path_or_stream: Union[BytesIO, Path]):
|
||||
@ -59,6 +65,7 @@ class HTMLDocumentBackend(DeclarativeDocumentBackend):
|
||||
self.max_levels = 10
|
||||
self.level = 0
|
||||
self.parents: dict[int, Optional[Union[DocItem, GroupItem]]] = {}
|
||||
self.ctx = _Context()
|
||||
for i in range(self.max_levels):
|
||||
self.parents[i] = None
|
||||
|
||||
@ -121,6 +128,7 @@ class HTMLDocumentBackend(DeclarativeDocumentBackend):
|
||||
self.content_layer = (
|
||||
ContentLayer.BODY if headers is None else ContentLayer.FURNITURE
|
||||
)
|
||||
self.ctx = _Context() # reset context
|
||||
self.walk(content, doc)
|
||||
else:
|
||||
raise RuntimeError(
|
||||
@ -294,28 +302,25 @@ class HTMLDocumentBackend(DeclarativeDocumentBackend):
|
||||
def handle_list(self, element: Tag, doc: DoclingDocument) -> None:
|
||||
"""Handles list tags (ul, ol) and their list items."""
|
||||
|
||||
if element.name == "ul":
|
||||
# create a list group
|
||||
self.parents[self.level + 1] = doc.add_group(
|
||||
parent=self.parents[self.level],
|
||||
name="list",
|
||||
label=GroupLabel.LIST,
|
||||
content_layer=self.content_layer,
|
||||
)
|
||||
elif element.name == "ol":
|
||||
start: Optional[int] = None
|
||||
if is_ordered := element.name == "ol":
|
||||
start_attr = element.get("start")
|
||||
start: int = (
|
||||
int(start_attr)
|
||||
if isinstance(start_attr, str) and start_attr.isnumeric()
|
||||
else 1
|
||||
)
|
||||
# create a list group
|
||||
self.parents[self.level + 1] = doc.add_group(
|
||||
parent=self.parents[self.level],
|
||||
name="ordered list" + (f" start {start}" if start != 1 else ""),
|
||||
label=GroupLabel.ORDERED_LIST,
|
||||
content_layer=self.content_layer,
|
||||
)
|
||||
if isinstance(start_attr, str) and start_attr.isnumeric():
|
||||
start = int(start_attr)
|
||||
name = "ordered list" + (f" start {start}" if start is not None else "")
|
||||
else:
|
||||
name = "list"
|
||||
# create a list group
|
||||
list_group = doc.add_list_group(
|
||||
name=name,
|
||||
parent=self.parents[self.level],
|
||||
content_layer=self.content_layer,
|
||||
)
|
||||
self.parents[self.level + 1] = list_group
|
||||
self.ctx.list_ordered_flag_by_ref[list_group.self_ref] = is_ordered
|
||||
if is_ordered and start is not None:
|
||||
self.ctx.list_start_by_ref[list_group.self_ref] = start
|
||||
|
||||
self.level += 1
|
||||
|
||||
self.walk(element, doc)
|
||||
@ -331,16 +336,11 @@ class HTMLDocumentBackend(DeclarativeDocumentBackend):
|
||||
if parent is None:
|
||||
_log.debug(f"list-item has no parent in DoclingDocument: {element}")
|
||||
return
|
||||
parent_label: str = parent.label
|
||||
index_in_list = len(parent.children) + 1
|
||||
if (
|
||||
parent_label == GroupLabel.ORDERED_LIST
|
||||
and isinstance(parent, GroupItem)
|
||||
and parent.name
|
||||
):
|
||||
start_in_list: str = parent.name.split(" ")[-1]
|
||||
start: int = int(start_in_list) if start_in_list.isnumeric() else 1
|
||||
index_in_list += start - 1
|
||||
enumerated = self.ctx.list_ordered_flag_by_ref.get(parent.self_ref, False)
|
||||
if enumerated and (start := self.ctx.list_start_by_ref.get(parent.self_ref)):
|
||||
marker = f"{start + len(parent.children)}."
|
||||
else:
|
||||
marker = ""
|
||||
|
||||
if nested_list:
|
||||
# Text in list item can be hidden within hierarchy, hence
|
||||
@ -350,12 +350,6 @@ class HTMLDocumentBackend(DeclarativeDocumentBackend):
|
||||
text = text.replace("\n", "").replace("\r", "")
|
||||
text = " ".join(text.split()).strip()
|
||||
|
||||
marker = ""
|
||||
enumerated = False
|
||||
if parent_label == GroupLabel.ORDERED_LIST:
|
||||
marker = str(index_in_list)
|
||||
enumerated = True
|
||||
|
||||
if len(text) > 0:
|
||||
# create a list-item
|
||||
self.parents[self.level + 1] = doc.add_list_item(
|
||||
@ -375,11 +369,6 @@ class HTMLDocumentBackend(DeclarativeDocumentBackend):
|
||||
elif element.text.strip():
|
||||
text = element.text.strip()
|
||||
|
||||
marker = ""
|
||||
enumerated = False
|
||||
if parent_label == GroupLabel.ORDERED_LIST:
|
||||
marker = f"{index_in_list!s}."
|
||||
enumerated = True
|
||||
doc.add_list_item(
|
||||
text=text,
|
||||
enumerated=enumerated,
|
||||
|
@ -14,13 +14,12 @@ from docling_core.types.doc import (
|
||||
DocItemLabel,
|
||||
DoclingDocument,
|
||||
DocumentOrigin,
|
||||
GroupLabel,
|
||||
NodeItem,
|
||||
TableCell,
|
||||
TableData,
|
||||
TextItem,
|
||||
)
|
||||
from docling_core.types.doc.document import Formatting, OrderedList, UnorderedList
|
||||
from docling_core.types.doc.document import Formatting
|
||||
from marko import Markdown
|
||||
from pydantic import AnyUrl, BaseModel, Field, TypeAdapter
|
||||
from typing_extensions import Annotated
|
||||
@ -51,6 +50,7 @@ class _HeadingCreationPayload(BaseModel):
|
||||
|
||||
class _ListItemCreationPayload(BaseModel):
|
||||
kind: Literal["list_item"] = "list_item"
|
||||
enumerated: bool
|
||||
|
||||
|
||||
_CreationPayload = Annotated[
|
||||
@ -187,15 +187,13 @@ class MarkdownDocumentBackend(DeclarativeDocumentBackend):
|
||||
doc: DoclingDocument,
|
||||
parent_item: Optional[NodeItem],
|
||||
text: str,
|
||||
enumerated: bool,
|
||||
formatting: Optional[Formatting] = None,
|
||||
hyperlink: Optional[Union[AnyUrl, Path]] = None,
|
||||
):
|
||||
if not isinstance(parent_item, (OrderedList, UnorderedList)):
|
||||
_log.warning("ListItem would have not had a list parent, adding one.")
|
||||
parent_item = doc.add_unordered_list(parent=parent_item)
|
||||
item = doc.add_list_item(
|
||||
text=text,
|
||||
enumerated=(isinstance(parent_item, OrderedList)),
|
||||
enumerated=enumerated,
|
||||
parent=parent_item,
|
||||
formatting=formatting,
|
||||
hyperlink=hyperlink,
|
||||
@ -238,6 +236,7 @@ class MarkdownDocumentBackend(DeclarativeDocumentBackend):
|
||||
creation_stack: list[
|
||||
_CreationPayload
|
||||
], # stack for lazy item creation triggered deep in marko's AST (on RawText)
|
||||
list_ordered_flag_by_ref: dict[str, bool],
|
||||
parent_item: Optional[NodeItem] = None,
|
||||
formatting: Optional[Formatting] = None,
|
||||
hyperlink: Optional[Union[AnyUrl, Path]] = None,
|
||||
@ -275,10 +274,8 @@ class MarkdownDocumentBackend(DeclarativeDocumentBackend):
|
||||
self._close_table(doc)
|
||||
_log.debug(f" - List {'ordered' if element.ordered else 'unordered'}")
|
||||
if has_non_empty_list_items:
|
||||
label = GroupLabel.ORDERED_LIST if element.ordered else GroupLabel.LIST
|
||||
parent_item = doc.add_group(
|
||||
label=label, name="list", parent=parent_item
|
||||
)
|
||||
parent_item = doc.add_list_group(name="list", parent=parent_item)
|
||||
list_ordered_flag_by_ref[parent_item.self_ref] = element.ordered
|
||||
|
||||
elif (
|
||||
isinstance(element, marko.block.ListItem)
|
||||
@ -289,16 +286,22 @@ class MarkdownDocumentBackend(DeclarativeDocumentBackend):
|
||||
self._close_table(doc)
|
||||
_log.debug(" - List item")
|
||||
|
||||
enumerated = (
|
||||
list_ordered_flag_by_ref.get(parent_item.self_ref, False)
|
||||
if parent_item
|
||||
else False
|
||||
)
|
||||
if len(child.children) > 1: # inline group will be created further down
|
||||
parent_item = self._create_list_item(
|
||||
doc=doc,
|
||||
parent_item=parent_item,
|
||||
text="",
|
||||
enumerated=enumerated,
|
||||
formatting=formatting,
|
||||
hyperlink=hyperlink,
|
||||
)
|
||||
else:
|
||||
creation_stack.append(_ListItemCreationPayload())
|
||||
creation_stack.append(_ListItemCreationPayload(enumerated=enumerated))
|
||||
|
||||
elif isinstance(element, marko.inline.Image):
|
||||
self._close_table(doc)
|
||||
@ -349,10 +352,18 @@ class MarkdownDocumentBackend(DeclarativeDocumentBackend):
|
||||
while len(creation_stack) > 0:
|
||||
to_create = creation_stack.pop()
|
||||
if isinstance(to_create, _ListItemCreationPayload):
|
||||
enumerated = (
|
||||
list_ordered_flag_by_ref.get(
|
||||
parent_item.self_ref, False
|
||||
)
|
||||
if parent_item
|
||||
else False
|
||||
)
|
||||
parent_item = self._create_list_item(
|
||||
doc=doc,
|
||||
parent_item=parent_item,
|
||||
text=snippet_text,
|
||||
enumerated=enumerated,
|
||||
formatting=formatting,
|
||||
hyperlink=hyperlink,
|
||||
)
|
||||
@ -453,6 +464,7 @@ class MarkdownDocumentBackend(DeclarativeDocumentBackend):
|
||||
doc=doc,
|
||||
visited=visited,
|
||||
creation_stack=creation_stack,
|
||||
list_ordered_flag_by_ref=list_ordered_flag_by_ref,
|
||||
parent_item=parent_item,
|
||||
formatting=formatting,
|
||||
hyperlink=hyperlink,
|
||||
@ -497,6 +509,7 @@ class MarkdownDocumentBackend(DeclarativeDocumentBackend):
|
||||
parent_item=None,
|
||||
visited=set(),
|
||||
creation_stack=[],
|
||||
list_ordered_flag_by_ref={},
|
||||
)
|
||||
self._close_table(doc=doc) # handle any last hanging table
|
||||
|
||||
|
@ -121,7 +121,9 @@ class MsPowerpointDocumentBackend(DeclarativeDocumentBackend, PaginatedDocumentB
|
||||
|
||||
return prov
|
||||
|
||||
def handle_text_elements(self, shape, parent_slide, slide_ind, doc, slide_size):
|
||||
def handle_text_elements(
|
||||
self, shape, parent_slide, slide_ind, doc: DoclingDocument, slide_size
|
||||
):
|
||||
is_list_group_created = False
|
||||
enum_list_item_value = 0
|
||||
new_list = None
|
||||
@ -165,10 +167,7 @@ class MsPowerpointDocumentBackend(DeclarativeDocumentBackend, PaginatedDocumentB
|
||||
enumerated = bullet_type == "Numbered"
|
||||
|
||||
if not is_list_group_created:
|
||||
new_list = doc.add_group(
|
||||
label=GroupLabel.ORDERED_LIST
|
||||
if enumerated
|
||||
else GroupLabel.LIST,
|
||||
new_list = doc.add_list_group(
|
||||
name="list",
|
||||
parent=parent_slide,
|
||||
)
|
||||
|
@ -10,11 +10,12 @@ from docling_core.types.doc import (
|
||||
DocumentOrigin,
|
||||
GroupLabel,
|
||||
ImageRef,
|
||||
ListGroup,
|
||||
NodeItem,
|
||||
TableCell,
|
||||
TableData,
|
||||
)
|
||||
from docling_core.types.doc.document import Formatting, OrderedList, UnorderedList
|
||||
from docling_core.types.doc.document import Formatting
|
||||
from docx import Document
|
||||
from docx.document import Document as DocxDocument
|
||||
from docx.oxml.table import CT_Tc
|
||||
@ -688,7 +689,7 @@ class MsWordDocumentBackend(DeclarativeDocumentBackend):
|
||||
paragraph_elements: list,
|
||||
) -> Optional[NodeItem]:
|
||||
return (
|
||||
doc.add_group(label=GroupLabel.INLINE, parent=prev_parent)
|
||||
doc.add_inline_group(parent=prev_parent)
|
||||
if len(paragraph_elements) > 1
|
||||
else prev_parent
|
||||
)
|
||||
@ -781,9 +782,7 @@ class MsWordDocumentBackend(DeclarativeDocumentBackend):
|
||||
else:
|
||||
# Inline equation
|
||||
level = self._get_level()
|
||||
inline_equation = doc.add_group(
|
||||
label=GroupLabel.INLINE, parent=self.parents[level - 1]
|
||||
)
|
||||
inline_equation = doc.add_inline_group(parent=self.parents[level - 1])
|
||||
text_tmp = text
|
||||
for eq in equations:
|
||||
if len(text_tmp) == 0:
|
||||
@ -931,18 +930,22 @@ class MsWordDocumentBackend(DeclarativeDocumentBackend):
|
||||
level: int,
|
||||
) -> None:
|
||||
# This should not happen by construction
|
||||
if not isinstance(self.parents[level], (OrderedList, UnorderedList)):
|
||||
if not isinstance(self.parents[level], ListGroup):
|
||||
return
|
||||
if not elements:
|
||||
return
|
||||
|
||||
if len(elements) == 1:
|
||||
text, format, hyperlink = elements[0]
|
||||
doc.add_list_item(
|
||||
marker=marker,
|
||||
enumerated=enumerated,
|
||||
parent=self.parents[level],
|
||||
text=text,
|
||||
formatting=format,
|
||||
hyperlink=hyperlink,
|
||||
)
|
||||
if text:
|
||||
doc.add_list_item(
|
||||
marker=marker,
|
||||
enumerated=enumerated,
|
||||
parent=self.parents[level],
|
||||
text=text,
|
||||
formatting=format,
|
||||
hyperlink=hyperlink,
|
||||
)
|
||||
else:
|
||||
new_item = doc.add_list_item(
|
||||
marker=marker,
|
||||
@ -950,15 +953,16 @@ class MsWordDocumentBackend(DeclarativeDocumentBackend):
|
||||
parent=self.parents[level],
|
||||
text="",
|
||||
)
|
||||
new_parent = doc.add_group(label=GroupLabel.INLINE, parent=new_item)
|
||||
new_parent = doc.add_inline_group(parent=new_item)
|
||||
for text, format, hyperlink in elements:
|
||||
doc.add_text(
|
||||
label=DocItemLabel.TEXT,
|
||||
parent=new_parent,
|
||||
text=text,
|
||||
formatting=format,
|
||||
hyperlink=hyperlink,
|
||||
)
|
||||
if text:
|
||||
doc.add_text(
|
||||
label=DocItemLabel.TEXT,
|
||||
parent=new_parent,
|
||||
text=text,
|
||||
formatting=format,
|
||||
hyperlink=hyperlink,
|
||||
)
|
||||
|
||||
def _add_list_item(
|
||||
self,
|
||||
@ -979,8 +983,8 @@ class MsWordDocumentBackend(DeclarativeDocumentBackend):
|
||||
if self._prev_numid() is None: # Open new list
|
||||
self.level_at_new_list = level
|
||||
|
||||
self.parents[level] = doc.add_group(
|
||||
label=GroupLabel.LIST, name="list", parent=self.parents[level - 1]
|
||||
self.parents[level] = doc.add_list_group(
|
||||
name="list", parent=self.parents[level - 1]
|
||||
)
|
||||
|
||||
# Set marker and enumerated arguments if this is an enumeration element.
|
||||
@ -1001,19 +1005,10 @@ class MsWordDocumentBackend(DeclarativeDocumentBackend):
|
||||
self.level_at_new_list + prev_indent + 1,
|
||||
self.level_at_new_list + ilevel + 1,
|
||||
):
|
||||
# Determine if this is an unordered list or an ordered list.
|
||||
# Set GroupLabel.ORDERED_LIST when it fits.
|
||||
self.listIter = 0
|
||||
if is_numbered:
|
||||
self.parents[i] = doc.add_group(
|
||||
label=GroupLabel.ORDERED_LIST,
|
||||
name="list",
|
||||
parent=self.parents[i - 1],
|
||||
)
|
||||
else:
|
||||
self.parents[i] = doc.add_group(
|
||||
label=GroupLabel.LIST, name="list", parent=self.parents[i - 1]
|
||||
)
|
||||
self.parents[i] = doc.add_list_group(
|
||||
name="list", parent=self.parents[i - 1]
|
||||
)
|
||||
|
||||
# TODO: Set marker and enumerated arguments if this is an enumeration element.
|
||||
self.listIter += 1
|
||||
|
@ -44,7 +44,7 @@ authors = [
|
||||
requires-python = '>=3.9,<4.0'
|
||||
dependencies = [
|
||||
'pydantic (>=2.0.0,<3.0.0)',
|
||||
'docling-core[chunking] (>=2.29.0,<3.0.0)',
|
||||
'docling-core[chunking] (>=2.39.0,<3.0.0)',
|
||||
'docling-ibm-models (>=3.4.4,<4.0.0)',
|
||||
'docling-parse (>=4.0.0,<5.0.0)',
|
||||
'filetype (>=1.2.0,<2.0.0)',
|
||||
|
@ -14,8 +14,8 @@
|
||||
<location><page_1><loc_52><loc_62><loc_88><loc_71></location>
|
||||
<row_0><col_0><col_header>1</col_0></row_0>
|
||||
</table>
|
||||
<paragraph><location><page_1><loc_52><loc_58><loc_79><loc_60></location>- b. Red-annotation of bounding boxes, Blue-predictions by TableFormer</paragraph>
|
||||
<paragraph><location><page_1><loc_52><loc_46><loc_80><loc_47></location>- c. Structure predicted by TableFormer:</paragraph>
|
||||
<paragraph><location><page_1><loc_52><loc_58><loc_79><loc_60></location>b. Red-annotation of bounding boxes, Blue-predictions by TableFormer</paragraph>
|
||||
<paragraph><location><page_1><loc_52><loc_46><loc_80><loc_47></location>c. Structure predicted by TableFormer:</paragraph>
|
||||
<figure>
|
||||
<location><page_1><loc_51><loc_48><loc_88><loc_57></location>
|
||||
</figure>
|
||||
@ -38,10 +38,10 @@
|
||||
<paragraph><location><page_2><loc_8><loc_71><loc_47><loc_87></location>The second problem is called table-structure decomposition. The latter is a long standing problem in the community of document understanding [6, 4, 14]. Contrary to the table-location problem, there are no commonly used approaches that can easily be re-purposed to solve this problem. Lately, a set of new model-architectures has been proposed by the community to address table-structure decomposition [37, 36, 18, 20]. All these models have some weaknesses (see Sec. 2). The common denominator here is the reliance on textual features and/or the inability to provide the bounding box of each table-cell in the original image.</paragraph>
|
||||
<paragraph><location><page_2><loc_8><loc_53><loc_47><loc_71></location>In this paper, we want to address these weaknesses and present a robust table-structure decomposition algorithm. The design criteria for our model are the following. First, we want our algorithm to be language agnostic. In this way, we can obtain the structure of any table, irregardless of the language. Second, we want our algorithm to leverage as much data as possible from the original PDF document. For programmatic PDF documents, the text-cells can often be extracted much faster and with higher accuracy compared to OCR methods. Last but not least, we want to have a direct link between the table-cell and its bounding box in the image.</paragraph>
|
||||
<paragraph><location><page_2><loc_8><loc_45><loc_47><loc_53></location>To meet the design criteria listed above, we developed a new model called TableFormer and a synthetically generated table structure dataset called SynthTabNet $^{1}$. In particular, our contributions in this work can be summarised as follows:</paragraph>
|
||||
<paragraph><location><page_2><loc_10><loc_38><loc_47><loc_44></location>- · We propose TableFormer , a transformer based model that predicts tables structure and bounding boxes for the table content simultaneously in an end-to-end approach.</paragraph>
|
||||
<paragraph><location><page_2><loc_10><loc_31><loc_47><loc_37></location>- · Across all benchmark datasets TableFormer significantly outperforms existing state-of-the-art metrics, while being much more efficient in training and inference to existing works.</paragraph>
|
||||
<paragraph><location><page_2><loc_10><loc_25><loc_47><loc_29></location>- · We present SynthTabNet a synthetically generated dataset, with various appearance styles and complexity.</paragraph>
|
||||
<paragraph><location><page_2><loc_10><loc_19><loc_47><loc_24></location>- · An augmented dataset based on PubTabNet [37], FinTabNet [36], and TableBank [17] with generated ground-truth for reproducibility.</paragraph>
|
||||
<paragraph><location><page_2><loc_10><loc_38><loc_47><loc_44></location>· We propose TableFormer , a transformer based model that predicts tables structure and bounding boxes for the table content simultaneously in an end-to-end approach.</paragraph>
|
||||
<paragraph><location><page_2><loc_10><loc_31><loc_47><loc_37></location>· Across all benchmark datasets TableFormer significantly outperforms existing state-of-the-art metrics, while being much more efficient in training and inference to existing works.</paragraph>
|
||||
<paragraph><location><page_2><loc_10><loc_25><loc_47><loc_29></location>· We present SynthTabNet a synthetically generated dataset, with various appearance styles and complexity.</paragraph>
|
||||
<paragraph><location><page_2><loc_10><loc_19><loc_47><loc_24></location>· An augmented dataset based on PubTabNet [37], FinTabNet [36], and TableBank [17] with generated ground-truth for reproducibility.</paragraph>
|
||||
<paragraph><location><page_2><loc_8><loc_12><loc_47><loc_18></location>The paper is structured as follows. In Sec. 2, we give a brief overview of the current state-of-the-art. In Sec. 3, we describe the datasets on which we train. In Sec. 4, we introduce the TableFormer model-architecture and describe</paragraph>
|
||||
<paragraph><location><page_2><loc_50><loc_86><loc_89><loc_91></location>its results & performance in Sec. 5. As a conclusion, we describe how this new model-architecture can be re-purposed for other tasks in the computer-vision community.</paragraph>
|
||||
<subtitle-level-1><location><page_2><loc_50><loc_83><loc_81><loc_85></location>2. Previous work and State of the Art</subtitle-level-1>
|
||||
@ -160,8 +160,8 @@
|
||||
<row_6><col_0><row_header>TableFormer</col_0><col_1><body>95.4</col_1><col_2><body>90.1</col_2><col_3><body>93.6</col_3></row_6>
|
||||
</table>
|
||||
<caption><location><page_7><loc_50><loc_13><loc_89><loc_17></location>Table 4: Results of structure with content retrieved using cell detection on PubTabNet. In all cases the input is PDF documents with cropped tables.</caption>
|
||||
<paragraph><location><page_8><loc_9><loc_89><loc_10><loc_90></location>- a.</paragraph>
|
||||
<paragraph><location><page_8><loc_11><loc_89><loc_82><loc_90></location>- Red - PDF cells, Green - predicted bounding boxes, Blue - post-processed predictions matched to PDF cells</paragraph>
|
||||
<paragraph><location><page_8><loc_9><loc_89><loc_10><loc_90></location>a.</paragraph>
|
||||
<paragraph><location><page_8><loc_11><loc_89><loc_82><loc_90></location>Red - PDF cells, Green - predicted bounding boxes, Blue - post-processed predictions matched to PDF cells</paragraph>
|
||||
<subtitle-level-1><location><page_8><loc_9><loc_87><loc_46><loc_88></location>Japanese language (previously unseen by TableFormer):</subtitle-level-1>
|
||||
<subtitle-level-1><location><page_8><loc_50><loc_87><loc_70><loc_88></location>Example table from FinTabNet:</subtitle-level-1>
|
||||
<figure>
|
||||
@ -215,47 +215,47 @@
|
||||
<paragraph><location><page_8><loc_8><loc_10><loc_47><loc_32></location>We showcase several visualizations for the different components of our network on various "complex" tables within datasets presented in this work in Fig. 5 and Fig. 6 As it is shown, our model is able to predict bounding boxes for all table cells, even for the empty ones. Additionally, our post-processing techniques can extract the cell content by matching the predicted bounding boxes to the PDF cells based on their overlap and spatial proximity. The left part of Fig. 5 demonstrates also the adaptability of our method to any language, as it can successfully extract Japanese text, although the training set contains only English content. We provide more visualizations including the intermediate steps in the supplementary material. Overall these illustrations justify the versatility of our method across a diverse range of table appearances and content type.</paragraph>
|
||||
<paragraph><location><page_8><loc_50><loc_18><loc_89><loc_35></location>In this paper, we presented TableFormer an end-to-end transformer based approach to predict table structures and bounding boxes of cells from an image. This approach enables us to recreate the table structure, and extract the cell content from PDF or OCR by using bounding boxes. Additionally, it provides the versatility required in real-world scenarios when dealing with various types of PDF documents, and languages. Furthermore, our method outperforms all state-of-the-arts with a wide margin. Finally, we introduce "SynthTabNet" a challenging synthetically generated dataset that reinforces missing characteristics from other datasets.</paragraph>
|
||||
<subtitle-level-1><location><page_8><loc_50><loc_14><loc_60><loc_15></location>References</subtitle-level-1>
|
||||
<paragraph><location><page_8><loc_51><loc_10><loc_89><loc_12></location>- [1] Nicolas Carion, Francisco Massa, Gabriel Synnaeve, Nicolas Usunier, Alexander Kirillov, and Sergey Zagoruyko. End-to-</paragraph>
|
||||
<paragraph><location><page_9><loc_11><loc_85><loc_47><loc_90></location>- end object detection with transformers. In Andrea Vedaldi, Horst Bischof, Thomas Brox, and Jan-Michael Frahm, editors, Computer Vision - ECCV 2020 , pages 213-229, Cham, 2020. Springer International Publishing. 5</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_81><loc_47><loc_85></location>- [2] Zewen Chi, Heyan Huang, Heng-Da Xu, Houjin Yu, Wanxuan Yin, and Xian-Ling Mao. Complicated table structure recognition. arXiv preprint arXiv:1908.04729 , 2019. 3</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_77><loc_47><loc_81></location>- [3] Bertrand Couasnon and Aurelie Lemaitre. Recognition of Tables and Forms , pages 647-677. Springer London, London, 2014. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_71><loc_47><loc_76></location>- [4] Herv´e D´ejean, Jean-Luc Meunier, Liangcai Gao, Yilun Huang, Yu Fang, Florian Kleber, and Eva-Maria Lang. ICDAR 2019 Competition on Table Detection and Recognition (cTDaR), Apr. 2019. http://sac.founderit.com/. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_66><loc_47><loc_71></location>- [5] Basilios Gatos, Dimitrios Danatsas, Ioannis Pratikakis, and Stavros J Perantonis. Automatic table detection in document images. In International Conference on Pattern Recognition and Image Analysis , pages 609-618. Springer, 2005. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_60><loc_47><loc_65></location>- [6] Max G¨obel, Tamir Hassan, Ermelinda Oro, and Giorgio Orsi. Icdar 2013 table competition. In 2013 12th International Conference on Document Analysis and Recognition , pages 1449-1453, 2013. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_56><loc_47><loc_60></location>- [7] EA Green and M Krishnamoorthy. Recognition of tables using table grammars. procs. In Symposium on Document Analysis and Recognition (SDAIR'95) , pages 261-277. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_49><loc_47><loc_56></location>- [8] Khurram Azeem Hashmi, Alain Pagani, Marcus Liwicki, Didier Stricker, and Muhammad Zeshan Afzal. Castabdetectors: Cascade network for table detection in document images with recursive feature pyramid and switchable atrous convolution. Journal of Imaging , 7(10), 2021. 1</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_45><loc_47><loc_49></location>- [9] Kaiming He, Georgia Gkioxari, Piotr Dollar, and Ross Girshick. Mask r-cnn. In Proceedings of the IEEE International Conference on Computer Vision (ICCV) , Oct 2017. 1</paragraph>
|
||||
<paragraph><location><page_9><loc_8><loc_39><loc_47><loc_44></location>- [10] Yelin He, X. Qi, Jiaquan Ye, Peng Gao, Yihao Chen, Bingcong Li, Xin Tang, and Rong Xiao. Pingan-vcgroup's solution for icdar 2021 competition on scientific table image recognition to latex. ArXiv , abs/2105.01846, 2021. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_8><loc_32><loc_47><loc_39></location>- [11] Jianying Hu, Ramanujan S Kashi, Daniel P Lopresti, and Gordon Wilfong. Medium-independent table detection. In Document Recognition and Retrieval VII , volume 3967, pages 291-302. International Society for Optics and Photonics, 1999. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_8><loc_25><loc_47><loc_32></location>- [12] Matthew Hurst. A constraint-based approach to table structure derivation. In Proceedings of the Seventh International Conference on Document Analysis and Recognition - Volume 2 , ICDAR '03, page 911, USA, 2003. IEEE Computer Society. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_8><loc_18><loc_47><loc_25></location>- [13] Thotreingam Kasar, Philippine Barlas, Sebastien Adam, Cl´ement Chatelain, and Thierry Paquet. Learning to detect tables in scanned document images using line information. In 2013 12th International Conference on Document Analysis and Recognition , pages 1185-1189. IEEE, 2013. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_8><loc_14><loc_47><loc_18></location>- [14] Pratik Kayal, Mrinal Anand, Harsh Desai, and Mayank Singh. Icdar 2021 competition on scientific table image recognition to latex, 2021. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_8><loc_10><loc_47><loc_14></location>- [15] Harold W Kuhn. The hungarian method for the assignment problem. Naval research logistics quarterly , 2(1-2):83-97, 1955. 6</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_82><loc_89><loc_90></location>- [16] Girish Kulkarni, Visruth Premraj, Vicente Ordonez, Sagnik Dhar, Siming Li, Yejin Choi, Alexander C. Berg, and Tamara L. Berg. Babytalk: Understanding and generating simple image descriptions. IEEE Transactions on Pattern Analysis and Machine Intelligence , 35(12):2891-2903, 2013. 4</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_78><loc_89><loc_82></location>- [17] Minghao Li, Lei Cui, Shaohan Huang, Furu Wei, Ming Zhou, and Zhoujun Li. Tablebank: A benchmark dataset for table detection and recognition, 2019. 2, 3</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_67><loc_89><loc_78></location>- [18] Yiren Li, Zheng Huang, Junchi Yan, Yi Zhou, Fan Ye, and Xianhui Liu. Gfte: Graph-based financial table extraction. In Alberto Del Bimbo, Rita Cucchiara, Stan Sclaroff, Giovanni Maria Farinella, Tao Mei, Marco Bertini, Hugo Jair Escalante, and Roberto Vezzani, editors, Pattern Recognition. ICPR International Workshops and Challenges , pages 644-658, Cham, 2021. Springer International Publishing. 2, 3</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_59><loc_89><loc_67></location>- [19] Nikolaos Livathinos, Cesar Berrospi, Maksym Lysak, Viktor Kuropiatnyk, Ahmed Nassar, Andre Carvalho, Michele Dolfi, Christoph Auer, Kasper Dinkla, and Peter Staar. Robust pdf document conversion using recurrent neural networks. Proceedings of the AAAI Conference on Artificial Intelligence , 35(17):15137-15145, May 2021. 1</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_53><loc_89><loc_58></location>- [20] Rujiao Long, Wen Wang, Nan Xue, Feiyu Gao, Zhibo Yang, Yongpan Wang, and Gui-Song Xia. Parsing table structures in the wild. In Proceedings of the IEEE/CVF International Conference on Computer Vision , pages 944-952, 2021. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_45><loc_89><loc_53></location>- [21] Shubham Singh Paliwal, D Vishwanath, Rohit Rahul, Monika Sharma, and Lovekesh Vig. Tablenet: Deep learning model for end-to-end table detection and tabular data extraction from scanned document images. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 128-133. IEEE, 2019. 1</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_30><loc_89><loc_44></location>- [22] Adam Paszke, Sam Gross, Francisco Massa, Adam Lerer, James Bradbury, Gregory Chanan, Trevor Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga, Alban Desmaison, Andreas Kopf, Edward Yang, Zachary DeVito, Martin Raison, Alykhan Tejani, Sasank Chilamkurthy, Benoit Steiner, Lu Fang, Junjie Bai, and Soumith Chintala. Pytorch: An imperative style, high-performance deep learning library. In H. Wallach, H. Larochelle, A. Beygelzimer, F. d'Alch´e-Buc, E. Fox, and R. Garnett, editors, Advances in Neural Information Processing Systems 32 , pages 8024-8035. Curran Associates, Inc., 2019. 6</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_21><loc_89><loc_29></location>- [23] Devashish Prasad, Ayan Gadpal, Kshitij Kapadni, Manish Visave, and Kavita Sultanpure. Cascadetabnet: An approach for end to end table detection and structure recognition from image-based documents. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition Workshops , pages 572-573, 2020. 1</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_16><loc_89><loc_21></location>- [24] Shah Rukh Qasim, Hassan Mahmood, and Faisal Shafait. Rethinking table recognition using graph neural networks. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 142-147. IEEE, 2019. 3</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_10><loc_89><loc_15></location>- [25] Hamid Rezatofighi, Nathan Tsoi, JunYoung Gwak, Amir Sadeghian, Ian Reid, and Silvio Savarese. Generalized intersection over union: A metric and a loss for bounding box regression. In Proceedings of the IEEE/CVF Conference on</paragraph>
|
||||
<paragraph><location><page_8><loc_51><loc_10><loc_89><loc_12></location>[1] Nicolas Carion, Francisco Massa, Gabriel Synnaeve, Nicolas Usunier, Alexander Kirillov, and Sergey Zagoruyko. End-to-</paragraph>
|
||||
<paragraph><location><page_9><loc_11><loc_85><loc_47><loc_90></location>end object detection with transformers. In Andrea Vedaldi, Horst Bischof, Thomas Brox, and Jan-Michael Frahm, editors, Computer Vision - ECCV 2020 , pages 213-229, Cham, 2020. Springer International Publishing. 5</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_81><loc_47><loc_85></location>[2] Zewen Chi, Heyan Huang, Heng-Da Xu, Houjin Yu, Wanxuan Yin, and Xian-Ling Mao. Complicated table structure recognition. arXiv preprint arXiv:1908.04729 , 2019. 3</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_77><loc_47><loc_81></location>[3] Bertrand Couasnon and Aurelie Lemaitre. Recognition of Tables and Forms , pages 647-677. Springer London, London, 2014. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_71><loc_47><loc_76></location>[4] Herv´e D´ejean, Jean-Luc Meunier, Liangcai Gao, Yilun Huang, Yu Fang, Florian Kleber, and Eva-Maria Lang. ICDAR 2019 Competition on Table Detection and Recognition (cTDaR), Apr. 2019. http://sac.founderit.com/. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_66><loc_47><loc_71></location>[5] Basilios Gatos, Dimitrios Danatsas, Ioannis Pratikakis, and Stavros J Perantonis. Automatic table detection in document images. In International Conference on Pattern Recognition and Image Analysis , pages 609-618. Springer, 2005. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_60><loc_47><loc_65></location>[6] Max G¨obel, Tamir Hassan, Ermelinda Oro, and Giorgio Orsi. Icdar 2013 table competition. In 2013 12th International Conference on Document Analysis and Recognition , pages 1449-1453, 2013. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_56><loc_47><loc_60></location>[7] EA Green and M Krishnamoorthy. Recognition of tables using table grammars. procs. In Symposium on Document Analysis and Recognition (SDAIR'95) , pages 261-277. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_49><loc_47><loc_56></location>[8] Khurram Azeem Hashmi, Alain Pagani, Marcus Liwicki, Didier Stricker, and Muhammad Zeshan Afzal. Castabdetectors: Cascade network for table detection in document images with recursive feature pyramid and switchable atrous convolution. Journal of Imaging , 7(10), 2021. 1</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_45><loc_47><loc_49></location>[9] Kaiming He, Georgia Gkioxari, Piotr Dollar, and Ross Girshick. Mask r-cnn. In Proceedings of the IEEE International Conference on Computer Vision (ICCV) , Oct 2017. 1</paragraph>
|
||||
<paragraph><location><page_9><loc_8><loc_39><loc_47><loc_44></location>[10] Yelin He, X. Qi, Jiaquan Ye, Peng Gao, Yihao Chen, Bingcong Li, Xin Tang, and Rong Xiao. Pingan-vcgroup's solution for icdar 2021 competition on scientific table image recognition to latex. ArXiv , abs/2105.01846, 2021. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_8><loc_32><loc_47><loc_39></location>[11] Jianying Hu, Ramanujan S Kashi, Daniel P Lopresti, and Gordon Wilfong. Medium-independent table detection. In Document Recognition and Retrieval VII , volume 3967, pages 291-302. International Society for Optics and Photonics, 1999. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_8><loc_25><loc_47><loc_32></location>[12] Matthew Hurst. A constraint-based approach to table structure derivation. In Proceedings of the Seventh International Conference on Document Analysis and Recognition - Volume 2 , ICDAR '03, page 911, USA, 2003. IEEE Computer Society. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_8><loc_18><loc_47><loc_25></location>[13] Thotreingam Kasar, Philippine Barlas, Sebastien Adam, Cl´ement Chatelain, and Thierry Paquet. Learning to detect tables in scanned document images using line information. In 2013 12th International Conference on Document Analysis and Recognition , pages 1185-1189. IEEE, 2013. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_8><loc_14><loc_47><loc_18></location>[14] Pratik Kayal, Mrinal Anand, Harsh Desai, and Mayank Singh. Icdar 2021 competition on scientific table image recognition to latex, 2021. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_8><loc_10><loc_47><loc_14></location>[15] Harold W Kuhn. The hungarian method for the assignment problem. Naval research logistics quarterly , 2(1-2):83-97, 1955. 6</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_82><loc_89><loc_90></location>[16] Girish Kulkarni, Visruth Premraj, Vicente Ordonez, Sagnik Dhar, Siming Li, Yejin Choi, Alexander C. Berg, and Tamara L. Berg. Babytalk: Understanding and generating simple image descriptions. IEEE Transactions on Pattern Analysis and Machine Intelligence , 35(12):2891-2903, 2013. 4</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_78><loc_89><loc_82></location>[17] Minghao Li, Lei Cui, Shaohan Huang, Furu Wei, Ming Zhou, and Zhoujun Li. Tablebank: A benchmark dataset for table detection and recognition, 2019. 2, 3</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_67><loc_89><loc_78></location>[18] Yiren Li, Zheng Huang, Junchi Yan, Yi Zhou, Fan Ye, and Xianhui Liu. Gfte: Graph-based financial table extraction. In Alberto Del Bimbo, Rita Cucchiara, Stan Sclaroff, Giovanni Maria Farinella, Tao Mei, Marco Bertini, Hugo Jair Escalante, and Roberto Vezzani, editors, Pattern Recognition. ICPR International Workshops and Challenges , pages 644-658, Cham, 2021. Springer International Publishing. 2, 3</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_59><loc_89><loc_67></location>[19] Nikolaos Livathinos, Cesar Berrospi, Maksym Lysak, Viktor Kuropiatnyk, Ahmed Nassar, Andre Carvalho, Michele Dolfi, Christoph Auer, Kasper Dinkla, and Peter Staar. Robust pdf document conversion using recurrent neural networks. Proceedings of the AAAI Conference on Artificial Intelligence , 35(17):15137-15145, May 2021. 1</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_53><loc_89><loc_58></location>[20] Rujiao Long, Wen Wang, Nan Xue, Feiyu Gao, Zhibo Yang, Yongpan Wang, and Gui-Song Xia. Parsing table structures in the wild. In Proceedings of the IEEE/CVF International Conference on Computer Vision , pages 944-952, 2021. 2</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_45><loc_89><loc_53></location>[21] Shubham Singh Paliwal, D Vishwanath, Rohit Rahul, Monika Sharma, and Lovekesh Vig. Tablenet: Deep learning model for end-to-end table detection and tabular data extraction from scanned document images. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 128-133. IEEE, 2019. 1</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_30><loc_89><loc_44></location>[22] Adam Paszke, Sam Gross, Francisco Massa, Adam Lerer, James Bradbury, Gregory Chanan, Trevor Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga, Alban Desmaison, Andreas Kopf, Edward Yang, Zachary DeVito, Martin Raison, Alykhan Tejani, Sasank Chilamkurthy, Benoit Steiner, Lu Fang, Junjie Bai, and Soumith Chintala. Pytorch: An imperative style, high-performance deep learning library. In H. Wallach, H. Larochelle, A. Beygelzimer, F. d'Alch´e-Buc, E. Fox, and R. Garnett, editors, Advances in Neural Information Processing Systems 32 , pages 8024-8035. Curran Associates, Inc., 2019. 6</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_21><loc_89><loc_29></location>[23] Devashish Prasad, Ayan Gadpal, Kshitij Kapadni, Manish Visave, and Kavita Sultanpure. Cascadetabnet: An approach for end to end table detection and structure recognition from image-based documents. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition Workshops , pages 572-573, 2020. 1</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_16><loc_89><loc_21></location>[24] Shah Rukh Qasim, Hassan Mahmood, and Faisal Shafait. Rethinking table recognition using graph neural networks. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 142-147. IEEE, 2019. 3</paragraph>
|
||||
<paragraph><location><page_9><loc_50><loc_10><loc_89><loc_15></location>[25] Hamid Rezatofighi, Nathan Tsoi, JunYoung Gwak, Amir Sadeghian, Ian Reid, and Silvio Savarese. Generalized intersection over union: A metric and a loss for bounding box regression. In Proceedings of the IEEE/CVF Conference on</paragraph>
|
||||
<paragraph><location><page_10><loc_11><loc_88><loc_47><loc_90></location>Computer Vision and Pattern Recognition , pages 658-666, 2019. 6</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_80><loc_47><loc_88></location>- [26] Sebastian Schreiber, Stefan Agne, Ivo Wolf, Andreas Dengel, and Sheraz Ahmed. Deepdesrt: Deep learning for detection and structure recognition of tables in document images. In 2017 14th IAPR International Conference on Document Analysis and Recognition (ICDAR) , volume 01, pages 11621167, 2017. 1</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_71><loc_47><loc_79></location>- [27] Sebastian Schreiber, Stefan Agne, Ivo Wolf, Andreas Dengel, and Sheraz Ahmed. Deepdesrt: Deep learning for detection and structure recognition of tables in document images. In 2017 14th IAPR international conference on document analysis and recognition (ICDAR) , volume 1, pages 1162-1167. IEEE, 2017. 3</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_66><loc_47><loc_71></location>- [28] Faisal Shafait and Ray Smith. Table detection in heterogeneous documents. In Proceedings of the 9th IAPR International Workshop on Document Analysis Systems , pages 6572, 2010. 2</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_59><loc_47><loc_65></location>- [29] Shoaib Ahmed Siddiqui, Imran Ali Fateh, Syed Tahseen Raza Rizvi, Andreas Dengel, and Sheraz Ahmed. Deeptabstr: Deep learning based table structure recognition. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 1403-1409. IEEE, 2019. 3</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_52><loc_47><loc_58></location>- [30] Peter W J Staar, Michele Dolfi, Christoph Auer, and Costas Bekas. Corpus conversion service: A machine learning platform to ingest documents at scale. In Proceedings of the 24th ACM SIGKDD , KDD '18, pages 774-782, New York, NY, USA, 2018. ACM. 1</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_42><loc_47><loc_51></location>- [31] Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, Ł ukasz Kaiser, and Illia Polosukhin. Attention is all you need. In I. Guyon, U. V. Luxburg, S. Bengio, H. Wallach, R. Fergus, S. Vishwanathan, and R. Garnett, editors, Advances in Neural Information Processing Systems 30 , pages 5998-6008. Curran Associates, Inc., 2017. 5</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_37><loc_47><loc_42></location>- [32] Oriol Vinyals, Alexander Toshev, Samy Bengio, and Dumitru Erhan. Show and tell: A neural image caption generator. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (CVPR) , June 2015. 2</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_31><loc_47><loc_36></location>- [33] Wenyuan Xue, Qingyong Li, and Dacheng Tao. Res2tim: reconstruct syntactic structures from table images. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 749-755. IEEE, 2019. 3</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_25><loc_47><loc_31></location>- [34] Wenyuan Xue, Baosheng Yu, Wen Wang, Dacheng Tao, and Qingyong Li. Tgrnet: A table graph reconstruction network for table structure recognition. arXiv preprint arXiv:2106.10598 , 2021. 3</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_20><loc_47><loc_25></location>- [35] Quanzeng You, Hailin Jin, Zhaowen Wang, Chen Fang, and Jiebo Luo. Image captioning with semantic attention. In Proceedings of the IEEE conference on computer vision and pattern recognition , pages 4651-4659, 2016. 4</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_13><loc_47><loc_19></location>- [36] Xinyi Zheng, Doug Burdick, Lucian Popa, Peter Zhong, and Nancy Xin Ru Wang. Global table extractor (gte): A framework for joint table identification and cell structure recognition using visual context. Winter Conference for Applications in Computer Vision (WACV) , 2021. 2, 3</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_10><loc_47><loc_12></location>- [37] Xu Zhong, Elaheh ShafieiBavani, and Antonio Jimeno Yepes. Image-based table recognition: Data, model,</paragraph>
|
||||
<paragraph><location><page_10><loc_54><loc_85><loc_89><loc_90></location>- and evaluation. In Andrea Vedaldi, Horst Bischof, Thomas Brox, and Jan-Michael Frahm, editors, Computer Vision ECCV 2020 , pages 564-580, Cham, 2020. Springer International Publishing. 2, 3, 7</paragraph>
|
||||
<paragraph><location><page_10><loc_50><loc_80><loc_89><loc_85></location>- [38] Xu Zhong, Jianbin Tang, and Antonio Jimeno Yepes. Publaynet: Largest dataset ever for document layout analysis. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 1015-1022, 2019. 1</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_80><loc_47><loc_88></location>[26] Sebastian Schreiber, Stefan Agne, Ivo Wolf, Andreas Dengel, and Sheraz Ahmed. Deepdesrt: Deep learning for detection and structure recognition of tables in document images. In 2017 14th IAPR International Conference on Document Analysis and Recognition (ICDAR) , volume 01, pages 11621167, 2017. 1</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_71><loc_47><loc_79></location>[27] Sebastian Schreiber, Stefan Agne, Ivo Wolf, Andreas Dengel, and Sheraz Ahmed. Deepdesrt: Deep learning for detection and structure recognition of tables in document images. In 2017 14th IAPR international conference on document analysis and recognition (ICDAR) , volume 1, pages 1162-1167. IEEE, 2017. 3</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_66><loc_47><loc_71></location>[28] Faisal Shafait and Ray Smith. Table detection in heterogeneous documents. In Proceedings of the 9th IAPR International Workshop on Document Analysis Systems , pages 6572, 2010. 2</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_59><loc_47><loc_65></location>[29] Shoaib Ahmed Siddiqui, Imran Ali Fateh, Syed Tahseen Raza Rizvi, Andreas Dengel, and Sheraz Ahmed. Deeptabstr: Deep learning based table structure recognition. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 1403-1409. IEEE, 2019. 3</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_52><loc_47><loc_58></location>[30] Peter W J Staar, Michele Dolfi, Christoph Auer, and Costas Bekas. Corpus conversion service: A machine learning platform to ingest documents at scale. In Proceedings of the 24th ACM SIGKDD , KDD '18, pages 774-782, New York, NY, USA, 2018. ACM. 1</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_42><loc_47><loc_51></location>[31] Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, Ł ukasz Kaiser, and Illia Polosukhin. Attention is all you need. In I. Guyon, U. V. Luxburg, S. Bengio, H. Wallach, R. Fergus, S. Vishwanathan, and R. Garnett, editors, Advances in Neural Information Processing Systems 30 , pages 5998-6008. Curran Associates, Inc., 2017. 5</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_37><loc_47><loc_42></location>[32] Oriol Vinyals, Alexander Toshev, Samy Bengio, and Dumitru Erhan. Show and tell: A neural image caption generator. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (CVPR) , June 2015. 2</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_31><loc_47><loc_36></location>[33] Wenyuan Xue, Qingyong Li, and Dacheng Tao. Res2tim: reconstruct syntactic structures from table images. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 749-755. IEEE, 2019. 3</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_25><loc_47><loc_31></location>[34] Wenyuan Xue, Baosheng Yu, Wen Wang, Dacheng Tao, and Qingyong Li. Tgrnet: A table graph reconstruction network for table structure recognition. arXiv preprint arXiv:2106.10598 , 2021. 3</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_20><loc_47><loc_25></location>[35] Quanzeng You, Hailin Jin, Zhaowen Wang, Chen Fang, and Jiebo Luo. Image captioning with semantic attention. In Proceedings of the IEEE conference on computer vision and pattern recognition , pages 4651-4659, 2016. 4</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_13><loc_47><loc_19></location>[36] Xinyi Zheng, Doug Burdick, Lucian Popa, Peter Zhong, and Nancy Xin Ru Wang. Global table extractor (gte): A framework for joint table identification and cell structure recognition using visual context. Winter Conference for Applications in Computer Vision (WACV) , 2021. 2, 3</paragraph>
|
||||
<paragraph><location><page_10><loc_8><loc_10><loc_47><loc_12></location>[37] Xu Zhong, Elaheh ShafieiBavani, and Antonio Jimeno Yepes. Image-based table recognition: Data, model,</paragraph>
|
||||
<paragraph><location><page_10><loc_54><loc_85><loc_89><loc_90></location>and evaluation. In Andrea Vedaldi, Horst Bischof, Thomas Brox, and Jan-Michael Frahm, editors, Computer Vision ECCV 2020 , pages 564-580, Cham, 2020. Springer International Publishing. 2, 3, 7</paragraph>
|
||||
<paragraph><location><page_10><loc_50><loc_80><loc_89><loc_85></location>[38] Xu Zhong, Jianbin Tang, and Antonio Jimeno Yepes. Publaynet: Largest dataset ever for document layout analysis. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 1015-1022, 2019. 1</paragraph>
|
||||
<subtitle-level-1><location><page_11><loc_22><loc_83><loc_76><loc_86></location>TableFormer: Table Structure Understanding with Transformers Supplementary Material</subtitle-level-1>
|
||||
<subtitle-level-1><location><page_11><loc_8><loc_78><loc_29><loc_80></location>1. Details on the datasets</subtitle-level-1>
|
||||
<subtitle-level-1><location><page_11><loc_8><loc_76><loc_25><loc_77></location>1.1. Data preparation</subtitle-level-1>
|
||||
@ -265,11 +265,11 @@
|
||||
<subtitle-level-1><location><page_11><loc_8><loc_15><loc_25><loc_16></location>1.2. Synthetic datasets</subtitle-level-1>
|
||||
<paragraph><location><page_11><loc_8><loc_10><loc_47><loc_14></location><location><page_11><loc_50><loc_74><loc_89><loc_79></location>Aiming to train and evaluate our models in a broader spectrum of table data we have synthesized four types of datasets. Each one contains tables with different appear- ances in regard to their size, structure, style and content. Every synthetic dataset contains 150k examples, summing up to 600k synthetic examples. All datasets are divided into Train, Test and Val splits (80%, 10%, 10%).</paragraph>
|
||||
<paragraph><location><page_11><loc_50><loc_71><loc_89><loc_73></location>The process of generating a synthetic dataset can be decomposed into the following steps:</paragraph>
|
||||
<paragraph><location><page_11><loc_50><loc_60><loc_89><loc_70></location>- 1. Prepare styling and content templates: The styling templates have been manually designed and organized into groups of scope specific appearances (e.g. financial data, marketing data, etc.) Additionally, we have prepared curated collections of content templates by extracting the most frequently used terms out of non-synthetic datasets (e.g. PubTabNet, FinTabNet, etc.).</paragraph>
|
||||
<paragraph><location><page_11><loc_50><loc_43><loc_89><loc_60></location>- 2. Generate table structures: The structure of each synthetic dataset assumes a horizontal table header which potentially spans over multiple rows and a table body that may contain a combination of row spans and column spans. However, spans are not allowed to cross the header - body boundary. The table structure is described by the parameters: Total number of table rows and columns, number of header rows, type of spans (header only spans, row only spans, column only spans, both row and column spans), maximum span size and the ratio of the table area covered by spans.</paragraph>
|
||||
<paragraph><location><page_11><loc_50><loc_37><loc_89><loc_43></location>- 3. Generate content: Based on the dataset theme , a set of suitable content templates is chosen first. Then, this content can be combined with purely random text to produce the synthetic content.</paragraph>
|
||||
<paragraph><location><page_11><loc_50><loc_31><loc_89><loc_37></location>- 4. Apply styling templates: Depending on the domain of the synthetic dataset, a set of styling templates is first manually selected. Then, a style is randomly selected to format the appearance of the synthesized table.</paragraph>
|
||||
<paragraph><location><page_11><loc_50><loc_23><loc_89><loc_31></location>- 5. Render the complete tables: The synthetic table is finally rendered by a web browser engine to generate the bounding boxes for each table cell. A batching technique is utilized to optimize the runtime overhead of the rendering process.</paragraph>
|
||||
<paragraph><location><page_11><loc_50><loc_60><loc_89><loc_70></location>1. Prepare styling and content templates: The styling templates have been manually designed and organized into groups of scope specific appearances (e.g. financial data, marketing data, etc.) Additionally, we have prepared curated collections of content templates by extracting the most frequently used terms out of non-synthetic datasets (e.g. PubTabNet, FinTabNet, etc.).</paragraph>
|
||||
<paragraph><location><page_11><loc_50><loc_43><loc_89><loc_60></location>2. Generate table structures: The structure of each synthetic dataset assumes a horizontal table header which potentially spans over multiple rows and a table body that may contain a combination of row spans and column spans. However, spans are not allowed to cross the header - body boundary. The table structure is described by the parameters: Total number of table rows and columns, number of header rows, type of spans (header only spans, row only spans, column only spans, both row and column spans), maximum span size and the ratio of the table area covered by spans.</paragraph>
|
||||
<paragraph><location><page_11><loc_50><loc_37><loc_89><loc_43></location>3. Generate content: Based on the dataset theme , a set of suitable content templates is chosen first. Then, this content can be combined with purely random text to produce the synthetic content.</paragraph>
|
||||
<paragraph><location><page_11><loc_50><loc_31><loc_89><loc_37></location>4. Apply styling templates: Depending on the domain of the synthetic dataset, a set of styling templates is first manually selected. Then, a style is randomly selected to format the appearance of the synthesized table.</paragraph>
|
||||
<paragraph><location><page_11><loc_50><loc_23><loc_89><loc_31></location>5. Render the complete tables: The synthetic table is finally rendered by a web browser engine to generate the bounding boxes for each table cell. A batching technique is utilized to optimize the runtime overhead of the rendering process.</paragraph>
|
||||
<subtitle-level-1><location><page_11><loc_50><loc_18><loc_89><loc_21></location>2. Prediction post-processing for PDF documents</subtitle-level-1>
|
||||
<paragraph><location><page_11><loc_50><loc_10><loc_89><loc_17></location>Although TableFormer can predict the table structure and the bounding boxes for tables recognized inside PDF documents, this is not enough when a full reconstruction of the original table is required. This happens mainly due the following reasons:</paragraph>
|
||||
<figure>
|
||||
@ -277,27 +277,27 @@
|
||||
<caption>Figure 7: Distribution of the tables across different dimensions per dataset. Simple vs complex tables per dataset and split, strict vs non strict html structures per dataset and table complexity, missing bboxes per dataset and table complexity.</caption>
|
||||
</figure>
|
||||
<caption><location><page_12><loc_8><loc_76><loc_89><loc_79></location>Figure 7: Distribution of the tables across different dimensions per dataset. Simple vs complex tables per dataset and split, strict vs non strict html structures per dataset and table complexity, missing bboxes per dataset and table complexity.</caption>
|
||||
<paragraph><location><page_12><loc_10><loc_71><loc_47><loc_73></location>- · TableFormer output does not include the table cell content.</paragraph>
|
||||
<paragraph><location><page_12><loc_10><loc_67><loc_47><loc_69></location>- · There are occasional inaccuracies in the predictions of the bounding boxes.</paragraph>
|
||||
<paragraph><location><page_12><loc_10><loc_71><loc_47><loc_73></location>· TableFormer output does not include the table cell content.</paragraph>
|
||||
<paragraph><location><page_12><loc_10><loc_67><loc_47><loc_69></location>· There are occasional inaccuracies in the predictions of the bounding boxes.</paragraph>
|
||||
<paragraph><location><page_12><loc_50><loc_68><loc_89><loc_73></location>dian cell size for all table cells. The usage of median during the computations, helps to eliminate outliers caused by occasional column spans which are usually wider than the normal.</paragraph>
|
||||
<paragraph><location><page_12><loc_8><loc_50><loc_47><loc_65></location>However, it is possible to mitigate those limitations by combining the TableFormer predictions with the information already present inside a programmatic PDF document. More specifically, PDF documents can be seen as a sequence of PDF cells where each cell is described by its content and bounding box. If we are able to associate the PDF cells with the predicted table cells, we can directly link the PDF cell content to the table cell structure and use the PDF bounding boxes to correct misalignments in the predicted table cell bounding boxes.</paragraph>
|
||||
<paragraph><location><page_12><loc_8><loc_47><loc_47><loc_50></location>Here is a step-by-step description of the prediction postprocessing:</paragraph>
|
||||
<paragraph><location><page_12><loc_8><loc_42><loc_47><loc_47></location>- 1. Get the minimal grid dimensions - number of rows and columns for the predicted table structure. This represents the most granular grid for the underlying table structure.</paragraph>
|
||||
<paragraph><location><page_12><loc_8><loc_36><loc_47><loc_42></location>- 2. Generate pair-wise matches between the bounding boxes of the PDF cells and the predicted cells. The Intersection Over Union (IOU) metric is used to evaluate the quality of the matches.</paragraph>
|
||||
<paragraph><location><page_12><loc_8><loc_33><loc_47><loc_36></location>- 3. Use a carefully selected IOU threshold to designate the matches as "good" ones and "bad" ones.</paragraph>
|
||||
<paragraph><location><page_12><loc_8><loc_29><loc_47><loc_33></location>- 3.a. If all IOU scores in a column are below the threshold, discard all predictions (structure and bounding boxes) for that column.</paragraph>
|
||||
<paragraph><location><page_12><loc_8><loc_24><loc_47><loc_28></location>- 4. Find the best-fitting content alignment for the predicted cells with good IOU per each column. The alignment of the column can be identified by the following formula:</paragraph>
|
||||
<paragraph><location><page_12><loc_8><loc_42><loc_47><loc_47></location>1. Get the minimal grid dimensions - number of rows and columns for the predicted table structure. This represents the most granular grid for the underlying table structure.</paragraph>
|
||||
<paragraph><location><page_12><loc_8><loc_36><loc_47><loc_42></location>2. Generate pair-wise matches between the bounding boxes of the PDF cells and the predicted cells. The Intersection Over Union (IOU) metric is used to evaluate the quality of the matches.</paragraph>
|
||||
<paragraph><location><page_12><loc_8><loc_33><loc_47><loc_36></location>3. Use a carefully selected IOU threshold to designate the matches as "good" ones and "bad" ones.</paragraph>
|
||||
<paragraph><location><page_12><loc_8><loc_29><loc_47><loc_33></location>3.a. If all IOU scores in a column are below the threshold, discard all predictions (structure and bounding boxes) for that column.</paragraph>
|
||||
<paragraph><location><page_12><loc_8><loc_24><loc_47><loc_28></location>4. Find the best-fitting content alignment for the predicted cells with good IOU per each column. The alignment of the column can be identified by the following formula:</paragraph>
|
||||
<paragraph><location><page_12><loc_8><loc_13><loc_47><loc_16></location>where c is one of { left, centroid, right } and x$_{c}$ is the xcoordinate for the corresponding point.</paragraph>
|
||||
<paragraph><location><page_12><loc_8><loc_10><loc_47><loc_13></location>- 5. Use the alignment computed in step 4, to compute the median x -coordinate for all table columns and the me-</paragraph>
|
||||
<paragraph><location><page_12><loc_50><loc_65><loc_89><loc_67></location>- 6. Snap all cells with bad IOU to their corresponding median x -coordinates and cell sizes.</paragraph>
|
||||
<paragraph><location><page_12><loc_50><loc_51><loc_89><loc_64></location>- 7. Generate a new set of pair-wise matches between the corrected bounding boxes and PDF cells. This time use a modified version of the IOU metric, where the area of the intersection between the predicted and PDF cells is divided by the PDF cell area. In case there are multiple matches for the same PDF cell, the prediction with the higher score is preferred. This covers the cases where the PDF cells are smaller than the area of predicted or corrected prediction cells.</paragraph>
|
||||
<paragraph><location><page_12><loc_50><loc_42><loc_89><loc_51></location>- 8. In some rare occasions, we have noticed that TableFormer can confuse a single column as two. When the postprocessing steps are applied, this results with two predicted columns pointing to the same PDF column. In such case we must de-duplicate the columns according to highest total column intersection score.</paragraph>
|
||||
<paragraph><location><page_12><loc_50><loc_28><loc_89><loc_41></location>- 9. Pick up the remaining orphan cells. There could be cases, when after applying all the previous post-processing steps, some PDF cells could still remain without any match to predicted cells. However, it is still possible to deduce the correct matching for an orphan PDF cell by mapping its bounding box on the geometry of the grid. This mapping decides if the content of the orphan cell will be appended to an already matched table cell, or a new table cell should be created to match with the orphan.</paragraph>
|
||||
<paragraph><location><page_12><loc_8><loc_10><loc_47><loc_13></location>5. Use the alignment computed in step 4, to compute the median x -coordinate for all table columns and the me-</paragraph>
|
||||
<paragraph><location><page_12><loc_50><loc_65><loc_89><loc_67></location>6. Snap all cells with bad IOU to their corresponding median x -coordinates and cell sizes.</paragraph>
|
||||
<paragraph><location><page_12><loc_50><loc_51><loc_89><loc_64></location>7. Generate a new set of pair-wise matches between the corrected bounding boxes and PDF cells. This time use a modified version of the IOU metric, where the area of the intersection between the predicted and PDF cells is divided by the PDF cell area. In case there are multiple matches for the same PDF cell, the prediction with the higher score is preferred. This covers the cases where the PDF cells are smaller than the area of predicted or corrected prediction cells.</paragraph>
|
||||
<paragraph><location><page_12><loc_50><loc_42><loc_89><loc_51></location>8. In some rare occasions, we have noticed that TableFormer can confuse a single column as two. When the postprocessing steps are applied, this results with two predicted columns pointing to the same PDF column. In such case we must de-duplicate the columns according to highest total column intersection score.</paragraph>
|
||||
<paragraph><location><page_12><loc_50><loc_28><loc_89><loc_41></location>9. Pick up the remaining orphan cells. There could be cases, when after applying all the previous post-processing steps, some PDF cells could still remain without any match to predicted cells. However, it is still possible to deduce the correct matching for an orphan PDF cell by mapping its bounding box on the geometry of the grid. This mapping decides if the content of the orphan cell will be appended to an already matched table cell, or a new table cell should be created to match with the orphan.</paragraph>
|
||||
<paragraph><location><page_12><loc_50><loc_24><loc_89><loc_28></location>9a. Compute the top and bottom boundary of the horizontal band for each grid row (min/max y coordinates per row).</paragraph>
|
||||
<paragraph><location><page_12><loc_50><loc_21><loc_89><loc_23></location>- 9b. Intersect the orphan's bounding box with the row bands, and map the cell to the closest grid row.</paragraph>
|
||||
<paragraph><location><page_12><loc_50><loc_16><loc_89><loc_20></location>- 9c. Compute the left and right boundary of the vertical band for each grid column (min/max x coordinates per column).</paragraph>
|
||||
<paragraph><location><page_12><loc_50><loc_13><loc_89><loc_16></location>- 9d. Intersect the orphan's bounding box with the column bands, and map the cell to the closest grid column.</paragraph>
|
||||
<paragraph><location><page_12><loc_50><loc_10><loc_89><loc_13></location>- 9e. If the table cell under the identified row and column is not empty, extend its content with the content of the or-</paragraph>
|
||||
<paragraph><location><page_12><loc_50><loc_21><loc_89><loc_23></location>9b. Intersect the orphan's bounding box with the row bands, and map the cell to the closest grid row.</paragraph>
|
||||
<paragraph><location><page_12><loc_50><loc_16><loc_89><loc_20></location>9c. Compute the left and right boundary of the vertical band for each grid column (min/max x coordinates per column).</paragraph>
|
||||
<paragraph><location><page_12><loc_50><loc_13><loc_89><loc_16></location>9d. Intersect the orphan's bounding box with the column bands, and map the cell to the closest grid column.</paragraph>
|
||||
<paragraph><location><page_12><loc_50><loc_10><loc_89><loc_13></location>9e. If the table cell under the identified row and column is not empty, extend its content with the content of the or-</paragraph>
|
||||
<paragraph><location><page_13><loc_8><loc_89><loc_15><loc_91></location>phan cell.</paragraph>
|
||||
<paragraph><location><page_13><loc_8><loc_86><loc_47><loc_89></location>9f. Otherwise create a new structural cell and match it wit the orphan cell.</paragraph>
|
||||
<paragraph><location><page_13><loc_8><loc_83><loc_47><loc_86></location>Aditional images with examples of TableFormer predictions and post-processing can be found below.</paragraph>
|
||||
|
138
tests/data/groundtruth/docling_v1/2203.01017v2.json
vendored
138
tests/data/groundtruth/docling_v1/2203.01017v2.json
vendored
@ -326,7 +326,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- b. Red-annotation of bounding boxes, Blue-predictions by TableFormer",
|
||||
"text": "b. Red-annotation of bounding boxes, Blue-predictions by TableFormer",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -349,7 +349,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- c. Structure predicted by TableFormer:",
|
||||
"text": "c. Structure predicted by TableFormer:",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -548,7 +548,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 We propose TableFormer , a transformer based model that predicts tables structure and bounding boxes for the table content simultaneously in an end-to-end approach.",
|
||||
"text": "\u00b7 We propose TableFormer , a transformer based model that predicts tables structure and bounding boxes for the table content simultaneously in an end-to-end approach.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -571,7 +571,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 Across all benchmark datasets TableFormer significantly outperforms existing state-of-the-art metrics, while being much more efficient in training and inference to existing works.",
|
||||
"text": "\u00b7 Across all benchmark datasets TableFormer significantly outperforms existing state-of-the-art metrics, while being much more efficient in training and inference to existing works.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -594,7 +594,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 We present SynthTabNet a synthetically generated dataset, with various appearance styles and complexity.",
|
||||
"text": "\u00b7 We present SynthTabNet a synthetically generated dataset, with various appearance styles and complexity.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -617,7 +617,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 An augmented dataset based on PubTabNet [37], FinTabNet [36], and TableBank [17] with generated ground-truth for reproducibility.",
|
||||
"text": "\u00b7 An augmented dataset based on PubTabNet [37], FinTabNet [36], and TableBank [17] with generated ground-truth for reproducibility.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2221,7 +2221,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- a.",
|
||||
"text": "a.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2244,7 +2244,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- Red - PDF cells, Green - predicted bounding boxes, Blue - post-processed predictions matched to PDF cells",
|
||||
"text": "Red - PDF cells, Green - predicted bounding boxes, Blue - post-processed predictions matched to PDF cells",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2555,7 +2555,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [1] Nicolas Carion, Francisco Massa, Gabriel Synnaeve, Nicolas Usunier, Alexander Kirillov, and Sergey Zagoruyko. End-to-",
|
||||
"text": "[1] Nicolas Carion, Francisco Massa, Gabriel Synnaeve, Nicolas Usunier, Alexander Kirillov, and Sergey Zagoruyko. End-to-",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2578,7 +2578,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- end object detection with transformers. In Andrea Vedaldi, Horst Bischof, Thomas Brox, and Jan-Michael Frahm, editors, Computer Vision - ECCV 2020 , pages 213-229, Cham, 2020. Springer International Publishing. 5",
|
||||
"text": "end object detection with transformers. In Andrea Vedaldi, Horst Bischof, Thomas Brox, and Jan-Michael Frahm, editors, Computer Vision - ECCV 2020 , pages 213-229, Cham, 2020. Springer International Publishing. 5",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2601,7 +2601,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [2] Zewen Chi, Heyan Huang, Heng-Da Xu, Houjin Yu, Wanxuan Yin, and Xian-Ling Mao. Complicated table structure recognition. arXiv preprint arXiv:1908.04729 , 2019. 3",
|
||||
"text": "[2] Zewen Chi, Heyan Huang, Heng-Da Xu, Houjin Yu, Wanxuan Yin, and Xian-Ling Mao. Complicated table structure recognition. arXiv preprint arXiv:1908.04729 , 2019. 3",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2624,7 +2624,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [3] Bertrand Couasnon and Aurelie Lemaitre. Recognition of Tables and Forms , pages 647-677. Springer London, London, 2014. 2",
|
||||
"text": "[3] Bertrand Couasnon and Aurelie Lemaitre. Recognition of Tables and Forms , pages 647-677. Springer London, London, 2014. 2",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2647,7 +2647,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [4] Herv\u00b4e D\u00b4ejean, Jean-Luc Meunier, Liangcai Gao, Yilun Huang, Yu Fang, Florian Kleber, and Eva-Maria Lang. ICDAR 2019 Competition on Table Detection and Recognition (cTDaR), Apr. 2019. http://sac.founderit.com/. 2",
|
||||
"text": "[4] Herv\u00b4e D\u00b4ejean, Jean-Luc Meunier, Liangcai Gao, Yilun Huang, Yu Fang, Florian Kleber, and Eva-Maria Lang. ICDAR 2019 Competition on Table Detection and Recognition (cTDaR), Apr. 2019. http://sac.founderit.com/. 2",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2670,7 +2670,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [5] Basilios Gatos, Dimitrios Danatsas, Ioannis Pratikakis, and Stavros J Perantonis. Automatic table detection in document images. In International Conference on Pattern Recognition and Image Analysis , pages 609-618. Springer, 2005. 2",
|
||||
"text": "[5] Basilios Gatos, Dimitrios Danatsas, Ioannis Pratikakis, and Stavros J Perantonis. Automatic table detection in document images. In International Conference on Pattern Recognition and Image Analysis , pages 609-618. Springer, 2005. 2",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2693,7 +2693,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [6] Max G\u00a8obel, Tamir Hassan, Ermelinda Oro, and Giorgio Orsi. Icdar 2013 table competition. In 2013 12th International Conference on Document Analysis and Recognition , pages 1449-1453, 2013. 2",
|
||||
"text": "[6] Max G\u00a8obel, Tamir Hassan, Ermelinda Oro, and Giorgio Orsi. Icdar 2013 table competition. In 2013 12th International Conference on Document Analysis and Recognition , pages 1449-1453, 2013. 2",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2716,7 +2716,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [7] EA Green and M Krishnamoorthy. Recognition of tables using table grammars. procs. In Symposium on Document Analysis and Recognition (SDAIR'95) , pages 261-277. 2",
|
||||
"text": "[7] EA Green and M Krishnamoorthy. Recognition of tables using table grammars. procs. In Symposium on Document Analysis and Recognition (SDAIR'95) , pages 261-277. 2",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2739,7 +2739,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [8] Khurram Azeem Hashmi, Alain Pagani, Marcus Liwicki, Didier Stricker, and Muhammad Zeshan Afzal. Castabdetectors: Cascade network for table detection in document images with recursive feature pyramid and switchable atrous convolution. Journal of Imaging , 7(10), 2021. 1",
|
||||
"text": "[8] Khurram Azeem Hashmi, Alain Pagani, Marcus Liwicki, Didier Stricker, and Muhammad Zeshan Afzal. Castabdetectors: Cascade network for table detection in document images with recursive feature pyramid and switchable atrous convolution. Journal of Imaging , 7(10), 2021. 1",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2762,7 +2762,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [9] Kaiming He, Georgia Gkioxari, Piotr Dollar, and Ross Girshick. Mask r-cnn. In Proceedings of the IEEE International Conference on Computer Vision (ICCV) , Oct 2017. 1",
|
||||
"text": "[9] Kaiming He, Georgia Gkioxari, Piotr Dollar, and Ross Girshick. Mask r-cnn. In Proceedings of the IEEE International Conference on Computer Vision (ICCV) , Oct 2017. 1",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2785,7 +2785,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [10] Yelin He, X. Qi, Jiaquan Ye, Peng Gao, Yihao Chen, Bingcong Li, Xin Tang, and Rong Xiao. Pingan-vcgroup's solution for icdar 2021 competition on scientific table image recognition to latex. ArXiv , abs/2105.01846, 2021. 2",
|
||||
"text": "[10] Yelin He, X. Qi, Jiaquan Ye, Peng Gao, Yihao Chen, Bingcong Li, Xin Tang, and Rong Xiao. Pingan-vcgroup's solution for icdar 2021 competition on scientific table image recognition to latex. ArXiv , abs/2105.01846, 2021. 2",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2808,7 +2808,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [11] Jianying Hu, Ramanujan S Kashi, Daniel P Lopresti, and Gordon Wilfong. Medium-independent table detection. In Document Recognition and Retrieval VII , volume 3967, pages 291-302. International Society for Optics and Photonics, 1999. 2",
|
||||
"text": "[11] Jianying Hu, Ramanujan S Kashi, Daniel P Lopresti, and Gordon Wilfong. Medium-independent table detection. In Document Recognition and Retrieval VII , volume 3967, pages 291-302. International Society for Optics and Photonics, 1999. 2",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2831,7 +2831,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [12] Matthew Hurst. A constraint-based approach to table structure derivation. In Proceedings of the Seventh International Conference on Document Analysis and Recognition - Volume 2 , ICDAR '03, page 911, USA, 2003. IEEE Computer Society. 2",
|
||||
"text": "[12] Matthew Hurst. A constraint-based approach to table structure derivation. In Proceedings of the Seventh International Conference on Document Analysis and Recognition - Volume 2 , ICDAR '03, page 911, USA, 2003. IEEE Computer Society. 2",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2854,7 +2854,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [13] Thotreingam Kasar, Philippine Barlas, Sebastien Adam, Cl\u00b4ement Chatelain, and Thierry Paquet. Learning to detect tables in scanned document images using line information. In 2013 12th International Conference on Document Analysis and Recognition , pages 1185-1189. IEEE, 2013. 2",
|
||||
"text": "[13] Thotreingam Kasar, Philippine Barlas, Sebastien Adam, Cl\u00b4ement Chatelain, and Thierry Paquet. Learning to detect tables in scanned document images using line information. In 2013 12th International Conference on Document Analysis and Recognition , pages 1185-1189. IEEE, 2013. 2",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2877,7 +2877,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [14] Pratik Kayal, Mrinal Anand, Harsh Desai, and Mayank Singh. Icdar 2021 competition on scientific table image recognition to latex, 2021. 2",
|
||||
"text": "[14] Pratik Kayal, Mrinal Anand, Harsh Desai, and Mayank Singh. Icdar 2021 competition on scientific table image recognition to latex, 2021. 2",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2900,7 +2900,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [15] Harold W Kuhn. The hungarian method for the assignment problem. Naval research logistics quarterly , 2(1-2):83-97, 1955. 6",
|
||||
"text": "[15] Harold W Kuhn. The hungarian method for the assignment problem. Naval research logistics quarterly , 2(1-2):83-97, 1955. 6",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2923,7 +2923,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [16] Girish Kulkarni, Visruth Premraj, Vicente Ordonez, Sagnik Dhar, Siming Li, Yejin Choi, Alexander C. Berg, and Tamara L. Berg. Babytalk: Understanding and generating simple image descriptions. IEEE Transactions on Pattern Analysis and Machine Intelligence , 35(12):2891-2903, 2013. 4",
|
||||
"text": "[16] Girish Kulkarni, Visruth Premraj, Vicente Ordonez, Sagnik Dhar, Siming Li, Yejin Choi, Alexander C. Berg, and Tamara L. Berg. Babytalk: Understanding and generating simple image descriptions. IEEE Transactions on Pattern Analysis and Machine Intelligence , 35(12):2891-2903, 2013. 4",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2946,7 +2946,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [17] Minghao Li, Lei Cui, Shaohan Huang, Furu Wei, Ming Zhou, and Zhoujun Li. Tablebank: A benchmark dataset for table detection and recognition, 2019. 2, 3",
|
||||
"text": "[17] Minghao Li, Lei Cui, Shaohan Huang, Furu Wei, Ming Zhou, and Zhoujun Li. Tablebank: A benchmark dataset for table detection and recognition, 2019. 2, 3",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2969,7 +2969,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [18] Yiren Li, Zheng Huang, Junchi Yan, Yi Zhou, Fan Ye, and Xianhui Liu. Gfte: Graph-based financial table extraction. In Alberto Del Bimbo, Rita Cucchiara, Stan Sclaroff, Giovanni Maria Farinella, Tao Mei, Marco Bertini, Hugo Jair Escalante, and Roberto Vezzani, editors, Pattern Recognition. ICPR International Workshops and Challenges , pages 644-658, Cham, 2021. Springer International Publishing. 2, 3",
|
||||
"text": "[18] Yiren Li, Zheng Huang, Junchi Yan, Yi Zhou, Fan Ye, and Xianhui Liu. Gfte: Graph-based financial table extraction. In Alberto Del Bimbo, Rita Cucchiara, Stan Sclaroff, Giovanni Maria Farinella, Tao Mei, Marco Bertini, Hugo Jair Escalante, and Roberto Vezzani, editors, Pattern Recognition. ICPR International Workshops and Challenges , pages 644-658, Cham, 2021. Springer International Publishing. 2, 3",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2992,7 +2992,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [19] Nikolaos Livathinos, Cesar Berrospi, Maksym Lysak, Viktor Kuropiatnyk, Ahmed Nassar, Andre Carvalho, Michele Dolfi, Christoph Auer, Kasper Dinkla, and Peter Staar. Robust pdf document conversion using recurrent neural networks. Proceedings of the AAAI Conference on Artificial Intelligence , 35(17):15137-15145, May 2021. 1",
|
||||
"text": "[19] Nikolaos Livathinos, Cesar Berrospi, Maksym Lysak, Viktor Kuropiatnyk, Ahmed Nassar, Andre Carvalho, Michele Dolfi, Christoph Auer, Kasper Dinkla, and Peter Staar. Robust pdf document conversion using recurrent neural networks. Proceedings of the AAAI Conference on Artificial Intelligence , 35(17):15137-15145, May 2021. 1",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3015,7 +3015,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [20] Rujiao Long, Wen Wang, Nan Xue, Feiyu Gao, Zhibo Yang, Yongpan Wang, and Gui-Song Xia. Parsing table structures in the wild. In Proceedings of the IEEE/CVF International Conference on Computer Vision , pages 944-952, 2021. 2",
|
||||
"text": "[20] Rujiao Long, Wen Wang, Nan Xue, Feiyu Gao, Zhibo Yang, Yongpan Wang, and Gui-Song Xia. Parsing table structures in the wild. In Proceedings of the IEEE/CVF International Conference on Computer Vision , pages 944-952, 2021. 2",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3038,7 +3038,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [21] Shubham Singh Paliwal, D Vishwanath, Rohit Rahul, Monika Sharma, and Lovekesh Vig. Tablenet: Deep learning model for end-to-end table detection and tabular data extraction from scanned document images. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 128-133. IEEE, 2019. 1",
|
||||
"text": "[21] Shubham Singh Paliwal, D Vishwanath, Rohit Rahul, Monika Sharma, and Lovekesh Vig. Tablenet: Deep learning model for end-to-end table detection and tabular data extraction from scanned document images. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 128-133. IEEE, 2019. 1",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3061,7 +3061,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [22] Adam Paszke, Sam Gross, Francisco Massa, Adam Lerer, James Bradbury, Gregory Chanan, Trevor Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga, Alban Desmaison, Andreas Kopf, Edward Yang, Zachary DeVito, Martin Raison, Alykhan Tejani, Sasank Chilamkurthy, Benoit Steiner, Lu Fang, Junjie Bai, and Soumith Chintala. Pytorch: An imperative style, high-performance deep learning library. In H. Wallach, H. Larochelle, A. Beygelzimer, F. d'Alch\u00b4e-Buc, E. Fox, and R. Garnett, editors, Advances in Neural Information Processing Systems 32 , pages 8024-8035. Curran Associates, Inc., 2019. 6",
|
||||
"text": "[22] Adam Paszke, Sam Gross, Francisco Massa, Adam Lerer, James Bradbury, Gregory Chanan, Trevor Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga, Alban Desmaison, Andreas Kopf, Edward Yang, Zachary DeVito, Martin Raison, Alykhan Tejani, Sasank Chilamkurthy, Benoit Steiner, Lu Fang, Junjie Bai, and Soumith Chintala. Pytorch: An imperative style, high-performance deep learning library. In H. Wallach, H. Larochelle, A. Beygelzimer, F. d'Alch\u00b4e-Buc, E. Fox, and R. Garnett, editors, Advances in Neural Information Processing Systems 32 , pages 8024-8035. Curran Associates, Inc., 2019. 6",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3084,7 +3084,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [23] Devashish Prasad, Ayan Gadpal, Kshitij Kapadni, Manish Visave, and Kavita Sultanpure. Cascadetabnet: An approach for end to end table detection and structure recognition from image-based documents. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition Workshops , pages 572-573, 2020. 1",
|
||||
"text": "[23] Devashish Prasad, Ayan Gadpal, Kshitij Kapadni, Manish Visave, and Kavita Sultanpure. Cascadetabnet: An approach for end to end table detection and structure recognition from image-based documents. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition Workshops , pages 572-573, 2020. 1",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3107,7 +3107,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [24] Shah Rukh Qasim, Hassan Mahmood, and Faisal Shafait. Rethinking table recognition using graph neural networks. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 142-147. IEEE, 2019. 3",
|
||||
"text": "[24] Shah Rukh Qasim, Hassan Mahmood, and Faisal Shafait. Rethinking table recognition using graph neural networks. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 142-147. IEEE, 2019. 3",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3130,7 +3130,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [25] Hamid Rezatofighi, Nathan Tsoi, JunYoung Gwak, Amir Sadeghian, Ian Reid, and Silvio Savarese. Generalized intersection over union: A metric and a loss for bounding box regression. In Proceedings of the IEEE/CVF Conference on",
|
||||
"text": "[25] Hamid Rezatofighi, Nathan Tsoi, JunYoung Gwak, Amir Sadeghian, Ian Reid, and Silvio Savarese. Generalized intersection over union: A metric and a loss for bounding box regression. In Proceedings of the IEEE/CVF Conference on",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3176,7 +3176,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [26] Sebastian Schreiber, Stefan Agne, Ivo Wolf, Andreas Dengel, and Sheraz Ahmed. Deepdesrt: Deep learning for detection and structure recognition of tables in document images. In 2017 14th IAPR International Conference on Document Analysis and Recognition (ICDAR) , volume 01, pages 11621167, 2017. 1",
|
||||
"text": "[26] Sebastian Schreiber, Stefan Agne, Ivo Wolf, Andreas Dengel, and Sheraz Ahmed. Deepdesrt: Deep learning for detection and structure recognition of tables in document images. In 2017 14th IAPR International Conference on Document Analysis and Recognition (ICDAR) , volume 01, pages 11621167, 2017. 1",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3199,7 +3199,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [27] Sebastian Schreiber, Stefan Agne, Ivo Wolf, Andreas Dengel, and Sheraz Ahmed. Deepdesrt: Deep learning for detection and structure recognition of tables in document images. In 2017 14th IAPR international conference on document analysis and recognition (ICDAR) , volume 1, pages 1162-1167. IEEE, 2017. 3",
|
||||
"text": "[27] Sebastian Schreiber, Stefan Agne, Ivo Wolf, Andreas Dengel, and Sheraz Ahmed. Deepdesrt: Deep learning for detection and structure recognition of tables in document images. In 2017 14th IAPR international conference on document analysis and recognition (ICDAR) , volume 1, pages 1162-1167. IEEE, 2017. 3",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3222,7 +3222,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [28] Faisal Shafait and Ray Smith. Table detection in heterogeneous documents. In Proceedings of the 9th IAPR International Workshop on Document Analysis Systems , pages 6572, 2010. 2",
|
||||
"text": "[28] Faisal Shafait and Ray Smith. Table detection in heterogeneous documents. In Proceedings of the 9th IAPR International Workshop on Document Analysis Systems , pages 6572, 2010. 2",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3245,7 +3245,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [29] Shoaib Ahmed Siddiqui, Imran Ali Fateh, Syed Tahseen Raza Rizvi, Andreas Dengel, and Sheraz Ahmed. Deeptabstr: Deep learning based table structure recognition. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 1403-1409. IEEE, 2019. 3",
|
||||
"text": "[29] Shoaib Ahmed Siddiqui, Imran Ali Fateh, Syed Tahseen Raza Rizvi, Andreas Dengel, and Sheraz Ahmed. Deeptabstr: Deep learning based table structure recognition. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 1403-1409. IEEE, 2019. 3",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3268,7 +3268,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [30] Peter W J Staar, Michele Dolfi, Christoph Auer, and Costas Bekas. Corpus conversion service: A machine learning platform to ingest documents at scale. In Proceedings of the 24th ACM SIGKDD , KDD '18, pages 774-782, New York, NY, USA, 2018. ACM. 1",
|
||||
"text": "[30] Peter W J Staar, Michele Dolfi, Christoph Auer, and Costas Bekas. Corpus conversion service: A machine learning platform to ingest documents at scale. In Proceedings of the 24th ACM SIGKDD , KDD '18, pages 774-782, New York, NY, USA, 2018. ACM. 1",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3291,7 +3291,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [31] Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, \u0141 ukasz Kaiser, and Illia Polosukhin. Attention is all you need. In I. Guyon, U. V. Luxburg, S. Bengio, H. Wallach, R. Fergus, S. Vishwanathan, and R. Garnett, editors, Advances in Neural Information Processing Systems 30 , pages 5998-6008. Curran Associates, Inc., 2017. 5",
|
||||
"text": "[31] Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, \u0141 ukasz Kaiser, and Illia Polosukhin. Attention is all you need. In I. Guyon, U. V. Luxburg, S. Bengio, H. Wallach, R. Fergus, S. Vishwanathan, and R. Garnett, editors, Advances in Neural Information Processing Systems 30 , pages 5998-6008. Curran Associates, Inc., 2017. 5",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3314,7 +3314,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [32] Oriol Vinyals, Alexander Toshev, Samy Bengio, and Dumitru Erhan. Show and tell: A neural image caption generator. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (CVPR) , June 2015. 2",
|
||||
"text": "[32] Oriol Vinyals, Alexander Toshev, Samy Bengio, and Dumitru Erhan. Show and tell: A neural image caption generator. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (CVPR) , June 2015. 2",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3337,7 +3337,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [33] Wenyuan Xue, Qingyong Li, and Dacheng Tao. Res2tim: reconstruct syntactic structures from table images. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 749-755. IEEE, 2019. 3",
|
||||
"text": "[33] Wenyuan Xue, Qingyong Li, and Dacheng Tao. Res2tim: reconstruct syntactic structures from table images. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 749-755. IEEE, 2019. 3",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3360,7 +3360,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [34] Wenyuan Xue, Baosheng Yu, Wen Wang, Dacheng Tao, and Qingyong Li. Tgrnet: A table graph reconstruction network for table structure recognition. arXiv preprint arXiv:2106.10598 , 2021. 3",
|
||||
"text": "[34] Wenyuan Xue, Baosheng Yu, Wen Wang, Dacheng Tao, and Qingyong Li. Tgrnet: A table graph reconstruction network for table structure recognition. arXiv preprint arXiv:2106.10598 , 2021. 3",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3383,7 +3383,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [35] Quanzeng You, Hailin Jin, Zhaowen Wang, Chen Fang, and Jiebo Luo. Image captioning with semantic attention. In Proceedings of the IEEE conference on computer vision and pattern recognition , pages 4651-4659, 2016. 4",
|
||||
"text": "[35] Quanzeng You, Hailin Jin, Zhaowen Wang, Chen Fang, and Jiebo Luo. Image captioning with semantic attention. In Proceedings of the IEEE conference on computer vision and pattern recognition , pages 4651-4659, 2016. 4",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3406,7 +3406,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [36] Xinyi Zheng, Doug Burdick, Lucian Popa, Peter Zhong, and Nancy Xin Ru Wang. Global table extractor (gte): A framework for joint table identification and cell structure recognition using visual context. Winter Conference for Applications in Computer Vision (WACV) , 2021. 2, 3",
|
||||
"text": "[36] Xinyi Zheng, Doug Burdick, Lucian Popa, Peter Zhong, and Nancy Xin Ru Wang. Global table extractor (gte): A framework for joint table identification and cell structure recognition using visual context. Winter Conference for Applications in Computer Vision (WACV) , 2021. 2, 3",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3429,7 +3429,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [37] Xu Zhong, Elaheh ShafieiBavani, and Antonio Jimeno Yepes. Image-based table recognition: Data, model,",
|
||||
"text": "[37] Xu Zhong, Elaheh ShafieiBavani, and Antonio Jimeno Yepes. Image-based table recognition: Data, model,",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3452,7 +3452,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- and evaluation. In Andrea Vedaldi, Horst Bischof, Thomas Brox, and Jan-Michael Frahm, editors, Computer Vision ECCV 2020 , pages 564-580, Cham, 2020. Springer International Publishing. 2, 3, 7",
|
||||
"text": "and evaluation. In Andrea Vedaldi, Horst Bischof, Thomas Brox, and Jan-Michael Frahm, editors, Computer Vision ECCV 2020 , pages 564-580, Cham, 2020. Springer International Publishing. 2, 3, 7",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3475,7 +3475,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [38] Xu Zhong, Jianbin Tang, and Antonio Jimeno Yepes. Publaynet: Largest dataset ever for document layout analysis. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 1015-1022, 2019. 1",
|
||||
"text": "[38] Xu Zhong, Jianbin Tang, and Antonio Jimeno Yepes. Publaynet: Largest dataset ever for document layout analysis. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 1015-1022, 2019. 1",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3719,7 +3719,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 1. Prepare styling and content templates: The styling templates have been manually designed and organized into groups of scope specific appearances (e.g. financial data, marketing data, etc.) Additionally, we have prepared curated collections of content templates by extracting the most frequently used terms out of non-synthetic datasets (e.g. PubTabNet, FinTabNet, etc.).",
|
||||
"text": "1. Prepare styling and content templates: The styling templates have been manually designed and organized into groups of scope specific appearances (e.g. financial data, marketing data, etc.) Additionally, we have prepared curated collections of content templates by extracting the most frequently used terms out of non-synthetic datasets (e.g. PubTabNet, FinTabNet, etc.).",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3742,7 +3742,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 2. Generate table structures: The structure of each synthetic dataset assumes a horizontal table header which potentially spans over multiple rows and a table body that may contain a combination of row spans and column spans. However, spans are not allowed to cross the header - body boundary. The table structure is described by the parameters: Total number of table rows and columns, number of header rows, type of spans (header only spans, row only spans, column only spans, both row and column spans), maximum span size and the ratio of the table area covered by spans.",
|
||||
"text": "2. Generate table structures: The structure of each synthetic dataset assumes a horizontal table header which potentially spans over multiple rows and a table body that may contain a combination of row spans and column spans. However, spans are not allowed to cross the header - body boundary. The table structure is described by the parameters: Total number of table rows and columns, number of header rows, type of spans (header only spans, row only spans, column only spans, both row and column spans), maximum span size and the ratio of the table area covered by spans.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3765,7 +3765,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 3. Generate content: Based on the dataset theme , a set of suitable content templates is chosen first. Then, this content can be combined with purely random text to produce the synthetic content.",
|
||||
"text": "3. Generate content: Based on the dataset theme , a set of suitable content templates is chosen first. Then, this content can be combined with purely random text to produce the synthetic content.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3788,7 +3788,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 4. Apply styling templates: Depending on the domain of the synthetic dataset, a set of styling templates is first manually selected. Then, a style is randomly selected to format the appearance of the synthesized table.",
|
||||
"text": "4. Apply styling templates: Depending on the domain of the synthetic dataset, a set of styling templates is first manually selected. Then, a style is randomly selected to format the appearance of the synthesized table.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3811,7 +3811,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 5. Render the complete tables: The synthetic table is finally rendered by a web browser engine to generate the bounding boxes for each table cell. A batching technique is utilized to optimize the runtime overhead of the rendering process.",
|
||||
"text": "5. Render the complete tables: The synthetic table is finally rendered by a web browser engine to generate the bounding boxes for each table cell. A batching technique is utilized to optimize the runtime overhead of the rendering process.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3908,7 +3908,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 TableFormer output does not include the table cell content.",
|
||||
"text": "\u00b7 TableFormer output does not include the table cell content.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3931,7 +3931,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 There are occasional inaccuracies in the predictions of the bounding boxes.",
|
||||
"text": "\u00b7 There are occasional inaccuracies in the predictions of the bounding boxes.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -4023,7 +4023,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 1. Get the minimal grid dimensions - number of rows and columns for the predicted table structure. This represents the most granular grid for the underlying table structure.",
|
||||
"text": "1. Get the minimal grid dimensions - number of rows and columns for the predicted table structure. This represents the most granular grid for the underlying table structure.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -4046,7 +4046,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 2. Generate pair-wise matches between the bounding boxes of the PDF cells and the predicted cells. The Intersection Over Union (IOU) metric is used to evaluate the quality of the matches.",
|
||||
"text": "2. Generate pair-wise matches between the bounding boxes of the PDF cells and the predicted cells. The Intersection Over Union (IOU) metric is used to evaluate the quality of the matches.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -4069,7 +4069,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 3. Use a carefully selected IOU threshold to designate the matches as \"good\" ones and \"bad\" ones.",
|
||||
"text": "3. Use a carefully selected IOU threshold to designate the matches as \"good\" ones and \"bad\" ones.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -4092,7 +4092,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 3.a. If all IOU scores in a column are below the threshold, discard all predictions (structure and bounding boxes) for that column.",
|
||||
"text": "3.a. If all IOU scores in a column are below the threshold, discard all predictions (structure and bounding boxes) for that column.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -4115,7 +4115,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 4. Find the best-fitting content alignment for the predicted cells with good IOU per each column. The alignment of the column can be identified by the following formula:",
|
||||
"text": "4. Find the best-fitting content alignment for the predicted cells with good IOU per each column. The alignment of the column can be identified by the following formula:",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -4184,7 +4184,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 5. Use the alignment computed in step 4, to compute the median x -coordinate for all table columns and the me-",
|
||||
"text": "5. Use the alignment computed in step 4, to compute the median x -coordinate for all table columns and the me-",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -4207,7 +4207,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 6. Snap all cells with bad IOU to their corresponding median x -coordinates and cell sizes.",
|
||||
"text": "6. Snap all cells with bad IOU to their corresponding median x -coordinates and cell sizes.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -4230,7 +4230,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 7. Generate a new set of pair-wise matches between the corrected bounding boxes and PDF cells. This time use a modified version of the IOU metric, where the area of the intersection between the predicted and PDF cells is divided by the PDF cell area. In case there are multiple matches for the same PDF cell, the prediction with the higher score is preferred. This covers the cases where the PDF cells are smaller than the area of predicted or corrected prediction cells.",
|
||||
"text": "7. Generate a new set of pair-wise matches between the corrected bounding boxes and PDF cells. This time use a modified version of the IOU metric, where the area of the intersection between the predicted and PDF cells is divided by the PDF cell area. In case there are multiple matches for the same PDF cell, the prediction with the higher score is preferred. This covers the cases where the PDF cells are smaller than the area of predicted or corrected prediction cells.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -4253,7 +4253,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 8. In some rare occasions, we have noticed that TableFormer can confuse a single column as two. When the postprocessing steps are applied, this results with two predicted columns pointing to the same PDF column. In such case we must de-duplicate the columns according to highest total column intersection score.",
|
||||
"text": "8. In some rare occasions, we have noticed that TableFormer can confuse a single column as two. When the postprocessing steps are applied, this results with two predicted columns pointing to the same PDF column. In such case we must de-duplicate the columns according to highest total column intersection score.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -4276,7 +4276,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 9. Pick up the remaining orphan cells. There could be cases, when after applying all the previous post-processing steps, some PDF cells could still remain without any match to predicted cells. However, it is still possible to deduce the correct matching for an orphan PDF cell by mapping its bounding box on the geometry of the grid. This mapping decides if the content of the orphan cell will be appended to an already matched table cell, or a new table cell should be created to match with the orphan.",
|
||||
"text": "9. Pick up the remaining orphan cells. There could be cases, when after applying all the previous post-processing steps, some PDF cells could still remain without any match to predicted cells. However, it is still possible to deduce the correct matching for an orphan PDF cell by mapping its bounding box on the geometry of the grid. This mapping decides if the content of the orphan cell will be appended to an already matched table cell, or a new table cell should be created to match with the orphan.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -4322,7 +4322,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 9b. Intersect the orphan's bounding box with the row bands, and map the cell to the closest grid row.",
|
||||
"text": "9b. Intersect the orphan's bounding box with the row bands, and map the cell to the closest grid row.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -4345,7 +4345,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 9c. Compute the left and right boundary of the vertical band for each grid column (min/max x coordinates per column).",
|
||||
"text": "9c. Compute the left and right boundary of the vertical band for each grid column (min/max x coordinates per column).",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -4368,7 +4368,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 9d. Intersect the orphan's bounding box with the column bands, and map the cell to the closest grid column.",
|
||||
"text": "9d. Intersect the orphan's bounding box with the column bands, and map the cell to the closest grid column.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -4391,7 +4391,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 9e. If the table cell under the identified row and column is not empty, extend its content with the content of the or-",
|
||||
"text": "9e. If the table cell under the identified row and column is not empty, extend its content with the content of the or-",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
|
138
tests/data/groundtruth/docling_v1/2203.01017v2.md
vendored
138
tests/data/groundtruth/docling_v1/2203.01017v2.md
vendored
@ -16,9 +16,9 @@ The occurrence of tables in documents is ubiquitous. They often summarise quanti
|
||||
|
||||
<!-- image -->
|
||||
|
||||
- b. Red-annotation of bounding boxes, Blue-predictions by TableFormer
|
||||
b. Red-annotation of bounding boxes, Blue-predictions by TableFormer
|
||||
|
||||
- c. Structure predicted by TableFormer:
|
||||
c. Structure predicted by TableFormer:
|
||||
|
||||
<!-- image -->
|
||||
|
||||
@ -44,13 +44,13 @@ In this paper, we want to address these weaknesses and present a robust table-st
|
||||
|
||||
To meet the design criteria listed above, we developed a new model called TableFormer and a synthetically generated table structure dataset called SynthTabNet $^{1}$. In particular, our contributions in this work can be summarised as follows:
|
||||
|
||||
- · We propose TableFormer , a transformer based model that predicts tables structure and bounding boxes for the table content simultaneously in an end-to-end approach.
|
||||
· We propose TableFormer , a transformer based model that predicts tables structure and bounding boxes for the table content simultaneously in an end-to-end approach.
|
||||
|
||||
- · Across all benchmark datasets TableFormer significantly outperforms existing state-of-the-art metrics, while being much more efficient in training and inference to existing works.
|
||||
· Across all benchmark datasets TableFormer significantly outperforms existing state-of-the-art metrics, while being much more efficient in training and inference to existing works.
|
||||
|
||||
- · We present SynthTabNet a synthetically generated dataset, with various appearance styles and complexity.
|
||||
· We present SynthTabNet a synthetically generated dataset, with various appearance styles and complexity.
|
||||
|
||||
- · An augmented dataset based on PubTabNet [37], FinTabNet [36], and TableBank [17] with generated ground-truth for reproducibility.
|
||||
· An augmented dataset based on PubTabNet [37], FinTabNet [36], and TableBank [17] with generated ground-truth for reproducibility.
|
||||
|
||||
The paper is structured as follows. In Sec. 2, we give a brief overview of the current state-of-the-art. In Sec. 3, we describe the datasets on which we train. In Sec. 4, we introduce the TableFormer model-architecture and describe
|
||||
|
||||
@ -216,9 +216,9 @@ Table 4: Results of structure with content retrieved using cell detection on Pub
|
||||
| EDD | 91.2 | 85.4 | 88.3 |
|
||||
| TableFormer | 95.4 | 90.1 | 93.6 |
|
||||
|
||||
- a.
|
||||
a.
|
||||
|
||||
- Red - PDF cells, Green - predicted bounding boxes, Blue - post-processed predictions matched to PDF cells
|
||||
Red - PDF cells, Green - predicted bounding boxes, Blue - post-processed predictions matched to PDF cells
|
||||
|
||||
## Japanese language (previously unseen by TableFormer):
|
||||
|
||||
@ -270,87 +270,87 @@ In this paper, we presented TableFormer an end-to-end transformer based approach
|
||||
|
||||
## References
|
||||
|
||||
- [1] Nicolas Carion, Francisco Massa, Gabriel Synnaeve, Nicolas Usunier, Alexander Kirillov, and Sergey Zagoruyko. End-to-
|
||||
[1] Nicolas Carion, Francisco Massa, Gabriel Synnaeve, Nicolas Usunier, Alexander Kirillov, and Sergey Zagoruyko. End-to-
|
||||
|
||||
- end object detection with transformers. In Andrea Vedaldi, Horst Bischof, Thomas Brox, and Jan-Michael Frahm, editors, Computer Vision - ECCV 2020 , pages 213-229, Cham, 2020. Springer International Publishing. 5
|
||||
end object detection with transformers. In Andrea Vedaldi, Horst Bischof, Thomas Brox, and Jan-Michael Frahm, editors, Computer Vision - ECCV 2020 , pages 213-229, Cham, 2020. Springer International Publishing. 5
|
||||
|
||||
- [2] Zewen Chi, Heyan Huang, Heng-Da Xu, Houjin Yu, Wanxuan Yin, and Xian-Ling Mao. Complicated table structure recognition. arXiv preprint arXiv:1908.04729 , 2019. 3
|
||||
[2] Zewen Chi, Heyan Huang, Heng-Da Xu, Houjin Yu, Wanxuan Yin, and Xian-Ling Mao. Complicated table structure recognition. arXiv preprint arXiv:1908.04729 , 2019. 3
|
||||
|
||||
- [3] Bertrand Couasnon and Aurelie Lemaitre. Recognition of Tables and Forms , pages 647-677. Springer London, London, 2014. 2
|
||||
[3] Bertrand Couasnon and Aurelie Lemaitre. Recognition of Tables and Forms , pages 647-677. Springer London, London, 2014. 2
|
||||
|
||||
- [4] Herv´e D´ejean, Jean-Luc Meunier, Liangcai Gao, Yilun Huang, Yu Fang, Florian Kleber, and Eva-Maria Lang. ICDAR 2019 Competition on Table Detection and Recognition (cTDaR), Apr. 2019. http://sac.founderit.com/. 2
|
||||
[4] Herv´e D´ejean, Jean-Luc Meunier, Liangcai Gao, Yilun Huang, Yu Fang, Florian Kleber, and Eva-Maria Lang. ICDAR 2019 Competition on Table Detection and Recognition (cTDaR), Apr. 2019. http://sac.founderit.com/. 2
|
||||
|
||||
- [5] Basilios Gatos, Dimitrios Danatsas, Ioannis Pratikakis, and Stavros J Perantonis. Automatic table detection in document images. In International Conference on Pattern Recognition and Image Analysis , pages 609-618. Springer, 2005. 2
|
||||
[5] Basilios Gatos, Dimitrios Danatsas, Ioannis Pratikakis, and Stavros J Perantonis. Automatic table detection in document images. In International Conference on Pattern Recognition and Image Analysis , pages 609-618. Springer, 2005. 2
|
||||
|
||||
- [6] Max G¨obel, Tamir Hassan, Ermelinda Oro, and Giorgio Orsi. Icdar 2013 table competition. In 2013 12th International Conference on Document Analysis and Recognition , pages 1449-1453, 2013. 2
|
||||
[6] Max G¨obel, Tamir Hassan, Ermelinda Oro, and Giorgio Orsi. Icdar 2013 table competition. In 2013 12th International Conference on Document Analysis and Recognition , pages 1449-1453, 2013. 2
|
||||
|
||||
- [7] EA Green and M Krishnamoorthy. Recognition of tables using table grammars. procs. In Symposium on Document Analysis and Recognition (SDAIR'95) , pages 261-277. 2
|
||||
[7] EA Green and M Krishnamoorthy. Recognition of tables using table grammars. procs. In Symposium on Document Analysis and Recognition (SDAIR'95) , pages 261-277. 2
|
||||
|
||||
- [8] Khurram Azeem Hashmi, Alain Pagani, Marcus Liwicki, Didier Stricker, and Muhammad Zeshan Afzal. Castabdetectors: Cascade network for table detection in document images with recursive feature pyramid and switchable atrous convolution. Journal of Imaging , 7(10), 2021. 1
|
||||
[8] Khurram Azeem Hashmi, Alain Pagani, Marcus Liwicki, Didier Stricker, and Muhammad Zeshan Afzal. Castabdetectors: Cascade network for table detection in document images with recursive feature pyramid and switchable atrous convolution. Journal of Imaging , 7(10), 2021. 1
|
||||
|
||||
- [9] Kaiming He, Georgia Gkioxari, Piotr Dollar, and Ross Girshick. Mask r-cnn. In Proceedings of the IEEE International Conference on Computer Vision (ICCV) , Oct 2017. 1
|
||||
[9] Kaiming He, Georgia Gkioxari, Piotr Dollar, and Ross Girshick. Mask r-cnn. In Proceedings of the IEEE International Conference on Computer Vision (ICCV) , Oct 2017. 1
|
||||
|
||||
- [10] Yelin He, X. Qi, Jiaquan Ye, Peng Gao, Yihao Chen, Bingcong Li, Xin Tang, and Rong Xiao. Pingan-vcgroup's solution for icdar 2021 competition on scientific table image recognition to latex. ArXiv , abs/2105.01846, 2021. 2
|
||||
[10] Yelin He, X. Qi, Jiaquan Ye, Peng Gao, Yihao Chen, Bingcong Li, Xin Tang, and Rong Xiao. Pingan-vcgroup's solution for icdar 2021 competition on scientific table image recognition to latex. ArXiv , abs/2105.01846, 2021. 2
|
||||
|
||||
- [11] Jianying Hu, Ramanujan S Kashi, Daniel P Lopresti, and Gordon Wilfong. Medium-independent table detection. In Document Recognition and Retrieval VII , volume 3967, pages 291-302. International Society for Optics and Photonics, 1999. 2
|
||||
[11] Jianying Hu, Ramanujan S Kashi, Daniel P Lopresti, and Gordon Wilfong. Medium-independent table detection. In Document Recognition and Retrieval VII , volume 3967, pages 291-302. International Society for Optics and Photonics, 1999. 2
|
||||
|
||||
- [12] Matthew Hurst. A constraint-based approach to table structure derivation. In Proceedings of the Seventh International Conference on Document Analysis and Recognition - Volume 2 , ICDAR '03, page 911, USA, 2003. IEEE Computer Society. 2
|
||||
[12] Matthew Hurst. A constraint-based approach to table structure derivation. In Proceedings of the Seventh International Conference on Document Analysis and Recognition - Volume 2 , ICDAR '03, page 911, USA, 2003. IEEE Computer Society. 2
|
||||
|
||||
- [13] Thotreingam Kasar, Philippine Barlas, Sebastien Adam, Cl´ement Chatelain, and Thierry Paquet. Learning to detect tables in scanned document images using line information. In 2013 12th International Conference on Document Analysis and Recognition , pages 1185-1189. IEEE, 2013. 2
|
||||
[13] Thotreingam Kasar, Philippine Barlas, Sebastien Adam, Cl´ement Chatelain, and Thierry Paquet. Learning to detect tables in scanned document images using line information. In 2013 12th International Conference on Document Analysis and Recognition , pages 1185-1189. IEEE, 2013. 2
|
||||
|
||||
- [14] Pratik Kayal, Mrinal Anand, Harsh Desai, and Mayank Singh. Icdar 2021 competition on scientific table image recognition to latex, 2021. 2
|
||||
[14] Pratik Kayal, Mrinal Anand, Harsh Desai, and Mayank Singh. Icdar 2021 competition on scientific table image recognition to latex, 2021. 2
|
||||
|
||||
- [15] Harold W Kuhn. The hungarian method for the assignment problem. Naval research logistics quarterly , 2(1-2):83-97, 1955. 6
|
||||
[15] Harold W Kuhn. The hungarian method for the assignment problem. Naval research logistics quarterly , 2(1-2):83-97, 1955. 6
|
||||
|
||||
- [16] Girish Kulkarni, Visruth Premraj, Vicente Ordonez, Sagnik Dhar, Siming Li, Yejin Choi, Alexander C. Berg, and Tamara L. Berg. Babytalk: Understanding and generating simple image descriptions. IEEE Transactions on Pattern Analysis and Machine Intelligence , 35(12):2891-2903, 2013. 4
|
||||
[16] Girish Kulkarni, Visruth Premraj, Vicente Ordonez, Sagnik Dhar, Siming Li, Yejin Choi, Alexander C. Berg, and Tamara L. Berg. Babytalk: Understanding and generating simple image descriptions. IEEE Transactions on Pattern Analysis and Machine Intelligence , 35(12):2891-2903, 2013. 4
|
||||
|
||||
- [17] Minghao Li, Lei Cui, Shaohan Huang, Furu Wei, Ming Zhou, and Zhoujun Li. Tablebank: A benchmark dataset for table detection and recognition, 2019. 2, 3
|
||||
[17] Minghao Li, Lei Cui, Shaohan Huang, Furu Wei, Ming Zhou, and Zhoujun Li. Tablebank: A benchmark dataset for table detection and recognition, 2019. 2, 3
|
||||
|
||||
- [18] Yiren Li, Zheng Huang, Junchi Yan, Yi Zhou, Fan Ye, and Xianhui Liu. Gfte: Graph-based financial table extraction. In Alberto Del Bimbo, Rita Cucchiara, Stan Sclaroff, Giovanni Maria Farinella, Tao Mei, Marco Bertini, Hugo Jair Escalante, and Roberto Vezzani, editors, Pattern Recognition. ICPR International Workshops and Challenges , pages 644-658, Cham, 2021. Springer International Publishing. 2, 3
|
||||
[18] Yiren Li, Zheng Huang, Junchi Yan, Yi Zhou, Fan Ye, and Xianhui Liu. Gfte: Graph-based financial table extraction. In Alberto Del Bimbo, Rita Cucchiara, Stan Sclaroff, Giovanni Maria Farinella, Tao Mei, Marco Bertini, Hugo Jair Escalante, and Roberto Vezzani, editors, Pattern Recognition. ICPR International Workshops and Challenges , pages 644-658, Cham, 2021. Springer International Publishing. 2, 3
|
||||
|
||||
- [19] Nikolaos Livathinos, Cesar Berrospi, Maksym Lysak, Viktor Kuropiatnyk, Ahmed Nassar, Andre Carvalho, Michele Dolfi, Christoph Auer, Kasper Dinkla, and Peter Staar. Robust pdf document conversion using recurrent neural networks. Proceedings of the AAAI Conference on Artificial Intelligence , 35(17):15137-15145, May 2021. 1
|
||||
[19] Nikolaos Livathinos, Cesar Berrospi, Maksym Lysak, Viktor Kuropiatnyk, Ahmed Nassar, Andre Carvalho, Michele Dolfi, Christoph Auer, Kasper Dinkla, and Peter Staar. Robust pdf document conversion using recurrent neural networks. Proceedings of the AAAI Conference on Artificial Intelligence , 35(17):15137-15145, May 2021. 1
|
||||
|
||||
- [20] Rujiao Long, Wen Wang, Nan Xue, Feiyu Gao, Zhibo Yang, Yongpan Wang, and Gui-Song Xia. Parsing table structures in the wild. In Proceedings of the IEEE/CVF International Conference on Computer Vision , pages 944-952, 2021. 2
|
||||
[20] Rujiao Long, Wen Wang, Nan Xue, Feiyu Gao, Zhibo Yang, Yongpan Wang, and Gui-Song Xia. Parsing table structures in the wild. In Proceedings of the IEEE/CVF International Conference on Computer Vision , pages 944-952, 2021. 2
|
||||
|
||||
- [21] Shubham Singh Paliwal, D Vishwanath, Rohit Rahul, Monika Sharma, and Lovekesh Vig. Tablenet: Deep learning model for end-to-end table detection and tabular data extraction from scanned document images. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 128-133. IEEE, 2019. 1
|
||||
[21] Shubham Singh Paliwal, D Vishwanath, Rohit Rahul, Monika Sharma, and Lovekesh Vig. Tablenet: Deep learning model for end-to-end table detection and tabular data extraction from scanned document images. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 128-133. IEEE, 2019. 1
|
||||
|
||||
- [22] Adam Paszke, Sam Gross, Francisco Massa, Adam Lerer, James Bradbury, Gregory Chanan, Trevor Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga, Alban Desmaison, Andreas Kopf, Edward Yang, Zachary DeVito, Martin Raison, Alykhan Tejani, Sasank Chilamkurthy, Benoit Steiner, Lu Fang, Junjie Bai, and Soumith Chintala. Pytorch: An imperative style, high-performance deep learning library. In H. Wallach, H. Larochelle, A. Beygelzimer, F. d'Alch´e-Buc, E. Fox, and R. Garnett, editors, Advances in Neural Information Processing Systems 32 , pages 8024-8035. Curran Associates, Inc., 2019. 6
|
||||
[22] Adam Paszke, Sam Gross, Francisco Massa, Adam Lerer, James Bradbury, Gregory Chanan, Trevor Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga, Alban Desmaison, Andreas Kopf, Edward Yang, Zachary DeVito, Martin Raison, Alykhan Tejani, Sasank Chilamkurthy, Benoit Steiner, Lu Fang, Junjie Bai, and Soumith Chintala. Pytorch: An imperative style, high-performance deep learning library. In H. Wallach, H. Larochelle, A. Beygelzimer, F. d'Alch´e-Buc, E. Fox, and R. Garnett, editors, Advances in Neural Information Processing Systems 32 , pages 8024-8035. Curran Associates, Inc., 2019. 6
|
||||
|
||||
- [23] Devashish Prasad, Ayan Gadpal, Kshitij Kapadni, Manish Visave, and Kavita Sultanpure. Cascadetabnet: An approach for end to end table detection and structure recognition from image-based documents. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition Workshops , pages 572-573, 2020. 1
|
||||
[23] Devashish Prasad, Ayan Gadpal, Kshitij Kapadni, Manish Visave, and Kavita Sultanpure. Cascadetabnet: An approach for end to end table detection and structure recognition from image-based documents. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition Workshops , pages 572-573, 2020. 1
|
||||
|
||||
- [24] Shah Rukh Qasim, Hassan Mahmood, and Faisal Shafait. Rethinking table recognition using graph neural networks. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 142-147. IEEE, 2019. 3
|
||||
[24] Shah Rukh Qasim, Hassan Mahmood, and Faisal Shafait. Rethinking table recognition using graph neural networks. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 142-147. IEEE, 2019. 3
|
||||
|
||||
- [25] Hamid Rezatofighi, Nathan Tsoi, JunYoung Gwak, Amir Sadeghian, Ian Reid, and Silvio Savarese. Generalized intersection over union: A metric and a loss for bounding box regression. In Proceedings of the IEEE/CVF Conference on
|
||||
[25] Hamid Rezatofighi, Nathan Tsoi, JunYoung Gwak, Amir Sadeghian, Ian Reid, and Silvio Savarese. Generalized intersection over union: A metric and a loss for bounding box regression. In Proceedings of the IEEE/CVF Conference on
|
||||
|
||||
Computer Vision and Pattern Recognition , pages 658-666, 2019. 6
|
||||
|
||||
- [26] Sebastian Schreiber, Stefan Agne, Ivo Wolf, Andreas Dengel, and Sheraz Ahmed. Deepdesrt: Deep learning for detection and structure recognition of tables in document images. In 2017 14th IAPR International Conference on Document Analysis and Recognition (ICDAR) , volume 01, pages 11621167, 2017. 1
|
||||
[26] Sebastian Schreiber, Stefan Agne, Ivo Wolf, Andreas Dengel, and Sheraz Ahmed. Deepdesrt: Deep learning for detection and structure recognition of tables in document images. In 2017 14th IAPR International Conference on Document Analysis and Recognition (ICDAR) , volume 01, pages 11621167, 2017. 1
|
||||
|
||||
- [27] Sebastian Schreiber, Stefan Agne, Ivo Wolf, Andreas Dengel, and Sheraz Ahmed. Deepdesrt: Deep learning for detection and structure recognition of tables in document images. In 2017 14th IAPR international conference on document analysis and recognition (ICDAR) , volume 1, pages 1162-1167. IEEE, 2017. 3
|
||||
[27] Sebastian Schreiber, Stefan Agne, Ivo Wolf, Andreas Dengel, and Sheraz Ahmed. Deepdesrt: Deep learning for detection and structure recognition of tables in document images. In 2017 14th IAPR international conference on document analysis and recognition (ICDAR) , volume 1, pages 1162-1167. IEEE, 2017. 3
|
||||
|
||||
- [28] Faisal Shafait and Ray Smith. Table detection in heterogeneous documents. In Proceedings of the 9th IAPR International Workshop on Document Analysis Systems , pages 6572, 2010. 2
|
||||
[28] Faisal Shafait and Ray Smith. Table detection in heterogeneous documents. In Proceedings of the 9th IAPR International Workshop on Document Analysis Systems , pages 6572, 2010. 2
|
||||
|
||||
- [29] Shoaib Ahmed Siddiqui, Imran Ali Fateh, Syed Tahseen Raza Rizvi, Andreas Dengel, and Sheraz Ahmed. Deeptabstr: Deep learning based table structure recognition. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 1403-1409. IEEE, 2019. 3
|
||||
[29] Shoaib Ahmed Siddiqui, Imran Ali Fateh, Syed Tahseen Raza Rizvi, Andreas Dengel, and Sheraz Ahmed. Deeptabstr: Deep learning based table structure recognition. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 1403-1409. IEEE, 2019. 3
|
||||
|
||||
- [30] Peter W J Staar, Michele Dolfi, Christoph Auer, and Costas Bekas. Corpus conversion service: A machine learning platform to ingest documents at scale. In Proceedings of the 24th ACM SIGKDD , KDD '18, pages 774-782, New York, NY, USA, 2018. ACM. 1
|
||||
[30] Peter W J Staar, Michele Dolfi, Christoph Auer, and Costas Bekas. Corpus conversion service: A machine learning platform to ingest documents at scale. In Proceedings of the 24th ACM SIGKDD , KDD '18, pages 774-782, New York, NY, USA, 2018. ACM. 1
|
||||
|
||||
- [31] Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, Ł ukasz Kaiser, and Illia Polosukhin. Attention is all you need. In I. Guyon, U. V. Luxburg, S. Bengio, H. Wallach, R. Fergus, S. Vishwanathan, and R. Garnett, editors, Advances in Neural Information Processing Systems 30 , pages 5998-6008. Curran Associates, Inc., 2017. 5
|
||||
[31] Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, Ł ukasz Kaiser, and Illia Polosukhin. Attention is all you need. In I. Guyon, U. V. Luxburg, S. Bengio, H. Wallach, R. Fergus, S. Vishwanathan, and R. Garnett, editors, Advances in Neural Information Processing Systems 30 , pages 5998-6008. Curran Associates, Inc., 2017. 5
|
||||
|
||||
- [32] Oriol Vinyals, Alexander Toshev, Samy Bengio, and Dumitru Erhan. Show and tell: A neural image caption generator. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (CVPR) , June 2015. 2
|
||||
[32] Oriol Vinyals, Alexander Toshev, Samy Bengio, and Dumitru Erhan. Show and tell: A neural image caption generator. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition (CVPR) , June 2015. 2
|
||||
|
||||
- [33] Wenyuan Xue, Qingyong Li, and Dacheng Tao. Res2tim: reconstruct syntactic structures from table images. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 749-755. IEEE, 2019. 3
|
||||
[33] Wenyuan Xue, Qingyong Li, and Dacheng Tao. Res2tim: reconstruct syntactic structures from table images. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 749-755. IEEE, 2019. 3
|
||||
|
||||
- [34] Wenyuan Xue, Baosheng Yu, Wen Wang, Dacheng Tao, and Qingyong Li. Tgrnet: A table graph reconstruction network for table structure recognition. arXiv preprint arXiv:2106.10598 , 2021. 3
|
||||
[34] Wenyuan Xue, Baosheng Yu, Wen Wang, Dacheng Tao, and Qingyong Li. Tgrnet: A table graph reconstruction network for table structure recognition. arXiv preprint arXiv:2106.10598 , 2021. 3
|
||||
|
||||
- [35] Quanzeng You, Hailin Jin, Zhaowen Wang, Chen Fang, and Jiebo Luo. Image captioning with semantic attention. In Proceedings of the IEEE conference on computer vision and pattern recognition , pages 4651-4659, 2016. 4
|
||||
[35] Quanzeng You, Hailin Jin, Zhaowen Wang, Chen Fang, and Jiebo Luo. Image captioning with semantic attention. In Proceedings of the IEEE conference on computer vision and pattern recognition , pages 4651-4659, 2016. 4
|
||||
|
||||
- [36] Xinyi Zheng, Doug Burdick, Lucian Popa, Peter Zhong, and Nancy Xin Ru Wang. Global table extractor (gte): A framework for joint table identification and cell structure recognition using visual context. Winter Conference for Applications in Computer Vision (WACV) , 2021. 2, 3
|
||||
[36] Xinyi Zheng, Doug Burdick, Lucian Popa, Peter Zhong, and Nancy Xin Ru Wang. Global table extractor (gte): A framework for joint table identification and cell structure recognition using visual context. Winter Conference for Applications in Computer Vision (WACV) , 2021. 2, 3
|
||||
|
||||
- [37] Xu Zhong, Elaheh ShafieiBavani, and Antonio Jimeno Yepes. Image-based table recognition: Data, model,
|
||||
[37] Xu Zhong, Elaheh ShafieiBavani, and Antonio Jimeno Yepes. Image-based table recognition: Data, model,
|
||||
|
||||
- and evaluation. In Andrea Vedaldi, Horst Bischof, Thomas Brox, and Jan-Michael Frahm, editors, Computer Vision ECCV 2020 , pages 564-580, Cham, 2020. Springer International Publishing. 2, 3, 7
|
||||
and evaluation. In Andrea Vedaldi, Horst Bischof, Thomas Brox, and Jan-Michael Frahm, editors, Computer Vision ECCV 2020 , pages 564-580, Cham, 2020. Springer International Publishing. 2, 3, 7
|
||||
|
||||
- [38] Xu Zhong, Jianbin Tang, and Antonio Jimeno Yepes. Publaynet: Largest dataset ever for document layout analysis. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 1015-1022, 2019. 1
|
||||
[38] Xu Zhong, Jianbin Tang, and Antonio Jimeno Yepes. Publaynet: Largest dataset ever for document layout analysis. In 2019 International Conference on Document Analysis and Recognition (ICDAR) , pages 1015-1022, 2019. 1
|
||||
|
||||
## TableFormer: Table Structure Understanding with Transformers Supplementary Material
|
||||
|
||||
@ -370,15 +370,15 @@ Aiming to train and evaluate our models in a broader spectrum of table data we h
|
||||
|
||||
The process of generating a synthetic dataset can be decomposed into the following steps:
|
||||
|
||||
- 1. Prepare styling and content templates: The styling templates have been manually designed and organized into groups of scope specific appearances (e.g. financial data, marketing data, etc.) Additionally, we have prepared curated collections of content templates by extracting the most frequently used terms out of non-synthetic datasets (e.g. PubTabNet, FinTabNet, etc.).
|
||||
1. Prepare styling and content templates: The styling templates have been manually designed and organized into groups of scope specific appearances (e.g. financial data, marketing data, etc.) Additionally, we have prepared curated collections of content templates by extracting the most frequently used terms out of non-synthetic datasets (e.g. PubTabNet, FinTabNet, etc.).
|
||||
|
||||
- 2. Generate table structures: The structure of each synthetic dataset assumes a horizontal table header which potentially spans over multiple rows and a table body that may contain a combination of row spans and column spans. However, spans are not allowed to cross the header - body boundary. The table structure is described by the parameters: Total number of table rows and columns, number of header rows, type of spans (header only spans, row only spans, column only spans, both row and column spans), maximum span size and the ratio of the table area covered by spans.
|
||||
2. Generate table structures: The structure of each synthetic dataset assumes a horizontal table header which potentially spans over multiple rows and a table body that may contain a combination of row spans and column spans. However, spans are not allowed to cross the header - body boundary. The table structure is described by the parameters: Total number of table rows and columns, number of header rows, type of spans (header only spans, row only spans, column only spans, both row and column spans), maximum span size and the ratio of the table area covered by spans.
|
||||
|
||||
- 3. Generate content: Based on the dataset theme , a set of suitable content templates is chosen first. Then, this content can be combined with purely random text to produce the synthetic content.
|
||||
3. Generate content: Based on the dataset theme , a set of suitable content templates is chosen first. Then, this content can be combined with purely random text to produce the synthetic content.
|
||||
|
||||
- 4. Apply styling templates: Depending on the domain of the synthetic dataset, a set of styling templates is first manually selected. Then, a style is randomly selected to format the appearance of the synthesized table.
|
||||
4. Apply styling templates: Depending on the domain of the synthetic dataset, a set of styling templates is first manually selected. Then, a style is randomly selected to format the appearance of the synthesized table.
|
||||
|
||||
- 5. Render the complete tables: The synthetic table is finally rendered by a web browser engine to generate the bounding boxes for each table cell. A batching technique is utilized to optimize the runtime overhead of the rendering process.
|
||||
5. Render the complete tables: The synthetic table is finally rendered by a web browser engine to generate the bounding boxes for each table cell. A batching technique is utilized to optimize the runtime overhead of the rendering process.
|
||||
|
||||
## 2. Prediction post-processing for PDF documents
|
||||
|
||||
@ -387,9 +387,9 @@ Although TableFormer can predict the table structure and the bounding boxes for
|
||||
Figure 7: Distribution of the tables across different dimensions per dataset. Simple vs complex tables per dataset and split, strict vs non strict html structures per dataset and table complexity, missing bboxes per dataset and table complexity.
|
||||
<!-- image -->
|
||||
|
||||
- · TableFormer output does not include the table cell content.
|
||||
· TableFormer output does not include the table cell content.
|
||||
|
||||
- · There are occasional inaccuracies in the predictions of the bounding boxes.
|
||||
· There are occasional inaccuracies in the predictions of the bounding boxes.
|
||||
|
||||
dian cell size for all table cells. The usage of median during the computations, helps to eliminate outliers caused by occasional column spans which are usually wider than the normal.
|
||||
|
||||
@ -397,37 +397,37 @@ However, it is possible to mitigate those limitations by combining the TableForm
|
||||
|
||||
Here is a step-by-step description of the prediction postprocessing:
|
||||
|
||||
- 1. Get the minimal grid dimensions - number of rows and columns for the predicted table structure. This represents the most granular grid for the underlying table structure.
|
||||
1. Get the minimal grid dimensions - number of rows and columns for the predicted table structure. This represents the most granular grid for the underlying table structure.
|
||||
|
||||
- 2. Generate pair-wise matches between the bounding boxes of the PDF cells and the predicted cells. The Intersection Over Union (IOU) metric is used to evaluate the quality of the matches.
|
||||
2. Generate pair-wise matches between the bounding boxes of the PDF cells and the predicted cells. The Intersection Over Union (IOU) metric is used to evaluate the quality of the matches.
|
||||
|
||||
- 3. Use a carefully selected IOU threshold to designate the matches as "good" ones and "bad" ones.
|
||||
3. Use a carefully selected IOU threshold to designate the matches as "good" ones and "bad" ones.
|
||||
|
||||
- 3.a. If all IOU scores in a column are below the threshold, discard all predictions (structure and bounding boxes) for that column.
|
||||
3.a. If all IOU scores in a column are below the threshold, discard all predictions (structure and bounding boxes) for that column.
|
||||
|
||||
- 4. Find the best-fitting content alignment for the predicted cells with good IOU per each column. The alignment of the column can be identified by the following formula:
|
||||
4. Find the best-fitting content alignment for the predicted cells with good IOU per each column. The alignment of the column can be identified by the following formula:
|
||||
|
||||
where c is one of { left, centroid, right } and x$_{c}$ is the xcoordinate for the corresponding point.
|
||||
|
||||
- 5. Use the alignment computed in step 4, to compute the median x -coordinate for all table columns and the me-
|
||||
5. Use the alignment computed in step 4, to compute the median x -coordinate for all table columns and the me-
|
||||
|
||||
- 6. Snap all cells with bad IOU to their corresponding median x -coordinates and cell sizes.
|
||||
6. Snap all cells with bad IOU to their corresponding median x -coordinates and cell sizes.
|
||||
|
||||
- 7. Generate a new set of pair-wise matches between the corrected bounding boxes and PDF cells. This time use a modified version of the IOU metric, where the area of the intersection between the predicted and PDF cells is divided by the PDF cell area. In case there are multiple matches for the same PDF cell, the prediction with the higher score is preferred. This covers the cases where the PDF cells are smaller than the area of predicted or corrected prediction cells.
|
||||
7. Generate a new set of pair-wise matches between the corrected bounding boxes and PDF cells. This time use a modified version of the IOU metric, where the area of the intersection between the predicted and PDF cells is divided by the PDF cell area. In case there are multiple matches for the same PDF cell, the prediction with the higher score is preferred. This covers the cases where the PDF cells are smaller than the area of predicted or corrected prediction cells.
|
||||
|
||||
- 8. In some rare occasions, we have noticed that TableFormer can confuse a single column as two. When the postprocessing steps are applied, this results with two predicted columns pointing to the same PDF column. In such case we must de-duplicate the columns according to highest total column intersection score.
|
||||
8. In some rare occasions, we have noticed that TableFormer can confuse a single column as two. When the postprocessing steps are applied, this results with two predicted columns pointing to the same PDF column. In such case we must de-duplicate the columns according to highest total column intersection score.
|
||||
|
||||
- 9. Pick up the remaining orphan cells. There could be cases, when after applying all the previous post-processing steps, some PDF cells could still remain without any match to predicted cells. However, it is still possible to deduce the correct matching for an orphan PDF cell by mapping its bounding box on the geometry of the grid. This mapping decides if the content of the orphan cell will be appended to an already matched table cell, or a new table cell should be created to match with the orphan.
|
||||
9. Pick up the remaining orphan cells. There could be cases, when after applying all the previous post-processing steps, some PDF cells could still remain without any match to predicted cells. However, it is still possible to deduce the correct matching for an orphan PDF cell by mapping its bounding box on the geometry of the grid. This mapping decides if the content of the orphan cell will be appended to an already matched table cell, or a new table cell should be created to match with the orphan.
|
||||
|
||||
9a. Compute the top and bottom boundary of the horizontal band for each grid row (min/max y coordinates per row).
|
||||
|
||||
- 9b. Intersect the orphan's bounding box with the row bands, and map the cell to the closest grid row.
|
||||
9b. Intersect the orphan's bounding box with the row bands, and map the cell to the closest grid row.
|
||||
|
||||
- 9c. Compute the left and right boundary of the vertical band for each grid column (min/max x coordinates per column).
|
||||
9c. Compute the left and right boundary of the vertical band for each grid column (min/max x coordinates per column).
|
||||
|
||||
- 9d. Intersect the orphan's bounding box with the column bands, and map the cell to the closest grid column.
|
||||
9d. Intersect the orphan's bounding box with the column bands, and map the cell to the closest grid column.
|
||||
|
||||
- 9e. If the table cell under the identified row and column is not empty, extend its content with the content of the or-
|
||||
9e. If the table cell under the identified row and column is not empty, extend its content with the content of the or-
|
||||
|
||||
phan cell.
|
||||
|
||||
|
@ -27,12 +27,12 @@
|
||||
<paragraph><location><page_2><loc_9><loc_71><loc_50><loc_86></location>Despite the substantial improvements achieved with machine-learning (ML) approaches and deep neural networks in recent years, document conversion remains a challenging problem, as demonstrated by the numerous public competitions held on this topic [1-4]. The challenge originates from the huge variability in PDF documents regarding layout, language and formats (scanned, programmatic or a combination of both). Engineering a single ML model that can be applied on all types of documents and provides high-quality layout segmentation remains to this day extremely challenging [5]. To highlight the variability in document layouts, we show a few example documents from the DocLayNet dataset in Figure 1.</paragraph>
|
||||
<paragraph><location><page_2><loc_9><loc_37><loc_48><loc_71></location>A key problem in the process of document conversion is to understand the structure of a single document page, i.e. which segments of text should be grouped together in a unit. To train models for this task, there are currently two large datasets available to the community, PubLayNet [6] and DocBank [7]. They were introduced in 2019 and 2020 respectively and significantly accelerated the implementation of layout detection and segmentation models due to their sizes of 300K and 500K ground-truth pages. These sizes were achieved by leveraging an automation approach. The benefit of automated ground-truth generation is obvious: one can generate large ground-truth datasets at virtually no cost. However, the automation introduces a constraint on the variability in the dataset, because corresponding structured source data must be available. PubLayNet and DocBank were both generated from scientific document repositories (PubMed and arXiv), which provide XML or L A T E X sources. Those scientific documents present a limited variability in their layouts, because they are typeset in uniform templates provided by the publishers. Obviously, documents such as technical manuals, annual company reports, legal text, government tenders, etc. have very different and partially unique layouts. As a consequence, the layout predictions obtained from models trained on PubLayNet or DocBank is very reasonable when applied on scientific documents. However, for more artistic or free-style layouts, we see sub-par prediction quality from these models, which we demonstrate in Section 5.</paragraph>
|
||||
<paragraph><location><page_2><loc_9><loc_27><loc_48><loc_36></location>In this paper, we present the DocLayNet dataset. It provides pageby-page layout annotation ground-truth using bounding-boxes for 11 distinct class labels on 80863 unique document pages, of which a fraction carry double- or triple-annotations. DocLayNet is similar in spirit to PubLayNet and DocBank and will likewise be made available to the public 1 in order to stimulate the document-layout analysis community. It distinguishes itself in the following aspects:</paragraph>
|
||||
<paragraph><location><page_2><loc_11><loc_22><loc_48><loc_26></location>- (1) Human Annotation : In contrast to PubLayNet and DocBank, we relied on human annotation instead of automation approaches to generate the data set.</paragraph>
|
||||
<paragraph><location><page_2><loc_11><loc_20><loc_48><loc_22></location>- (2) Large Layout Variability : We include diverse and complex layouts from a large variety of public sources.</paragraph>
|
||||
<paragraph><location><page_2><loc_11><loc_15><loc_48><loc_19></location>- (3) Detailed Label Set : We define 11 class labels to distinguish layout features in high detail. PubLayNet provides 5 labels; DocBank provides 13, although not a superset of ours.</paragraph>
|
||||
<paragraph><location><page_2><loc_11><loc_13><loc_48><loc_15></location>- (4) Redundant Annotations : A fraction of the pages in the DocLayNet data set carry more than one human annotation.</paragraph>
|
||||
<paragraph><location><page_2><loc_11><loc_22><loc_48><loc_26></location>(1) Human Annotation : In contrast to PubLayNet and DocBank, we relied on human annotation instead of automation approaches to generate the data set.</paragraph>
|
||||
<paragraph><location><page_2><loc_11><loc_20><loc_48><loc_22></location>(2) Large Layout Variability : We include diverse and complex layouts from a large variety of public sources.</paragraph>
|
||||
<paragraph><location><page_2><loc_11><loc_15><loc_48><loc_19></location>(3) Detailed Label Set : We define 11 class labels to distinguish layout features in high detail. PubLayNet provides 5 labels; DocBank provides 13, although not a superset of ours.</paragraph>
|
||||
<paragraph><location><page_2><loc_11><loc_13><loc_48><loc_15></location>(4) Redundant Annotations : A fraction of the pages in the DocLayNet data set carry more than one human annotation.</paragraph>
|
||||
<paragraph><location><page_2><loc_56><loc_87><loc_91><loc_89></location>This enables experimentation with annotation uncertainty and quality control analysis.</paragraph>
|
||||
<paragraph><location><page_2><loc_54><loc_80><loc_91><loc_86></location>- (5) Pre-defined Train-, Test- & Validation-set : Like DocBank, we provide fixed train-, test- & validation-sets to ensure proportional representation of the class-labels. Further, we prevent leakage of unique layouts across sets, which has a large effect on model accuracy scores.</paragraph>
|
||||
<paragraph><location><page_2><loc_54><loc_80><loc_91><loc_86></location>(5) Pre-defined Train-, Test- & Validation-set : Like DocBank, we provide fixed train-, test- & validation-sets to ensure proportional representation of the class-labels. Further, we prevent leakage of unique layouts across sets, which has a large effect on model accuracy scores.</paragraph>
|
||||
<paragraph><location><page_2><loc_52><loc_72><loc_91><loc_79></location>All aspects outlined above are detailed in Section 3. In Section 4, we will elaborate on how we designed and executed this large-scale human annotation campaign. We will also share key insights and lessons learned that might prove helpful for other parties planning to set up annotation campaigns.</paragraph>
|
||||
<paragraph><location><page_2><loc_52><loc_61><loc_91><loc_72></location>In Section 5, we will present baseline accuracy numbers for a variety of object detection methods (Faster R-CNN, Mask R-CNN and YOLOv5) trained on DocLayNet. We further show how the model performance is impacted by varying the DocLayNet dataset size, reducing the label set and modifying the train/test-split. Last but not least, we compare the performance of models trained on PubLayNet, DocBank and DocLayNet and demonstrate that a model trained on DocLayNet provides overall more robust layout recovery.</paragraph>
|
||||
<subtitle-level-1><location><page_2><loc_52><loc_58><loc_69><loc_59></location>2 RELATED WORK</subtitle-level-1>
|
||||
@ -86,12 +86,12 @@
|
||||
<paragraph><location><page_5><loc_9><loc_87><loc_48><loc_89></location>the textual content of an element, which goes beyond visual layout recognition, in particular outside the Scientific Articles category.</paragraph>
|
||||
<paragraph><location><page_5><loc_9><loc_69><loc_48><loc_86></location>At first sight, the task of visual document-layout interpretation appears intuitive enough to obtain plausible annotations in most cases. However, during early trial-runs in the core team, we observed many cases in which annotators use different annotation styles, especially for documents with challenging layouts. For example, if a figure is presented with subfigures, one annotator might draw a single figure bounding-box, while another might annotate each subfigure separately. The same applies for lists, where one might annotate all list items in one block or each list item separately. In essence, we observed that challenging layouts would be annotated in different but plausible ways. To illustrate this, we show in Figure 4 multiple examples of plausible but inconsistent annotations on the same pages.</paragraph>
|
||||
<paragraph><location><page_5><loc_9><loc_57><loc_48><loc_68></location>Obviously, this inconsistency in annotations is not desirable for datasets which are intended to be used for model training. To minimise these inconsistencies, we created a detailed annotation guideline. While perfect consistency across 40 annotation staff members is clearly not possible to achieve, we saw a huge improvement in annotation consistency after the introduction of our annotation guideline. A few selected, non-trivial highlights of the guideline are:</paragraph>
|
||||
<paragraph><location><page_5><loc_11><loc_51><loc_48><loc_56></location>- (1) Every list-item is an individual object instance with class label List-item . This definition is different from PubLayNet and DocBank, where all list-items are grouped together into one List object.</paragraph>
|
||||
<paragraph><location><page_5><loc_11><loc_45><loc_48><loc_50></location>- (2) A List-item is a paragraph with hanging indentation. Singleline elements can qualify as List-item if the neighbour elements expose hanging indentation. Bullet or enumeration symbols are not a requirement.</paragraph>
|
||||
<paragraph><location><page_5><loc_11><loc_42><loc_48><loc_45></location>- (3) For every Caption , there must be exactly one corresponding Picture or Table .</paragraph>
|
||||
<paragraph><location><page_5><loc_11><loc_40><loc_48><loc_42></location>- (4) Connected sub-pictures are grouped together in one Picture object.</paragraph>
|
||||
<paragraph><location><page_5><loc_11><loc_38><loc_43><loc_39></location>- (5) Formula numbers are included in a Formula object.</paragraph>
|
||||
<paragraph><location><page_5><loc_11><loc_34><loc_48><loc_38></location>- (6) Emphasised text (e.g. in italic or bold) at the beginning of a paragraph is not considered a Section-header , unless it appears exclusively on its own line.</paragraph>
|
||||
<paragraph><location><page_5><loc_11><loc_51><loc_48><loc_56></location>(1) Every list-item is an individual object instance with class label List-item . This definition is different from PubLayNet and DocBank, where all list-items are grouped together into one List object.</paragraph>
|
||||
<paragraph><location><page_5><loc_11><loc_45><loc_48><loc_50></location>(2) A List-item is a paragraph with hanging indentation. Singleline elements can qualify as List-item if the neighbour elements expose hanging indentation. Bullet or enumeration symbols are not a requirement.</paragraph>
|
||||
<paragraph><location><page_5><loc_11><loc_42><loc_48><loc_45></location>(3) For every Caption , there must be exactly one corresponding Picture or Table .</paragraph>
|
||||
<paragraph><location><page_5><loc_11><loc_40><loc_48><loc_42></location>(4) Connected sub-pictures are grouped together in one Picture object.</paragraph>
|
||||
<paragraph><location><page_5><loc_11><loc_38><loc_43><loc_39></location>(5) Formula numbers are included in a Formula object.</paragraph>
|
||||
<paragraph><location><page_5><loc_11><loc_34><loc_48><loc_38></location>(6) Emphasised text (e.g. in italic or bold) at the beginning of a paragraph is not considered a Section-header , unless it appears exclusively on its own line.</paragraph>
|
||||
<paragraph><location><page_5><loc_9><loc_27><loc_48><loc_33></location>The complete annotation guideline is over 100 pages long and a detailed description is obviously out of scope for this paper. Nevertheless, it will be made publicly available alongside with DocLayNet for future reference.</paragraph>
|
||||
<paragraph><location><page_5><loc_9><loc_11><loc_48><loc_27></location>Phase 3: Training. After a first trial with a small group of people, we realised that providing the annotation guideline and a set of random practice pages did not yield the desired quality level for layout annotation. Therefore we prepared a subset of pages with two different complexity levels, each with a practice and an exam part. 974 pages were reference-annotated by one proficient core team member. Annotation staff were then given the task to annotate the same subsets (blinded from the reference). By comparing the annotations of each staff member with the reference annotations, we could quantify how closely their annotations matched the reference. Only after passing two exam levels with high annotation quality, staff were admitted into the production phase. Practice iterations</paragraph>
|
||||
<figure>
|
||||
@ -203,19 +203,19 @@
|
||||
<paragraph><location><page_8><loc_52><loc_64><loc_91><loc_76></location>From the dataset, we have derived on the one hand reference metrics for human performance on document-layout annotation (through double and triple annotations) and on the other hand evaluated the baseline performance of commonly used object detection methods. We also illustrated the impact of various dataset-related aspects on model performance through data-ablation experiments, both from a size and class-label perspective. Last but not least, we compared the accuracy of models trained on other public datasets and showed that DocLayNet trained models are more robust.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_60><loc_91><loc_64></location>To date, there is still a significant gap between human and ML accuracy on the layout interpretation task, and we hope that this work will inspire the research community to close that gap.</paragraph>
|
||||
<subtitle-level-1><location><page_8><loc_52><loc_56><loc_63><loc_58></location>REFERENCES</subtitle-level-1>
|
||||
<paragraph><location><page_8><loc_52><loc_53><loc_91><loc_56></location>- [1] Max Göbel, Tamir Hassan, Ermelinda Oro, and Giorgio Orsi. Icdar 2013 table competition. In 2013 12th International Conference on Document Analysis and Recognition , pages 1449-1453, 2013.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_49><loc_91><loc_53></location>- [2] Christian Clausner, Apostolos Antonacopoulos, and Stefan Pletschacher. Icdar2017 competition on recognition of documents with complex layouts rdcl2017. In 2017 14th IAPR International Conference on Document Analysis and Recognition (ICDAR) , volume 01, pages 1404-1410, 2017.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_46><loc_91><loc_49></location>- [3] Hervé Déjean, Jean-Luc Meunier, Liangcai Gao, Yilun Huang, Yu Fang, Florian Kleber, and Eva-Maria Lang. ICDAR 2019 Competition on Table Detection and Recognition (cTDaR), April 2019. http://sac.founderit.com/.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_42><loc_91><loc_46></location>- [4] Antonio Jimeno Yepes, Peter Zhong, and Douglas Burdick. Competition on scientific literature parsing. In Proceedings of the International Conference on Document Analysis and Recognition , ICDAR, pages 605-617. LNCS 12824, SpringerVerlag, sep 2021.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_38><loc_91><loc_42></location>- [5] Logan Markewich, Hao Zhang, Yubin Xing, Navid Lambert-Shirzad, Jiang Zhexin, Roy Lee, Zhi Li, and Seok-Bum Ko. Segmentation for document layout analysis: not dead yet. International Journal on Document Analysis and Recognition (IJDAR) , pages 1-11, 01 2022.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_35><loc_91><loc_38></location>- [6] Xu Zhong, Jianbin Tang, and Antonio Jimeno-Yepes. Publaynet: Largest dataset ever for document layout analysis. In Proceedings of the International Conference on Document Analysis and Recognition , ICDAR, pages 1015-1022, sep 2019.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_30><loc_91><loc_35></location>- [7] Minghao Li, Yiheng Xu, Lei Cui, Shaohan Huang, Furu Wei, Zhoujun Li, and Ming Zhou. Docbank: A benchmark dataset for document layout analysis. In Proceedings of the 28th International Conference on Computational Linguistics , COLING, pages 949-960. International Committee on Computational Linguistics, dec 2020.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_27><loc_91><loc_30></location>- [8] Riaz Ahmad, Muhammad Tanvir Afzal, and M. Qadir. Information extraction from pdf sources based on rule-based system using integrated formats. In SemWebEval@ESWC , 2016.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_23><loc_91><loc_27></location>- [9] Ross B. Girshick, Jeff Donahue, Trevor Darrell, and Jitendra Malik. Rich feature hierarchies for accurate object detection and semantic segmentation. In IEEE Conference on Computer Vision and Pattern Recognition , CVPR, pages 580-587. IEEE Computer Society, jun 2014.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_21><loc_91><loc_23></location>- [10] Ross B. Girshick. Fast R-CNN. In 2015 IEEE International Conference on Computer Vision , ICCV, pages 1440-1448. IEEE Computer Society, dec 2015.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_18><loc_91><loc_21></location>- [11] Shaoqing Ren, Kaiming He, Ross Girshick, and Jian Sun. Faster r-cnn: Towards real-time object detection with region proposal networks. IEEE Transactions on Pattern Analysis and Machine Intelligence , 39(6):1137-1149, 2017.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_15><loc_91><loc_18></location>- [12] Kaiming He, Georgia Gkioxari, Piotr Dollár, and Ross B. Girshick. Mask R-CNN. In IEEE International Conference on Computer Vision , ICCV, pages 2980-2988. IEEE Computer Society, Oct 2017.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_11><loc_91><loc_15></location>- [13] Glenn Jocher, Alex Stoken, Ayush Chaurasia, Jirka Borovec, NanoCode012, TaoXie, Yonghye Kwon, Kalen Michael, Liu Changyu, Jiacong Fang, Abhiram V, Laughing, tkianai, yxNONG, Piotr Skalski, Adam Hogan, Jebastin Nadar, imyhxy, Lorenzo Mammana, Alex Wang, Cristi Fati, Diego Montes, Jan Hajek, Laurentiu</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_53><loc_91><loc_56></location>[1] Max Göbel, Tamir Hassan, Ermelinda Oro, and Giorgio Orsi. Icdar 2013 table competition. In 2013 12th International Conference on Document Analysis and Recognition , pages 1449-1453, 2013.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_49><loc_91><loc_53></location>[2] Christian Clausner, Apostolos Antonacopoulos, and Stefan Pletschacher. Icdar2017 competition on recognition of documents with complex layouts rdcl2017. In 2017 14th IAPR International Conference on Document Analysis and Recognition (ICDAR) , volume 01, pages 1404-1410, 2017.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_46><loc_91><loc_49></location>[3] Hervé Déjean, Jean-Luc Meunier, Liangcai Gao, Yilun Huang, Yu Fang, Florian Kleber, and Eva-Maria Lang. ICDAR 2019 Competition on Table Detection and Recognition (cTDaR), April 2019. http://sac.founderit.com/.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_42><loc_91><loc_46></location>[4] Antonio Jimeno Yepes, Peter Zhong, and Douglas Burdick. Competition on scientific literature parsing. In Proceedings of the International Conference on Document Analysis and Recognition , ICDAR, pages 605-617. LNCS 12824, SpringerVerlag, sep 2021.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_38><loc_91><loc_42></location>[5] Logan Markewich, Hao Zhang, Yubin Xing, Navid Lambert-Shirzad, Jiang Zhexin, Roy Lee, Zhi Li, and Seok-Bum Ko. Segmentation for document layout analysis: not dead yet. International Journal on Document Analysis and Recognition (IJDAR) , pages 1-11, 01 2022.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_35><loc_91><loc_38></location>[6] Xu Zhong, Jianbin Tang, and Antonio Jimeno-Yepes. Publaynet: Largest dataset ever for document layout analysis. In Proceedings of the International Conference on Document Analysis and Recognition , ICDAR, pages 1015-1022, sep 2019.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_30><loc_91><loc_35></location>[7] Minghao Li, Yiheng Xu, Lei Cui, Shaohan Huang, Furu Wei, Zhoujun Li, and Ming Zhou. Docbank: A benchmark dataset for document layout analysis. In Proceedings of the 28th International Conference on Computational Linguistics , COLING, pages 949-960. International Committee on Computational Linguistics, dec 2020.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_27><loc_91><loc_30></location>[8] Riaz Ahmad, Muhammad Tanvir Afzal, and M. Qadir. Information extraction from pdf sources based on rule-based system using integrated formats. In SemWebEval@ESWC , 2016.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_23><loc_91><loc_27></location>[9] Ross B. Girshick, Jeff Donahue, Trevor Darrell, and Jitendra Malik. Rich feature hierarchies for accurate object detection and semantic segmentation. In IEEE Conference on Computer Vision and Pattern Recognition , CVPR, pages 580-587. IEEE Computer Society, jun 2014.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_21><loc_91><loc_23></location>[10] Ross B. Girshick. Fast R-CNN. In 2015 IEEE International Conference on Computer Vision , ICCV, pages 1440-1448. IEEE Computer Society, dec 2015.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_18><loc_91><loc_21></location>[11] Shaoqing Ren, Kaiming He, Ross Girshick, and Jian Sun. Faster r-cnn: Towards real-time object detection with region proposal networks. IEEE Transactions on Pattern Analysis and Machine Intelligence , 39(6):1137-1149, 2017.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_15><loc_91><loc_18></location>[12] Kaiming He, Georgia Gkioxari, Piotr Dollár, and Ross B. Girshick. Mask R-CNN. In IEEE International Conference on Computer Vision , ICCV, pages 2980-2988. IEEE Computer Society, Oct 2017.</paragraph>
|
||||
<paragraph><location><page_8><loc_52><loc_11><loc_91><loc_15></location>[13] Glenn Jocher, Alex Stoken, Ayush Chaurasia, Jirka Borovec, NanoCode012, TaoXie, Yonghye Kwon, Kalen Michael, Liu Changyu, Jiacong Fang, Abhiram V, Laughing, tkianai, yxNONG, Piotr Skalski, Adam Hogan, Jebastin Nadar, imyhxy, Lorenzo Mammana, Alex Wang, Cristi Fati, Diego Montes, Jan Hajek, Laurentiu</paragraph>
|
||||
<figure>
|
||||
<location><page_9><loc_9><loc_44><loc_91><loc_89></location>
|
||||
<caption>Text Caption List-Item Formula Table Section-Header Picture Page-Header Page-Footer Title</caption>
|
||||
@ -223,14 +223,14 @@
|
||||
<caption><location><page_9><loc_10><loc_43><loc_52><loc_44></location>Text Caption List-Item Formula Table Section-Header Picture Page-Header Page-Footer Title</caption>
|
||||
<paragraph><location><page_9><loc_9><loc_36><loc_91><loc_41></location>Figure 6: Example layout predictions on selected pages from the DocLayNet test-set. (A, D) exhibit favourable results on coloured backgrounds. (B, C) show accurate list-item and paragraph differentiation despite densely-spaced lines. (E) demonstrates good table and figure distinction. (F) shows predictions on a Chinese patent with multiple overlaps, label confusion and missing boxes.</paragraph>
|
||||
<paragraph><location><page_9><loc_11><loc_31><loc_48><loc_33></location>Diaconu, Mai Thanh Minh, Marc, albinxavi, fatih, oleg, and wanghao yang. ultralytics/yolov5: v6.0 - yolov5n nano models, roboflow integration, tensorflow export, opencv dnn support, October 2021.</paragraph>
|
||||
<paragraph><location><page_9><loc_52><loc_32><loc_91><loc_33></location>- [20] Shoubin Li, Xuyan Ma, Shuaiqun Pan, Jun Hu, Lin Shi, and Qing Wang. Vtlayout: Fusion of visual and text features for document layout analysis, 2021.</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_28><loc_48><loc_30></location>- [14] Nicolas Carion, Francisco Massa, Gabriel Synnaeve, Nicolas Usunier, Alexander Kirillov, and Sergey Zagoruyko. End-to-end object detection with transformers. CoRR , abs/2005.12872, 2020.</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_26><loc_48><loc_27></location>- [15] Mingxing Tan, Ruoming Pang, and Quoc V. Le. Efficientdet: Scalable and efficient object detection. CoRR , abs/1911.09070, 2019.</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_23><loc_48><loc_25></location>- [16] Tsung-Yi Lin, Michael Maire, Serge J. Belongie, Lubomir D. Bourdev, Ross B. Girshick, James Hays, Pietro Perona, Deva Ramanan, Piotr Dollár, and C. Lawrence Zitnick. Microsoft COCO: common objects in context, 2014.</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_21><loc_48><loc_22></location>- [17] Yuxin Wu, Alexander Kirillov, Francisco Massa, Wan-Yen Lo, and Ross Girshick. Detectron2, 2019.</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_16><loc_48><loc_20></location>- [18] Nikolaos Livathinos, Cesar Berrospi, Maksym Lysak, Viktor Kuropiatnyk, Ahmed Nassar, Andre Carvalho, Michele Dolfi, Christoph Auer, Kasper Dinkla, and Peter W. J. Staar. Robust pdf document conversion using recurrent neural networks. In Proceedings of the 35th Conference on Artificial Intelligence , AAAI, pages 1513715145, feb 2021.</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_10><loc_48><loc_15></location>- [19] Yiheng Xu, Minghao Li, Lei Cui, Shaohan Huang, Furu Wei, and Ming Zhou. Layoutlm: Pre-training of text and layout for document image understanding. In Proceedings of the 26th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining , KDD, pages 1192-1200, New York, USA, 2020. Association for Computing Machinery.</paragraph>
|
||||
<paragraph><location><page_9><loc_52><loc_29><loc_91><loc_31></location>- [21] Peng Zhang, Can Li, Liang Qiao, Zhanzhan Cheng, Shiliang Pu, Yi Niu, and Fei Wu. Vsr: A unified framework for document layout analysis combining vision, semantics and relations, 2021.</paragraph>
|
||||
<paragraph><location><page_9><loc_52><loc_25><loc_91><loc_28></location>- [22] Peter W J Staar, Michele Dolfi, Christoph Auer, and Costas Bekas. Corpus conversion service: A machine learning platform to ingest documents at scale. In Proceedings of the 24th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining , KDD, pages 774-782. ACM, 2018.</paragraph>
|
||||
<paragraph><location><page_9><loc_52><loc_23><loc_91><loc_24></location>- [23] Connor Shorten and Taghi M. Khoshgoftaar. A survey on image data augmentation for deep learning. Journal of Big Data , 6(1):60, 2019.</paragraph>
|
||||
<paragraph><location><page_9><loc_52><loc_32><loc_91><loc_33></location>[20] Shoubin Li, Xuyan Ma, Shuaiqun Pan, Jun Hu, Lin Shi, and Qing Wang. Vtlayout: Fusion of visual and text features for document layout analysis, 2021.</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_28><loc_48><loc_30></location>[14] Nicolas Carion, Francisco Massa, Gabriel Synnaeve, Nicolas Usunier, Alexander Kirillov, and Sergey Zagoruyko. End-to-end object detection with transformers. CoRR , abs/2005.12872, 2020.</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_26><loc_48><loc_27></location>[15] Mingxing Tan, Ruoming Pang, and Quoc V. Le. Efficientdet: Scalable and efficient object detection. CoRR , abs/1911.09070, 2019.</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_23><loc_48><loc_25></location>[16] Tsung-Yi Lin, Michael Maire, Serge J. Belongie, Lubomir D. Bourdev, Ross B. Girshick, James Hays, Pietro Perona, Deva Ramanan, Piotr Dollár, and C. Lawrence Zitnick. Microsoft COCO: common objects in context, 2014.</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_21><loc_48><loc_22></location>[17] Yuxin Wu, Alexander Kirillov, Francisco Massa, Wan-Yen Lo, and Ross Girshick. Detectron2, 2019.</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_16><loc_48><loc_20></location>[18] Nikolaos Livathinos, Cesar Berrospi, Maksym Lysak, Viktor Kuropiatnyk, Ahmed Nassar, Andre Carvalho, Michele Dolfi, Christoph Auer, Kasper Dinkla, and Peter W. J. Staar. Robust pdf document conversion using recurrent neural networks. In Proceedings of the 35th Conference on Artificial Intelligence , AAAI, pages 1513715145, feb 2021.</paragraph>
|
||||
<paragraph><location><page_9><loc_9><loc_10><loc_48><loc_15></location>[19] Yiheng Xu, Minghao Li, Lei Cui, Shaohan Huang, Furu Wei, and Ming Zhou. Layoutlm: Pre-training of text and layout for document image understanding. In Proceedings of the 26th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining , KDD, pages 1192-1200, New York, USA, 2020. Association for Computing Machinery.</paragraph>
|
||||
<paragraph><location><page_9><loc_52><loc_29><loc_91><loc_31></location>[21] Peng Zhang, Can Li, Liang Qiao, Zhanzhan Cheng, Shiliang Pu, Yi Niu, and Fei Wu. Vsr: A unified framework for document layout analysis combining vision, semantics and relations, 2021.</paragraph>
|
||||
<paragraph><location><page_9><loc_52><loc_25><loc_91><loc_28></location>[22] Peter W J Staar, Michele Dolfi, Christoph Auer, and Costas Bekas. Corpus conversion service: A machine learning platform to ingest documents at scale. In Proceedings of the 24th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining , KDD, pages 774-782. ACM, 2018.</paragraph>
|
||||
<paragraph><location><page_9><loc_52><loc_23><loc_91><loc_24></location>[23] Connor Shorten and Taghi M. Khoshgoftaar. A survey on image data augmentation for deep learning. Journal of Big Data , 6(1):60, 2019.</paragraph>
|
||||
</document>
|
@ -654,7 +654,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- (1) Human Annotation : In contrast to PubLayNet and DocBank, we relied on human annotation instead of automation approaches to generate the data set.",
|
||||
"text": "(1) Human Annotation : In contrast to PubLayNet and DocBank, we relied on human annotation instead of automation approaches to generate the data set.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -677,7 +677,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- (2) Large Layout Variability : We include diverse and complex layouts from a large variety of public sources.",
|
||||
"text": "(2) Large Layout Variability : We include diverse and complex layouts from a large variety of public sources.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -700,7 +700,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- (3) Detailed Label Set : We define 11 class labels to distinguish layout features in high detail. PubLayNet provides 5 labels; DocBank provides 13, although not a superset of ours.",
|
||||
"text": "(3) Detailed Label Set : We define 11 class labels to distinguish layout features in high detail. PubLayNet provides 5 labels; DocBank provides 13, although not a superset of ours.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -723,7 +723,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- (4) Redundant Annotations : A fraction of the pages in the DocLayNet data set carry more than one human annotation.",
|
||||
"text": "(4) Redundant Annotations : A fraction of the pages in the DocLayNet data set carry more than one human annotation.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -792,7 +792,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- (5) Pre-defined Train-, Test- & Validation-set : Like DocBank, we provide fixed train-, test- & validation-sets to ensure proportional representation of the class-labels. Further, we prevent leakage of unique layouts across sets, which has a large effect on model accuracy scores.",
|
||||
"text": "(5) Pre-defined Train-, Test- & Validation-set : Like DocBank, we provide fixed train-, test- & validation-sets to ensure proportional representation of the class-labels. Further, we prevent leakage of unique layouts across sets, which has a large effect on model accuracy scores.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1511,7 +1511,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- (1) Every list-item is an individual object instance with class label List-item . This definition is different from PubLayNet and DocBank, where all list-items are grouped together into one List object.",
|
||||
"text": "(1) Every list-item is an individual object instance with class label List-item . This definition is different from PubLayNet and DocBank, where all list-items are grouped together into one List object.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1534,7 +1534,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- (2) A List-item is a paragraph with hanging indentation. Singleline elements can qualify as List-item if the neighbour elements expose hanging indentation. Bullet or enumeration symbols are not a requirement.",
|
||||
"text": "(2) A List-item is a paragraph with hanging indentation. Singleline elements can qualify as List-item if the neighbour elements expose hanging indentation. Bullet or enumeration symbols are not a requirement.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1557,7 +1557,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- (3) For every Caption , there must be exactly one corresponding Picture or Table .",
|
||||
"text": "(3) For every Caption , there must be exactly one corresponding Picture or Table .",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1580,7 +1580,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- (4) Connected sub-pictures are grouped together in one Picture object.",
|
||||
"text": "(4) Connected sub-pictures are grouped together in one Picture object.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1603,7 +1603,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- (5) Formula numbers are included in a Formula object.",
|
||||
"text": "(5) Formula numbers are included in a Formula object.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1626,7 +1626,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- (6) Emphasised text (e.g. in italic or bold) at the beginning of a paragraph is not considered a Section-header , unless it appears exclusively on its own line.",
|
||||
"text": "(6) Emphasised text (e.g. in italic or bold) at the beginning of a paragraph is not considered a Section-header , unless it appears exclusively on its own line.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2507,7 +2507,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [1] Max G\u00f6bel, Tamir Hassan, Ermelinda Oro, and Giorgio Orsi. Icdar 2013 table competition. In 2013 12th International Conference on Document Analysis and Recognition , pages 1449-1453, 2013.",
|
||||
"text": "[1] Max G\u00f6bel, Tamir Hassan, Ermelinda Oro, and Giorgio Orsi. Icdar 2013 table competition. In 2013 12th International Conference on Document Analysis and Recognition , pages 1449-1453, 2013.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2530,7 +2530,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [2] Christian Clausner, Apostolos Antonacopoulos, and Stefan Pletschacher. Icdar2017 competition on recognition of documents with complex layouts rdcl2017. In 2017 14th IAPR International Conference on Document Analysis and Recognition (ICDAR) , volume 01, pages 1404-1410, 2017.",
|
||||
"text": "[2] Christian Clausner, Apostolos Antonacopoulos, and Stefan Pletschacher. Icdar2017 competition on recognition of documents with complex layouts rdcl2017. In 2017 14th IAPR International Conference on Document Analysis and Recognition (ICDAR) , volume 01, pages 1404-1410, 2017.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2553,7 +2553,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [3] Herv\u00e9 D\u00e9jean, Jean-Luc Meunier, Liangcai Gao, Yilun Huang, Yu Fang, Florian Kleber, and Eva-Maria Lang. ICDAR 2019 Competition on Table Detection and Recognition (cTDaR), April 2019. http://sac.founderit.com/.",
|
||||
"text": "[3] Herv\u00e9 D\u00e9jean, Jean-Luc Meunier, Liangcai Gao, Yilun Huang, Yu Fang, Florian Kleber, and Eva-Maria Lang. ICDAR 2019 Competition on Table Detection and Recognition (cTDaR), April 2019. http://sac.founderit.com/.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2576,7 +2576,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [4] Antonio Jimeno Yepes, Peter Zhong, and Douglas Burdick. Competition on scientific literature parsing. In Proceedings of the International Conference on Document Analysis and Recognition , ICDAR, pages 605-617. LNCS 12824, SpringerVerlag, sep 2021.",
|
||||
"text": "[4] Antonio Jimeno Yepes, Peter Zhong, and Douglas Burdick. Competition on scientific literature parsing. In Proceedings of the International Conference on Document Analysis and Recognition , ICDAR, pages 605-617. LNCS 12824, SpringerVerlag, sep 2021.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2599,7 +2599,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [5] Logan Markewich, Hao Zhang, Yubin Xing, Navid Lambert-Shirzad, Jiang Zhexin, Roy Lee, Zhi Li, and Seok-Bum Ko. Segmentation for document layout analysis: not dead yet. International Journal on Document Analysis and Recognition (IJDAR) , pages 1-11, 01 2022.",
|
||||
"text": "[5] Logan Markewich, Hao Zhang, Yubin Xing, Navid Lambert-Shirzad, Jiang Zhexin, Roy Lee, Zhi Li, and Seok-Bum Ko. Segmentation for document layout analysis: not dead yet. International Journal on Document Analysis and Recognition (IJDAR) , pages 1-11, 01 2022.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2622,7 +2622,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [6] Xu Zhong, Jianbin Tang, and Antonio Jimeno-Yepes. Publaynet: Largest dataset ever for document layout analysis. In Proceedings of the International Conference on Document Analysis and Recognition , ICDAR, pages 1015-1022, sep 2019.",
|
||||
"text": "[6] Xu Zhong, Jianbin Tang, and Antonio Jimeno-Yepes. Publaynet: Largest dataset ever for document layout analysis. In Proceedings of the International Conference on Document Analysis and Recognition , ICDAR, pages 1015-1022, sep 2019.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2645,7 +2645,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [7] Minghao Li, Yiheng Xu, Lei Cui, Shaohan Huang, Furu Wei, Zhoujun Li, and Ming Zhou. Docbank: A benchmark dataset for document layout analysis. In Proceedings of the 28th International Conference on Computational Linguistics , COLING, pages 949-960. International Committee on Computational Linguistics, dec 2020.",
|
||||
"text": "[7] Minghao Li, Yiheng Xu, Lei Cui, Shaohan Huang, Furu Wei, Zhoujun Li, and Ming Zhou. Docbank: A benchmark dataset for document layout analysis. In Proceedings of the 28th International Conference on Computational Linguistics , COLING, pages 949-960. International Committee on Computational Linguistics, dec 2020.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2668,7 +2668,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [8] Riaz Ahmad, Muhammad Tanvir Afzal, and M. Qadir. Information extraction from pdf sources based on rule-based system using integrated formats. In SemWebEval@ESWC , 2016.",
|
||||
"text": "[8] Riaz Ahmad, Muhammad Tanvir Afzal, and M. Qadir. Information extraction from pdf sources based on rule-based system using integrated formats. In SemWebEval@ESWC , 2016.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2691,7 +2691,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [9] Ross B. Girshick, Jeff Donahue, Trevor Darrell, and Jitendra Malik. Rich feature hierarchies for accurate object detection and semantic segmentation. In IEEE Conference on Computer Vision and Pattern Recognition , CVPR, pages 580-587. IEEE Computer Society, jun 2014.",
|
||||
"text": "[9] Ross B. Girshick, Jeff Donahue, Trevor Darrell, and Jitendra Malik. Rich feature hierarchies for accurate object detection and semantic segmentation. In IEEE Conference on Computer Vision and Pattern Recognition , CVPR, pages 580-587. IEEE Computer Society, jun 2014.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2714,7 +2714,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [10] Ross B. Girshick. Fast R-CNN. In 2015 IEEE International Conference on Computer Vision , ICCV, pages 1440-1448. IEEE Computer Society, dec 2015.",
|
||||
"text": "[10] Ross B. Girshick. Fast R-CNN. In 2015 IEEE International Conference on Computer Vision , ICCV, pages 1440-1448. IEEE Computer Society, dec 2015.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2737,7 +2737,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [11] Shaoqing Ren, Kaiming He, Ross Girshick, and Jian Sun. Faster r-cnn: Towards real-time object detection with region proposal networks. IEEE Transactions on Pattern Analysis and Machine Intelligence , 39(6):1137-1149, 2017.",
|
||||
"text": "[11] Shaoqing Ren, Kaiming He, Ross Girshick, and Jian Sun. Faster r-cnn: Towards real-time object detection with region proposal networks. IEEE Transactions on Pattern Analysis and Machine Intelligence , 39(6):1137-1149, 2017.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2760,7 +2760,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [12] Kaiming He, Georgia Gkioxari, Piotr Doll\u00e1r, and Ross B. Girshick. Mask R-CNN. In IEEE International Conference on Computer Vision , ICCV, pages 2980-2988. IEEE Computer Society, Oct 2017.",
|
||||
"text": "[12] Kaiming He, Georgia Gkioxari, Piotr Doll\u00e1r, and Ross B. Girshick. Mask R-CNN. In IEEE International Conference on Computer Vision , ICCV, pages 2980-2988. IEEE Computer Society, Oct 2017.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2783,7 +2783,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [13] Glenn Jocher, Alex Stoken, Ayush Chaurasia, Jirka Borovec, NanoCode012, TaoXie, Yonghye Kwon, Kalen Michael, Liu Changyu, Jiacong Fang, Abhiram V, Laughing, tkianai, yxNONG, Piotr Skalski, Adam Hogan, Jebastin Nadar, imyhxy, Lorenzo Mammana, Alex Wang, Cristi Fati, Diego Montes, Jan Hajek, Laurentiu",
|
||||
"text": "[13] Glenn Jocher, Alex Stoken, Ayush Chaurasia, Jirka Borovec, NanoCode012, TaoXie, Yonghye Kwon, Kalen Michael, Liu Changyu, Jiacong Fang, Abhiram V, Laughing, tkianai, yxNONG, Piotr Skalski, Adam Hogan, Jebastin Nadar, imyhxy, Lorenzo Mammana, Alex Wang, Cristi Fati, Diego Montes, Jan Hajek, Laurentiu",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2880,7 +2880,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [20] Shoubin Li, Xuyan Ma, Shuaiqun Pan, Jun Hu, Lin Shi, and Qing Wang. Vtlayout: Fusion of visual and text features for document layout analysis, 2021.",
|
||||
"text": "[20] Shoubin Li, Xuyan Ma, Shuaiqun Pan, Jun Hu, Lin Shi, and Qing Wang. Vtlayout: Fusion of visual and text features for document layout analysis, 2021.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2903,7 +2903,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [14] Nicolas Carion, Francisco Massa, Gabriel Synnaeve, Nicolas Usunier, Alexander Kirillov, and Sergey Zagoruyko. End-to-end object detection with transformers. CoRR , abs/2005.12872, 2020.",
|
||||
"text": "[14] Nicolas Carion, Francisco Massa, Gabriel Synnaeve, Nicolas Usunier, Alexander Kirillov, and Sergey Zagoruyko. End-to-end object detection with transformers. CoRR , abs/2005.12872, 2020.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2926,7 +2926,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [15] Mingxing Tan, Ruoming Pang, and Quoc V. Le. Efficientdet: Scalable and efficient object detection. CoRR , abs/1911.09070, 2019.",
|
||||
"text": "[15] Mingxing Tan, Ruoming Pang, and Quoc V. Le. Efficientdet: Scalable and efficient object detection. CoRR , abs/1911.09070, 2019.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2949,7 +2949,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [16] Tsung-Yi Lin, Michael Maire, Serge J. Belongie, Lubomir D. Bourdev, Ross B. Girshick, James Hays, Pietro Perona, Deva Ramanan, Piotr Doll\u00e1r, and C. Lawrence Zitnick. Microsoft COCO: common objects in context, 2014.",
|
||||
"text": "[16] Tsung-Yi Lin, Michael Maire, Serge J. Belongie, Lubomir D. Bourdev, Ross B. Girshick, James Hays, Pietro Perona, Deva Ramanan, Piotr Doll\u00e1r, and C. Lawrence Zitnick. Microsoft COCO: common objects in context, 2014.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2972,7 +2972,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [17] Yuxin Wu, Alexander Kirillov, Francisco Massa, Wan-Yen Lo, and Ross Girshick. Detectron2, 2019.",
|
||||
"text": "[17] Yuxin Wu, Alexander Kirillov, Francisco Massa, Wan-Yen Lo, and Ross Girshick. Detectron2, 2019.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2995,7 +2995,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [18] Nikolaos Livathinos, Cesar Berrospi, Maksym Lysak, Viktor Kuropiatnyk, Ahmed Nassar, Andre Carvalho, Michele Dolfi, Christoph Auer, Kasper Dinkla, and Peter W. J. Staar. Robust pdf document conversion using recurrent neural networks. In Proceedings of the 35th Conference on Artificial Intelligence , AAAI, pages 1513715145, feb 2021.",
|
||||
"text": "[18] Nikolaos Livathinos, Cesar Berrospi, Maksym Lysak, Viktor Kuropiatnyk, Ahmed Nassar, Andre Carvalho, Michele Dolfi, Christoph Auer, Kasper Dinkla, and Peter W. J. Staar. Robust pdf document conversion using recurrent neural networks. In Proceedings of the 35th Conference on Artificial Intelligence , AAAI, pages 1513715145, feb 2021.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3018,7 +3018,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [19] Yiheng Xu, Minghao Li, Lei Cui, Shaohan Huang, Furu Wei, and Ming Zhou. Layoutlm: Pre-training of text and layout for document image understanding. In Proceedings of the 26th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining , KDD, pages 1192-1200, New York, USA, 2020. Association for Computing Machinery.",
|
||||
"text": "[19] Yiheng Xu, Minghao Li, Lei Cui, Shaohan Huang, Furu Wei, and Ming Zhou. Layoutlm: Pre-training of text and layout for document image understanding. In Proceedings of the 26th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining , KDD, pages 1192-1200, New York, USA, 2020. Association for Computing Machinery.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3041,7 +3041,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [21] Peng Zhang, Can Li, Liang Qiao, Zhanzhan Cheng, Shiliang Pu, Yi Niu, and Fei Wu. Vsr: A unified framework for document layout analysis combining vision, semantics and relations, 2021.",
|
||||
"text": "[21] Peng Zhang, Can Li, Liang Qiao, Zhanzhan Cheng, Shiliang Pu, Yi Niu, and Fei Wu. Vsr: A unified framework for document layout analysis combining vision, semantics and relations, 2021.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3064,7 +3064,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [22] Peter W J Staar, Michele Dolfi, Christoph Auer, and Costas Bekas. Corpus conversion service: A machine learning platform to ingest documents at scale. In Proceedings of the 24th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining , KDD, pages 774-782. ACM, 2018.",
|
||||
"text": "[22] Peter W J Staar, Michele Dolfi, Christoph Auer, and Costas Bekas. Corpus conversion service: A machine learning platform to ingest documents at scale. In Proceedings of the 24th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining , KDD, pages 774-782. ACM, 2018.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3087,7 +3087,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- [23] Connor Shorten and Taghi M. Khoshgoftaar. A survey on image data augmentation for deep learning. Journal of Big Data , 6(1):60, 2019.",
|
||||
"text": "[23] Connor Shorten and Taghi M. Khoshgoftaar. A survey on image data augmentation for deep learning. Journal of Big Data , 6(1):60, 2019.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
|
68
tests/data/groundtruth/docling_v1/2206.01062.md
vendored
68
tests/data/groundtruth/docling_v1/2206.01062.md
vendored
@ -47,17 +47,17 @@ A key problem in the process of document conversion is to understand the structu
|
||||
|
||||
In this paper, we present the DocLayNet dataset. It provides pageby-page layout annotation ground-truth using bounding-boxes for 11 distinct class labels on 80863 unique document pages, of which a fraction carry double- or triple-annotations. DocLayNet is similar in spirit to PubLayNet and DocBank and will likewise be made available to the public 1 in order to stimulate the document-layout analysis community. It distinguishes itself in the following aspects:
|
||||
|
||||
- (1) Human Annotation : In contrast to PubLayNet and DocBank, we relied on human annotation instead of automation approaches to generate the data set.
|
||||
(1) Human Annotation : In contrast to PubLayNet and DocBank, we relied on human annotation instead of automation approaches to generate the data set.
|
||||
|
||||
- (2) Large Layout Variability : We include diverse and complex layouts from a large variety of public sources.
|
||||
(2) Large Layout Variability : We include diverse and complex layouts from a large variety of public sources.
|
||||
|
||||
- (3) Detailed Label Set : We define 11 class labels to distinguish layout features in high detail. PubLayNet provides 5 labels; DocBank provides 13, although not a superset of ours.
|
||||
(3) Detailed Label Set : We define 11 class labels to distinguish layout features in high detail. PubLayNet provides 5 labels; DocBank provides 13, although not a superset of ours.
|
||||
|
||||
- (4) Redundant Annotations : A fraction of the pages in the DocLayNet data set carry more than one human annotation.
|
||||
(4) Redundant Annotations : A fraction of the pages in the DocLayNet data set carry more than one human annotation.
|
||||
|
||||
This enables experimentation with annotation uncertainty and quality control analysis.
|
||||
|
||||
- (5) Pre-defined Train-, Test- & Validation-set : Like DocBank, we provide fixed train-, test- & validation-sets to ensure proportional representation of the class-labels. Further, we prevent leakage of unique layouts across sets, which has a large effect on model accuracy scores.
|
||||
(5) Pre-defined Train-, Test- & Validation-set : Like DocBank, we provide fixed train-, test- & validation-sets to ensure proportional representation of the class-labels. Further, we prevent leakage of unique layouts across sets, which has a large effect on model accuracy scores.
|
||||
|
||||
All aspects outlined above are detailed in Section 3. In Section 4, we will elaborate on how we designed and executed this large-scale human annotation campaign. We will also share key insights and lessons learned that might prove helpful for other parties planning to set up annotation campaigns.
|
||||
|
||||
@ -131,17 +131,17 @@ At first sight, the task of visual document-layout interpretation appears intuit
|
||||
|
||||
Obviously, this inconsistency in annotations is not desirable for datasets which are intended to be used for model training. To minimise these inconsistencies, we created a detailed annotation guideline. While perfect consistency across 40 annotation staff members is clearly not possible to achieve, we saw a huge improvement in annotation consistency after the introduction of our annotation guideline. A few selected, non-trivial highlights of the guideline are:
|
||||
|
||||
- (1) Every list-item is an individual object instance with class label List-item . This definition is different from PubLayNet and DocBank, where all list-items are grouped together into one List object.
|
||||
(1) Every list-item is an individual object instance with class label List-item . This definition is different from PubLayNet and DocBank, where all list-items are grouped together into one List object.
|
||||
|
||||
- (2) A List-item is a paragraph with hanging indentation. Singleline elements can qualify as List-item if the neighbour elements expose hanging indentation. Bullet or enumeration symbols are not a requirement.
|
||||
(2) A List-item is a paragraph with hanging indentation. Singleline elements can qualify as List-item if the neighbour elements expose hanging indentation. Bullet or enumeration symbols are not a requirement.
|
||||
|
||||
- (3) For every Caption , there must be exactly one corresponding Picture or Table .
|
||||
(3) For every Caption , there must be exactly one corresponding Picture or Table .
|
||||
|
||||
- (4) Connected sub-pictures are grouped together in one Picture object.
|
||||
(4) Connected sub-pictures are grouped together in one Picture object.
|
||||
|
||||
- (5) Formula numbers are included in a Formula object.
|
||||
(5) Formula numbers are included in a Formula object.
|
||||
|
||||
- (6) Emphasised text (e.g. in italic or bold) at the beginning of a paragraph is not considered a Section-header , unless it appears exclusively on its own line.
|
||||
(6) Emphasised text (e.g. in italic or bold) at the beginning of a paragraph is not considered a Section-header , unless it appears exclusively on its own line.
|
||||
|
||||
The complete annotation guideline is over 100 pages long and a detailed description is obviously out of scope for this paper. Nevertheless, it will be made publicly available alongside with DocLayNet for future reference.
|
||||
|
||||
@ -282,31 +282,31 @@ To date, there is still a significant gap between human and ML accuracy on the l
|
||||
|
||||
## REFERENCES
|
||||
|
||||
- [1] Max Göbel, Tamir Hassan, Ermelinda Oro, and Giorgio Orsi. Icdar 2013 table competition. In 2013 12th International Conference on Document Analysis and Recognition , pages 1449-1453, 2013.
|
||||
[1] Max Göbel, Tamir Hassan, Ermelinda Oro, and Giorgio Orsi. Icdar 2013 table competition. In 2013 12th International Conference on Document Analysis and Recognition , pages 1449-1453, 2013.
|
||||
|
||||
- [2] Christian Clausner, Apostolos Antonacopoulos, and Stefan Pletschacher. Icdar2017 competition on recognition of documents with complex layouts rdcl2017. In 2017 14th IAPR International Conference on Document Analysis and Recognition (ICDAR) , volume 01, pages 1404-1410, 2017.
|
||||
[2] Christian Clausner, Apostolos Antonacopoulos, and Stefan Pletschacher. Icdar2017 competition on recognition of documents with complex layouts rdcl2017. In 2017 14th IAPR International Conference on Document Analysis and Recognition (ICDAR) , volume 01, pages 1404-1410, 2017.
|
||||
|
||||
- [3] Hervé Déjean, Jean-Luc Meunier, Liangcai Gao, Yilun Huang, Yu Fang, Florian Kleber, and Eva-Maria Lang. ICDAR 2019 Competition on Table Detection and Recognition (cTDaR), April 2019. http://sac.founderit.com/.
|
||||
[3] Hervé Déjean, Jean-Luc Meunier, Liangcai Gao, Yilun Huang, Yu Fang, Florian Kleber, and Eva-Maria Lang. ICDAR 2019 Competition on Table Detection and Recognition (cTDaR), April 2019. http://sac.founderit.com/.
|
||||
|
||||
- [4] Antonio Jimeno Yepes, Peter Zhong, and Douglas Burdick. Competition on scientific literature parsing. In Proceedings of the International Conference on Document Analysis and Recognition , ICDAR, pages 605-617. LNCS 12824, SpringerVerlag, sep 2021.
|
||||
[4] Antonio Jimeno Yepes, Peter Zhong, and Douglas Burdick. Competition on scientific literature parsing. In Proceedings of the International Conference on Document Analysis and Recognition , ICDAR, pages 605-617. LNCS 12824, SpringerVerlag, sep 2021.
|
||||
|
||||
- [5] Logan Markewich, Hao Zhang, Yubin Xing, Navid Lambert-Shirzad, Jiang Zhexin, Roy Lee, Zhi Li, and Seok-Bum Ko. Segmentation for document layout analysis: not dead yet. International Journal on Document Analysis and Recognition (IJDAR) , pages 1-11, 01 2022.
|
||||
[5] Logan Markewich, Hao Zhang, Yubin Xing, Navid Lambert-Shirzad, Jiang Zhexin, Roy Lee, Zhi Li, and Seok-Bum Ko. Segmentation for document layout analysis: not dead yet. International Journal on Document Analysis and Recognition (IJDAR) , pages 1-11, 01 2022.
|
||||
|
||||
- [6] Xu Zhong, Jianbin Tang, and Antonio Jimeno-Yepes. Publaynet: Largest dataset ever for document layout analysis. In Proceedings of the International Conference on Document Analysis and Recognition , ICDAR, pages 1015-1022, sep 2019.
|
||||
[6] Xu Zhong, Jianbin Tang, and Antonio Jimeno-Yepes. Publaynet: Largest dataset ever for document layout analysis. In Proceedings of the International Conference on Document Analysis and Recognition , ICDAR, pages 1015-1022, sep 2019.
|
||||
|
||||
- [7] Minghao Li, Yiheng Xu, Lei Cui, Shaohan Huang, Furu Wei, Zhoujun Li, and Ming Zhou. Docbank: A benchmark dataset for document layout analysis. In Proceedings of the 28th International Conference on Computational Linguistics , COLING, pages 949-960. International Committee on Computational Linguistics, dec 2020.
|
||||
[7] Minghao Li, Yiheng Xu, Lei Cui, Shaohan Huang, Furu Wei, Zhoujun Li, and Ming Zhou. Docbank: A benchmark dataset for document layout analysis. In Proceedings of the 28th International Conference on Computational Linguistics , COLING, pages 949-960. International Committee on Computational Linguistics, dec 2020.
|
||||
|
||||
- [8] Riaz Ahmad, Muhammad Tanvir Afzal, and M. Qadir. Information extraction from pdf sources based on rule-based system using integrated formats. In SemWebEval@ESWC , 2016.
|
||||
[8] Riaz Ahmad, Muhammad Tanvir Afzal, and M. Qadir. Information extraction from pdf sources based on rule-based system using integrated formats. In SemWebEval@ESWC , 2016.
|
||||
|
||||
- [9] Ross B. Girshick, Jeff Donahue, Trevor Darrell, and Jitendra Malik. Rich feature hierarchies for accurate object detection and semantic segmentation. In IEEE Conference on Computer Vision and Pattern Recognition , CVPR, pages 580-587. IEEE Computer Society, jun 2014.
|
||||
[9] Ross B. Girshick, Jeff Donahue, Trevor Darrell, and Jitendra Malik. Rich feature hierarchies for accurate object detection and semantic segmentation. In IEEE Conference on Computer Vision and Pattern Recognition , CVPR, pages 580-587. IEEE Computer Society, jun 2014.
|
||||
|
||||
- [10] Ross B. Girshick. Fast R-CNN. In 2015 IEEE International Conference on Computer Vision , ICCV, pages 1440-1448. IEEE Computer Society, dec 2015.
|
||||
[10] Ross B. Girshick. Fast R-CNN. In 2015 IEEE International Conference on Computer Vision , ICCV, pages 1440-1448. IEEE Computer Society, dec 2015.
|
||||
|
||||
- [11] Shaoqing Ren, Kaiming He, Ross Girshick, and Jian Sun. Faster r-cnn: Towards real-time object detection with region proposal networks. IEEE Transactions on Pattern Analysis and Machine Intelligence , 39(6):1137-1149, 2017.
|
||||
[11] Shaoqing Ren, Kaiming He, Ross Girshick, and Jian Sun. Faster r-cnn: Towards real-time object detection with region proposal networks. IEEE Transactions on Pattern Analysis and Machine Intelligence , 39(6):1137-1149, 2017.
|
||||
|
||||
- [12] Kaiming He, Georgia Gkioxari, Piotr Dollár, and Ross B. Girshick. Mask R-CNN. In IEEE International Conference on Computer Vision , ICCV, pages 2980-2988. IEEE Computer Society, Oct 2017.
|
||||
[12] Kaiming He, Georgia Gkioxari, Piotr Dollár, and Ross B. Girshick. Mask R-CNN. In IEEE International Conference on Computer Vision , ICCV, pages 2980-2988. IEEE Computer Society, Oct 2017.
|
||||
|
||||
- [13] Glenn Jocher, Alex Stoken, Ayush Chaurasia, Jirka Borovec, NanoCode012, TaoXie, Yonghye Kwon, Kalen Michael, Liu Changyu, Jiacong Fang, Abhiram V, Laughing, tkianai, yxNONG, Piotr Skalski, Adam Hogan, Jebastin Nadar, imyhxy, Lorenzo Mammana, Alex Wang, Cristi Fati, Diego Montes, Jan Hajek, Laurentiu
|
||||
[13] Glenn Jocher, Alex Stoken, Ayush Chaurasia, Jirka Borovec, NanoCode012, TaoXie, Yonghye Kwon, Kalen Michael, Liu Changyu, Jiacong Fang, Abhiram V, Laughing, tkianai, yxNONG, Piotr Skalski, Adam Hogan, Jebastin Nadar, imyhxy, Lorenzo Mammana, Alex Wang, Cristi Fati, Diego Montes, Jan Hajek, Laurentiu
|
||||
|
||||
Text Caption List-Item Formula Table Section-Header Picture Page-Header Page-Footer Title
|
||||
<!-- image -->
|
||||
@ -315,22 +315,22 @@ Figure 6: Example layout predictions on selected pages from the DocLayNet test-s
|
||||
|
||||
Diaconu, Mai Thanh Minh, Marc, albinxavi, fatih, oleg, and wanghao yang. ultralytics/yolov5: v6.0 - yolov5n nano models, roboflow integration, tensorflow export, opencv dnn support, October 2021.
|
||||
|
||||
- [20] Shoubin Li, Xuyan Ma, Shuaiqun Pan, Jun Hu, Lin Shi, and Qing Wang. Vtlayout: Fusion of visual and text features for document layout analysis, 2021.
|
||||
[20] Shoubin Li, Xuyan Ma, Shuaiqun Pan, Jun Hu, Lin Shi, and Qing Wang. Vtlayout: Fusion of visual and text features for document layout analysis, 2021.
|
||||
|
||||
- [14] Nicolas Carion, Francisco Massa, Gabriel Synnaeve, Nicolas Usunier, Alexander Kirillov, and Sergey Zagoruyko. End-to-end object detection with transformers. CoRR , abs/2005.12872, 2020.
|
||||
[14] Nicolas Carion, Francisco Massa, Gabriel Synnaeve, Nicolas Usunier, Alexander Kirillov, and Sergey Zagoruyko. End-to-end object detection with transformers. CoRR , abs/2005.12872, 2020.
|
||||
|
||||
- [15] Mingxing Tan, Ruoming Pang, and Quoc V. Le. Efficientdet: Scalable and efficient object detection. CoRR , abs/1911.09070, 2019.
|
||||
[15] Mingxing Tan, Ruoming Pang, and Quoc V. Le. Efficientdet: Scalable and efficient object detection. CoRR , abs/1911.09070, 2019.
|
||||
|
||||
- [16] Tsung-Yi Lin, Michael Maire, Serge J. Belongie, Lubomir D. Bourdev, Ross B. Girshick, James Hays, Pietro Perona, Deva Ramanan, Piotr Dollár, and C. Lawrence Zitnick. Microsoft COCO: common objects in context, 2014.
|
||||
[16] Tsung-Yi Lin, Michael Maire, Serge J. Belongie, Lubomir D. Bourdev, Ross B. Girshick, James Hays, Pietro Perona, Deva Ramanan, Piotr Dollár, and C. Lawrence Zitnick. Microsoft COCO: common objects in context, 2014.
|
||||
|
||||
- [17] Yuxin Wu, Alexander Kirillov, Francisco Massa, Wan-Yen Lo, and Ross Girshick. Detectron2, 2019.
|
||||
[17] Yuxin Wu, Alexander Kirillov, Francisco Massa, Wan-Yen Lo, and Ross Girshick. Detectron2, 2019.
|
||||
|
||||
- [18] Nikolaos Livathinos, Cesar Berrospi, Maksym Lysak, Viktor Kuropiatnyk, Ahmed Nassar, Andre Carvalho, Michele Dolfi, Christoph Auer, Kasper Dinkla, and Peter W. J. Staar. Robust pdf document conversion using recurrent neural networks. In Proceedings of the 35th Conference on Artificial Intelligence , AAAI, pages 1513715145, feb 2021.
|
||||
[18] Nikolaos Livathinos, Cesar Berrospi, Maksym Lysak, Viktor Kuropiatnyk, Ahmed Nassar, Andre Carvalho, Michele Dolfi, Christoph Auer, Kasper Dinkla, and Peter W. J. Staar. Robust pdf document conversion using recurrent neural networks. In Proceedings of the 35th Conference on Artificial Intelligence , AAAI, pages 1513715145, feb 2021.
|
||||
|
||||
- [19] Yiheng Xu, Minghao Li, Lei Cui, Shaohan Huang, Furu Wei, and Ming Zhou. Layoutlm: Pre-training of text and layout for document image understanding. In Proceedings of the 26th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining , KDD, pages 1192-1200, New York, USA, 2020. Association for Computing Machinery.
|
||||
[19] Yiheng Xu, Minghao Li, Lei Cui, Shaohan Huang, Furu Wei, and Ming Zhou. Layoutlm: Pre-training of text and layout for document image understanding. In Proceedings of the 26th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining , KDD, pages 1192-1200, New York, USA, 2020. Association for Computing Machinery.
|
||||
|
||||
- [21] Peng Zhang, Can Li, Liang Qiao, Zhanzhan Cheng, Shiliang Pu, Yi Niu, and Fei Wu. Vsr: A unified framework for document layout analysis combining vision, semantics and relations, 2021.
|
||||
[21] Peng Zhang, Can Li, Liang Qiao, Zhanzhan Cheng, Shiliang Pu, Yi Niu, and Fei Wu. Vsr: A unified framework for document layout analysis combining vision, semantics and relations, 2021.
|
||||
|
||||
- [22] Peter W J Staar, Michele Dolfi, Christoph Auer, and Costas Bekas. Corpus conversion service: A machine learning platform to ingest documents at scale. In Proceedings of the 24th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining , KDD, pages 774-782. ACM, 2018.
|
||||
[22] Peter W J Staar, Michele Dolfi, Christoph Auer, and Costas Bekas. Corpus conversion service: A machine learning platform to ingest documents at scale. In Proceedings of the 24th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining , KDD, pages 774-782. ACM, 2018.
|
||||
|
||||
- [23] Connor Shorten and Taghi M. Khoshgoftaar. A survey on image data augmentation for deep learning. Journal of Big Data , 6(1):60, 2019.
|
||||
[23] Connor Shorten and Taghi M. Khoshgoftaar. A survey on image data augmentation for deep learning. Journal of Big Data , 6(1):60, 2019.
|
@ -42,11 +42,11 @@
|
||||
<subtitle-level-1><location><page_6><loc_22><loc_40><loc_43><loc_41></location>4.1 Language Definition</subtitle-level-1>
|
||||
<paragraph><location><page_6><loc_22><loc_34><loc_79><loc_38></location>In Figure 3, we illustrate how the OTSL is defined. In essence, the OTSL defines only 5 tokens that directly describe a tabular structure based on an atomic 2D grid.</paragraph>
|
||||
<paragraph><location><page_6><loc_24><loc_33><loc_67><loc_34></location>The OTSL vocabulary is comprised of the following tokens:</paragraph>
|
||||
<paragraph><location><page_6><loc_23><loc_30><loc_75><loc_31></location>- -"C" cell a new table cell that either has or does not have cell content</paragraph>
|
||||
<paragraph><location><page_6><loc_23><loc_27><loc_79><loc_29></location>- -"L" cell left-looking cell , merging with the left neighbor cell to create a span</paragraph>
|
||||
<paragraph><location><page_6><loc_23><loc_24><loc_79><loc_26></location>- -"U" cell up-looking cell , merging with the upper neighbor cell to create a span</paragraph>
|
||||
<paragraph><location><page_6><loc_23><loc_22><loc_74><loc_23></location>- -"X" cell cross cell , to merge with both left and upper neighbor cells</paragraph>
|
||||
<paragraph><location><page_6><loc_23><loc_20><loc_54><loc_21></location>- -"NL" new-line , switch to the next row.</paragraph>
|
||||
<paragraph><location><page_6><loc_23><loc_30><loc_75><loc_31></location>-"C" cell a new table cell that either has or does not have cell content</paragraph>
|
||||
<paragraph><location><page_6><loc_23><loc_27><loc_79><loc_29></location>-"L" cell left-looking cell , merging with the left neighbor cell to create a span</paragraph>
|
||||
<paragraph><location><page_6><loc_23><loc_24><loc_79><loc_26></location>-"U" cell up-looking cell , merging with the upper neighbor cell to create a span</paragraph>
|
||||
<paragraph><location><page_6><loc_23><loc_22><loc_74><loc_23></location>-"X" cell cross cell , to merge with both left and upper neighbor cells</paragraph>
|
||||
<paragraph><location><page_6><loc_23><loc_20><loc_54><loc_21></location>-"NL" new-line , switch to the next row.</paragraph>
|
||||
<paragraph><location><page_6><loc_22><loc_16><loc_79><loc_19></location>A notable attribute of OTSL is that it has the capability of achieving lossless conversion to HTML.</paragraph>
|
||||
<figure>
|
||||
<location><page_7><loc_27><loc_65><loc_73><loc_79></location>
|
||||
@ -55,13 +55,13 @@
|
||||
<caption><location><page_7><loc_22><loc_80><loc_79><loc_84></location>Fig. 3. OTSL description of table structure: A - table example; B - graphical representation of table structure; C - mapping structure on a grid; D - OTSL structure encoding; E - explanation on cell encoding</caption>
|
||||
<subtitle-level-1><location><page_7><loc_22><loc_60><loc_40><loc_61></location>4.2 Language Syntax</subtitle-level-1>
|
||||
<paragraph><location><page_7><loc_22><loc_58><loc_59><loc_59></location>The OTSL representation follows these syntax rules:</paragraph>
|
||||
<paragraph><location><page_7><loc_23><loc_54><loc_79><loc_56></location>- 1. Left-looking cell rule : The left neighbour of an "L" cell must be either another "L" cell or a "C" cell.</paragraph>
|
||||
<paragraph><location><page_7><loc_23><loc_51><loc_79><loc_53></location>- 2. Up-looking cell rule : The upper neighbour of a "U" cell must be either another "U" cell or a "C" cell.</paragraph>
|
||||
<paragraph><location><page_7><loc_23><loc_54><loc_79><loc_56></location>1. Left-looking cell rule : The left neighbour of an "L" cell must be either another "L" cell or a "C" cell.</paragraph>
|
||||
<paragraph><location><page_7><loc_23><loc_51><loc_79><loc_53></location>2. Up-looking cell rule : The upper neighbour of a "U" cell must be either another "U" cell or a "C" cell.</paragraph>
|
||||
<subtitle-level-1><location><page_7><loc_23><loc_49><loc_37><loc_50></location>3. Cross cell rule :</subtitle-level-1>
|
||||
<paragraph><location><page_7><loc_25><loc_44><loc_79><loc_49></location>- The left neighbour of an "X" cell must be either another "X" cell or a "U" cell, and the upper neighbour of an "X" cell must be either another "X" cell or an "L" cell.</paragraph>
|
||||
<paragraph><location><page_7><loc_23><loc_43><loc_78><loc_44></location>- 4. First row rule : Only "L" cells and "C" cells are allowed in the first row.</paragraph>
|
||||
<paragraph><location><page_7><loc_23><loc_40><loc_79><loc_43></location>- 5. First column rule : Only "U" cells and "C" cells are allowed in the first column.</paragraph>
|
||||
<paragraph><location><page_7><loc_23><loc_37><loc_79><loc_40></location>- 6. Rectangular rule : The table representation is always rectangular - all rows must have an equal number of tokens, terminated with "NL" token.</paragraph>
|
||||
<paragraph><location><page_7><loc_25><loc_44><loc_79><loc_49></location>The left neighbour of an "X" cell must be either another "X" cell or a "U" cell, and the upper neighbour of an "X" cell must be either another "X" cell or an "L" cell.</paragraph>
|
||||
<paragraph><location><page_7><loc_23><loc_43><loc_78><loc_44></location>4. First row rule : Only "L" cells and "C" cells are allowed in the first row.</paragraph>
|
||||
<paragraph><location><page_7><loc_23><loc_40><loc_79><loc_43></location>5. First column rule : Only "U" cells and "C" cells are allowed in the first column.</paragraph>
|
||||
<paragraph><location><page_7><loc_23><loc_37><loc_79><loc_40></location>6. Rectangular rule : The table representation is always rectangular - all rows must have an equal number of tokens, terminated with "NL" token.</paragraph>
|
||||
<paragraph><location><page_7><loc_22><loc_19><loc_79><loc_35></location>The application of these rules gives OTSL a set of unique properties. First of all, the OTSL enforces a strictly rectangular structure representation, where every new-line token starts a new row. As a consequence, all rows and all columns have exactly the same number of tokens, irrespective of cell spans. Secondly, the OTSL representation is unambiguous: Every table structure is represented in one way. In this representation every table cell corresponds to a "C"-cell token, which in case of spans is always located in the top-left corner of the table cell definition. Third, OTSL syntax rules are only backward-looking. As a consequence, every predicted token can be validated straight during sequence generation by looking at the previously predicted sequence. As such, OTSL can guarantee that every predicted sequence is syntactically valid.</paragraph>
|
||||
<paragraph><location><page_7><loc_22><loc_16><loc_79><loc_19></location>These characteristics can be easily learned by sequence generator networks, as we demonstrate further below. We find strong indications that this pattern</paragraph>
|
||||
<paragraph><location><page_8><loc_22><loc_82><loc_79><loc_85></location>reduces significantly the column drift seen in the HTML based models (see Figure 5).</paragraph>
|
||||
@ -121,27 +121,27 @@
|
||||
<paragraph><location><page_12><loc_22><loc_59><loc_79><loc_74></location>First and foremost, given the same network configuration, inference time for a table-structure prediction is about 2 times faster compared to the conventional HTML approach. This is primarily owed to the shorter sequence length of the OTSL representation. Additional performance benefits can be obtained with HPO (hyper parameter optimization). As we demonstrate in our experiments, models trained on OTSL can be significantly smaller, e.g. by reducing the number of encoder and decoder layers, while preserving comparatively good prediction quality. This can further improve inference performance, yielding 5-6 times faster inference speed in OTSL with prediction quality comparable to models trained on HTML (see Table 1).</paragraph>
|
||||
<paragraph><location><page_12><loc_22><loc_41><loc_79><loc_59></location>Secondly, OTSL has more inherent structure and a significantly restricted vocabulary size. This allows autoregressive models to perform better in the TED metric, but especially with regards to prediction accuracy of the table-cell bounding boxes (see Table 2). As shown in Figure 5, we observe that the OTSL drastically reduces the drift for table cell bounding boxes at high row count and in sparse tables. This leads to more accurate predictions and a significant reduction in post-processing complexity, which is an undesired necessity in HTML-based Im2Seq models. Significant novelty lies in OTSL syntactical rules, which are few, simple and always backwards looking. Each new token can be validated only by analyzing the sequence of previous tokens, without requiring the entire sequence to detect mistakes. This in return allows to perform structural error detection and correction on-the-fly during sequence generation.</paragraph>
|
||||
<subtitle-level-1><location><page_12><loc_22><loc_36><loc_32><loc_38></location>References</subtitle-level-1>
|
||||
<paragraph><location><page_12><loc_23><loc_29><loc_79><loc_34></location>- 1. Auer, C., Dolfi, M., Carvalho, A., Ramis, C.B., Staar, P.W.J.: Delivering document conversion as a cloud service with high throughput and responsiveness. CoRR abs/2206.00785 (2022). https://doi.org/10.48550/arXiv.2206.00785 , https://doi.org/10.48550/arXiv.2206.00785</paragraph>
|
||||
<paragraph><location><page_12><loc_23><loc_23><loc_79><loc_28></location>- 2. Chen, B., Peng, D., Zhang, J., Ren, Y., Jin, L.: Complex table structure recognition in the wild using transformer and identity matrix-based augmentation. In: Porwal, U., Fornés, A., Shafait, F. (eds.) Frontiers in Handwriting Recognition. pp. 545561. Springer International Publishing, Cham (2022)</paragraph>
|
||||
<paragraph><location><page_12><loc_23><loc_20><loc_79><loc_23></location>- 3. Chi, Z., Huang, H., Xu, H.D., Yu, H., Yin, W., Mao, X.L.: Complicated table structure recognition. arXiv preprint arXiv:1908.04729 (2019)</paragraph>
|
||||
<paragraph><location><page_12><loc_23><loc_16><loc_79><loc_20></location>- 4. Deng, Y., Rosenberg, D., Mann, G.: Challenges in end-to-end neural scientific table recognition. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 894-901. IEEE (2019)</paragraph>
|
||||
<paragraph><location><page_13><loc_23><loc_81><loc_79><loc_85></location>- 5. Kayal, P., Anand, M., Desai, H., Singh, M.: Tables to latex: structure and content extraction from scientific tables. International Journal on Document Analysis and Recognition (IJDAR) pp. 1-10 (2022)</paragraph>
|
||||
<paragraph><location><page_13><loc_23><loc_76><loc_79><loc_81></location>- 6. Lee, E., Kwon, J., Yang, H., Park, J., Lee, S., Koo, H.I., Cho, N.I.: Table structure recognition based on grid shape graph. In: 2022 Asia-Pacific Signal and Information Processing Association Annual Summit and Conference (APSIPA ASC). pp. 18681873. IEEE (2022)</paragraph>
|
||||
<paragraph><location><page_13><loc_23><loc_73><loc_79><loc_75></location>- 7. Li, M., Cui, L., Huang, S., Wei, F., Zhou, M., Li, Z.: Tablebank: A benchmark dataset for table detection and recognition (2019)</paragraph>
|
||||
<paragraph><location><page_13><loc_23><loc_66><loc_79><loc_72></location>- 8. Livathinos, N., Berrospi, C., Lysak, M., Kuropiatnyk, V., Nassar, A., Carvalho, A., Dolfi, M., Auer, C., Dinkla, K., Staar, P.: Robust pdf document conversion using recurrent neural networks. Proceedings of the AAAI Conference on Artificial Intelligence 35 (17), 15137-15145 (May 2021), https://ojs.aaai.org/index.php/ AAAI/article/view/17777</paragraph>
|
||||
<paragraph><location><page_13><loc_23><loc_62><loc_79><loc_66></location>- 9. Nassar, A., Livathinos, N., Lysak, M., Staar, P.: Tableformer: Table structure understanding with transformers. In: Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). pp. 4614-4623 (June 2022)</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_53><loc_79><loc_61></location>- 10. Pfitzmann, B., Auer, C., Dolfi, M., Nassar, A.S., Staar, P.W.J.: Doclaynet: A large human-annotated dataset for document-layout segmentation. In: Zhang, A., Rangwala, H. (eds.) KDD '22: The 28th ACM SIGKDD Conference on Knowledge Discovery and Data Mining, Washington, DC, USA, August 14 - 18, 2022. pp. 3743-3751. ACM (2022). https://doi.org/10.1145/3534678.3539043 , https:// doi.org/10.1145/3534678.3539043</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_48><loc_79><loc_53></location>- 11. Prasad, D., Gadpal, A., Kapadni, K., Visave, M., Sultanpure, K.: Cascadetabnet: An approach for end to end table detection and structure recognition from imagebased documents. In: Proceedings of the IEEE/CVF conference on computer vision and pattern recognition workshops. pp. 572-573 (2020)</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_42><loc_79><loc_48></location>- 12. Schreiber, S., Agne, S., Wolf, I., Dengel, A., Ahmed, S.: Deepdesrt: Deep learning for detection and structure recognition of tables in document images. In: 2017 14th IAPR international conference on document analysis and recognition (ICDAR). vol. 1, pp. 1162-1167. IEEE (2017)</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_37><loc_79><loc_42></location>- 13. Siddiqui, S.A., Fateh, I.A., Rizvi, S.T.R., Dengel, A., Ahmed, S.: Deeptabstr: Deep learning based table structure recognition. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 1403-1409 (2019). https:// doi.org/10.1109/ICDAR.2019.00226</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_31><loc_79><loc_36></location>- 14. Smock, B., Pesala, R., Abraham, R.: PubTables-1M: Towards comprehensive table extraction from unstructured documents. In: Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). pp. 4634-4642 (June 2022)</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_23><loc_79><loc_31></location>- 15. Staar, P.W.J., Dolfi, M., Auer, C., Bekas, C.: Corpus conversion service: A machine learning platform to ingest documents at scale. In: Proceedings of the 24th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining. pp. 774-782. KDD '18, Association for Computing Machinery, New York, NY, USA (2018). https://doi.org/10.1145/3219819.3219834 , https://doi.org/10. 1145/3219819.3219834</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_20><loc_79><loc_23></location>- 16. Wang, X.: Tabular Abstraction, Editing, and Formatting. Ph.D. thesis, CAN (1996), aAINN09397</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_16><loc_79><loc_20></location>- 17. Xue, W., Li, Q., Tao, D.: Res2tim: Reconstruct syntactic structures from table images. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 749-755. IEEE (2019)</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_81><loc_79><loc_85></location>- 18. Xue, W., Yu, B., Wang, W., Tao, D., Li, Q.: Tgrnet: A table graph reconstruction network for table structure recognition. In: Proceedings of the IEEE/CVF International Conference on Computer Vision. pp. 1295-1304 (2021)</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_76><loc_79><loc_81></location>- 19. Ye, J., Qi, X., He, Y., Chen, Y., Gu, D., Gao, P., Xiao, R.: Pingan-vcgroup's solution for icdar 2021 competition on scientific literature parsing task b: Table recognition to html (2021). https://doi.org/10.48550/ARXIV.2105.01848 , https://arxiv.org/abs/2105.01848</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_73><loc_79><loc_75></location>- 20. Zhang, Z., Zhang, J., Du, J., Wang, F.: Split, embed and merge: An accurate table structure recognizer. Pattern Recognition 126 , 108565 (2022)</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_66><loc_79><loc_72></location>- 21. Zheng, X., Burdick, D., Popa, L., Zhong, X., Wang, N.X.R.: Global table extractor (gte): A framework for joint table identification and cell structure recognition using visual context. In: 2021 IEEE Winter Conference on Applications of Computer Vision (WACV). pp. 697-706 (2021). https://doi.org/10.1109/WACV48630.2021. 00074</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_60><loc_79><loc_66></location>- 22. Zhong, X., ShafieiBavani, E., Jimeno Yepes, A.: Image-based table recognition: Data, model, and evaluation. In: Vedaldi, A., Bischof, H., Brox, T., Frahm, J.M. (eds.) Computer Vision - ECCV 2020. pp. 564-580. Springer International Publishing, Cham (2020)</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_56><loc_79><loc_60></location>- 23. Zhong, X., Tang, J., Yepes, A.J.: Publaynet: largest dataset ever for document layout analysis. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 1015-1022. IEEE (2019)</paragraph>
|
||||
<paragraph><location><page_12><loc_23><loc_29><loc_79><loc_34></location>1. Auer, C., Dolfi, M., Carvalho, A., Ramis, C.B., Staar, P.W.J.: Delivering document conversion as a cloud service with high throughput and responsiveness. CoRR abs/2206.00785 (2022). https://doi.org/10.48550/arXiv.2206.00785 , https://doi.org/10.48550/arXiv.2206.00785</paragraph>
|
||||
<paragraph><location><page_12><loc_23><loc_23><loc_79><loc_28></location>2. Chen, B., Peng, D., Zhang, J., Ren, Y., Jin, L.: Complex table structure recognition in the wild using transformer and identity matrix-based augmentation. In: Porwal, U., Fornés, A., Shafait, F. (eds.) Frontiers in Handwriting Recognition. pp. 545561. Springer International Publishing, Cham (2022)</paragraph>
|
||||
<paragraph><location><page_12><loc_23><loc_20><loc_79><loc_23></location>3. Chi, Z., Huang, H., Xu, H.D., Yu, H., Yin, W., Mao, X.L.: Complicated table structure recognition. arXiv preprint arXiv:1908.04729 (2019)</paragraph>
|
||||
<paragraph><location><page_12><loc_23><loc_16><loc_79><loc_20></location>4. Deng, Y., Rosenberg, D., Mann, G.: Challenges in end-to-end neural scientific table recognition. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 894-901. IEEE (2019)</paragraph>
|
||||
<paragraph><location><page_13><loc_23><loc_81><loc_79><loc_85></location>5. Kayal, P., Anand, M., Desai, H., Singh, M.: Tables to latex: structure and content extraction from scientific tables. International Journal on Document Analysis and Recognition (IJDAR) pp. 1-10 (2022)</paragraph>
|
||||
<paragraph><location><page_13><loc_23><loc_76><loc_79><loc_81></location>6. Lee, E., Kwon, J., Yang, H., Park, J., Lee, S., Koo, H.I., Cho, N.I.: Table structure recognition based on grid shape graph. In: 2022 Asia-Pacific Signal and Information Processing Association Annual Summit and Conference (APSIPA ASC). pp. 18681873. IEEE (2022)</paragraph>
|
||||
<paragraph><location><page_13><loc_23><loc_73><loc_79><loc_75></location>7. Li, M., Cui, L., Huang, S., Wei, F., Zhou, M., Li, Z.: Tablebank: A benchmark dataset for table detection and recognition (2019)</paragraph>
|
||||
<paragraph><location><page_13><loc_23><loc_66><loc_79><loc_72></location>8. Livathinos, N., Berrospi, C., Lysak, M., Kuropiatnyk, V., Nassar, A., Carvalho, A., Dolfi, M., Auer, C., Dinkla, K., Staar, P.: Robust pdf document conversion using recurrent neural networks. Proceedings of the AAAI Conference on Artificial Intelligence 35 (17), 15137-15145 (May 2021), https://ojs.aaai.org/index.php/ AAAI/article/view/17777</paragraph>
|
||||
<paragraph><location><page_13><loc_23><loc_62><loc_79><loc_66></location>9. Nassar, A., Livathinos, N., Lysak, M., Staar, P.: Tableformer: Table structure understanding with transformers. In: Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). pp. 4614-4623 (June 2022)</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_53><loc_79><loc_61></location>10. Pfitzmann, B., Auer, C., Dolfi, M., Nassar, A.S., Staar, P.W.J.: Doclaynet: A large human-annotated dataset for document-layout segmentation. In: Zhang, A., Rangwala, H. (eds.) KDD '22: The 28th ACM SIGKDD Conference on Knowledge Discovery and Data Mining, Washington, DC, USA, August 14 - 18, 2022. pp. 3743-3751. ACM (2022). https://doi.org/10.1145/3534678.3539043 , https:// doi.org/10.1145/3534678.3539043</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_48><loc_79><loc_53></location>11. Prasad, D., Gadpal, A., Kapadni, K., Visave, M., Sultanpure, K.: Cascadetabnet: An approach for end to end table detection and structure recognition from imagebased documents. In: Proceedings of the IEEE/CVF conference on computer vision and pattern recognition workshops. pp. 572-573 (2020)</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_42><loc_79><loc_48></location>12. Schreiber, S., Agne, S., Wolf, I., Dengel, A., Ahmed, S.: Deepdesrt: Deep learning for detection and structure recognition of tables in document images. In: 2017 14th IAPR international conference on document analysis and recognition (ICDAR). vol. 1, pp. 1162-1167. IEEE (2017)</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_37><loc_79><loc_42></location>13. Siddiqui, S.A., Fateh, I.A., Rizvi, S.T.R., Dengel, A., Ahmed, S.: Deeptabstr: Deep learning based table structure recognition. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 1403-1409 (2019). https:// doi.org/10.1109/ICDAR.2019.00226</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_31><loc_79><loc_36></location>14. Smock, B., Pesala, R., Abraham, R.: PubTables-1M: Towards comprehensive table extraction from unstructured documents. In: Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). pp. 4634-4642 (June 2022)</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_23><loc_79><loc_31></location>15. Staar, P.W.J., Dolfi, M., Auer, C., Bekas, C.: Corpus conversion service: A machine learning platform to ingest documents at scale. In: Proceedings of the 24th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining. pp. 774-782. KDD '18, Association for Computing Machinery, New York, NY, USA (2018). https://doi.org/10.1145/3219819.3219834 , https://doi.org/10. 1145/3219819.3219834</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_20><loc_79><loc_23></location>16. Wang, X.: Tabular Abstraction, Editing, and Formatting. Ph.D. thesis, CAN (1996), aAINN09397</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_16><loc_79><loc_20></location>17. Xue, W., Li, Q., Tao, D.: Res2tim: Reconstruct syntactic structures from table images. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 749-755. IEEE (2019)</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_81><loc_79><loc_85></location>18. Xue, W., Yu, B., Wang, W., Tao, D., Li, Q.: Tgrnet: A table graph reconstruction network for table structure recognition. In: Proceedings of the IEEE/CVF International Conference on Computer Vision. pp. 1295-1304 (2021)</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_76><loc_79><loc_81></location>19. Ye, J., Qi, X., He, Y., Chen, Y., Gu, D., Gao, P., Xiao, R.: Pingan-vcgroup's solution for icdar 2021 competition on scientific literature parsing task b: Table recognition to html (2021). https://doi.org/10.48550/ARXIV.2105.01848 , https://arxiv.org/abs/2105.01848</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_73><loc_79><loc_75></location>20. Zhang, Z., Zhang, J., Du, J., Wang, F.: Split, embed and merge: An accurate table structure recognizer. Pattern Recognition 126 , 108565 (2022)</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_66><loc_79><loc_72></location>21. Zheng, X., Burdick, D., Popa, L., Zhong, X., Wang, N.X.R.: Global table extractor (gte): A framework for joint table identification and cell structure recognition using visual context. In: 2021 IEEE Winter Conference on Applications of Computer Vision (WACV). pp. 697-706 (2021). https://doi.org/10.1109/WACV48630.2021. 00074</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_60><loc_79><loc_66></location>22. Zhong, X., ShafieiBavani, E., Jimeno Yepes, A.: Image-based table recognition: Data, model, and evaluation. In: Vedaldi, A., Bischof, H., Brox, T., Frahm, J.M. (eds.) Computer Vision - ECCV 2020. pp. 564-580. Springer International Publishing, Cham (2020)</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_56><loc_79><loc_60></location>23. Zhong, X., Tang, J., Yepes, A.J.: Publaynet: largest dataset ever for document layout analysis. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 1015-1022. IEEE (2019)</paragraph>
|
||||
</document>
|
@ -937,7 +937,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- -\"C\" cell a new table cell that either has or does not have cell content",
|
||||
"text": "-\"C\" cell a new table cell that either has or does not have cell content",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -960,7 +960,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- -\"L\" cell left-looking cell , merging with the left neighbor cell to create a span",
|
||||
"text": "-\"L\" cell left-looking cell , merging with the left neighbor cell to create a span",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -983,7 +983,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- -\"U\" cell up-looking cell , merging with the upper neighbor cell to create a span",
|
||||
"text": "-\"U\" cell up-looking cell , merging with the upper neighbor cell to create a span",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1006,7 +1006,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- -\"X\" cell cross cell , to merge with both left and upper neighbor cells",
|
||||
"text": "-\"X\" cell cross cell , to merge with both left and upper neighbor cells",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1029,7 +1029,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- -\"NL\" new-line , switch to the next row.",
|
||||
"text": "-\"NL\" new-line , switch to the next row.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1149,7 +1149,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 1. Left-looking cell rule : The left neighbour of an \"L\" cell must be either another \"L\" cell or a \"C\" cell.",
|
||||
"text": "1. Left-looking cell rule : The left neighbour of an \"L\" cell must be either another \"L\" cell or a \"C\" cell.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1172,7 +1172,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 2. Up-looking cell rule : The upper neighbour of a \"U\" cell must be either another \"U\" cell or a \"C\" cell.",
|
||||
"text": "2. Up-looking cell rule : The upper neighbour of a \"U\" cell must be either another \"U\" cell or a \"C\" cell.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1218,7 +1218,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- The left neighbour of an \"X\" cell must be either another \"X\" cell or a \"U\" cell, and the upper neighbour of an \"X\" cell must be either another \"X\" cell or an \"L\" cell.",
|
||||
"text": "The left neighbour of an \"X\" cell must be either another \"X\" cell or a \"U\" cell, and the upper neighbour of an \"X\" cell must be either another \"X\" cell or an \"L\" cell.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1241,7 +1241,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 4. First row rule : Only \"L\" cells and \"C\" cells are allowed in the first row.",
|
||||
"text": "4. First row rule : Only \"L\" cells and \"C\" cells are allowed in the first row.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1264,7 +1264,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 5. First column rule : Only \"U\" cells and \"C\" cells are allowed in the first column.",
|
||||
"text": "5. First column rule : Only \"U\" cells and \"C\" cells are allowed in the first column.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1287,7 +1287,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 6. Rectangular rule : The table representation is always rectangular - all rows must have an equal number of tokens, terminated with \"NL\" token.",
|
||||
"text": "6. Rectangular rule : The table representation is always rectangular - all rows must have an equal number of tokens, terminated with \"NL\" token.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1979,7 +1979,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 1. Auer, C., Dolfi, M., Carvalho, A., Ramis, C.B., Staar, P.W.J.: Delivering document conversion as a cloud service with high throughput and responsiveness. CoRR abs/2206.00785 (2022). https://doi.org/10.48550/arXiv.2206.00785 , https://doi.org/10.48550/arXiv.2206.00785",
|
||||
"text": "1. Auer, C., Dolfi, M., Carvalho, A., Ramis, C.B., Staar, P.W.J.: Delivering document conversion as a cloud service with high throughput and responsiveness. CoRR abs/2206.00785 (2022). https://doi.org/10.48550/arXiv.2206.00785 , https://doi.org/10.48550/arXiv.2206.00785",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2002,7 +2002,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 2. Chen, B., Peng, D., Zhang, J., Ren, Y., Jin, L.: Complex table structure recognition in the wild using transformer and identity matrix-based augmentation. In: Porwal, U., Forn\u00e9s, A., Shafait, F. (eds.) Frontiers in Handwriting Recognition. pp. 545561. Springer International Publishing, Cham (2022)",
|
||||
"text": "2. Chen, B., Peng, D., Zhang, J., Ren, Y., Jin, L.: Complex table structure recognition in the wild using transformer and identity matrix-based augmentation. In: Porwal, U., Forn\u00e9s, A., Shafait, F. (eds.) Frontiers in Handwriting Recognition. pp. 545561. Springer International Publishing, Cham (2022)",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2025,7 +2025,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 3. Chi, Z., Huang, H., Xu, H.D., Yu, H., Yin, W., Mao, X.L.: Complicated table structure recognition. arXiv preprint arXiv:1908.04729 (2019)",
|
||||
"text": "3. Chi, Z., Huang, H., Xu, H.D., Yu, H., Yin, W., Mao, X.L.: Complicated table structure recognition. arXiv preprint arXiv:1908.04729 (2019)",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2048,7 +2048,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 4. Deng, Y., Rosenberg, D., Mann, G.: Challenges in end-to-end neural scientific table recognition. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 894-901. IEEE (2019)",
|
||||
"text": "4. Deng, Y., Rosenberg, D., Mann, G.: Challenges in end-to-end neural scientific table recognition. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 894-901. IEEE (2019)",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2071,7 +2071,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 5. Kayal, P., Anand, M., Desai, H., Singh, M.: Tables to latex: structure and content extraction from scientific tables. International Journal on Document Analysis and Recognition (IJDAR) pp. 1-10 (2022)",
|
||||
"text": "5. Kayal, P., Anand, M., Desai, H., Singh, M.: Tables to latex: structure and content extraction from scientific tables. International Journal on Document Analysis and Recognition (IJDAR) pp. 1-10 (2022)",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2094,7 +2094,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 6. Lee, E., Kwon, J., Yang, H., Park, J., Lee, S., Koo, H.I., Cho, N.I.: Table structure recognition based on grid shape graph. In: 2022 Asia-Pacific Signal and Information Processing Association Annual Summit and Conference (APSIPA ASC). pp. 18681873. IEEE (2022)",
|
||||
"text": "6. Lee, E., Kwon, J., Yang, H., Park, J., Lee, S., Koo, H.I., Cho, N.I.: Table structure recognition based on grid shape graph. In: 2022 Asia-Pacific Signal and Information Processing Association Annual Summit and Conference (APSIPA ASC). pp. 18681873. IEEE (2022)",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2117,7 +2117,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 7. Li, M., Cui, L., Huang, S., Wei, F., Zhou, M., Li, Z.: Tablebank: A benchmark dataset for table detection and recognition (2019)",
|
||||
"text": "7. Li, M., Cui, L., Huang, S., Wei, F., Zhou, M., Li, Z.: Tablebank: A benchmark dataset for table detection and recognition (2019)",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2140,7 +2140,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 8. Livathinos, N., Berrospi, C., Lysak, M., Kuropiatnyk, V., Nassar, A., Carvalho, A., Dolfi, M., Auer, C., Dinkla, K., Staar, P.: Robust pdf document conversion using recurrent neural networks. Proceedings of the AAAI Conference on Artificial Intelligence 35 (17), 15137-15145 (May 2021), https://ojs.aaai.org/index.php/ AAAI/article/view/17777",
|
||||
"text": "8. Livathinos, N., Berrospi, C., Lysak, M., Kuropiatnyk, V., Nassar, A., Carvalho, A., Dolfi, M., Auer, C., Dinkla, K., Staar, P.: Robust pdf document conversion using recurrent neural networks. Proceedings of the AAAI Conference on Artificial Intelligence 35 (17), 15137-15145 (May 2021), https://ojs.aaai.org/index.php/ AAAI/article/view/17777",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2163,7 +2163,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 9. Nassar, A., Livathinos, N., Lysak, M., Staar, P.: Tableformer: Table structure understanding with transformers. In: Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). pp. 4614-4623 (June 2022)",
|
||||
"text": "9. Nassar, A., Livathinos, N., Lysak, M., Staar, P.: Tableformer: Table structure understanding with transformers. In: Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). pp. 4614-4623 (June 2022)",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2186,7 +2186,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 10. Pfitzmann, B., Auer, C., Dolfi, M., Nassar, A.S., Staar, P.W.J.: Doclaynet: A large human-annotated dataset for document-layout segmentation. In: Zhang, A., Rangwala, H. (eds.) KDD '22: The 28th ACM SIGKDD Conference on Knowledge Discovery and Data Mining, Washington, DC, USA, August 14 - 18, 2022. pp. 3743-3751. ACM (2022). https://doi.org/10.1145/3534678.3539043 , https:// doi.org/10.1145/3534678.3539043",
|
||||
"text": "10. Pfitzmann, B., Auer, C., Dolfi, M., Nassar, A.S., Staar, P.W.J.: Doclaynet: A large human-annotated dataset for document-layout segmentation. In: Zhang, A., Rangwala, H. (eds.) KDD '22: The 28th ACM SIGKDD Conference on Knowledge Discovery and Data Mining, Washington, DC, USA, August 14 - 18, 2022. pp. 3743-3751. ACM (2022). https://doi.org/10.1145/3534678.3539043 , https:// doi.org/10.1145/3534678.3539043",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2209,7 +2209,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 11. Prasad, D., Gadpal, A., Kapadni, K., Visave, M., Sultanpure, K.: Cascadetabnet: An approach for end to end table detection and structure recognition from imagebased documents. In: Proceedings of the IEEE/CVF conference on computer vision and pattern recognition workshops. pp. 572-573 (2020)",
|
||||
"text": "11. Prasad, D., Gadpal, A., Kapadni, K., Visave, M., Sultanpure, K.: Cascadetabnet: An approach for end to end table detection and structure recognition from imagebased documents. In: Proceedings of the IEEE/CVF conference on computer vision and pattern recognition workshops. pp. 572-573 (2020)",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2232,7 +2232,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 12. Schreiber, S., Agne, S., Wolf, I., Dengel, A., Ahmed, S.: Deepdesrt: Deep learning for detection and structure recognition of tables in document images. In: 2017 14th IAPR international conference on document analysis and recognition (ICDAR). vol. 1, pp. 1162-1167. IEEE (2017)",
|
||||
"text": "12. Schreiber, S., Agne, S., Wolf, I., Dengel, A., Ahmed, S.: Deepdesrt: Deep learning for detection and structure recognition of tables in document images. In: 2017 14th IAPR international conference on document analysis and recognition (ICDAR). vol. 1, pp. 1162-1167. IEEE (2017)",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2255,7 +2255,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 13. Siddiqui, S.A., Fateh, I.A., Rizvi, S.T.R., Dengel, A., Ahmed, S.: Deeptabstr: Deep learning based table structure recognition. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 1403-1409 (2019). https:// doi.org/10.1109/ICDAR.2019.00226",
|
||||
"text": "13. Siddiqui, S.A., Fateh, I.A., Rizvi, S.T.R., Dengel, A., Ahmed, S.: Deeptabstr: Deep learning based table structure recognition. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 1403-1409 (2019). https:// doi.org/10.1109/ICDAR.2019.00226",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2278,7 +2278,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 14. Smock, B., Pesala, R., Abraham, R.: PubTables-1M: Towards comprehensive table extraction from unstructured documents. In: Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). pp. 4634-4642 (June 2022)",
|
||||
"text": "14. Smock, B., Pesala, R., Abraham, R.: PubTables-1M: Towards comprehensive table extraction from unstructured documents. In: Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). pp. 4634-4642 (June 2022)",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2301,7 +2301,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 15. Staar, P.W.J., Dolfi, M., Auer, C., Bekas, C.: Corpus conversion service: A machine learning platform to ingest documents at scale. In: Proceedings of the 24th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining. pp. 774-782. KDD '18, Association for Computing Machinery, New York, NY, USA (2018). https://doi.org/10.1145/3219819.3219834 , https://doi.org/10. 1145/3219819.3219834",
|
||||
"text": "15. Staar, P.W.J., Dolfi, M., Auer, C., Bekas, C.: Corpus conversion service: A machine learning platform to ingest documents at scale. In: Proceedings of the 24th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining. pp. 774-782. KDD '18, Association for Computing Machinery, New York, NY, USA (2018). https://doi.org/10.1145/3219819.3219834 , https://doi.org/10. 1145/3219819.3219834",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2324,7 +2324,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 16. Wang, X.: Tabular Abstraction, Editing, and Formatting. Ph.D. thesis, CAN (1996), aAINN09397",
|
||||
"text": "16. Wang, X.: Tabular Abstraction, Editing, and Formatting. Ph.D. thesis, CAN (1996), aAINN09397",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2347,7 +2347,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 17. Xue, W., Li, Q., Tao, D.: Res2tim: Reconstruct syntactic structures from table images. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 749-755. IEEE (2019)",
|
||||
"text": "17. Xue, W., Li, Q., Tao, D.: Res2tim: Reconstruct syntactic structures from table images. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 749-755. IEEE (2019)",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2370,7 +2370,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 18. Xue, W., Yu, B., Wang, W., Tao, D., Li, Q.: Tgrnet: A table graph reconstruction network for table structure recognition. In: Proceedings of the IEEE/CVF International Conference on Computer Vision. pp. 1295-1304 (2021)",
|
||||
"text": "18. Xue, W., Yu, B., Wang, W., Tao, D., Li, Q.: Tgrnet: A table graph reconstruction network for table structure recognition. In: Proceedings of the IEEE/CVF International Conference on Computer Vision. pp. 1295-1304 (2021)",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2393,7 +2393,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 19. Ye, J., Qi, X., He, Y., Chen, Y., Gu, D., Gao, P., Xiao, R.: Pingan-vcgroup's solution for icdar 2021 competition on scientific literature parsing task b: Table recognition to html (2021). https://doi.org/10.48550/ARXIV.2105.01848 , https://arxiv.org/abs/2105.01848",
|
||||
"text": "19. Ye, J., Qi, X., He, Y., Chen, Y., Gu, D., Gao, P., Xiao, R.: Pingan-vcgroup's solution for icdar 2021 competition on scientific literature parsing task b: Table recognition to html (2021). https://doi.org/10.48550/ARXIV.2105.01848 , https://arxiv.org/abs/2105.01848",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2416,7 +2416,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 20. Zhang, Z., Zhang, J., Du, J., Wang, F.: Split, embed and merge: An accurate table structure recognizer. Pattern Recognition 126 , 108565 (2022)",
|
||||
"text": "20. Zhang, Z., Zhang, J., Du, J., Wang, F.: Split, embed and merge: An accurate table structure recognizer. Pattern Recognition 126 , 108565 (2022)",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2439,7 +2439,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 21. Zheng, X., Burdick, D., Popa, L., Zhong, X., Wang, N.X.R.: Global table extractor (gte): A framework for joint table identification and cell structure recognition using visual context. In: 2021 IEEE Winter Conference on Applications of Computer Vision (WACV). pp. 697-706 (2021). https://doi.org/10.1109/WACV48630.2021. 00074",
|
||||
"text": "21. Zheng, X., Burdick, D., Popa, L., Zhong, X., Wang, N.X.R.: Global table extractor (gte): A framework for joint table identification and cell structure recognition using visual context. In: 2021 IEEE Winter Conference on Applications of Computer Vision (WACV). pp. 697-706 (2021). https://doi.org/10.1109/WACV48630.2021. 00074",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2462,7 +2462,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 22. Zhong, X., ShafieiBavani, E., Jimeno Yepes, A.: Image-based table recognition: Data, model, and evaluation. In: Vedaldi, A., Bischof, H., Brox, T., Frahm, J.M. (eds.) Computer Vision - ECCV 2020. pp. 564-580. Springer International Publishing, Cham (2020)",
|
||||
"text": "22. Zhong, X., ShafieiBavani, E., Jimeno Yepes, A.: Image-based table recognition: Data, model, and evaluation. In: Vedaldi, A., Bischof, H., Brox, T., Frahm, J.M. (eds.) Computer Vision - ECCV 2020. pp. 564-580. Springer International Publishing, Cham (2020)",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2485,7 +2485,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 23. Zhong, X., Tang, J., Yepes, A.J.: Publaynet: largest dataset ever for document layout analysis. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 1015-1022. IEEE (2019)",
|
||||
"text": "23. Zhong, X., Tang, J., Yepes, A.J.: Publaynet: largest dataset ever for document layout analysis. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 1015-1022. IEEE (2019)",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
|
@ -70,15 +70,15 @@ In Figure 3, we illustrate how the OTSL is defined. In essence, the OTSL defines
|
||||
|
||||
The OTSL vocabulary is comprised of the following tokens:
|
||||
|
||||
- -"C" cell a new table cell that either has or does not have cell content
|
||||
-"C" cell a new table cell that either has or does not have cell content
|
||||
|
||||
- -"L" cell left-looking cell , merging with the left neighbor cell to create a span
|
||||
-"L" cell left-looking cell , merging with the left neighbor cell to create a span
|
||||
|
||||
- -"U" cell up-looking cell , merging with the upper neighbor cell to create a span
|
||||
-"U" cell up-looking cell , merging with the upper neighbor cell to create a span
|
||||
|
||||
- -"X" cell cross cell , to merge with both left and upper neighbor cells
|
||||
-"X" cell cross cell , to merge with both left and upper neighbor cells
|
||||
|
||||
- -"NL" new-line , switch to the next row.
|
||||
-"NL" new-line , switch to the next row.
|
||||
|
||||
A notable attribute of OTSL is that it has the capability of achieving lossless conversion to HTML.
|
||||
|
||||
@ -89,19 +89,19 @@ Fig. 3. OTSL description of table structure: A - table example; B - graphical re
|
||||
|
||||
The OTSL representation follows these syntax rules:
|
||||
|
||||
- 1. Left-looking cell rule : The left neighbour of an "L" cell must be either another "L" cell or a "C" cell.
|
||||
1. Left-looking cell rule : The left neighbour of an "L" cell must be either another "L" cell or a "C" cell.
|
||||
|
||||
- 2. Up-looking cell rule : The upper neighbour of a "U" cell must be either another "U" cell or a "C" cell.
|
||||
2. Up-looking cell rule : The upper neighbour of a "U" cell must be either another "U" cell or a "C" cell.
|
||||
|
||||
## 3. Cross cell rule :
|
||||
|
||||
- The left neighbour of an "X" cell must be either another "X" cell or a "U" cell, and the upper neighbour of an "X" cell must be either another "X" cell or an "L" cell.
|
||||
The left neighbour of an "X" cell must be either another "X" cell or a "U" cell, and the upper neighbour of an "X" cell must be either another "X" cell or an "L" cell.
|
||||
|
||||
- 4. First row rule : Only "L" cells and "C" cells are allowed in the first row.
|
||||
4. First row rule : Only "L" cells and "C" cells are allowed in the first row.
|
||||
|
||||
- 5. First column rule : Only "U" cells and "C" cells are allowed in the first column.
|
||||
5. First column rule : Only "U" cells and "C" cells are allowed in the first column.
|
||||
|
||||
- 6. Rectangular rule : The table representation is always rectangular - all rows must have an equal number of tokens, terminated with "NL" token.
|
||||
6. Rectangular rule : The table representation is always rectangular - all rows must have an equal number of tokens, terminated with "NL" token.
|
||||
|
||||
The application of these rules gives OTSL a set of unique properties. First of all, the OTSL enforces a strictly rectangular structure representation, where every new-line token starts a new row. As a consequence, all rows and all columns have exactly the same number of tokens, irrespective of cell spans. Secondly, the OTSL representation is unambiguous: Every table structure is represented in one way. In this representation every table cell corresponds to a "C"-cell token, which in case of spans is always located in the top-left corner of the table cell definition. Third, OTSL syntax rules are only backward-looking. As a consequence, every predicted token can be validated straight during sequence generation by looking at the previously predicted sequence. As such, OTSL can guarantee that every predicted sequence is syntactically valid.
|
||||
|
||||
@ -177,48 +177,48 @@ Secondly, OTSL has more inherent structure and a significantly restricted vocabu
|
||||
|
||||
## References
|
||||
|
||||
- 1. Auer, C., Dolfi, M., Carvalho, A., Ramis, C.B., Staar, P.W.J.: Delivering document conversion as a cloud service with high throughput and responsiveness. CoRR abs/2206.00785 (2022). https://doi.org/10.48550/arXiv.2206.00785 , https://doi.org/10.48550/arXiv.2206.00785
|
||||
1. Auer, C., Dolfi, M., Carvalho, A., Ramis, C.B., Staar, P.W.J.: Delivering document conversion as a cloud service with high throughput and responsiveness. CoRR abs/2206.00785 (2022). https://doi.org/10.48550/arXiv.2206.00785 , https://doi.org/10.48550/arXiv.2206.00785
|
||||
|
||||
- 2. Chen, B., Peng, D., Zhang, J., Ren, Y., Jin, L.: Complex table structure recognition in the wild using transformer and identity matrix-based augmentation. In: Porwal, U., Fornés, A., Shafait, F. (eds.) Frontiers in Handwriting Recognition. pp. 545561. Springer International Publishing, Cham (2022)
|
||||
2. Chen, B., Peng, D., Zhang, J., Ren, Y., Jin, L.: Complex table structure recognition in the wild using transformer and identity matrix-based augmentation. In: Porwal, U., Fornés, A., Shafait, F. (eds.) Frontiers in Handwriting Recognition. pp. 545561. Springer International Publishing, Cham (2022)
|
||||
|
||||
- 3. Chi, Z., Huang, H., Xu, H.D., Yu, H., Yin, W., Mao, X.L.: Complicated table structure recognition. arXiv preprint arXiv:1908.04729 (2019)
|
||||
3. Chi, Z., Huang, H., Xu, H.D., Yu, H., Yin, W., Mao, X.L.: Complicated table structure recognition. arXiv preprint arXiv:1908.04729 (2019)
|
||||
|
||||
- 4. Deng, Y., Rosenberg, D., Mann, G.: Challenges in end-to-end neural scientific table recognition. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 894-901. IEEE (2019)
|
||||
4. Deng, Y., Rosenberg, D., Mann, G.: Challenges in end-to-end neural scientific table recognition. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 894-901. IEEE (2019)
|
||||
|
||||
- 5. Kayal, P., Anand, M., Desai, H., Singh, M.: Tables to latex: structure and content extraction from scientific tables. International Journal on Document Analysis and Recognition (IJDAR) pp. 1-10 (2022)
|
||||
5. Kayal, P., Anand, M., Desai, H., Singh, M.: Tables to latex: structure and content extraction from scientific tables. International Journal on Document Analysis and Recognition (IJDAR) pp. 1-10 (2022)
|
||||
|
||||
- 6. Lee, E., Kwon, J., Yang, H., Park, J., Lee, S., Koo, H.I., Cho, N.I.: Table structure recognition based on grid shape graph. In: 2022 Asia-Pacific Signal and Information Processing Association Annual Summit and Conference (APSIPA ASC). pp. 18681873. IEEE (2022)
|
||||
6. Lee, E., Kwon, J., Yang, H., Park, J., Lee, S., Koo, H.I., Cho, N.I.: Table structure recognition based on grid shape graph. In: 2022 Asia-Pacific Signal and Information Processing Association Annual Summit and Conference (APSIPA ASC). pp. 18681873. IEEE (2022)
|
||||
|
||||
- 7. Li, M., Cui, L., Huang, S., Wei, F., Zhou, M., Li, Z.: Tablebank: A benchmark dataset for table detection and recognition (2019)
|
||||
7. Li, M., Cui, L., Huang, S., Wei, F., Zhou, M., Li, Z.: Tablebank: A benchmark dataset for table detection and recognition (2019)
|
||||
|
||||
- 8. Livathinos, N., Berrospi, C., Lysak, M., Kuropiatnyk, V., Nassar, A., Carvalho, A., Dolfi, M., Auer, C., Dinkla, K., Staar, P.: Robust pdf document conversion using recurrent neural networks. Proceedings of the AAAI Conference on Artificial Intelligence 35 (17), 15137-15145 (May 2021), https://ojs.aaai.org/index.php/ AAAI/article/view/17777
|
||||
8. Livathinos, N., Berrospi, C., Lysak, M., Kuropiatnyk, V., Nassar, A., Carvalho, A., Dolfi, M., Auer, C., Dinkla, K., Staar, P.: Robust pdf document conversion using recurrent neural networks. Proceedings of the AAAI Conference on Artificial Intelligence 35 (17), 15137-15145 (May 2021), https://ojs.aaai.org/index.php/ AAAI/article/view/17777
|
||||
|
||||
- 9. Nassar, A., Livathinos, N., Lysak, M., Staar, P.: Tableformer: Table structure understanding with transformers. In: Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). pp. 4614-4623 (June 2022)
|
||||
9. Nassar, A., Livathinos, N., Lysak, M., Staar, P.: Tableformer: Table structure understanding with transformers. In: Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). pp. 4614-4623 (June 2022)
|
||||
|
||||
- 10. Pfitzmann, B., Auer, C., Dolfi, M., Nassar, A.S., Staar, P.W.J.: Doclaynet: A large human-annotated dataset for document-layout segmentation. In: Zhang, A., Rangwala, H. (eds.) KDD '22: The 28th ACM SIGKDD Conference on Knowledge Discovery and Data Mining, Washington, DC, USA, August 14 - 18, 2022. pp. 3743-3751. ACM (2022). https://doi.org/10.1145/3534678.3539043 , https:// doi.org/10.1145/3534678.3539043
|
||||
10. Pfitzmann, B., Auer, C., Dolfi, M., Nassar, A.S., Staar, P.W.J.: Doclaynet: A large human-annotated dataset for document-layout segmentation. In: Zhang, A., Rangwala, H. (eds.) KDD '22: The 28th ACM SIGKDD Conference on Knowledge Discovery and Data Mining, Washington, DC, USA, August 14 - 18, 2022. pp. 3743-3751. ACM (2022). https://doi.org/10.1145/3534678.3539043 , https:// doi.org/10.1145/3534678.3539043
|
||||
|
||||
- 11. Prasad, D., Gadpal, A., Kapadni, K., Visave, M., Sultanpure, K.: Cascadetabnet: An approach for end to end table detection and structure recognition from imagebased documents. In: Proceedings of the IEEE/CVF conference on computer vision and pattern recognition workshops. pp. 572-573 (2020)
|
||||
11. Prasad, D., Gadpal, A., Kapadni, K., Visave, M., Sultanpure, K.: Cascadetabnet: An approach for end to end table detection and structure recognition from imagebased documents. In: Proceedings of the IEEE/CVF conference on computer vision and pattern recognition workshops. pp. 572-573 (2020)
|
||||
|
||||
- 12. Schreiber, S., Agne, S., Wolf, I., Dengel, A., Ahmed, S.: Deepdesrt: Deep learning for detection and structure recognition of tables in document images. In: 2017 14th IAPR international conference on document analysis and recognition (ICDAR). vol. 1, pp. 1162-1167. IEEE (2017)
|
||||
12. Schreiber, S., Agne, S., Wolf, I., Dengel, A., Ahmed, S.: Deepdesrt: Deep learning for detection and structure recognition of tables in document images. In: 2017 14th IAPR international conference on document analysis and recognition (ICDAR). vol. 1, pp. 1162-1167. IEEE (2017)
|
||||
|
||||
- 13. Siddiqui, S.A., Fateh, I.A., Rizvi, S.T.R., Dengel, A., Ahmed, S.: Deeptabstr: Deep learning based table structure recognition. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 1403-1409 (2019). https:// doi.org/10.1109/ICDAR.2019.00226
|
||||
13. Siddiqui, S.A., Fateh, I.A., Rizvi, S.T.R., Dengel, A., Ahmed, S.: Deeptabstr: Deep learning based table structure recognition. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 1403-1409 (2019). https:// doi.org/10.1109/ICDAR.2019.00226
|
||||
|
||||
- 14. Smock, B., Pesala, R., Abraham, R.: PubTables-1M: Towards comprehensive table extraction from unstructured documents. In: Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). pp. 4634-4642 (June 2022)
|
||||
14. Smock, B., Pesala, R., Abraham, R.: PubTables-1M: Towards comprehensive table extraction from unstructured documents. In: Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). pp. 4634-4642 (June 2022)
|
||||
|
||||
- 15. Staar, P.W.J., Dolfi, M., Auer, C., Bekas, C.: Corpus conversion service: A machine learning platform to ingest documents at scale. In: Proceedings of the 24th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining. pp. 774-782. KDD '18, Association for Computing Machinery, New York, NY, USA (2018). https://doi.org/10.1145/3219819.3219834 , https://doi.org/10. 1145/3219819.3219834
|
||||
15. Staar, P.W.J., Dolfi, M., Auer, C., Bekas, C.: Corpus conversion service: A machine learning platform to ingest documents at scale. In: Proceedings of the 24th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining. pp. 774-782. KDD '18, Association for Computing Machinery, New York, NY, USA (2018). https://doi.org/10.1145/3219819.3219834 , https://doi.org/10. 1145/3219819.3219834
|
||||
|
||||
- 16. Wang, X.: Tabular Abstraction, Editing, and Formatting. Ph.D. thesis, CAN (1996), aAINN09397
|
||||
16. Wang, X.: Tabular Abstraction, Editing, and Formatting. Ph.D. thesis, CAN (1996), aAINN09397
|
||||
|
||||
- 17. Xue, W., Li, Q., Tao, D.: Res2tim: Reconstruct syntactic structures from table images. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 749-755. IEEE (2019)
|
||||
17. Xue, W., Li, Q., Tao, D.: Res2tim: Reconstruct syntactic structures from table images. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 749-755. IEEE (2019)
|
||||
|
||||
- 18. Xue, W., Yu, B., Wang, W., Tao, D., Li, Q.: Tgrnet: A table graph reconstruction network for table structure recognition. In: Proceedings of the IEEE/CVF International Conference on Computer Vision. pp. 1295-1304 (2021)
|
||||
18. Xue, W., Yu, B., Wang, W., Tao, D., Li, Q.: Tgrnet: A table graph reconstruction network for table structure recognition. In: Proceedings of the IEEE/CVF International Conference on Computer Vision. pp. 1295-1304 (2021)
|
||||
|
||||
- 19. Ye, J., Qi, X., He, Y., Chen, Y., Gu, D., Gao, P., Xiao, R.: Pingan-vcgroup's solution for icdar 2021 competition on scientific literature parsing task b: Table recognition to html (2021). https://doi.org/10.48550/ARXIV.2105.01848 , https://arxiv.org/abs/2105.01848
|
||||
19. Ye, J., Qi, X., He, Y., Chen, Y., Gu, D., Gao, P., Xiao, R.: Pingan-vcgroup's solution for icdar 2021 competition on scientific literature parsing task b: Table recognition to html (2021). https://doi.org/10.48550/ARXIV.2105.01848 , https://arxiv.org/abs/2105.01848
|
||||
|
||||
- 20. Zhang, Z., Zhang, J., Du, J., Wang, F.: Split, embed and merge: An accurate table structure recognizer. Pattern Recognition 126 , 108565 (2022)
|
||||
20. Zhang, Z., Zhang, J., Du, J., Wang, F.: Split, embed and merge: An accurate table structure recognizer. Pattern Recognition 126 , 108565 (2022)
|
||||
|
||||
- 21. Zheng, X., Burdick, D., Popa, L., Zhong, X., Wang, N.X.R.: Global table extractor (gte): A framework for joint table identification and cell structure recognition using visual context. In: 2021 IEEE Winter Conference on Applications of Computer Vision (WACV). pp. 697-706 (2021). https://doi.org/10.1109/WACV48630.2021. 00074
|
||||
21. Zheng, X., Burdick, D., Popa, L., Zhong, X., Wang, N.X.R.: Global table extractor (gte): A framework for joint table identification and cell structure recognition using visual context. In: 2021 IEEE Winter Conference on Applications of Computer Vision (WACV). pp. 697-706 (2021). https://doi.org/10.1109/WACV48630.2021. 00074
|
||||
|
||||
- 22. Zhong, X., ShafieiBavani, E., Jimeno Yepes, A.: Image-based table recognition: Data, model, and evaluation. In: Vedaldi, A., Bischof, H., Brox, T., Frahm, J.M. (eds.) Computer Vision - ECCV 2020. pp. 564-580. Springer International Publishing, Cham (2020)
|
||||
22. Zhong, X., ShafieiBavani, E., Jimeno Yepes, A.: Image-based table recognition: Data, model, and evaluation. In: Vedaldi, A., Bischof, H., Brox, T., Frahm, J.M. (eds.) Computer Vision - ECCV 2020. pp. 564-580. Springer International Publishing, Cham (2020)
|
||||
|
||||
- 23. Zhong, X., Tang, J., Yepes, A.J.: Publaynet: largest dataset ever for document layout analysis. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 1015-1022. IEEE (2019)
|
||||
23. Zhong, X., Tang, J., Yepes, A.J.: Publaynet: largest dataset ever for document layout analysis. In: 2019 International Conference on Document Analysis and Recognition (ICDAR). pp. 1015-1022. IEEE (2019)
|
@ -6,50 +6,50 @@
|
||||
<paragraph><location><page_1><loc_12><loc_65><loc_85><loc_71></location>During this period, the term "word processing" didn't exist, but the typewriter laid the groundwork for future developments. Over time, advancements such as carbon paper (for copies) and the electric typewriter (introduced by IBM in 1935) improved the speed and convenience of document creation.</paragraph>
|
||||
<subtitle-level-1><location><page_1><loc_12><loc_58><loc_57><loc_60></location>The Birth of Word Processing (1960s - 1970s)</subtitle-level-1>
|
||||
<paragraph><location><page_1><loc_12><loc_52><loc_88><loc_56></location>The term "word processor" first emerged in the 1960s and referred to any system designed to streamline written communication and document production. Early word processors were not software programs but rather standalone machines.</paragraph>
|
||||
<paragraph><location><page_1><loc_15><loc_43><loc_87><loc_50></location>- · IBM MT/ST (Magnetic Tape/Selectric Typewriter) : Introduced in 1964, this machine combined IBM's Selectric typewriter with magnetic tape storage. It allowed users to record, edit, and replay typed content-an early example of digital text storage.</paragraph>
|
||||
<paragraph><location><page_1><loc_15><loc_38><loc_84><loc_43></location>- · Wang Laboratories : In the 1970s, Wang introduced dedicated word processing machines. These devices, like the Wang 1200, featured small screens and floppy disks, making them revolutionary for their time.</paragraph>
|
||||
<paragraph><location><page_1><loc_15><loc_43><loc_87><loc_50></location>· IBM MT/ST (Magnetic Tape/Selectric Typewriter) : Introduced in 1964, this machine combined IBM's Selectric typewriter with magnetic tape storage. It allowed users to record, edit, and replay typed content-an early example of digital text storage.</paragraph>
|
||||
<paragraph><location><page_1><loc_15><loc_38><loc_84><loc_43></location>· Wang Laboratories : In the 1970s, Wang introduced dedicated word processing machines. These devices, like the Wang 1200, featured small screens and floppy disks, making them revolutionary for their time.</paragraph>
|
||||
<paragraph><location><page_1><loc_12><loc_33><loc_86><loc_37></location>These machines were primarily used in offices, where secretarial pools benefited from their ability to make revisions without retyping entire documents.</paragraph>
|
||||
<subtitle-level-1><location><page_1><loc_12><loc_27><loc_52><loc_28></location>The Rise of Personal Computers (1980s)</subtitle-level-1>
|
||||
<paragraph><location><page_1><loc_12><loc_22><loc_87><loc_25></location>The advent of personal computers in the late 1970s and early 1980s transformed word processing from a niche tool to an essential technology for businesses and individuals alike.</paragraph>
|
||||
<paragraph><location><page_1><loc_15><loc_15><loc_88><loc_20></location>- · WordStar (1978) : Developed for the CP/M operating system, WordStar was one of the first widely used word processing programs. It featured early examples of modern features like cut, copy, and paste.</paragraph>
|
||||
<paragraph><location><page_1><loc_15><loc_10><loc_88><loc_15></location>- · Microsoft Word (1983) : Microsoft launched Word for MS-DOS in 1983, introducing a graphical user interface (GUI) and mouse support. Over the years, Microsoft Word became the industry standard for word processing.</paragraph>
|
||||
<paragraph><location><page_1><loc_15><loc_15><loc_88><loc_20></location>· WordStar (1978) : Developed for the CP/M operating system, WordStar was one of the first widely used word processing programs. It featured early examples of modern features like cut, copy, and paste.</paragraph>
|
||||
<paragraph><location><page_1><loc_15><loc_10><loc_88><loc_15></location>· Microsoft Word (1983) : Microsoft launched Word for MS-DOS in 1983, introducing a graphical user interface (GUI) and mouse support. Over the years, Microsoft Word became the industry standard for word processing.</paragraph>
|
||||
<paragraph><location><page_2><loc_12><loc_87><loc_87><loc_91></location>Other notable software from this era included WordPerfect, which was popular among legal professionals, and Apple's MacWrite, which leveraged the Macintosh's graphical capabilities.</paragraph>
|
||||
<subtitle-level-1><location><page_2><loc_12><loc_80><loc_46><loc_81></location>The Modern Era (1990s - Present)</subtitle-level-1>
|
||||
<paragraph><location><page_2><loc_12><loc_75><loc_86><loc_78></location>By the 1990s, word processing software had become more sophisticated, with features like spell check, grammar check, templates, and collaborative tools.</paragraph>
|
||||
<paragraph><location><page_2><loc_15><loc_70><loc_83><loc_73></location>- · Microsoft Office Suite : Microsoft continued to dominate with its Office Suite, integrating Word with other productivity tools like Excel and PowerPoint.</paragraph>
|
||||
<paragraph><location><page_2><loc_15><loc_67><loc_87><loc_70></location>- · OpenOffice and LibreOffice : Open-source alternatives emerged in the early 2000s, offering free and flexible word processing options.</paragraph>
|
||||
<paragraph><location><page_2><loc_15><loc_62><loc_88><loc_67></location>- · Google Docs (2006) : The introduction of cloud-based word processing revolutionized collaboration. Google Docs enabled real-time editing and sharing, making it a staple for teams and remote work.</paragraph>
|
||||
<paragraph><location><page_2><loc_15><loc_70><loc_83><loc_73></location>· Microsoft Office Suite : Microsoft continued to dominate with its Office Suite, integrating Word with other productivity tools like Excel and PowerPoint.</paragraph>
|
||||
<paragraph><location><page_2><loc_15><loc_67><loc_87><loc_70></location>· OpenOffice and LibreOffice : Open-source alternatives emerged in the early 2000s, offering free and flexible word processing options.</paragraph>
|
||||
<paragraph><location><page_2><loc_15><loc_62><loc_88><loc_67></location>· Google Docs (2006) : The introduction of cloud-based word processing revolutionized collaboration. Google Docs enabled real-time editing and sharing, making it a staple for teams and remote work.</paragraph>
|
||||
<subtitle-level-1><location><page_2><loc_12><loc_55><loc_39><loc_57></location>Future of Word Processing</subtitle-level-1>
|
||||
<paragraph><location><page_2><loc_12><loc_45><loc_87><loc_53></location>Today, word processors are more than just tools for typing. They integrate artificial intelligence for grammar and style suggestions (e.g., Grammarly), voice-to-text features, and advanced layout options. As AI continues to advance, word processors may evolve into even more intuitive tools that predict user needs, automate repetitive tasks, and support richer multimedia integration.</paragraph>
|
||||
<paragraph><location><page_2><loc_12><loc_35><loc_87><loc_40></location>From the clunky typewriters of the 19th century to the AI-powered cloud tools of today, the word processor has come a long way. It remains an essential tool for communication and creativity, shaping how we write and share ideas.</paragraph>
|
||||
<subtitle-level-1><location><page_3><loc_12><loc_90><loc_46><loc_91></location>Specialized Word Processing Tools</subtitle-level-1>
|
||||
<paragraph><location><page_3><loc_12><loc_83><loc_86><loc_88></location>In addition to general-purpose word processors, specialized tools have emerged to cater to specific industries and needs. These tools incorporate unique features tailored to their users' workflows:</paragraph>
|
||||
<paragraph><location><page_3><loc_15><loc_73><loc_87><loc_81></location>- · Academic and Technical Writing : Tools like LaTeX gained popularity among academics, scientists, and engineers. Unlike traditional word processors, LaTeX focuses on precise formatting, particularly for complex mathematical equations, scientific papers, and technical documents. It relies on a markup language to produce polished documents suitable for publishing.</paragraph>
|
||||
<paragraph><location><page_3><loc_15><loc_67><loc_85><loc_73></location>- · Screenwriting Software : For screenwriters, tools like Final Draft and Celtx are specialized to handle scripts for film and television. These programs automate the formatting of dialogue, scene descriptions, and other elements unique to screenwriting.</paragraph>
|
||||
<paragraph><location><page_3><loc_15><loc_60><loc_88><loc_67></location>- · Legal Document Processors : Word processors tailored for legal professionals, like WordPerfect, offered features such as redlining (early version tracking) and document comparison. Even today, many law firms rely on these tools due to their robust formatting options for contracts and legal briefs.</paragraph>
|
||||
<paragraph><location><page_3><loc_15><loc_73><loc_87><loc_81></location>· Academic and Technical Writing : Tools like LaTeX gained popularity among academics, scientists, and engineers. Unlike traditional word processors, LaTeX focuses on precise formatting, particularly for complex mathematical equations, scientific papers, and technical documents. It relies on a markup language to produce polished documents suitable for publishing.</paragraph>
|
||||
<paragraph><location><page_3><loc_15><loc_67><loc_85><loc_73></location>· Screenwriting Software : For screenwriters, tools like Final Draft and Celtx are specialized to handle scripts for film and television. These programs automate the formatting of dialogue, scene descriptions, and other elements unique to screenwriting.</paragraph>
|
||||
<paragraph><location><page_3><loc_15><loc_60><loc_88><loc_67></location>· Legal Document Processors : Word processors tailored for legal professionals, like WordPerfect, offered features such as redlining (early version tracking) and document comparison. Even today, many law firms rely on these tools due to their robust formatting options for contracts and legal briefs.</paragraph>
|
||||
<subtitle-level-1><location><page_3><loc_12><loc_53><loc_57><loc_55></location>Key Features That Changed Word Processing</subtitle-level-1>
|
||||
<paragraph><location><page_3><loc_12><loc_47><loc_86><loc_52></location>The evolution of word processors wasn't just about hardware or software improvements-it was about the features that revolutionized how people wrote and edited. Some of these transformative features include:</paragraph>
|
||||
<paragraph><location><page_3><loc_15><loc_42><loc_86><loc_45></location>- 1. Undo/Redo : Introduced in the 1980s, the ability to undo mistakes and redo actions made experimentation and error correction much easier.</paragraph>
|
||||
<paragraph><location><page_3><loc_15><loc_38><loc_87><loc_42></location>- 2. Spell Check and Grammar Check : By the 1990s, these became standard, allowing users to spot errors automatically.</paragraph>
|
||||
<paragraph><location><page_3><loc_15><loc_35><loc_82><loc_38></location>- 3. Templates : Pre-designed formats for documents, such as resumes, letters, and invoices, helped users save time.</paragraph>
|
||||
<paragraph><location><page_3><loc_15><loc_32><loc_84><loc_35></location>- 4. Track Changes : A game-changer for collaboration, this feature allowed multiple users to suggest edits while maintaining the original text.</paragraph>
|
||||
<paragraph><location><page_3><loc_15><loc_27><loc_88><loc_32></location>- 5. Real-Time Collaboration : Tools like Google Docs and Microsoft 365 enabled multiple users to edit the same document simultaneously, forever changing teamwork dynamics.</paragraph>
|
||||
<paragraph><location><page_3><loc_15><loc_42><loc_86><loc_45></location>1. Undo/Redo : Introduced in the 1980s, the ability to undo mistakes and redo actions made experimentation and error correction much easier.</paragraph>
|
||||
<paragraph><location><page_3><loc_15><loc_38><loc_87><loc_42></location>2. Spell Check and Grammar Check : By the 1990s, these became standard, allowing users to spot errors automatically.</paragraph>
|
||||
<paragraph><location><page_3><loc_15><loc_35><loc_82><loc_38></location>3. Templates : Pre-designed formats for documents, such as resumes, letters, and invoices, helped users save time.</paragraph>
|
||||
<paragraph><location><page_3><loc_15><loc_32><loc_84><loc_35></location>4. Track Changes : A game-changer for collaboration, this feature allowed multiple users to suggest edits while maintaining the original text.</paragraph>
|
||||
<paragraph><location><page_3><loc_15><loc_27><loc_88><loc_32></location>5. Real-Time Collaboration : Tools like Google Docs and Microsoft 365 enabled multiple users to edit the same document simultaneously, forever changing teamwork dynamics.</paragraph>
|
||||
<subtitle-level-1><location><page_3><loc_12><loc_20><loc_52><loc_22></location>The Cultural Impact of Word Processors</subtitle-level-1>
|
||||
<paragraph><location><page_3><loc_12><loc_14><loc_87><loc_18></location>The word processor didn't just change workplaces-it changed culture. It democratized writing, enabling anyone with access to a computer to produce professional-quality documents. This shift had profound implications for education, business, and creative fields:</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_87><loc_86><loc_91></location>- · Accessibility : Writers no longer needed expensive publishing equipment or training in typesetting to create polished work. This accessibility paved the way for selfpublishing, blogging, and even fan fiction communities.</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_82><loc_88><loc_87></location>- · Education : Word processors became a cornerstone of education, teaching students not only how to write essays but also how to use technology effectively. Features like bibliography generators and integrated research tools enhanced learning.</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_77><loc_87><loc_82></location>- · Creative Writing : Writers gained powerful tools to organize their ideas. Programs like Scrivener allowed authors to manage large projects, from novels to screenplays, with features like chapter outlines and character notes.</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_87><loc_86><loc_91></location>· Accessibility : Writers no longer needed expensive publishing equipment or training in typesetting to create polished work. This accessibility paved the way for selfpublishing, blogging, and even fan fiction communities.</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_82><loc_88><loc_87></location>· Education : Word processors became a cornerstone of education, teaching students not only how to write essays but also how to use technology effectively. Features like bibliography generators and integrated research tools enhanced learning.</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_77><loc_87><loc_82></location>· Creative Writing : Writers gained powerful tools to organize their ideas. Programs like Scrivener allowed authors to manage large projects, from novels to screenplays, with features like chapter outlines and character notes.</paragraph>
|
||||
<subtitle-level-1><location><page_4><loc_12><loc_70><loc_50><loc_72></location>Word Processors in a Post-Digital Era</subtitle-level-1>
|
||||
<paragraph><location><page_4><loc_12><loc_67><loc_88><loc_68></location>As we move further into the 21st century, the role of the word processor continues to evolve:</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_58><loc_88><loc_65></location>- 1. Artificial Intelligence : Modern word processors are leveraging AI to suggest content improvements. Tools like Grammarly, ProWritingAid, and even native features in Word now analyze tone, conciseness, and clarity. Some AI systems can even generate entire paragraphs or rewrite sentences.</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_52><loc_86><loc_58></location>- 2. Integration with Other Tools : Word processors are no longer standalone. They integrate with task managers, cloud storage, and project management platforms. For instance, Google Docs syncs with Google Drive, while Microsoft Word integrates seamlessly with OneDrive and Teams.</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_45><loc_84><loc_52></location>- 3. Voice Typing : Speech-to-text capabilities have made word processing more accessible, particularly for those with disabilities. Tools like Dragon NaturallySpeaking and built-in options in Google Docs and Microsoft Word have made dictation mainstream.</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_40><loc_87><loc_45></location>- 4. Multimedia Documents : Word processing has expanded beyond text. Modern tools allow users to embed images, videos, charts, and interactive elements, transforming simple documents into rich multimedia experiences.</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_35><loc_86><loc_40></location>- 5. Cross-Platform Accessibility : Thanks to cloud computing, documents can now be accessed and edited across devices. Whether you're on a desktop, tablet, or smartphone, you can continue working seamlessly.</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_58><loc_88><loc_65></location>1. Artificial Intelligence : Modern word processors are leveraging AI to suggest content improvements. Tools like Grammarly, ProWritingAid, and even native features in Word now analyze tone, conciseness, and clarity. Some AI systems can even generate entire paragraphs or rewrite sentences.</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_52><loc_86><loc_58></location>2. Integration with Other Tools : Word processors are no longer standalone. They integrate with task managers, cloud storage, and project management platforms. For instance, Google Docs syncs with Google Drive, while Microsoft Word integrates seamlessly with OneDrive and Teams.</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_45><loc_84><loc_52></location>3. Voice Typing : Speech-to-text capabilities have made word processing more accessible, particularly for those with disabilities. Tools like Dragon NaturallySpeaking and built-in options in Google Docs and Microsoft Word have made dictation mainstream.</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_40><loc_87><loc_45></location>4. Multimedia Documents : Word processing has expanded beyond text. Modern tools allow users to embed images, videos, charts, and interactive elements, transforming simple documents into rich multimedia experiences.</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_35><loc_86><loc_40></location>5. Cross-Platform Accessibility : Thanks to cloud computing, documents can now be accessed and edited across devices. Whether you're on a desktop, tablet, or smartphone, you can continue working seamlessly.</paragraph>
|
||||
<subtitle-level-1><location><page_4><loc_12><loc_29><loc_38><loc_30></location>A Glimpse Into the Future</subtitle-level-1>
|
||||
<paragraph><location><page_4><loc_12><loc_24><loc_87><loc_27></location>The word processor's future lies in adaptability and intelligence. Some exciting possibilities include:</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_19><loc_87><loc_22></location>- · Fully AI-Assisted Writing : Imagine a word processor that understands your writing style, drafts emails, or creates entire essays based on minimal input.</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_14><loc_88><loc_19></location>- · Immersive Interfaces : As augmented reality (AR) and virtual reality (VR) technology advance, users may be able to write and edit in 3D spaces, collaborating in virtual environments.</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_11><loc_87><loc_14></location>- · Hyper-Personalization : Word processors could offer dynamic suggestions based on industry-specific needs, user habits, or even regional language variations.</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_19><loc_87><loc_22></location>· Fully AI-Assisted Writing : Imagine a word processor that understands your writing style, drafts emails, or creates entire essays based on minimal input.</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_14><loc_88><loc_19></location>· Immersive Interfaces : As augmented reality (AR) and virtual reality (VR) technology advance, users may be able to write and edit in 3D spaces, collaborating in virtual environments.</paragraph>
|
||||
<paragraph><location><page_4><loc_15><loc_11><loc_87><loc_14></location>· Hyper-Personalization : Word processors could offer dynamic suggestions based on industry-specific needs, user habits, or even regional language variations.</paragraph>
|
||||
<paragraph><location><page_5><loc_12><loc_80><loc_86><loc_88></location>The journey of the word processor-from clunky typewriters to AI-powered platformsreflects humanity's broader technological progress. What began as a tool to simply replace handwriting has transformed into a powerful ally for creativity, communication, and collaboration. As technology continues to advance, the word processor will undoubtedly remain at the heart of how we express ideas and connect with one another.</paragraph>
|
||||
</document>
|
@ -238,7 +238,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 IBM MT/ST (Magnetic Tape/Selectric Typewriter) : Introduced in 1964, this machine combined IBM's Selectric typewriter with magnetic tape storage. It allowed users to record, edit, and replay typed content-an early example of digital text storage.",
|
||||
"text": "\u00b7 IBM MT/ST (Magnetic Tape/Selectric Typewriter) : Introduced in 1964, this machine combined IBM's Selectric typewriter with magnetic tape storage. It allowed users to record, edit, and replay typed content-an early example of digital text storage.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -261,7 +261,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 Wang Laboratories : In the 1970s, Wang introduced dedicated word processing machines. These devices, like the Wang 1200, featured small screens and floppy disks, making them revolutionary for their time.",
|
||||
"text": "\u00b7 Wang Laboratories : In the 1970s, Wang introduced dedicated word processing machines. These devices, like the Wang 1200, featured small screens and floppy disks, making them revolutionary for their time.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -353,7 +353,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 WordStar (1978) : Developed for the CP/M operating system, WordStar was one of the first widely used word processing programs. It featured early examples of modern features like cut, copy, and paste.",
|
||||
"text": "\u00b7 WordStar (1978) : Developed for the CP/M operating system, WordStar was one of the first widely used word processing programs. It featured early examples of modern features like cut, copy, and paste.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -376,7 +376,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 Microsoft Word (1983) : Microsoft launched Word for MS-DOS in 1983, introducing a graphical user interface (GUI) and mouse support. Over the years, Microsoft Word became the industry standard for word processing.",
|
||||
"text": "\u00b7 Microsoft Word (1983) : Microsoft launched Word for MS-DOS in 1983, introducing a graphical user interface (GUI) and mouse support. Over the years, Microsoft Word became the industry standard for word processing.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -468,7 +468,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 Microsoft Office Suite : Microsoft continued to dominate with its Office Suite, integrating Word with other productivity tools like Excel and PowerPoint.",
|
||||
"text": "\u00b7 Microsoft Office Suite : Microsoft continued to dominate with its Office Suite, integrating Word with other productivity tools like Excel and PowerPoint.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -491,7 +491,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 OpenOffice and LibreOffice : Open-source alternatives emerged in the early 2000s, offering free and flexible word processing options.",
|
||||
"text": "\u00b7 OpenOffice and LibreOffice : Open-source alternatives emerged in the early 2000s, offering free and flexible word processing options.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -514,7 +514,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 Google Docs (2006) : The introduction of cloud-based word processing revolutionized collaboration. Google Docs enabled real-time editing and sharing, making it a staple for teams and remote work.",
|
||||
"text": "\u00b7 Google Docs (2006) : The introduction of cloud-based word processing revolutionized collaboration. Google Docs enabled real-time editing and sharing, making it a staple for teams and remote work.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -652,7 +652,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 Academic and Technical Writing : Tools like LaTeX gained popularity among academics, scientists, and engineers. Unlike traditional word processors, LaTeX focuses on precise formatting, particularly for complex mathematical equations, scientific papers, and technical documents. It relies on a markup language to produce polished documents suitable for publishing.",
|
||||
"text": "\u00b7 Academic and Technical Writing : Tools like LaTeX gained popularity among academics, scientists, and engineers. Unlike traditional word processors, LaTeX focuses on precise formatting, particularly for complex mathematical equations, scientific papers, and technical documents. It relies on a markup language to produce polished documents suitable for publishing.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -675,7 +675,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 Screenwriting Software : For screenwriters, tools like Final Draft and Celtx are specialized to handle scripts for film and television. These programs automate the formatting of dialogue, scene descriptions, and other elements unique to screenwriting.",
|
||||
"text": "\u00b7 Screenwriting Software : For screenwriters, tools like Final Draft and Celtx are specialized to handle scripts for film and television. These programs automate the formatting of dialogue, scene descriptions, and other elements unique to screenwriting.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -698,7 +698,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 Legal Document Processors : Word processors tailored for legal professionals, like WordPerfect, offered features such as redlining (early version tracking) and document comparison. Even today, many law firms rely on these tools due to their robust formatting options for contracts and legal briefs.",
|
||||
"text": "\u00b7 Legal Document Processors : Word processors tailored for legal professionals, like WordPerfect, offered features such as redlining (early version tracking) and document comparison. Even today, many law firms rely on these tools due to their robust formatting options for contracts and legal briefs.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -767,7 +767,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 1. Undo/Redo : Introduced in the 1980s, the ability to undo mistakes and redo actions made experimentation and error correction much easier.",
|
||||
"text": "1. Undo/Redo : Introduced in the 1980s, the ability to undo mistakes and redo actions made experimentation and error correction much easier.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -790,7 +790,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 2. Spell Check and Grammar Check : By the 1990s, these became standard, allowing users to spot errors automatically.",
|
||||
"text": "2. Spell Check and Grammar Check : By the 1990s, these became standard, allowing users to spot errors automatically.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -813,7 +813,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 3. Templates : Pre-designed formats for documents, such as resumes, letters, and invoices, helped users save time.",
|
||||
"text": "3. Templates : Pre-designed formats for documents, such as resumes, letters, and invoices, helped users save time.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -836,7 +836,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 4. Track Changes : A game-changer for collaboration, this feature allowed multiple users to suggest edits while maintaining the original text.",
|
||||
"text": "4. Track Changes : A game-changer for collaboration, this feature allowed multiple users to suggest edits while maintaining the original text.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -859,7 +859,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 5. Real-Time Collaboration : Tools like Google Docs and Microsoft 365 enabled multiple users to edit the same document simultaneously, forever changing teamwork dynamics.",
|
||||
"text": "5. Real-Time Collaboration : Tools like Google Docs and Microsoft 365 enabled multiple users to edit the same document simultaneously, forever changing teamwork dynamics.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -928,7 +928,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 Accessibility : Writers no longer needed expensive publishing equipment or training in typesetting to create polished work. This accessibility paved the way for selfpublishing, blogging, and even fan fiction communities.",
|
||||
"text": "\u00b7 Accessibility : Writers no longer needed expensive publishing equipment or training in typesetting to create polished work. This accessibility paved the way for selfpublishing, blogging, and even fan fiction communities.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -951,7 +951,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 Education : Word processors became a cornerstone of education, teaching students not only how to write essays but also how to use technology effectively. Features like bibliography generators and integrated research tools enhanced learning.",
|
||||
"text": "\u00b7 Education : Word processors became a cornerstone of education, teaching students not only how to write essays but also how to use technology effectively. Features like bibliography generators and integrated research tools enhanced learning.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -974,7 +974,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 Creative Writing : Writers gained powerful tools to organize their ideas. Programs like Scrivener allowed authors to manage large projects, from novels to screenplays, with features like chapter outlines and character notes.",
|
||||
"text": "\u00b7 Creative Writing : Writers gained powerful tools to organize their ideas. Programs like Scrivener allowed authors to manage large projects, from novels to screenplays, with features like chapter outlines and character notes.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1043,7 +1043,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 1. Artificial Intelligence : Modern word processors are leveraging AI to suggest content improvements. Tools like Grammarly, ProWritingAid, and even native features in Word now analyze tone, conciseness, and clarity. Some AI systems can even generate entire paragraphs or rewrite sentences.",
|
||||
"text": "1. Artificial Intelligence : Modern word processors are leveraging AI to suggest content improvements. Tools like Grammarly, ProWritingAid, and even native features in Word now analyze tone, conciseness, and clarity. Some AI systems can even generate entire paragraphs or rewrite sentences.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1066,7 +1066,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 2. Integration with Other Tools : Word processors are no longer standalone. They integrate with task managers, cloud storage, and project management platforms. For instance, Google Docs syncs with Google Drive, while Microsoft Word integrates seamlessly with OneDrive and Teams.",
|
||||
"text": "2. Integration with Other Tools : Word processors are no longer standalone. They integrate with task managers, cloud storage, and project management platforms. For instance, Google Docs syncs with Google Drive, while Microsoft Word integrates seamlessly with OneDrive and Teams.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1089,7 +1089,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 3. Voice Typing : Speech-to-text capabilities have made word processing more accessible, particularly for those with disabilities. Tools like Dragon NaturallySpeaking and built-in options in Google Docs and Microsoft Word have made dictation mainstream.",
|
||||
"text": "3. Voice Typing : Speech-to-text capabilities have made word processing more accessible, particularly for those with disabilities. Tools like Dragon NaturallySpeaking and built-in options in Google Docs and Microsoft Word have made dictation mainstream.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1112,7 +1112,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 4. Multimedia Documents : Word processing has expanded beyond text. Modern tools allow users to embed images, videos, charts, and interactive elements, transforming simple documents into rich multimedia experiences.",
|
||||
"text": "4. Multimedia Documents : Word processing has expanded beyond text. Modern tools allow users to embed images, videos, charts, and interactive elements, transforming simple documents into rich multimedia experiences.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1135,7 +1135,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 5. Cross-Platform Accessibility : Thanks to cloud computing, documents can now be accessed and edited across devices. Whether you're on a desktop, tablet, or smartphone, you can continue working seamlessly.",
|
||||
"text": "5. Cross-Platform Accessibility : Thanks to cloud computing, documents can now be accessed and edited across devices. Whether you're on a desktop, tablet, or smartphone, you can continue working seamlessly.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1204,7 +1204,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 Fully AI-Assisted Writing : Imagine a word processor that understands your writing style, drafts emails, or creates entire essays based on minimal input.",
|
||||
"text": "\u00b7 Fully AI-Assisted Writing : Imagine a word processor that understands your writing style, drafts emails, or creates entire essays based on minimal input.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1227,7 +1227,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 Immersive Interfaces : As augmented reality (AR) and virtual reality (VR) technology advance, users may be able to write and edit in 3D spaces, collaborating in virtual environments.",
|
||||
"text": "\u00b7 Immersive Interfaces : As augmented reality (AR) and virtual reality (VR) technology advance, users may be able to write and edit in 3D spaces, collaborating in virtual environments.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1250,7 +1250,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- \u00b7 Hyper-Personalization : Word processors could offer dynamic suggestions based on industry-specific needs, user habits, or even regional language variations.",
|
||||
"text": "\u00b7 Hyper-Personalization : Word processors could offer dynamic suggestions based on industry-specific needs, user habits, or even regional language variations.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
|
52
tests/data/groundtruth/docling_v1/multi_page.md
vendored
52
tests/data/groundtruth/docling_v1/multi_page.md
vendored
@ -12,9 +12,9 @@ During this period, the term "word processing" didn't exist, but the typewriter
|
||||
|
||||
The term "word processor" first emerged in the 1960s and referred to any system designed to streamline written communication and document production. Early word processors were not software programs but rather standalone machines.
|
||||
|
||||
- · IBM MT/ST (Magnetic Tape/Selectric Typewriter) : Introduced in 1964, this machine combined IBM's Selectric typewriter with magnetic tape storage. It allowed users to record, edit, and replay typed content-an early example of digital text storage.
|
||||
· IBM MT/ST (Magnetic Tape/Selectric Typewriter) : Introduced in 1964, this machine combined IBM's Selectric typewriter with magnetic tape storage. It allowed users to record, edit, and replay typed content-an early example of digital text storage.
|
||||
|
||||
- · Wang Laboratories : In the 1970s, Wang introduced dedicated word processing machines. These devices, like the Wang 1200, featured small screens and floppy disks, making them revolutionary for their time.
|
||||
· Wang Laboratories : In the 1970s, Wang introduced dedicated word processing machines. These devices, like the Wang 1200, featured small screens and floppy disks, making them revolutionary for their time.
|
||||
|
||||
These machines were primarily used in offices, where secretarial pools benefited from their ability to make revisions without retyping entire documents.
|
||||
|
||||
@ -22,9 +22,9 @@ These machines were primarily used in offices, where secretarial pools benefited
|
||||
|
||||
The advent of personal computers in the late 1970s and early 1980s transformed word processing from a niche tool to an essential technology for businesses and individuals alike.
|
||||
|
||||
- · WordStar (1978) : Developed for the CP/M operating system, WordStar was one of the first widely used word processing programs. It featured early examples of modern features like cut, copy, and paste.
|
||||
· WordStar (1978) : Developed for the CP/M operating system, WordStar was one of the first widely used word processing programs. It featured early examples of modern features like cut, copy, and paste.
|
||||
|
||||
- · Microsoft Word (1983) : Microsoft launched Word for MS-DOS in 1983, introducing a graphical user interface (GUI) and mouse support. Over the years, Microsoft Word became the industry standard for word processing.
|
||||
· Microsoft Word (1983) : Microsoft launched Word for MS-DOS in 1983, introducing a graphical user interface (GUI) and mouse support. Over the years, Microsoft Word became the industry standard for word processing.
|
||||
|
||||
Other notable software from this era included WordPerfect, which was popular among legal professionals, and Apple's MacWrite, which leveraged the Macintosh's graphical capabilities.
|
||||
|
||||
@ -32,11 +32,11 @@ Other notable software from this era included WordPerfect, which was popular amo
|
||||
|
||||
By the 1990s, word processing software had become more sophisticated, with features like spell check, grammar check, templates, and collaborative tools.
|
||||
|
||||
- · Microsoft Office Suite : Microsoft continued to dominate with its Office Suite, integrating Word with other productivity tools like Excel and PowerPoint.
|
||||
· Microsoft Office Suite : Microsoft continued to dominate with its Office Suite, integrating Word with other productivity tools like Excel and PowerPoint.
|
||||
|
||||
- · OpenOffice and LibreOffice : Open-source alternatives emerged in the early 2000s, offering free and flexible word processing options.
|
||||
· OpenOffice and LibreOffice : Open-source alternatives emerged in the early 2000s, offering free and flexible word processing options.
|
||||
|
||||
- · Google Docs (2006) : The introduction of cloud-based word processing revolutionized collaboration. Google Docs enabled real-time editing and sharing, making it a staple for teams and remote work.
|
||||
· Google Docs (2006) : The introduction of cloud-based word processing revolutionized collaboration. Google Docs enabled real-time editing and sharing, making it a staple for teams and remote work.
|
||||
|
||||
## Future of Word Processing
|
||||
|
||||
@ -48,58 +48,58 @@ From the clunky typewriters of the 19th century to the AI-powered cloud tools of
|
||||
|
||||
In addition to general-purpose word processors, specialized tools have emerged to cater to specific industries and needs. These tools incorporate unique features tailored to their users' workflows:
|
||||
|
||||
- · Academic and Technical Writing : Tools like LaTeX gained popularity among academics, scientists, and engineers. Unlike traditional word processors, LaTeX focuses on precise formatting, particularly for complex mathematical equations, scientific papers, and technical documents. It relies on a markup language to produce polished documents suitable for publishing.
|
||||
· Academic and Technical Writing : Tools like LaTeX gained popularity among academics, scientists, and engineers. Unlike traditional word processors, LaTeX focuses on precise formatting, particularly for complex mathematical equations, scientific papers, and technical documents. It relies on a markup language to produce polished documents suitable for publishing.
|
||||
|
||||
- · Screenwriting Software : For screenwriters, tools like Final Draft and Celtx are specialized to handle scripts for film and television. These programs automate the formatting of dialogue, scene descriptions, and other elements unique to screenwriting.
|
||||
· Screenwriting Software : For screenwriters, tools like Final Draft and Celtx are specialized to handle scripts for film and television. These programs automate the formatting of dialogue, scene descriptions, and other elements unique to screenwriting.
|
||||
|
||||
- · Legal Document Processors : Word processors tailored for legal professionals, like WordPerfect, offered features such as redlining (early version tracking) and document comparison. Even today, many law firms rely on these tools due to their robust formatting options for contracts and legal briefs.
|
||||
· Legal Document Processors : Word processors tailored for legal professionals, like WordPerfect, offered features such as redlining (early version tracking) and document comparison. Even today, many law firms rely on these tools due to their robust formatting options for contracts and legal briefs.
|
||||
|
||||
## Key Features That Changed Word Processing
|
||||
|
||||
The evolution of word processors wasn't just about hardware or software improvements-it was about the features that revolutionized how people wrote and edited. Some of these transformative features include:
|
||||
|
||||
- 1. Undo/Redo : Introduced in the 1980s, the ability to undo mistakes and redo actions made experimentation and error correction much easier.
|
||||
1. Undo/Redo : Introduced in the 1980s, the ability to undo mistakes and redo actions made experimentation and error correction much easier.
|
||||
|
||||
- 2. Spell Check and Grammar Check : By the 1990s, these became standard, allowing users to spot errors automatically.
|
||||
2. Spell Check and Grammar Check : By the 1990s, these became standard, allowing users to spot errors automatically.
|
||||
|
||||
- 3. Templates : Pre-designed formats for documents, such as resumes, letters, and invoices, helped users save time.
|
||||
3. Templates : Pre-designed formats for documents, such as resumes, letters, and invoices, helped users save time.
|
||||
|
||||
- 4. Track Changes : A game-changer for collaboration, this feature allowed multiple users to suggest edits while maintaining the original text.
|
||||
4. Track Changes : A game-changer for collaboration, this feature allowed multiple users to suggest edits while maintaining the original text.
|
||||
|
||||
- 5. Real-Time Collaboration : Tools like Google Docs and Microsoft 365 enabled multiple users to edit the same document simultaneously, forever changing teamwork dynamics.
|
||||
5. Real-Time Collaboration : Tools like Google Docs and Microsoft 365 enabled multiple users to edit the same document simultaneously, forever changing teamwork dynamics.
|
||||
|
||||
## The Cultural Impact of Word Processors
|
||||
|
||||
The word processor didn't just change workplaces-it changed culture. It democratized writing, enabling anyone with access to a computer to produce professional-quality documents. This shift had profound implications for education, business, and creative fields:
|
||||
|
||||
- · Accessibility : Writers no longer needed expensive publishing equipment or training in typesetting to create polished work. This accessibility paved the way for selfpublishing, blogging, and even fan fiction communities.
|
||||
· Accessibility : Writers no longer needed expensive publishing equipment or training in typesetting to create polished work. This accessibility paved the way for selfpublishing, blogging, and even fan fiction communities.
|
||||
|
||||
- · Education : Word processors became a cornerstone of education, teaching students not only how to write essays but also how to use technology effectively. Features like bibliography generators and integrated research tools enhanced learning.
|
||||
· Education : Word processors became a cornerstone of education, teaching students not only how to write essays but also how to use technology effectively. Features like bibliography generators and integrated research tools enhanced learning.
|
||||
|
||||
- · Creative Writing : Writers gained powerful tools to organize their ideas. Programs like Scrivener allowed authors to manage large projects, from novels to screenplays, with features like chapter outlines and character notes.
|
||||
· Creative Writing : Writers gained powerful tools to organize their ideas. Programs like Scrivener allowed authors to manage large projects, from novels to screenplays, with features like chapter outlines and character notes.
|
||||
|
||||
## Word Processors in a Post-Digital Era
|
||||
|
||||
As we move further into the 21st century, the role of the word processor continues to evolve:
|
||||
|
||||
- 1. Artificial Intelligence : Modern word processors are leveraging AI to suggest content improvements. Tools like Grammarly, ProWritingAid, and even native features in Word now analyze tone, conciseness, and clarity. Some AI systems can even generate entire paragraphs or rewrite sentences.
|
||||
1. Artificial Intelligence : Modern word processors are leveraging AI to suggest content improvements. Tools like Grammarly, ProWritingAid, and even native features in Word now analyze tone, conciseness, and clarity. Some AI systems can even generate entire paragraphs or rewrite sentences.
|
||||
|
||||
- 2. Integration with Other Tools : Word processors are no longer standalone. They integrate with task managers, cloud storage, and project management platforms. For instance, Google Docs syncs with Google Drive, while Microsoft Word integrates seamlessly with OneDrive and Teams.
|
||||
2. Integration with Other Tools : Word processors are no longer standalone. They integrate with task managers, cloud storage, and project management platforms. For instance, Google Docs syncs with Google Drive, while Microsoft Word integrates seamlessly with OneDrive and Teams.
|
||||
|
||||
- 3. Voice Typing : Speech-to-text capabilities have made word processing more accessible, particularly for those with disabilities. Tools like Dragon NaturallySpeaking and built-in options in Google Docs and Microsoft Word have made dictation mainstream.
|
||||
3. Voice Typing : Speech-to-text capabilities have made word processing more accessible, particularly for those with disabilities. Tools like Dragon NaturallySpeaking and built-in options in Google Docs and Microsoft Word have made dictation mainstream.
|
||||
|
||||
- 4. Multimedia Documents : Word processing has expanded beyond text. Modern tools allow users to embed images, videos, charts, and interactive elements, transforming simple documents into rich multimedia experiences.
|
||||
4. Multimedia Documents : Word processing has expanded beyond text. Modern tools allow users to embed images, videos, charts, and interactive elements, transforming simple documents into rich multimedia experiences.
|
||||
|
||||
- 5. Cross-Platform Accessibility : Thanks to cloud computing, documents can now be accessed and edited across devices. Whether you're on a desktop, tablet, or smartphone, you can continue working seamlessly.
|
||||
5. Cross-Platform Accessibility : Thanks to cloud computing, documents can now be accessed and edited across devices. Whether you're on a desktop, tablet, or smartphone, you can continue working seamlessly.
|
||||
|
||||
## A Glimpse Into the Future
|
||||
|
||||
The word processor's future lies in adaptability and intelligence. Some exciting possibilities include:
|
||||
|
||||
- · Fully AI-Assisted Writing : Imagine a word processor that understands your writing style, drafts emails, or creates entire essays based on minimal input.
|
||||
· Fully AI-Assisted Writing : Imagine a word processor that understands your writing style, drafts emails, or creates entire essays based on minimal input.
|
||||
|
||||
- · Immersive Interfaces : As augmented reality (AR) and virtual reality (VR) technology advance, users may be able to write and edit in 3D spaces, collaborating in virtual environments.
|
||||
· Immersive Interfaces : As augmented reality (AR) and virtual reality (VR) technology advance, users may be able to write and edit in 3D spaces, collaborating in virtual environments.
|
||||
|
||||
- · Hyper-Personalization : Word processors could offer dynamic suggestions based on industry-specific needs, user habits, or even regional language variations.
|
||||
· Hyper-Personalization : Word processors could offer dynamic suggestions based on industry-specific needs, user habits, or even regional language variations.
|
||||
|
||||
The journey of the word processor-from clunky typewriters to AI-powered platformsreflects humanity's broader technological progress. What began as a tool to simply replace handwriting has transformed into a powerful ally for creativity, communication, and collaboration. As technology continues to advance, the word processor will undoubtedly remain at the heart of how we express ideas and connect with one another.
|
@ -17,10 +17,10 @@
|
||||
<location><page_3><loc_23><loc_64><loc_29><loc_66></location>
|
||||
</figure>
|
||||
<subtitle-level-1><location><page_3><loc_24><loc_57><loc_31><loc_59></location>Highlights</subtitle-level-1>
|
||||
<paragraph><location><page_3><loc_24><loc_55><loc_40><loc_56></location>- GLYPH<g115>GLYPH<g3> GLYPH<g40>GLYPH<g81>GLYPH<g75>GLYPH<g68>GLYPH<g81>GLYPH<g70>GLYPH<g72>GLYPH<g3> GLYPH<g87>GLYPH<g75>GLYPH<g72>GLYPH<g3> GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g73>GLYPH<g82>GLYPH<g85>GLYPH<g80>GLYPH<g68>GLYPH<g81>GLYPH<g70>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g92>GLYPH<g82>GLYPH<g88>GLYPH<g85> GLYPH<g3> GLYPH<g71>GLYPH<g68>GLYPH<g87>GLYPH<g68>GLYPH<g69>GLYPH<g68>GLYPH<g86>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g68>GLYPH<g87>GLYPH<g76>GLYPH<g82>GLYPH<g81>GLYPH<g86></paragraph>
|
||||
<paragraph><location><page_3><loc_24><loc_51><loc_42><loc_54></location>- GLYPH<g115>GLYPH<g3> GLYPH<g40>GLYPH<g68>GLYPH<g85> GLYPH<g81>GLYPH<g3> GLYPH<g74>GLYPH<g85>GLYPH<g72>GLYPH<g68>GLYPH<g87>GLYPH<g72>GLYPH<g85>GLYPH<g3> GLYPH<g85>GLYPH<g72>GLYPH<g87>GLYPH<g88>GLYPH<g85> GLYPH<g81>GLYPH<g3> GLYPH<g82>GLYPH<g81>GLYPH<g3> GLYPH<g44>GLYPH<g55>GLYPH<g3> GLYPH<g83>GLYPH<g85>GLYPH<g82>GLYPH<g77>GLYPH<g72>GLYPH<g70>GLYPH<g87>GLYPH<g86> GLYPH<g3> GLYPH<g87>GLYPH<g75>GLYPH<g85>GLYPH<g82>GLYPH<g88>GLYPH<g74>GLYPH<g75>GLYPH<g3> GLYPH<g80>GLYPH<g82>GLYPH<g71>GLYPH<g72>GLYPH<g85> GLYPH<g81>GLYPH<g76>GLYPH<g93>GLYPH<g68>GLYPH<g87>GLYPH<g76>GLYPH<g82>GLYPH<g81>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g71>GLYPH<g68>GLYPH<g87>GLYPH<g68>GLYPH<g69>GLYPH<g68>GLYPH<g86>GLYPH<g72>GLYPH<g3> GLYPH<g68>GLYPH<g81>GLYPH<g71> GLYPH<g3> GLYPH<g68>GLYPH<g83>GLYPH<g83>GLYPH<g79>GLYPH<g76>GLYPH<g70>GLYPH<g68>GLYPH<g87>GLYPH<g76>GLYPH<g82>GLYPH<g81>GLYPH<g86></paragraph>
|
||||
<paragraph><location><page_3><loc_24><loc_48><loc_41><loc_50></location>- GLYPH<g115>GLYPH<g3> GLYPH<g53>GLYPH<g72>GLYPH<g79>GLYPH<g92>GLYPH<g3> GLYPH<g82>GLYPH<g81>GLYPH<g3> GLYPH<g44>GLYPH<g37>GLYPH<g48>GLYPH<g3> GLYPH<g72>GLYPH<g91>GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g87>GLYPH<g3> GLYPH<g70>GLYPH<g82>GLYPH<g81>GLYPH<g86>GLYPH<g88>GLYPH<g79>GLYPH<g87>GLYPH<g76>GLYPH<g81>GLYPH<g74>GLYPH<g15>GLYPH<g3> GLYPH<g86>GLYPH<g78>GLYPH<g76>GLYPH<g79>GLYPH<g79>GLYPH<g86> GLYPH<g3> GLYPH<g86>GLYPH<g75>GLYPH<g68>GLYPH<g85>GLYPH<g76>GLYPH<g81>GLYPH<g74>GLYPH<g3> GLYPH<g68>GLYPH<g81>GLYPH<g71>GLYPH<g3> GLYPH<g85>GLYPH<g72>GLYPH<g81>GLYPH<g82>GLYPH<g90>GLYPH<g81>GLYPH<g3> GLYPH<g86>GLYPH<g72>GLYPH<g85>GLYPH<g89>GLYPH<g76>GLYPH<g70>GLYPH<g72>GLYPH<g86></paragraph>
|
||||
<paragraph><location><page_3><loc_24><loc_45><loc_38><loc_47></location>- GLYPH<g115>GLYPH<g3> GLYPH<g55> GLYPH<g68>GLYPH<g78>GLYPH<g72>GLYPH<g3> GLYPH<g68>GLYPH<g71>GLYPH<g89>GLYPH<g68>GLYPH<g81>GLYPH<g87>GLYPH<g68>GLYPH<g74>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g68>GLYPH<g70>GLYPH<g70>GLYPH<g72>GLYPH<g86>GLYPH<g86>GLYPH<g3> GLYPH<g87>GLYPH<g82>GLYPH<g3> GLYPH<g68> GLYPH<g3> GLYPH<g90>GLYPH<g82>GLYPH<g85>GLYPH<g79>GLYPH<g71>GLYPH<g90>GLYPH<g76>GLYPH<g71>GLYPH<g72>GLYPH<g3> GLYPH<g86>GLYPH<g82>GLYPH<g88>GLYPH<g85>GLYPH<g70>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g72>GLYPH<g91>GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g87>GLYPH<g76>GLYPH<g86>GLYPH<g72></paragraph>
|
||||
<paragraph><location><page_3><loc_24><loc_55><loc_40><loc_56></location>GLYPH<g115>GLYPH<g3> GLYPH<g40>GLYPH<g81>GLYPH<g75>GLYPH<g68>GLYPH<g81>GLYPH<g70>GLYPH<g72>GLYPH<g3> GLYPH<g87>GLYPH<g75>GLYPH<g72>GLYPH<g3> GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g73>GLYPH<g82>GLYPH<g85>GLYPH<g80>GLYPH<g68>GLYPH<g81>GLYPH<g70>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g92>GLYPH<g82>GLYPH<g88>GLYPH<g85> GLYPH<g3> GLYPH<g71>GLYPH<g68>GLYPH<g87>GLYPH<g68>GLYPH<g69>GLYPH<g68>GLYPH<g86>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g68>GLYPH<g87>GLYPH<g76>GLYPH<g82>GLYPH<g81>GLYPH<g86></paragraph>
|
||||
<paragraph><location><page_3><loc_24><loc_51><loc_42><loc_54></location>GLYPH<g115>GLYPH<g3> GLYPH<g40>GLYPH<g68>GLYPH<g85> GLYPH<g81>GLYPH<g3> GLYPH<g74>GLYPH<g85>GLYPH<g72>GLYPH<g68>GLYPH<g87>GLYPH<g72>GLYPH<g85>GLYPH<g3> GLYPH<g85>GLYPH<g72>GLYPH<g87>GLYPH<g88>GLYPH<g85> GLYPH<g81>GLYPH<g3> GLYPH<g82>GLYPH<g81>GLYPH<g3> GLYPH<g44>GLYPH<g55>GLYPH<g3> GLYPH<g83>GLYPH<g85>GLYPH<g82>GLYPH<g77>GLYPH<g72>GLYPH<g70>GLYPH<g87>GLYPH<g86> GLYPH<g3> GLYPH<g87>GLYPH<g75>GLYPH<g85>GLYPH<g82>GLYPH<g88>GLYPH<g74>GLYPH<g75>GLYPH<g3> GLYPH<g80>GLYPH<g82>GLYPH<g71>GLYPH<g72>GLYPH<g85> GLYPH<g81>GLYPH<g76>GLYPH<g93>GLYPH<g68>GLYPH<g87>GLYPH<g76>GLYPH<g82>GLYPH<g81>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g71>GLYPH<g68>GLYPH<g87>GLYPH<g68>GLYPH<g69>GLYPH<g68>GLYPH<g86>GLYPH<g72>GLYPH<g3> GLYPH<g68>GLYPH<g81>GLYPH<g71> GLYPH<g3> GLYPH<g68>GLYPH<g83>GLYPH<g83>GLYPH<g79>GLYPH<g76>GLYPH<g70>GLYPH<g68>GLYPH<g87>GLYPH<g76>GLYPH<g82>GLYPH<g81>GLYPH<g86></paragraph>
|
||||
<paragraph><location><page_3><loc_24><loc_48><loc_41><loc_50></location>GLYPH<g115>GLYPH<g3> GLYPH<g53>GLYPH<g72>GLYPH<g79>GLYPH<g92>GLYPH<g3> GLYPH<g82>GLYPH<g81>GLYPH<g3> GLYPH<g44>GLYPH<g37>GLYPH<g48>GLYPH<g3> GLYPH<g72>GLYPH<g91>GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g87>GLYPH<g3> GLYPH<g70>GLYPH<g82>GLYPH<g81>GLYPH<g86>GLYPH<g88>GLYPH<g79>GLYPH<g87>GLYPH<g76>GLYPH<g81>GLYPH<g74>GLYPH<g15>GLYPH<g3> GLYPH<g86>GLYPH<g78>GLYPH<g76>GLYPH<g79>GLYPH<g79>GLYPH<g86> GLYPH<g3> GLYPH<g86>GLYPH<g75>GLYPH<g68>GLYPH<g85>GLYPH<g76>GLYPH<g81>GLYPH<g74>GLYPH<g3> GLYPH<g68>GLYPH<g81>GLYPH<g71>GLYPH<g3> GLYPH<g85>GLYPH<g72>GLYPH<g81>GLYPH<g82>GLYPH<g90>GLYPH<g81>GLYPH<g3> GLYPH<g86>GLYPH<g72>GLYPH<g85>GLYPH<g89>GLYPH<g76>GLYPH<g70>GLYPH<g72>GLYPH<g86></paragraph>
|
||||
<paragraph><location><page_3><loc_24><loc_45><loc_38><loc_47></location>GLYPH<g115>GLYPH<g3> GLYPH<g55> GLYPH<g68>GLYPH<g78>GLYPH<g72>GLYPH<g3> GLYPH<g68>GLYPH<g71>GLYPH<g89>GLYPH<g68>GLYPH<g81>GLYPH<g87>GLYPH<g68>GLYPH<g74>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g68>GLYPH<g70>GLYPH<g70>GLYPH<g72>GLYPH<g86>GLYPH<g86>GLYPH<g3> GLYPH<g87>GLYPH<g82>GLYPH<g3> GLYPH<g68> GLYPH<g3> GLYPH<g90>GLYPH<g82>GLYPH<g85>GLYPH<g79>GLYPH<g71>GLYPH<g90>GLYPH<g76>GLYPH<g71>GLYPH<g72>GLYPH<g3> GLYPH<g86>GLYPH<g82>GLYPH<g88>GLYPH<g85>GLYPH<g70>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g72>GLYPH<g91>GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g87>GLYPH<g76>GLYPH<g86>GLYPH<g72></paragraph>
|
||||
<figure>
|
||||
<location><page_3><loc_10><loc_13><loc_42><loc_24></location>
|
||||
</figure>
|
||||
@ -33,15 +33,15 @@
|
||||
<paragraph><location><page_3><loc_46><loc_46><loc_82><loc_52></location>With combined experiences and direct access to development groups, we're the experts in IBM DB2® for i. The DB2 for i Center of Excellence (CoE) can help you achieve-perhaps reexamine and exceed-your business requirements and gain more confidence and satisfaction in IBM product data management products and solutions.</paragraph>
|
||||
<subtitle-level-1><location><page_3><loc_46><loc_44><loc_71><loc_45></location>Who we are, some of what we do</subtitle-level-1>
|
||||
<paragraph><location><page_3><loc_46><loc_42><loc_71><loc_43></location>Global CoE engagements cover topics including:</paragraph>
|
||||
<paragraph><location><page_3><loc_46><loc_40><loc_66><loc_41></location>- r Database performance and scalability</paragraph>
|
||||
<paragraph><location><page_3><loc_46><loc_39><loc_69><loc_39></location>- r Advanced SQL knowledge and skills transfer</paragraph>
|
||||
<paragraph><location><page_3><loc_46><loc_37><loc_64><loc_38></location>- r Business intelligence and analytics</paragraph>
|
||||
<paragraph><location><page_3><loc_46><loc_36><loc_56><loc_37></location>- r DB2 Web Query</paragraph>
|
||||
<paragraph><location><page_3><loc_46><loc_35><loc_82><loc_36></location>- r Query/400 modernization for better reporting and analysis capabilities</paragraph>
|
||||
<paragraph><location><page_3><loc_46><loc_33><loc_69><loc_34></location>- r Database modernization and re-engineering</paragraph>
|
||||
<paragraph><location><page_3><loc_46><loc_32><loc_65><loc_33></location>- r Data-centric architecture and design</paragraph>
|
||||
<paragraph><location><page_3><loc_46><loc_31><loc_76><loc_32></location>- r Extremely large database and overcoming limits to growth</paragraph>
|
||||
<paragraph><location><page_3><loc_46><loc_30><loc_62><loc_30></location>- r ISV education and enablement</paragraph>
|
||||
<paragraph><location><page_3><loc_46><loc_40><loc_66><loc_41></location>r Database performance and scalability</paragraph>
|
||||
<paragraph><location><page_3><loc_46><loc_39><loc_69><loc_39></location>r Advanced SQL knowledge and skills transfer</paragraph>
|
||||
<paragraph><location><page_3><loc_46><loc_37><loc_64><loc_38></location>r Business intelligence and analytics</paragraph>
|
||||
<paragraph><location><page_3><loc_46><loc_36><loc_56><loc_37></location>r DB2 Web Query</paragraph>
|
||||
<paragraph><location><page_3><loc_46><loc_35><loc_82><loc_36></location>r Query/400 modernization for better reporting and analysis capabilities</paragraph>
|
||||
<paragraph><location><page_3><loc_46><loc_33><loc_69><loc_34></location>r Database modernization and re-engineering</paragraph>
|
||||
<paragraph><location><page_3><loc_46><loc_32><loc_65><loc_33></location>r Data-centric architecture and design</paragraph>
|
||||
<paragraph><location><page_3><loc_46><loc_31><loc_76><loc_32></location>r Extremely large database and overcoming limits to growth</paragraph>
|
||||
<paragraph><location><page_3><loc_46><loc_30><loc_62><loc_30></location>r ISV education and enablement</paragraph>
|
||||
<subtitle-level-1><location><page_4><loc_11><loc_88><loc_25><loc_91></location>Preface</subtitle-level-1>
|
||||
<paragraph><location><page_4><loc_22><loc_75><loc_89><loc_83></location>This IBMfi Redpaper™ publication provides information about the IBM i 7.2 feature of IBM DB2fi for i Row and Column Access Control (RCAC). It offers a broad description of the function and advantages of controlling access to data in a comprehensive and transparent way. This publication helps you understand the capabilities of RCAC and provides examples of defining, creating, and implementing the row permissions and column masks in a relational database environment.</paragraph>
|
||||
<paragraph><location><page_4><loc_22><loc_67><loc_89><loc_73></location>This paper is intended for database engineers, data-centric application developers, and security officers who want to design and implement RCAC as a part of their data control and governance policy. A solid background in IBM i object level security, DB2 for i relational database concepts, and SQL is assumed.</paragraph>
|
||||
@ -64,15 +64,15 @@
|
||||
<paragraph><location><page_5><loc_22><loc_46><loc_89><loc_56></location>Recent news headlines are filled with reports of data breaches and cyber-attacks impacting global businesses of all sizes. The Identity Theft Resource Center$^{1}$ reports that almost 5000 data breaches have occurred since 2005, exposing over 600 million records of data. The financial cost of these data breaches is skyrocketing. Studies from the Ponemon Institute$^{2}$ revealed that the average cost of a data breach increased in 2013 by 15% globally and resulted in a brand equity loss of $9.4 million per attack. The average cost that is incurred for each lost record containing sensitive information increased more than 9% to $145 per record.</paragraph>
|
||||
<paragraph><location><page_5><loc_22><loc_38><loc_86><loc_44></location>Businesses must make a serious effort to secure their data and recognize that securing information assets is a cost of doing business. In many parts of the world and in many industries, securing the data is required by law and subject to audits. Data security is no longer an option; it is a requirement.</paragraph>
|
||||
<paragraph><location><page_5><loc_22><loc_34><loc_89><loc_37></location>This chapter describes how you can secure and protect data in DB2 for i. The following topics are covered in this chapter:</paragraph>
|
||||
<paragraph><location><page_5><loc_22><loc_32><loc_41><loc_33></location>- GLYPH<SM590000> Security fundamentals</paragraph>
|
||||
<paragraph><location><page_5><loc_22><loc_30><loc_46><loc_32></location>- GLYPH<SM590000> Current state of IBM i security</paragraph>
|
||||
<paragraph><location><page_5><loc_22><loc_29><loc_43><loc_30></location>- GLYPH<SM590000> DB2 for i security controls</paragraph>
|
||||
<paragraph><location><page_5><loc_22><loc_32><loc_41><loc_33></location>GLYPH<SM590000> Security fundamentals</paragraph>
|
||||
<paragraph><location><page_5><loc_22><loc_30><loc_46><loc_32></location>GLYPH<SM590000> Current state of IBM i security</paragraph>
|
||||
<paragraph><location><page_5><loc_22><loc_29><loc_43><loc_30></location>GLYPH<SM590000> DB2 for i security controls</paragraph>
|
||||
<subtitle-level-1><location><page_6><loc_11><loc_89><loc_44><loc_91></location>1.1 Security fundamentals</subtitle-level-1>
|
||||
<paragraph><location><page_6><loc_22><loc_84><loc_89><loc_87></location>Before reviewing database security techniques, there are two fundamental steps in securing information assets that must be described:</paragraph>
|
||||
<paragraph><location><page_6><loc_22><loc_77><loc_89><loc_83></location>- GLYPH<SM590000> First, and most important, is the definition of a company's security policy . Without a security policy, there is no definition of what are acceptable practices for using, accessing, and storing information by who, what, when, where, and how. A security policy should minimally address three things: confidentiality, integrity, and availability.</paragraph>
|
||||
<paragraph><location><page_6><loc_25><loc_66><loc_89><loc_76></location>- The monitoring and assessment of adherence to the security policy determines whether your security strategy is working. Often, IBM security consultants are asked to perform security assessments for companies without regard to the security policy. Although these assessments can be useful for observing how the system is defined and how data is being accessed, they cannot determine the level of security without a security policy. Without a security policy, it really is not an assessment as much as it is a baseline for monitoring the changes in the security settings that are captured.</paragraph>
|
||||
<paragraph><location><page_6><loc_22><loc_77><loc_89><loc_83></location>GLYPH<SM590000> First, and most important, is the definition of a company's security policy . Without a security policy, there is no definition of what are acceptable practices for using, accessing, and storing information by who, what, when, where, and how. A security policy should minimally address three things: confidentiality, integrity, and availability.</paragraph>
|
||||
<paragraph><location><page_6><loc_25><loc_66><loc_89><loc_76></location>The monitoring and assessment of adherence to the security policy determines whether your security strategy is working. Often, IBM security consultants are asked to perform security assessments for companies without regard to the security policy. Although these assessments can be useful for observing how the system is defined and how data is being accessed, they cannot determine the level of security without a security policy. Without a security policy, it really is not an assessment as much as it is a baseline for monitoring the changes in the security settings that are captured.</paragraph>
|
||||
<paragraph><location><page_6><loc_25><loc_64><loc_89><loc_65></location>A security policy is what defines whether the system and its settings are secure (or not).</paragraph>
|
||||
<paragraph><location><page_6><loc_22><loc_53><loc_89><loc_63></location>- GLYPH<SM590000> The second fundamental in securing data assets is the use of resource security . If implemented properly, resource security prevents data breaches from both internal and external intrusions. Resource security controls are closely tied to the part of the security policy that defines who should have access to what information resources. A hacker might be good enough to get through your company firewalls and sift his way through to your system, but if they do not have explicit access to your database, the hacker cannot compromise your information assets.</paragraph>
|
||||
<paragraph><location><page_6><loc_22><loc_53><loc_89><loc_63></location>GLYPH<SM590000> The second fundamental in securing data assets is the use of resource security . If implemented properly, resource security prevents data breaches from both internal and external intrusions. Resource security controls are closely tied to the part of the security policy that defines who should have access to what information resources. A hacker might be good enough to get through your company firewalls and sift his way through to your system, but if they do not have explicit access to your database, the hacker cannot compromise your information assets.</paragraph>
|
||||
<paragraph><location><page_6><loc_22><loc_48><loc_87><loc_51></location>With your eyes now open to the importance of securing information assets, the rest of this chapter reviews the methods that are available for securing database resources on IBM i.</paragraph>
|
||||
<subtitle-level-1><location><page_6><loc_11><loc_43><loc_53><loc_45></location>1.2 Current state of IBM i security</subtitle-level-1>
|
||||
<paragraph><location><page_6><loc_22><loc_35><loc_89><loc_41></location>Because of the inherently secure nature of IBM i, many clients rely on the default system settings to protect their business data that is stored in DB2 for i. In most cases, this means no data protection because the default setting for the Create default public authority (QCRTAUT) system value is *CHANGE.</paragraph>
|
||||
@ -90,9 +90,9 @@
|
||||
<caption><location><page_7><loc_22><loc_12><loc_52><loc_13></location>Figure 1-2 Existing row and column controls</caption>
|
||||
<subtitle-level-1><location><page_8><loc_11><loc_89><loc_55><loc_91></location>2.1.6 Change Function Usage CL command</subtitle-level-1>
|
||||
<paragraph><location><page_8><loc_22><loc_87><loc_89><loc_88></location>The following CL commands can be used to work with, display, or change function usage IDs:</paragraph>
|
||||
<paragraph><location><page_8><loc_22><loc_84><loc_49><loc_86></location>- GLYPH<SM590000> Work Function Usage ( WRKFCNUSG )</paragraph>
|
||||
<paragraph><location><page_8><loc_22><loc_83><loc_51><loc_84></location>- GLYPH<SM590000> Change Function Usage ( CHGFCNUSG )</paragraph>
|
||||
<paragraph><location><page_8><loc_22><loc_81><loc_51><loc_83></location>- GLYPH<SM590000> Display Function Usage ( DSPFCNUSG )</paragraph>
|
||||
<paragraph><location><page_8><loc_22><loc_84><loc_49><loc_86></location>GLYPH<SM590000> Work Function Usage ( WRKFCNUSG )</paragraph>
|
||||
<paragraph><location><page_8><loc_22><loc_83><loc_51><loc_84></location>GLYPH<SM590000> Change Function Usage ( CHGFCNUSG )</paragraph>
|
||||
<paragraph><location><page_8><loc_22><loc_81><loc_51><loc_83></location>GLYPH<SM590000> Display Function Usage ( DSPFCNUSG )</paragraph>
|
||||
<paragraph><location><page_8><loc_22><loc_77><loc_84><loc_80></location>For example, the following CHGFCNUSG command shows granting authorization to user HBEDOYA to administer and manage RCAC rules:</paragraph>
|
||||
<paragraph><location><page_8><loc_22><loc_75><loc_72><loc_76></location>CHGFCNUSG FCNID(QIBM_DB_SECADM) USER(HBEDOYA) USAGE(*ALLOWED)</paragraph>
|
||||
<subtitle-level-1><location><page_8><loc_11><loc_71><loc_89><loc_72></location>2.1.7 Verifying function usage IDs for RCAC with the FUNCTION_USAGE view</subtitle-level-1>
|
||||
@ -165,11 +165,11 @@
|
||||
</table>
|
||||
<caption><location><page_11><loc_22><loc_87><loc_61><loc_88></location>Table 3-1 Special registers and their corresponding values</caption>
|
||||
<paragraph><location><page_11><loc_22><loc_70><loc_88><loc_73></location>Figure 3-5 shows the difference in the special register values when an adopted authority is used:</paragraph>
|
||||
<paragraph><location><page_11><loc_22><loc_68><loc_67><loc_69></location>- GLYPH<SM590000> A user connects to the server using the user profile ALICE.</paragraph>
|
||||
<paragraph><location><page_11><loc_22><loc_66><loc_74><loc_67></location>- GLYPH<SM590000> USER and CURRENT USER initially have the same value of ALICE.</paragraph>
|
||||
<paragraph><location><page_11><loc_22><loc_62><loc_88><loc_65></location>- GLYPH<SM590000> ALICE calls an SQL procedure that is named proc1, which is owned by user profile JOE and was created to adopt JOE's authority when it is called.</paragraph>
|
||||
<paragraph><location><page_11><loc_22><loc_57><loc_89><loc_61></location>- GLYPH<SM590000> While the procedure is running, the special register USER still contains the value of ALICE because it excludes any adopted authority. The special register CURRENT USER contains the value of JOE because it includes any adopted authority.</paragraph>
|
||||
<paragraph><location><page_11><loc_22><loc_53><loc_89><loc_56></location>- GLYPH<SM590000> When proc1 ends, the session reverts to its original state with both USER and CURRENT USER having the value of ALICE.</paragraph>
|
||||
<paragraph><location><page_11><loc_22><loc_68><loc_67><loc_69></location>GLYPH<SM590000> A user connects to the server using the user profile ALICE.</paragraph>
|
||||
<paragraph><location><page_11><loc_22><loc_66><loc_74><loc_67></location>GLYPH<SM590000> USER and CURRENT USER initially have the same value of ALICE.</paragraph>
|
||||
<paragraph><location><page_11><loc_22><loc_62><loc_88><loc_65></location>GLYPH<SM590000> ALICE calls an SQL procedure that is named proc1, which is owned by user profile JOE and was created to adopt JOE's authority when it is called.</paragraph>
|
||||
<paragraph><location><page_11><loc_22><loc_57><loc_89><loc_61></location>GLYPH<SM590000> While the procedure is running, the special register USER still contains the value of ALICE because it excludes any adopted authority. The special register CURRENT USER contains the value of JOE because it includes any adopted authority.</paragraph>
|
||||
<paragraph><location><page_11><loc_22><loc_53><loc_89><loc_56></location>GLYPH<SM590000> When proc1 ends, the session reverts to its original state with both USER and CURRENT USER having the value of ALICE.</paragraph>
|
||||
<figure>
|
||||
<location><page_11><loc_22><loc_25><loc_49><loc_51></location>
|
||||
<caption>Figure 3-5 Special registers and adopted authority</caption>
|
||||
@ -198,22 +198,22 @@
|
||||
<paragraph><location><page_12><loc_22><loc_45><loc_89><loc_55></location>The VERIFY_GROUP_FOR_USER function was added in IBM i 7.2. Although it is primarily intended for use with RCAC permissions and masks, it can be used in other SQL statements. The first parameter must be one of these three special registers: SESSION_USER, USER, or CURRENT_USER. The second and subsequent parameters are a list of user or group profiles. Each of these values must be 1 - 10 characters in length. These values are not validated for their existence, which means that you can specify the names of user profiles that do not exist without receiving any kind of error.</paragraph>
|
||||
<paragraph><location><page_12><loc_22><loc_39><loc_89><loc_43></location>If a special register value is in the list of user profiles or it is a member of a group profile included in the list, the function returns a long integer value of 1. Otherwise, it returns a value of 0. It never returns the null value.</paragraph>
|
||||
<paragraph><location><page_12><loc_22><loc_36><loc_75><loc_38></location>Here is an example of using the VERIFY_GROUP_FOR_USER function:</paragraph>
|
||||
<paragraph><location><page_12><loc_22><loc_34><loc_66><loc_35></location>- 1. There are user profiles for MGR, JANE, JUDY, and TONY.</paragraph>
|
||||
<paragraph><location><page_12><loc_22><loc_32><loc_65><loc_33></location>- 2. The user profile JANE specifies a group profile of MGR.</paragraph>
|
||||
<paragraph><location><page_12><loc_22><loc_28><loc_88><loc_31></location>- 3. If a user is connected to the server using user profile JANE, all of the following function invocations return a value of 1:</paragraph>
|
||||
<paragraph><location><page_12><loc_22><loc_34><loc_66><loc_35></location>1. There are user profiles for MGR, JANE, JUDY, and TONY.</paragraph>
|
||||
<paragraph><location><page_12><loc_22><loc_32><loc_65><loc_33></location>2. The user profile JANE specifies a group profile of MGR.</paragraph>
|
||||
<paragraph><location><page_12><loc_22><loc_28><loc_88><loc_31></location>3. If a user is connected to the server using user profile JANE, all of the following function invocations return a value of 1:</paragraph>
|
||||
<paragraph><location><page_12><loc_25><loc_19><loc_74><loc_27></location>VERIFY_GROUP_FOR_USER (CURRENT_USER, 'MGR') VERIFY_GROUP_FOR_USER (CURRENT_USER, 'JANE', 'MGR') VERIFY_GROUP_FOR_USER (CURRENT_USER, 'JANE', 'MGR', 'STEVE') The following function invocation returns a value of 0: VERIFY_GROUP_FOR_USER (CURRENT_USER, 'JUDY', 'TONY')</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_90><loc_27><loc_91></location>RETURN</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_88><loc_26><loc_89></location>CASE</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_67><loc_85><loc_88></location>WHEN VERIFY_GROUP_FOR_USER ( SESSION_USER , 'HR', 'EMP' ) = 1 THEN EMPLOYEES . DATE_OF_BIRTH WHEN VERIFY_GROUP_FOR_USER ( SESSION_USER , 'MGR' ) = 1 AND SESSION_USER = EMPLOYEES . USER_ID THEN EMPLOYEES . DATE_OF_BIRTH WHEN VERIFY_GROUP_FOR_USER ( SESSION_USER , 'MGR' ) = 1 AND SESSION_USER <> EMPLOYEES . USER_ID THEN ( 9999 || '-' || MONTH ( EMPLOYEES . DATE_OF_BIRTH ) || '-' || DAY (EMPLOYEES.DATE_OF_BIRTH )) ELSE NULL END ENABLE ;</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_63><loc_89><loc_65></location>- 2. The other column to mask in this example is the TAX_ID information. In this example, the rules to enforce include the following ones:</paragraph>
|
||||
<paragraph><location><page_13><loc_25><loc_60><loc_77><loc_62></location>- -Human Resources can see the unmasked TAX_ID of the employees.</paragraph>
|
||||
<paragraph><location><page_13><loc_25><loc_58><loc_66><loc_59></location>- -Employees can see only their own unmasked TAX_ID.</paragraph>
|
||||
<paragraph><location><page_13><loc_25><loc_55><loc_89><loc_57></location>- -Managers see a masked version of TAX_ID with the first five characters replaced with the X character (for example, XXX-XX-1234).</paragraph>
|
||||
<paragraph><location><page_13><loc_25><loc_52><loc_87><loc_54></location>- -Any other person sees the entire TAX_ID as masked, for example, XXX-XX-XXXX.</paragraph>
|
||||
<paragraph><location><page_13><loc_25><loc_50><loc_87><loc_51></location>- To implement this column mask, run the SQL statement that is shown in Example 3-9.</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_63><loc_89><loc_65></location>2. The other column to mask in this example is the TAX_ID information. In this example, the rules to enforce include the following ones:</paragraph>
|
||||
<paragraph><location><page_13><loc_25><loc_60><loc_77><loc_62></location>-Human Resources can see the unmasked TAX_ID of the employees.</paragraph>
|
||||
<paragraph><location><page_13><loc_25><loc_58><loc_66><loc_59></location>-Employees can see only their own unmasked TAX_ID.</paragraph>
|
||||
<paragraph><location><page_13><loc_25><loc_55><loc_89><loc_57></location>-Managers see a masked version of TAX_ID with the first five characters replaced with the X character (for example, XXX-XX-1234).</paragraph>
|
||||
<paragraph><location><page_13><loc_25><loc_52><loc_87><loc_54></location>-Any other person sees the entire TAX_ID as masked, for example, XXX-XX-XXXX.</paragraph>
|
||||
<paragraph><location><page_13><loc_25><loc_50><loc_87><loc_51></location>To implement this column mask, run the SQL statement that is shown in Example 3-9.</paragraph>
|
||||
<paragraph><location><page_13><loc_22><loc_14><loc_86><loc_47></location>CREATE MASK HR_SCHEMA.MASK_TAX_ID_ON_EMPLOYEES ON HR_SCHEMA.EMPLOYEES AS EMPLOYEES FOR COLUMN TAX_ID RETURN CASE WHEN VERIFY_GROUP_FOR_USER ( SESSION_USER , 'HR' ) = 1 THEN EMPLOYEES . TAX_ID WHEN VERIFY_GROUP_FOR_USER ( SESSION_USER , 'MGR' ) = 1 AND SESSION_USER = EMPLOYEES . USER_ID THEN EMPLOYEES . TAX_ID WHEN VERIFY_GROUP_FOR_USER ( SESSION_USER , 'MGR' ) = 1 AND SESSION_USER <> EMPLOYEES . USER_ID THEN ( 'XXX-XX-' CONCAT QSYS2 . SUBSTR ( EMPLOYEES . TAX_ID , 8 , 4 ) ) WHEN VERIFY_GROUP_FOR_USER ( SESSION_USER , 'EMP' ) = 1 THEN EMPLOYEES . TAX_ID ELSE 'XXX-XX-XXXX' END ENABLE ;</paragraph>
|
||||
<caption><location><page_13><loc_22><loc_48><loc_58><loc_49></location>Example 3-9 Creating a mask on the TAX_ID column</caption>
|
||||
<paragraph><location><page_14><loc_22><loc_90><loc_74><loc_91></location>- 3. Figure 3-10 shows the masks that are created in the HR_SCHEMA.</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_90><loc_74><loc_91></location>3. Figure 3-10 shows the masks that are created in the HR_SCHEMA.</paragraph>
|
||||
<figure>
|
||||
<location><page_14><loc_10><loc_79><loc_89><loc_88></location>
|
||||
<caption>Figure 3-10 Column masks shown in System i Navigator</caption>
|
||||
@ -221,22 +221,22 @@
|
||||
<caption><location><page_14><loc_11><loc_77><loc_48><loc_78></location>Figure 3-10 Column masks shown in System i Navigator</caption>
|
||||
<subtitle-level-1><location><page_14><loc_11><loc_73><loc_33><loc_74></location>3.6.6 Activating RCAC</subtitle-level-1>
|
||||
<paragraph><location><page_14><loc_22><loc_67><loc_89><loc_71></location>Now that you have created the row permission and the two column masks, RCAC must be activated. The row permission and the two column masks are enabled (last clause in the scripts), but now you must activate RCAC on the table. To do so, complete the following steps:</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_65><loc_67><loc_66></location>- 1. Run the SQL statements that are shown in Example 3-10.</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_65><loc_67><loc_66></location>1. Run the SQL statements that are shown in Example 3-10.</paragraph>
|
||||
<subtitle-level-1><location><page_14><loc_22><loc_62><loc_61><loc_63></location>Example 3-10 Activating RCAC on the EMPLOYEES table</subtitle-level-1>
|
||||
<paragraph><location><page_14><loc_22><loc_60><loc_62><loc_61></location>- /* Active Row Access Control (permissions) */</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_58><loc_58><loc_60></location>- /* Active Column Access Control (masks)</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_60><loc_62><loc_61></location>/* Active Row Access Control (permissions) */</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_58><loc_58><loc_60></location>/* Active Column Access Control (masks)</paragraph>
|
||||
<paragraph><location><page_14><loc_60><loc_58><loc_62><loc_60></location>*/</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_57><loc_48><loc_58></location>ALTER TABLE HR_SCHEMA.EMPLOYEES</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_55><loc_44><loc_56></location>ACTIVATE ROW ACCESS CONTROL</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_54><loc_48><loc_55></location>ACTIVATE COLUMN ACCESS CONTROL;</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_48><loc_88><loc_52></location>- 2. Look at the definition of the EMPLOYEE table, as shown in Figure 3-11. To do this, from the main navigation pane of System i Navigator, click Schemas HR_SCHEMA Tables , right-click the EMPLOYEES table, and click Definition .</paragraph>
|
||||
<paragraph><location><page_14><loc_22><loc_48><loc_88><loc_52></location>2. Look at the definition of the EMPLOYEE table, as shown in Figure 3-11. To do this, from the main navigation pane of System i Navigator, click Schemas HR_SCHEMA Tables , right-click the EMPLOYEES table, and click Definition .</paragraph>
|
||||
<figure>
|
||||
<location><page_14><loc_10><loc_18><loc_87><loc_46></location>
|
||||
<caption>Figure 3-11 Selecting the EMPLOYEES table from System i Navigator</caption>
|
||||
</figure>
|
||||
<caption><location><page_14><loc_11><loc_17><loc_57><loc_18></location>Figure 3-11 Selecting the EMPLOYEES table from System i Navigator</caption>
|
||||
<paragraph><location><page_15><loc_22><loc_87><loc_84><loc_91></location>- 2. Figure 4-68 shows the Visual Explain of the same SQL statement, but with RCAC enabled. It is clear that the implementation of the SQL statement is more complex because the row permission rule becomes part of the WHERE clause.</paragraph>
|
||||
<paragraph><location><page_15><loc_22><loc_32><loc_89><loc_36></location>- 3. Compare the advised indexes that are provided by the Optimizer without RCAC and with RCAC enabled. Figure 4-69 shows the index advice for the SQL statement without RCAC enabled. The index being advised is for the ORDER BY clause.</paragraph>
|
||||
<paragraph><location><page_15><loc_22><loc_87><loc_84><loc_91></location>2. Figure 4-68 shows the Visual Explain of the same SQL statement, but with RCAC enabled. It is clear that the implementation of the SQL statement is more complex because the row permission rule becomes part of the WHERE clause.</paragraph>
|
||||
<paragraph><location><page_15><loc_22><loc_32><loc_89><loc_36></location>3. Compare the advised indexes that are provided by the Optimizer without RCAC and with RCAC enabled. Figure 4-69 shows the index advice for the SQL statement without RCAC enabled. The index being advised is for the ORDER BY clause.</paragraph>
|
||||
<figure>
|
||||
<location><page_15><loc_22><loc_40><loc_89><loc_85></location>
|
||||
<caption>Figure 4-68 Visual Explain with RCAC enabled</caption>
|
||||
|
@ -305,7 +305,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- GLYPH<g115>GLYPH<g3> GLYPH<g40>GLYPH<g81>GLYPH<g75>GLYPH<g68>GLYPH<g81>GLYPH<g70>GLYPH<g72>GLYPH<g3> GLYPH<g87>GLYPH<g75>GLYPH<g72>GLYPH<g3> GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g73>GLYPH<g82>GLYPH<g85>GLYPH<g80>GLYPH<g68>GLYPH<g81>GLYPH<g70>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g92>GLYPH<g82>GLYPH<g88>GLYPH<g85> GLYPH<g3> GLYPH<g71>GLYPH<g68>GLYPH<g87>GLYPH<g68>GLYPH<g69>GLYPH<g68>GLYPH<g86>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g68>GLYPH<g87>GLYPH<g76>GLYPH<g82>GLYPH<g81>GLYPH<g86>",
|
||||
"text": "GLYPH<g115>GLYPH<g3> GLYPH<g40>GLYPH<g81>GLYPH<g75>GLYPH<g68>GLYPH<g81>GLYPH<g70>GLYPH<g72>GLYPH<g3> GLYPH<g87>GLYPH<g75>GLYPH<g72>GLYPH<g3> GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g73>GLYPH<g82>GLYPH<g85>GLYPH<g80>GLYPH<g68>GLYPH<g81>GLYPH<g70>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g92>GLYPH<g82>GLYPH<g88>GLYPH<g85> GLYPH<g3> GLYPH<g71>GLYPH<g68>GLYPH<g87>GLYPH<g68>GLYPH<g69>GLYPH<g68>GLYPH<g86>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g68>GLYPH<g87>GLYPH<g76>GLYPH<g82>GLYPH<g81>GLYPH<g86>",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -328,7 +328,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- GLYPH<g115>GLYPH<g3> GLYPH<g40>GLYPH<g68>GLYPH<g85> GLYPH<g81>GLYPH<g3> GLYPH<g74>GLYPH<g85>GLYPH<g72>GLYPH<g68>GLYPH<g87>GLYPH<g72>GLYPH<g85>GLYPH<g3> GLYPH<g85>GLYPH<g72>GLYPH<g87>GLYPH<g88>GLYPH<g85> GLYPH<g81>GLYPH<g3> GLYPH<g82>GLYPH<g81>GLYPH<g3> GLYPH<g44>GLYPH<g55>GLYPH<g3> GLYPH<g83>GLYPH<g85>GLYPH<g82>GLYPH<g77>GLYPH<g72>GLYPH<g70>GLYPH<g87>GLYPH<g86> GLYPH<g3> GLYPH<g87>GLYPH<g75>GLYPH<g85>GLYPH<g82>GLYPH<g88>GLYPH<g74>GLYPH<g75>GLYPH<g3> GLYPH<g80>GLYPH<g82>GLYPH<g71>GLYPH<g72>GLYPH<g85> GLYPH<g81>GLYPH<g76>GLYPH<g93>GLYPH<g68>GLYPH<g87>GLYPH<g76>GLYPH<g82>GLYPH<g81>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g71>GLYPH<g68>GLYPH<g87>GLYPH<g68>GLYPH<g69>GLYPH<g68>GLYPH<g86>GLYPH<g72>GLYPH<g3> GLYPH<g68>GLYPH<g81>GLYPH<g71> GLYPH<g3> GLYPH<g68>GLYPH<g83>GLYPH<g83>GLYPH<g79>GLYPH<g76>GLYPH<g70>GLYPH<g68>GLYPH<g87>GLYPH<g76>GLYPH<g82>GLYPH<g81>GLYPH<g86>",
|
||||
"text": "GLYPH<g115>GLYPH<g3> GLYPH<g40>GLYPH<g68>GLYPH<g85> GLYPH<g81>GLYPH<g3> GLYPH<g74>GLYPH<g85>GLYPH<g72>GLYPH<g68>GLYPH<g87>GLYPH<g72>GLYPH<g85>GLYPH<g3> GLYPH<g85>GLYPH<g72>GLYPH<g87>GLYPH<g88>GLYPH<g85> GLYPH<g81>GLYPH<g3> GLYPH<g82>GLYPH<g81>GLYPH<g3> GLYPH<g44>GLYPH<g55>GLYPH<g3> GLYPH<g83>GLYPH<g85>GLYPH<g82>GLYPH<g77>GLYPH<g72>GLYPH<g70>GLYPH<g87>GLYPH<g86> GLYPH<g3> GLYPH<g87>GLYPH<g75>GLYPH<g85>GLYPH<g82>GLYPH<g88>GLYPH<g74>GLYPH<g75>GLYPH<g3> GLYPH<g80>GLYPH<g82>GLYPH<g71>GLYPH<g72>GLYPH<g85> GLYPH<g81>GLYPH<g76>GLYPH<g93>GLYPH<g68>GLYPH<g87>GLYPH<g76>GLYPH<g82>GLYPH<g81>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g71>GLYPH<g68>GLYPH<g87>GLYPH<g68>GLYPH<g69>GLYPH<g68>GLYPH<g86>GLYPH<g72>GLYPH<g3> GLYPH<g68>GLYPH<g81>GLYPH<g71> GLYPH<g3> GLYPH<g68>GLYPH<g83>GLYPH<g83>GLYPH<g79>GLYPH<g76>GLYPH<g70>GLYPH<g68>GLYPH<g87>GLYPH<g76>GLYPH<g82>GLYPH<g81>GLYPH<g86>",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -351,7 +351,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- GLYPH<g115>GLYPH<g3> GLYPH<g53>GLYPH<g72>GLYPH<g79>GLYPH<g92>GLYPH<g3> GLYPH<g82>GLYPH<g81>GLYPH<g3> GLYPH<g44>GLYPH<g37>GLYPH<g48>GLYPH<g3> GLYPH<g72>GLYPH<g91>GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g87>GLYPH<g3> GLYPH<g70>GLYPH<g82>GLYPH<g81>GLYPH<g86>GLYPH<g88>GLYPH<g79>GLYPH<g87>GLYPH<g76>GLYPH<g81>GLYPH<g74>GLYPH<g15>GLYPH<g3> GLYPH<g86>GLYPH<g78>GLYPH<g76>GLYPH<g79>GLYPH<g79>GLYPH<g86> GLYPH<g3> GLYPH<g86>GLYPH<g75>GLYPH<g68>GLYPH<g85>GLYPH<g76>GLYPH<g81>GLYPH<g74>GLYPH<g3> GLYPH<g68>GLYPH<g81>GLYPH<g71>GLYPH<g3> GLYPH<g85>GLYPH<g72>GLYPH<g81>GLYPH<g82>GLYPH<g90>GLYPH<g81>GLYPH<g3> GLYPH<g86>GLYPH<g72>GLYPH<g85>GLYPH<g89>GLYPH<g76>GLYPH<g70>GLYPH<g72>GLYPH<g86>",
|
||||
"text": "GLYPH<g115>GLYPH<g3> GLYPH<g53>GLYPH<g72>GLYPH<g79>GLYPH<g92>GLYPH<g3> GLYPH<g82>GLYPH<g81>GLYPH<g3> GLYPH<g44>GLYPH<g37>GLYPH<g48>GLYPH<g3> GLYPH<g72>GLYPH<g91>GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g87>GLYPH<g3> GLYPH<g70>GLYPH<g82>GLYPH<g81>GLYPH<g86>GLYPH<g88>GLYPH<g79>GLYPH<g87>GLYPH<g76>GLYPH<g81>GLYPH<g74>GLYPH<g15>GLYPH<g3> GLYPH<g86>GLYPH<g78>GLYPH<g76>GLYPH<g79>GLYPH<g79>GLYPH<g86> GLYPH<g3> GLYPH<g86>GLYPH<g75>GLYPH<g68>GLYPH<g85>GLYPH<g76>GLYPH<g81>GLYPH<g74>GLYPH<g3> GLYPH<g68>GLYPH<g81>GLYPH<g71>GLYPH<g3> GLYPH<g85>GLYPH<g72>GLYPH<g81>GLYPH<g82>GLYPH<g90>GLYPH<g81>GLYPH<g3> GLYPH<g86>GLYPH<g72>GLYPH<g85>GLYPH<g89>GLYPH<g76>GLYPH<g70>GLYPH<g72>GLYPH<g86>",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -374,7 +374,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- GLYPH<g115>GLYPH<g3> GLYPH<g55> GLYPH<g68>GLYPH<g78>GLYPH<g72>GLYPH<g3> GLYPH<g68>GLYPH<g71>GLYPH<g89>GLYPH<g68>GLYPH<g81>GLYPH<g87>GLYPH<g68>GLYPH<g74>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g68>GLYPH<g70>GLYPH<g70>GLYPH<g72>GLYPH<g86>GLYPH<g86>GLYPH<g3> GLYPH<g87>GLYPH<g82>GLYPH<g3> GLYPH<g68> GLYPH<g3> GLYPH<g90>GLYPH<g82>GLYPH<g85>GLYPH<g79>GLYPH<g71>GLYPH<g90>GLYPH<g76>GLYPH<g71>GLYPH<g72>GLYPH<g3> GLYPH<g86>GLYPH<g82>GLYPH<g88>GLYPH<g85>GLYPH<g70>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g72>GLYPH<g91>GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g87>GLYPH<g76>GLYPH<g86>GLYPH<g72>",
|
||||
"text": "GLYPH<g115>GLYPH<g3> GLYPH<g55> GLYPH<g68>GLYPH<g78>GLYPH<g72>GLYPH<g3> GLYPH<g68>GLYPH<g71>GLYPH<g89>GLYPH<g68>GLYPH<g81>GLYPH<g87>GLYPH<g68>GLYPH<g74>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g68>GLYPH<g70>GLYPH<g70>GLYPH<g72>GLYPH<g86>GLYPH<g86>GLYPH<g3> GLYPH<g87>GLYPH<g82>GLYPH<g3> GLYPH<g68> GLYPH<g3> GLYPH<g90>GLYPH<g82>GLYPH<g85>GLYPH<g79>GLYPH<g71>GLYPH<g90>GLYPH<g76>GLYPH<g71>GLYPH<g72>GLYPH<g3> GLYPH<g86>GLYPH<g82>GLYPH<g88>GLYPH<g85>GLYPH<g70>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g72>GLYPH<g91>GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g87>GLYPH<g76>GLYPH<g86>GLYPH<g72>",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -609,7 +609,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- r Database performance and scalability",
|
||||
"text": "r Database performance and scalability",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -632,7 +632,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- r Advanced SQL knowledge and skills transfer",
|
||||
"text": "r Advanced SQL knowledge and skills transfer",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -655,7 +655,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- r Business intelligence and analytics",
|
||||
"text": "r Business intelligence and analytics",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -678,7 +678,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- r DB2 Web Query",
|
||||
"text": "r DB2 Web Query",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -701,7 +701,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- r Query/400 modernization for better reporting and analysis capabilities",
|
||||
"text": "r Query/400 modernization for better reporting and analysis capabilities",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -724,7 +724,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- r Database modernization and re-engineering",
|
||||
"text": "r Database modernization and re-engineering",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -747,7 +747,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- r Data-centric architecture and design",
|
||||
"text": "r Data-centric architecture and design",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -770,7 +770,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- r Extremely large database and overcoming limits to growth",
|
||||
"text": "r Extremely large database and overcoming limits to growth",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -793,7 +793,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- r ISV education and enablement",
|
||||
"text": "r ISV education and enablement",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1130,7 +1130,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- GLYPH<SM590000> Security fundamentals",
|
||||
"text": "GLYPH<SM590000> Security fundamentals",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1153,7 +1153,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- GLYPH<SM590000> Current state of IBM i security",
|
||||
"text": "GLYPH<SM590000> Current state of IBM i security",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1176,7 +1176,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- GLYPH<SM590000> DB2 for i security controls",
|
||||
"text": "GLYPH<SM590000> DB2 for i security controls",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1291,7 +1291,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- GLYPH<SM590000> First, and most important, is the definition of a company's security policy . Without a security policy, there is no definition of what are acceptable practices for using, accessing, and storing information by who, what, when, where, and how. A security policy should minimally address three things: confidentiality, integrity, and availability.",
|
||||
"text": "GLYPH<SM590000> First, and most important, is the definition of a company's security policy . Without a security policy, there is no definition of what are acceptable practices for using, accessing, and storing information by who, what, when, where, and how. A security policy should minimally address three things: confidentiality, integrity, and availability.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1314,7 +1314,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- The monitoring and assessment of adherence to the security policy determines whether your security strategy is working. Often, IBM security consultants are asked to perform security assessments for companies without regard to the security policy. Although these assessments can be useful for observing how the system is defined and how data is being accessed, they cannot determine the level of security without a security policy. Without a security policy, it really is not an assessment as much as it is a baseline for monitoring the changes in the security settings that are captured.",
|
||||
"text": "The monitoring and assessment of adherence to the security policy determines whether your security strategy is working. Often, IBM security consultants are asked to perform security assessments for companies without regard to the security policy. Although these assessments can be useful for observing how the system is defined and how data is being accessed, they cannot determine the level of security without a security policy. Without a security policy, it really is not an assessment as much as it is a baseline for monitoring the changes in the security settings that are captured.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1360,7 +1360,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- GLYPH<SM590000> The second fundamental in securing data assets is the use of resource security . If implemented properly, resource security prevents data breaches from both internal and external intrusions. Resource security controls are closely tied to the part of the security policy that defines who should have access to what information resources. A hacker might be good enough to get through your company firewalls and sift his way through to your system, but if they do not have explicit access to your database, the hacker cannot compromise your information assets.",
|
||||
"text": "GLYPH<SM590000> The second fundamental in securing data assets is the use of resource security . If implemented properly, resource security prevents data breaches from both internal and external intrusions. Resource security controls are closely tied to the part of the security policy that defines who should have access to what information resources. A hacker might be good enough to get through your company firewalls and sift his way through to your system, but if they do not have explicit access to your database, the hacker cannot compromise your information assets.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1687,7 +1687,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- GLYPH<SM590000> Work Function Usage ( WRKFCNUSG )",
|
||||
"text": "GLYPH<SM590000> Work Function Usage ( WRKFCNUSG )",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1710,7 +1710,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- GLYPH<SM590000> Change Function Usage ( CHGFCNUSG )",
|
||||
"text": "GLYPH<SM590000> Change Function Usage ( CHGFCNUSG )",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -1733,7 +1733,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- GLYPH<SM590000> Display Function Usage ( DSPFCNUSG )",
|
||||
"text": "GLYPH<SM590000> Display Function Usage ( DSPFCNUSG )",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2558,7 +2558,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- GLYPH<SM590000> A user connects to the server using the user profile ALICE.",
|
||||
"text": "GLYPH<SM590000> A user connects to the server using the user profile ALICE.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2581,7 +2581,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- GLYPH<SM590000> USER and CURRENT USER initially have the same value of ALICE.",
|
||||
"text": "GLYPH<SM590000> USER and CURRENT USER initially have the same value of ALICE.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2604,7 +2604,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- GLYPH<SM590000> ALICE calls an SQL procedure that is named proc1, which is owned by user profile JOE and was created to adopt JOE's authority when it is called.",
|
||||
"text": "GLYPH<SM590000> ALICE calls an SQL procedure that is named proc1, which is owned by user profile JOE and was created to adopt JOE's authority when it is called.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2627,7 +2627,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- GLYPH<SM590000> While the procedure is running, the special register USER still contains the value of ALICE because it excludes any adopted authority. The special register CURRENT USER contains the value of JOE because it includes any adopted authority.",
|
||||
"text": "GLYPH<SM590000> While the procedure is running, the special register USER still contains the value of ALICE because it excludes any adopted authority. The special register CURRENT USER contains the value of JOE because it includes any adopted authority.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2650,7 +2650,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- GLYPH<SM590000> When proc1 ends, the session reverts to its original state with both USER and CURRENT USER having the value of ALICE.",
|
||||
"text": "GLYPH<SM590000> When proc1 ends, the session reverts to its original state with both USER and CURRENT USER having the value of ALICE.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2913,7 +2913,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 1. There are user profiles for MGR, JANE, JUDY, and TONY.",
|
||||
"text": "1. There are user profiles for MGR, JANE, JUDY, and TONY.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2936,7 +2936,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 2. The user profile JANE specifies a group profile of MGR.",
|
||||
"text": "2. The user profile JANE specifies a group profile of MGR.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -2959,7 +2959,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 3. If a user is connected to the server using user profile JANE, all of the following function invocations return a value of 1:",
|
||||
"text": "3. If a user is connected to the server using user profile JANE, all of the following function invocations return a value of 1:",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3074,7 +3074,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 2. The other column to mask in this example is the TAX_ID information. In this example, the rules to enforce include the following ones:",
|
||||
"text": "2. The other column to mask in this example is the TAX_ID information. In this example, the rules to enforce include the following ones:",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3097,7 +3097,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- -Human Resources can see the unmasked TAX_ID of the employees.",
|
||||
"text": "-Human Resources can see the unmasked TAX_ID of the employees.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3120,7 +3120,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- -Employees can see only their own unmasked TAX_ID.",
|
||||
"text": "-Employees can see only their own unmasked TAX_ID.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3143,7 +3143,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- -Managers see a masked version of TAX_ID with the first five characters replaced with the X character (for example, XXX-XX-1234).",
|
||||
"text": "-Managers see a masked version of TAX_ID with the first five characters replaced with the X character (for example, XXX-XX-1234).",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3166,7 +3166,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- -Any other person sees the entire TAX_ID as masked, for example, XXX-XX-XXXX.",
|
||||
"text": "-Any other person sees the entire TAX_ID as masked, for example, XXX-XX-XXXX.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3189,7 +3189,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- To implement this column mask, run the SQL statement that is shown in Example 3-9.",
|
||||
"text": "To implement this column mask, run the SQL statement that is shown in Example 3-9.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3258,7 +3258,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 3. Figure 3-10 shows the masks that are created in the HR_SCHEMA.",
|
||||
"text": "3. Figure 3-10 shows the masks that are created in the HR_SCHEMA.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3355,7 +3355,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 1. Run the SQL statements that are shown in Example 3-10.",
|
||||
"text": "1. Run the SQL statements that are shown in Example 3-10.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3401,7 +3401,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- /* Active Row Access Control (permissions) */",
|
||||
"text": "/* Active Row Access Control (permissions) */",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3424,7 +3424,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- /* Active Column Access Control (masks)",
|
||||
"text": "/* Active Column Access Control (masks)",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3539,7 +3539,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 2. Look at the definition of the EMPLOYEE table, as shown in Figure 3-11. To do this, from the main navigation pane of System i Navigator, click Schemas \uf0ae HR_SCHEMA \uf0ae Tables , right-click the EMPLOYEES table, and click Definition .",
|
||||
"text": "2. Look at the definition of the EMPLOYEE table, as shown in Figure 3-11. To do this, from the main navigation pane of System i Navigator, click Schemas \uf0ae HR_SCHEMA \uf0ae Tables , right-click the EMPLOYEES table, and click Definition .",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3590,7 +3590,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 2. Figure 4-68 shows the Visual Explain of the same SQL statement, but with RCAC enabled. It is clear that the implementation of the SQL statement is more complex because the row permission rule becomes part of the WHERE clause.",
|
||||
"text": "2. Figure 4-68 shows the Visual Explain of the same SQL statement, but with RCAC enabled. It is clear that the implementation of the SQL statement is more complex because the row permission rule becomes part of the WHERE clause.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
@ -3613,7 +3613,7 @@
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "- 3. Compare the advised indexes that are provided by the Optimizer without RCAC and with RCAC enabled. Figure 4-69 shows the index advice for the SQL statement without RCAC enabled. The index being advised is for the ORDER BY clause.",
|
||||
"text": "3. Compare the advised indexes that are provided by the Optimizer without RCAC and with RCAC enabled. Figure 4-69 shows the index advice for the SQL statement without RCAC enabled. The index being advised is for the ORDER BY clause.",
|
||||
"type": "paragraph",
|
||||
"payload": null,
|
||||
"name": "List-item",
|
||||
|
@ -18,13 +18,13 @@ Solution Brief IBM Systems Lab Services and Training
|
||||
|
||||
## Highlights
|
||||
|
||||
- GLYPH<g115>GLYPH<g3> GLYPH<g40>GLYPH<g81>GLYPH<g75>GLYPH<g68>GLYPH<g81>GLYPH<g70>GLYPH<g72>GLYPH<g3> GLYPH<g87>GLYPH<g75>GLYPH<g72>GLYPH<g3> GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g73>GLYPH<g82>GLYPH<g85>GLYPH<g80>GLYPH<g68>GLYPH<g81>GLYPH<g70>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g92>GLYPH<g82>GLYPH<g88>GLYPH<g85> GLYPH<g3> GLYPH<g71>GLYPH<g68>GLYPH<g87>GLYPH<g68>GLYPH<g69>GLYPH<g68>GLYPH<g86>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g68>GLYPH<g87>GLYPH<g76>GLYPH<g82>GLYPH<g81>GLYPH<g86>
|
||||
GLYPH<g115>GLYPH<g3> GLYPH<g40>GLYPH<g81>GLYPH<g75>GLYPH<g68>GLYPH<g81>GLYPH<g70>GLYPH<g72>GLYPH<g3> GLYPH<g87>GLYPH<g75>GLYPH<g72>GLYPH<g3> GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g73>GLYPH<g82>GLYPH<g85>GLYPH<g80>GLYPH<g68>GLYPH<g81>GLYPH<g70>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g92>GLYPH<g82>GLYPH<g88>GLYPH<g85> GLYPH<g3> GLYPH<g71>GLYPH<g68>GLYPH<g87>GLYPH<g68>GLYPH<g69>GLYPH<g68>GLYPH<g86>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g68>GLYPH<g87>GLYPH<g76>GLYPH<g82>GLYPH<g81>GLYPH<g86>
|
||||
|
||||
- GLYPH<g115>GLYPH<g3> GLYPH<g40>GLYPH<g68>GLYPH<g85> GLYPH<g81>GLYPH<g3> GLYPH<g74>GLYPH<g85>GLYPH<g72>GLYPH<g68>GLYPH<g87>GLYPH<g72>GLYPH<g85>GLYPH<g3> GLYPH<g85>GLYPH<g72>GLYPH<g87>GLYPH<g88>GLYPH<g85> GLYPH<g81>GLYPH<g3> GLYPH<g82>GLYPH<g81>GLYPH<g3> GLYPH<g44>GLYPH<g55>GLYPH<g3> GLYPH<g83>GLYPH<g85>GLYPH<g82>GLYPH<g77>GLYPH<g72>GLYPH<g70>GLYPH<g87>GLYPH<g86> GLYPH<g3> GLYPH<g87>GLYPH<g75>GLYPH<g85>GLYPH<g82>GLYPH<g88>GLYPH<g74>GLYPH<g75>GLYPH<g3> GLYPH<g80>GLYPH<g82>GLYPH<g71>GLYPH<g72>GLYPH<g85> GLYPH<g81>GLYPH<g76>GLYPH<g93>GLYPH<g68>GLYPH<g87>GLYPH<g76>GLYPH<g82>GLYPH<g81>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g71>GLYPH<g68>GLYPH<g87>GLYPH<g68>GLYPH<g69>GLYPH<g68>GLYPH<g86>GLYPH<g72>GLYPH<g3> GLYPH<g68>GLYPH<g81>GLYPH<g71> GLYPH<g3> GLYPH<g68>GLYPH<g83>GLYPH<g83>GLYPH<g79>GLYPH<g76>GLYPH<g70>GLYPH<g68>GLYPH<g87>GLYPH<g76>GLYPH<g82>GLYPH<g81>GLYPH<g86>
|
||||
GLYPH<g115>GLYPH<g3> GLYPH<g40>GLYPH<g68>GLYPH<g85> GLYPH<g81>GLYPH<g3> GLYPH<g74>GLYPH<g85>GLYPH<g72>GLYPH<g68>GLYPH<g87>GLYPH<g72>GLYPH<g85>GLYPH<g3> GLYPH<g85>GLYPH<g72>GLYPH<g87>GLYPH<g88>GLYPH<g85> GLYPH<g81>GLYPH<g3> GLYPH<g82>GLYPH<g81>GLYPH<g3> GLYPH<g44>GLYPH<g55>GLYPH<g3> GLYPH<g83>GLYPH<g85>GLYPH<g82>GLYPH<g77>GLYPH<g72>GLYPH<g70>GLYPH<g87>GLYPH<g86> GLYPH<g3> GLYPH<g87>GLYPH<g75>GLYPH<g85>GLYPH<g82>GLYPH<g88>GLYPH<g74>GLYPH<g75>GLYPH<g3> GLYPH<g80>GLYPH<g82>GLYPH<g71>GLYPH<g72>GLYPH<g85> GLYPH<g81>GLYPH<g76>GLYPH<g93>GLYPH<g68>GLYPH<g87>GLYPH<g76>GLYPH<g82>GLYPH<g81>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g71>GLYPH<g68>GLYPH<g87>GLYPH<g68>GLYPH<g69>GLYPH<g68>GLYPH<g86>GLYPH<g72>GLYPH<g3> GLYPH<g68>GLYPH<g81>GLYPH<g71> GLYPH<g3> GLYPH<g68>GLYPH<g83>GLYPH<g83>GLYPH<g79>GLYPH<g76>GLYPH<g70>GLYPH<g68>GLYPH<g87>GLYPH<g76>GLYPH<g82>GLYPH<g81>GLYPH<g86>
|
||||
|
||||
- GLYPH<g115>GLYPH<g3> GLYPH<g53>GLYPH<g72>GLYPH<g79>GLYPH<g92>GLYPH<g3> GLYPH<g82>GLYPH<g81>GLYPH<g3> GLYPH<g44>GLYPH<g37>GLYPH<g48>GLYPH<g3> GLYPH<g72>GLYPH<g91>GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g87>GLYPH<g3> GLYPH<g70>GLYPH<g82>GLYPH<g81>GLYPH<g86>GLYPH<g88>GLYPH<g79>GLYPH<g87>GLYPH<g76>GLYPH<g81>GLYPH<g74>GLYPH<g15>GLYPH<g3> GLYPH<g86>GLYPH<g78>GLYPH<g76>GLYPH<g79>GLYPH<g79>GLYPH<g86> GLYPH<g3> GLYPH<g86>GLYPH<g75>GLYPH<g68>GLYPH<g85>GLYPH<g76>GLYPH<g81>GLYPH<g74>GLYPH<g3> GLYPH<g68>GLYPH<g81>GLYPH<g71>GLYPH<g3> GLYPH<g85>GLYPH<g72>GLYPH<g81>GLYPH<g82>GLYPH<g90>GLYPH<g81>GLYPH<g3> GLYPH<g86>GLYPH<g72>GLYPH<g85>GLYPH<g89>GLYPH<g76>GLYPH<g70>GLYPH<g72>GLYPH<g86>
|
||||
GLYPH<g115>GLYPH<g3> GLYPH<g53>GLYPH<g72>GLYPH<g79>GLYPH<g92>GLYPH<g3> GLYPH<g82>GLYPH<g81>GLYPH<g3> GLYPH<g44>GLYPH<g37>GLYPH<g48>GLYPH<g3> GLYPH<g72>GLYPH<g91>GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g87>GLYPH<g3> GLYPH<g70>GLYPH<g82>GLYPH<g81>GLYPH<g86>GLYPH<g88>GLYPH<g79>GLYPH<g87>GLYPH<g76>GLYPH<g81>GLYPH<g74>GLYPH<g15>GLYPH<g3> GLYPH<g86>GLYPH<g78>GLYPH<g76>GLYPH<g79>GLYPH<g79>GLYPH<g86> GLYPH<g3> GLYPH<g86>GLYPH<g75>GLYPH<g68>GLYPH<g85>GLYPH<g76>GLYPH<g81>GLYPH<g74>GLYPH<g3> GLYPH<g68>GLYPH<g81>GLYPH<g71>GLYPH<g3> GLYPH<g85>GLYPH<g72>GLYPH<g81>GLYPH<g82>GLYPH<g90>GLYPH<g81>GLYPH<g3> GLYPH<g86>GLYPH<g72>GLYPH<g85>GLYPH<g89>GLYPH<g76>GLYPH<g70>GLYPH<g72>GLYPH<g86>
|
||||
|
||||
- GLYPH<g115>GLYPH<g3> GLYPH<g55> GLYPH<g68>GLYPH<g78>GLYPH<g72>GLYPH<g3> GLYPH<g68>GLYPH<g71>GLYPH<g89>GLYPH<g68>GLYPH<g81>GLYPH<g87>GLYPH<g68>GLYPH<g74>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g68>GLYPH<g70>GLYPH<g70>GLYPH<g72>GLYPH<g86>GLYPH<g86>GLYPH<g3> GLYPH<g87>GLYPH<g82>GLYPH<g3> GLYPH<g68> GLYPH<g3> GLYPH<g90>GLYPH<g82>GLYPH<g85>GLYPH<g79>GLYPH<g71>GLYPH<g90>GLYPH<g76>GLYPH<g71>GLYPH<g72>GLYPH<g3> GLYPH<g86>GLYPH<g82>GLYPH<g88>GLYPH<g85>GLYPH<g70>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g72>GLYPH<g91>GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g87>GLYPH<g76>GLYPH<g86>GLYPH<g72>
|
||||
GLYPH<g115>GLYPH<g3> GLYPH<g55> GLYPH<g68>GLYPH<g78>GLYPH<g72>GLYPH<g3> GLYPH<g68>GLYPH<g71>GLYPH<g89>GLYPH<g68>GLYPH<g81>GLYPH<g87>GLYPH<g68>GLYPH<g74>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g68>GLYPH<g70>GLYPH<g70>GLYPH<g72>GLYPH<g86>GLYPH<g86>GLYPH<g3> GLYPH<g87>GLYPH<g82>GLYPH<g3> GLYPH<g68> GLYPH<g3> GLYPH<g90>GLYPH<g82>GLYPH<g85>GLYPH<g79>GLYPH<g71>GLYPH<g90>GLYPH<g76>GLYPH<g71>GLYPH<g72>GLYPH<g3> GLYPH<g86>GLYPH<g82>GLYPH<g88>GLYPH<g85>GLYPH<g70>GLYPH<g72>GLYPH<g3> GLYPH<g82>GLYPH<g73>GLYPH<g3> GLYPH<g72>GLYPH<g91>GLYPH<g83>GLYPH<g72>GLYPH<g85>GLYPH<g87>GLYPH<g76>GLYPH<g86>GLYPH<g72>
|
||||
|
||||
<!-- image -->
|
||||
|
||||
@ -46,23 +46,23 @@ With combined experiences and direct access to development groups, we're the exp
|
||||
|
||||
Global CoE engagements cover topics including:
|
||||
|
||||
- r Database performance and scalability
|
||||
r Database performance and scalability
|
||||
|
||||
- r Advanced SQL knowledge and skills transfer
|
||||
r Advanced SQL knowledge and skills transfer
|
||||
|
||||
- r Business intelligence and analytics
|
||||
r Business intelligence and analytics
|
||||
|
||||
- r DB2 Web Query
|
||||
r DB2 Web Query
|
||||
|
||||
- r Query/400 modernization for better reporting and analysis capabilities
|
||||
r Query/400 modernization for better reporting and analysis capabilities
|
||||
|
||||
- r Database modernization and re-engineering
|
||||
r Database modernization and re-engineering
|
||||
|
||||
- r Data-centric architecture and design
|
||||
r Data-centric architecture and design
|
||||
|
||||
- r Extremely large database and overcoming limits to growth
|
||||
r Extremely large database and overcoming limits to growth
|
||||
|
||||
- r ISV education and enablement
|
||||
r ISV education and enablement
|
||||
|
||||
## Preface
|
||||
|
||||
@ -96,23 +96,23 @@ Businesses must make a serious effort to secure their data and recognize that se
|
||||
|
||||
This chapter describes how you can secure and protect data in DB2 for i. The following topics are covered in this chapter:
|
||||
|
||||
- GLYPH<SM590000> Security fundamentals
|
||||
GLYPH<SM590000> Security fundamentals
|
||||
|
||||
- GLYPH<SM590000> Current state of IBM i security
|
||||
GLYPH<SM590000> Current state of IBM i security
|
||||
|
||||
- GLYPH<SM590000> DB2 for i security controls
|
||||
GLYPH<SM590000> DB2 for i security controls
|
||||
|
||||
## 1.1 Security fundamentals
|
||||
|
||||
Before reviewing database security techniques, there are two fundamental steps in securing information assets that must be described:
|
||||
|
||||
- GLYPH<SM590000> First, and most important, is the definition of a company's security policy . Without a security policy, there is no definition of what are acceptable practices for using, accessing, and storing information by who, what, when, where, and how. A security policy should minimally address three things: confidentiality, integrity, and availability.
|
||||
GLYPH<SM590000> First, and most important, is the definition of a company's security policy . Without a security policy, there is no definition of what are acceptable practices for using, accessing, and storing information by who, what, when, where, and how. A security policy should minimally address three things: confidentiality, integrity, and availability.
|
||||
|
||||
- The monitoring and assessment of adherence to the security policy determines whether your security strategy is working. Often, IBM security consultants are asked to perform security assessments for companies without regard to the security policy. Although these assessments can be useful for observing how the system is defined and how data is being accessed, they cannot determine the level of security without a security policy. Without a security policy, it really is not an assessment as much as it is a baseline for monitoring the changes in the security settings that are captured.
|
||||
The monitoring and assessment of adherence to the security policy determines whether your security strategy is working. Often, IBM security consultants are asked to perform security assessments for companies without regard to the security policy. Although these assessments can be useful for observing how the system is defined and how data is being accessed, they cannot determine the level of security without a security policy. Without a security policy, it really is not an assessment as much as it is a baseline for monitoring the changes in the security settings that are captured.
|
||||
|
||||
A security policy is what defines whether the system and its settings are secure (or not).
|
||||
|
||||
- GLYPH<SM590000> The second fundamental in securing data assets is the use of resource security . If implemented properly, resource security prevents data breaches from both internal and external intrusions. Resource security controls are closely tied to the part of the security policy that defines who should have access to what information resources. A hacker might be good enough to get through your company firewalls and sift his way through to your system, but if they do not have explicit access to your database, the hacker cannot compromise your information assets.
|
||||
GLYPH<SM590000> The second fundamental in securing data assets is the use of resource security . If implemented properly, resource security prevents data breaches from both internal and external intrusions. Resource security controls are closely tied to the part of the security policy that defines who should have access to what information resources. A hacker might be good enough to get through your company firewalls and sift his way through to your system, but if they do not have explicit access to your database, the hacker cannot compromise your information assets.
|
||||
|
||||
With your eyes now open to the importance of securing information assets, the rest of this chapter reviews the methods that are available for securing database resources on IBM i.
|
||||
|
||||
@ -141,11 +141,11 @@ Figure 1-2 Existing row and column controls
|
||||
|
||||
The following CL commands can be used to work with, display, or change function usage IDs:
|
||||
|
||||
- GLYPH<SM590000> Work Function Usage ( WRKFCNUSG )
|
||||
GLYPH<SM590000> Work Function Usage ( WRKFCNUSG )
|
||||
|
||||
- GLYPH<SM590000> Change Function Usage ( CHGFCNUSG )
|
||||
GLYPH<SM590000> Change Function Usage ( CHGFCNUSG )
|
||||
|
||||
- GLYPH<SM590000> Display Function Usage ( DSPFCNUSG )
|
||||
GLYPH<SM590000> Display Function Usage ( DSPFCNUSG )
|
||||
|
||||
For example, the following CHGFCNUSG command shows granting authorization to user HBEDOYA to administer and manage RCAC rules:
|
||||
|
||||
@ -244,15 +244,15 @@ Table 3-1 Special registers and their corresponding values
|
||||
|
||||
Figure 3-5 shows the difference in the special register values when an adopted authority is used:
|
||||
|
||||
- GLYPH<SM590000> A user connects to the server using the user profile ALICE.
|
||||
GLYPH<SM590000> A user connects to the server using the user profile ALICE.
|
||||
|
||||
- GLYPH<SM590000> USER and CURRENT USER initially have the same value of ALICE.
|
||||
GLYPH<SM590000> USER and CURRENT USER initially have the same value of ALICE.
|
||||
|
||||
- GLYPH<SM590000> ALICE calls an SQL procedure that is named proc1, which is owned by user profile JOE and was created to adopt JOE's authority when it is called.
|
||||
GLYPH<SM590000> ALICE calls an SQL procedure that is named proc1, which is owned by user profile JOE and was created to adopt JOE's authority when it is called.
|
||||
|
||||
- GLYPH<SM590000> While the procedure is running, the special register USER still contains the value of ALICE because it excludes any adopted authority. The special register CURRENT USER contains the value of JOE because it includes any adopted authority.
|
||||
GLYPH<SM590000> While the procedure is running, the special register USER still contains the value of ALICE because it excludes any adopted authority. The special register CURRENT USER contains the value of JOE because it includes any adopted authority.
|
||||
|
||||
- GLYPH<SM590000> When proc1 ends, the session reverts to its original state with both USER and CURRENT USER having the value of ALICE.
|
||||
GLYPH<SM590000> When proc1 ends, the session reverts to its original state with both USER and CURRENT USER having the value of ALICE.
|
||||
|
||||
Figure 3-5 Special registers and adopted authority
|
||||
<!-- image -->
|
||||
@ -287,11 +287,11 @@ If a special register value is in the list of user profiles or it is a member of
|
||||
|
||||
Here is an example of using the VERIFY_GROUP_FOR_USER function:
|
||||
|
||||
- 1. There are user profiles for MGR, JANE, JUDY, and TONY.
|
||||
1. There are user profiles for MGR, JANE, JUDY, and TONY.
|
||||
|
||||
- 2. The user profile JANE specifies a group profile of MGR.
|
||||
2. The user profile JANE specifies a group profile of MGR.
|
||||
|
||||
- 3. If a user is connected to the server using user profile JANE, all of the following function invocations return a value of 1:
|
||||
3. If a user is connected to the server using user profile JANE, all of the following function invocations return a value of 1:
|
||||
|
||||
VERIFY_GROUP_FOR_USER (CURRENT_USER, 'MGR') VERIFY_GROUP_FOR_USER (CURRENT_USER, 'JANE', 'MGR') VERIFY_GROUP_FOR_USER (CURRENT_USER, 'JANE', 'MGR', 'STEVE') The following function invocation returns a value of 0: VERIFY_GROUP_FOR_USER (CURRENT_USER, 'JUDY', 'TONY')
|
||||
|
||||
@ -301,23 +301,23 @@ CASE
|
||||
|
||||
WHEN VERIFY_GROUP_FOR_USER ( SESSION_USER , 'HR', 'EMP' ) = 1 THEN EMPLOYEES . DATE_OF_BIRTH WHEN VERIFY_GROUP_FOR_USER ( SESSION_USER , 'MGR' ) = 1 AND SESSION_USER = EMPLOYEES . USER_ID THEN EMPLOYEES . DATE_OF_BIRTH WHEN VERIFY_GROUP_FOR_USER ( SESSION_USER , 'MGR' ) = 1 AND SESSION_USER <> EMPLOYEES . USER_ID THEN ( 9999 || '-' || MONTH ( EMPLOYEES . DATE_OF_BIRTH ) || '-' || DAY (EMPLOYEES.DATE_OF_BIRTH )) ELSE NULL END ENABLE ;
|
||||
|
||||
- 2. The other column to mask in this example is the TAX_ID information. In this example, the rules to enforce include the following ones:
|
||||
2. The other column to mask in this example is the TAX_ID information. In this example, the rules to enforce include the following ones:
|
||||
|
||||
- -Human Resources can see the unmasked TAX_ID of the employees.
|
||||
-Human Resources can see the unmasked TAX_ID of the employees.
|
||||
|
||||
- -Employees can see only their own unmasked TAX_ID.
|
||||
-Employees can see only their own unmasked TAX_ID.
|
||||
|
||||
- -Managers see a masked version of TAX_ID with the first five characters replaced with the X character (for example, XXX-XX-1234).
|
||||
-Managers see a masked version of TAX_ID with the first five characters replaced with the X character (for example, XXX-XX-1234).
|
||||
|
||||
- -Any other person sees the entire TAX_ID as masked, for example, XXX-XX-XXXX.
|
||||
-Any other person sees the entire TAX_ID as masked, for example, XXX-XX-XXXX.
|
||||
|
||||
- To implement this column mask, run the SQL statement that is shown in Example 3-9.
|
||||
To implement this column mask, run the SQL statement that is shown in Example 3-9.
|
||||
|
||||
CREATE MASK HR_SCHEMA.MASK_TAX_ID_ON_EMPLOYEES ON HR_SCHEMA.EMPLOYEES AS EMPLOYEES FOR COLUMN TAX_ID RETURN CASE WHEN VERIFY_GROUP_FOR_USER ( SESSION_USER , 'HR' ) = 1 THEN EMPLOYEES . TAX_ID WHEN VERIFY_GROUP_FOR_USER ( SESSION_USER , 'MGR' ) = 1 AND SESSION_USER = EMPLOYEES . USER_ID THEN EMPLOYEES . TAX_ID WHEN VERIFY_GROUP_FOR_USER ( SESSION_USER , 'MGR' ) = 1 AND SESSION_USER <> EMPLOYEES . USER_ID THEN ( 'XXX-XX-' CONCAT QSYS2 . SUBSTR ( EMPLOYEES . TAX_ID , 8 , 4 ) ) WHEN VERIFY_GROUP_FOR_USER ( SESSION_USER , 'EMP' ) = 1 THEN EMPLOYEES . TAX_ID ELSE 'XXX-XX-XXXX' END ENABLE ;
|
||||
|
||||
Example 3-9 Creating a mask on the TAX_ID column
|
||||
|
||||
- 3. Figure 3-10 shows the masks that are created in the HR_SCHEMA.
|
||||
3. Figure 3-10 shows the masks that are created in the HR_SCHEMA.
|
||||
|
||||
Figure 3-10 Column masks shown in System i Navigator
|
||||
<!-- image -->
|
||||
@ -326,13 +326,13 @@ Figure 3-10 Column masks shown in System i Navigator
|
||||
|
||||
Now that you have created the row permission and the two column masks, RCAC must be activated. The row permission and the two column masks are enabled (last clause in the scripts), but now you must activate RCAC on the table. To do so, complete the following steps:
|
||||
|
||||
- 1. Run the SQL statements that are shown in Example 3-10.
|
||||
1. Run the SQL statements that are shown in Example 3-10.
|
||||
|
||||
## Example 3-10 Activating RCAC on the EMPLOYEES table
|
||||
|
||||
- /* Active Row Access Control (permissions) */
|
||||
/* Active Row Access Control (permissions) */
|
||||
|
||||
- /* Active Column Access Control (masks)
|
||||
/* Active Column Access Control (masks)
|
||||
|
||||
*/
|
||||
|
||||
@ -342,14 +342,14 @@ ACTIVATE ROW ACCESS CONTROL
|
||||
|
||||
ACTIVATE COLUMN ACCESS CONTROL;
|
||||
|
||||
- 2. Look at the definition of the EMPLOYEE table, as shown in Figure 3-11. To do this, from the main navigation pane of System i Navigator, click Schemas HR_SCHEMA Tables , right-click the EMPLOYEES table, and click Definition .
|
||||
2. Look at the definition of the EMPLOYEE table, as shown in Figure 3-11. To do this, from the main navigation pane of System i Navigator, click Schemas HR_SCHEMA Tables , right-click the EMPLOYEES table, and click Definition .
|
||||
|
||||
Figure 3-11 Selecting the EMPLOYEES table from System i Navigator
|
||||
<!-- image -->
|
||||
|
||||
- 2. Figure 4-68 shows the Visual Explain of the same SQL statement, but with RCAC enabled. It is clear that the implementation of the SQL statement is more complex because the row permission rule becomes part of the WHERE clause.
|
||||
2. Figure 4-68 shows the Visual Explain of the same SQL statement, but with RCAC enabled. It is clear that the implementation of the SQL statement is more complex because the row permission rule becomes part of the WHERE clause.
|
||||
|
||||
- 3. Compare the advised indexes that are provided by the Optimizer without RCAC and with RCAC enabled. Figure 4-69 shows the index advice for the SQL statement without RCAC enabled. The index being advised is for the ORDER BY clause.
|
||||
3. Compare the advised indexes that are provided by the Optimizer without RCAC and with RCAC enabled. Figure 4-69 shows the index advice for the SQL statement without RCAC enabled. The index being advised is for the ORDER BY clause.
|
||||
|
||||
Figure 4-68 Visual Explain with RCAC enabled
|
||||
<!-- image -->
|
||||
|
140
tests/data/groundtruth/docling_v2/2203.01017v2.json
vendored
140
tests/data/groundtruth/docling_v2/2203.01017v2.json
vendored
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "2203.01017v2",
|
||||
"origin": {
|
||||
"mimetype": "application/pdf",
|
||||
@ -1340,7 +1340,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/13",
|
||||
@ -2096,7 +2096,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/39",
|
||||
@ -3055,7 +3055,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/72",
|
||||
@ -3086,7 +3086,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/73",
|
||||
@ -3117,7 +3117,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/74",
|
||||
@ -3148,7 +3148,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/75",
|
||||
@ -9249,7 +9249,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/284",
|
||||
@ -9280,7 +9280,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/285",
|
||||
@ -11288,7 +11288,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/354",
|
||||
@ -11348,7 +11348,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/356",
|
||||
@ -11379,7 +11379,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/357",
|
||||
@ -11410,7 +11410,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/358",
|
||||
@ -11441,7 +11441,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/359",
|
||||
@ -11472,7 +11472,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/360",
|
||||
@ -11503,7 +11503,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/361",
|
||||
@ -11534,7 +11534,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/362",
|
||||
@ -11565,7 +11565,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/363",
|
||||
@ -11596,7 +11596,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/364",
|
||||
@ -11627,7 +11627,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/365",
|
||||
@ -11658,7 +11658,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/366",
|
||||
@ -11689,7 +11689,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/367",
|
||||
@ -11720,7 +11720,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/368",
|
||||
@ -11751,7 +11751,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/369",
|
||||
@ -11782,7 +11782,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/370",
|
||||
@ -11813,7 +11813,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/371",
|
||||
@ -11844,7 +11844,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/372",
|
||||
@ -11875,7 +11875,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/373",
|
||||
@ -11906,7 +11906,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/374",
|
||||
@ -11937,7 +11937,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/375",
|
||||
@ -11968,7 +11968,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/376",
|
||||
@ -11999,7 +11999,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/377",
|
||||
@ -12030,7 +12030,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/378",
|
||||
@ -12061,7 +12061,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/379",
|
||||
@ -12092,7 +12092,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/380",
|
||||
@ -12181,7 +12181,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/383",
|
||||
@ -12212,7 +12212,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/384",
|
||||
@ -12243,7 +12243,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/385",
|
||||
@ -12274,7 +12274,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/386",
|
||||
@ -12305,7 +12305,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/387",
|
||||
@ -12336,7 +12336,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/388",
|
||||
@ -12367,7 +12367,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/389",
|
||||
@ -12398,7 +12398,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/390",
|
||||
@ -12429,7 +12429,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/391",
|
||||
@ -12460,7 +12460,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/392",
|
||||
@ -12491,7 +12491,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/393",
|
||||
@ -12522,7 +12522,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/394",
|
||||
@ -12553,7 +12553,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/395",
|
||||
@ -12584,7 +12584,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/396",
|
||||
@ -12923,7 +12923,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/407",
|
||||
@ -12954,7 +12954,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/408",
|
||||
@ -12985,7 +12985,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/409",
|
||||
@ -13016,7 +13016,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/410",
|
||||
@ -13047,7 +13047,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/411",
|
||||
@ -14906,7 +14906,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/475",
|
||||
@ -14937,7 +14937,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/476",
|
||||
@ -15055,7 +15055,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/480",
|
||||
@ -15086,7 +15086,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/481",
|
||||
@ -15117,7 +15117,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/482",
|
||||
@ -15148,7 +15148,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/483",
|
||||
@ -15179,7 +15179,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/484",
|
||||
@ -15268,7 +15268,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/487",
|
||||
@ -15299,7 +15299,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/488",
|
||||
@ -15330,7 +15330,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/489",
|
||||
@ -15361,7 +15361,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/490",
|
||||
@ -15392,7 +15392,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/491",
|
||||
@ -15452,7 +15452,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/493",
|
||||
@ -15483,7 +15483,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/494",
|
||||
@ -15514,7 +15514,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/495",
|
||||
@ -15545,7 +15545,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/496",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "2206.01062",
|
||||
"origin": {
|
||||
"mimetype": "application/pdf",
|
||||
@ -10866,7 +10866,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/356",
|
||||
@ -10897,7 +10897,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/357",
|
||||
@ -10928,7 +10928,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/358",
|
||||
@ -10959,7 +10959,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/359",
|
||||
@ -11048,7 +11048,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/362",
|
||||
@ -12430,7 +12430,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/409",
|
||||
@ -12461,7 +12461,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/410",
|
||||
@ -12492,7 +12492,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/411",
|
||||
@ -12523,7 +12523,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/412",
|
||||
@ -12554,7 +12554,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/413",
|
||||
@ -12585,7 +12585,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/414",
|
||||
@ -14713,7 +14713,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/487",
|
||||
@ -14744,7 +14744,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/488",
|
||||
@ -14775,7 +14775,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/489",
|
||||
@ -14806,7 +14806,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/490",
|
||||
@ -14837,7 +14837,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/491",
|
||||
@ -14868,7 +14868,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/492",
|
||||
@ -14899,7 +14899,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/493",
|
||||
@ -14930,7 +14930,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/494",
|
||||
@ -14961,7 +14961,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/495",
|
||||
@ -14992,7 +14992,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/496",
|
||||
@ -15023,7 +15023,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/497",
|
||||
@ -15054,7 +15054,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/498",
|
||||
@ -15085,7 +15085,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/499",
|
||||
@ -15580,7 +15580,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/516",
|
||||
@ -15611,7 +15611,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/517",
|
||||
@ -15642,7 +15642,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/518",
|
||||
@ -15673,7 +15673,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/519",
|
||||
@ -15704,7 +15704,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/520",
|
||||
@ -15735,7 +15735,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/521",
|
||||
@ -15766,7 +15766,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/522",
|
||||
@ -15797,7 +15797,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/523",
|
||||
@ -15828,7 +15828,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/524",
|
||||
@ -15859,7 +15859,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
}
|
||||
],
|
||||
"pictures": [
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "2305.03393v1-pg9",
|
||||
"origin": {
|
||||
"mimetype": "application/pdf",
|
||||
|
@ -60,8 +60,6 @@
|
||||
<page_header><loc_159><loc_59><loc_366><loc_64>Optimized Table Tokenization for Table Structure Recognition</page_header>
|
||||
<page_header><loc_389><loc_59><loc_393><loc_64>7</page_header>
|
||||
<picture><loc_135><loc_103><loc_367><loc_177><caption><loc_110><loc_79><loc_393><loc_98>Fig. 3. OTSL description of table structure: A - table example; B - graphical representation of table structure; C - mapping structure on a grid; D - OTSL structure encoding; E - explanation on cell encoding</caption></picture>
|
||||
<unordered_list><list_item><loc_273><loc_172><loc_349><loc_176>4 - 2d merges: "C", "L", "U", "X"</list_item>
|
||||
</unordered_list>
|
||||
<section_header_level_1><loc_110><loc_193><loc_202><loc_198>4.2 Language Syntax</section_header_level_1>
|
||||
<text><loc_110><loc_205><loc_297><loc_211>The OTSL representation follows these syntax rules:</text>
|
||||
<unordered_list><list_item><loc_114><loc_219><loc_393><loc_232>1. Left-looking cell rule : The left neighbour of an "L" cell must be either another "L" cell or a "C" cell.</list_item>
|
||||
|
1140
tests/data/groundtruth/docling_v2/2305.03393v1.json
vendored
1140
tests/data/groundtruth/docling_v2/2305.03393v1.json
vendored
File diff suppressed because it is too large
Load Diff
@ -84,8 +84,6 @@ Fig. 3. OTSL description of table structure: A - table example; B - graphical re
|
||||
|
||||
<!-- image -->
|
||||
|
||||
- 4 - 2d merges: "C", "L", "U", "X"
|
||||
|
||||
## 4.2 Language Syntax
|
||||
|
||||
The OTSL representation follows these syntax rules:
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "amt_handbook_sample",
|
||||
"origin": {
|
||||
"mimetype": "application/pdf",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "code_and_formula",
|
||||
"origin": {
|
||||
"mimetype": "application/pdf",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "csv-comma-in-cell",
|
||||
"origin": {
|
||||
"mimetype": "text/csv",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "csv-comma",
|
||||
"origin": {
|
||||
"mimetype": "text/csv",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "csv-inconsistent-header",
|
||||
"origin": {
|
||||
"mimetype": "text/csv",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "csv-pipe",
|
||||
"origin": {
|
||||
"mimetype": "text/csv",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "csv-semicolon",
|
||||
"origin": {
|
||||
"mimetype": "text/csv",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "csv-tab",
|
||||
"origin": {
|
||||
"mimetype": "text/csv",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "csv-too-few-columns",
|
||||
"origin": {
|
||||
"mimetype": "text/csv",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "csv-too-many-columns",
|
||||
"origin": {
|
||||
"mimetype": "text/csv",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "equations",
|
||||
"origin": {
|
||||
"mimetype": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
|
||||
|
@ -7,6 +7,9 @@ item-0 at level 0: unspecified: group _root_
|
||||
item-6 at level 3: list: group list
|
||||
item-7 at level 4: list_item: First item in unordered list
|
||||
item-8 at level 4: list_item: Second item in unordered list
|
||||
item-9 at level 3: ordered_list: group ordered list
|
||||
item-9 at level 3: list: group ordered list
|
||||
item-10 at level 4: list_item: First item in ordered list
|
||||
item-11 at level 4: list_item: Second item in ordered list
|
||||
item-11 at level 4: list_item: Second item in ordered list
|
||||
item-12 at level 3: list: group ordered list start 42
|
||||
item-13 at level 4: list_item: First item in ordered list with start
|
||||
item-14 at level 4: list_item: Second item in ordered list with start
|
@ -1,10 +1,10 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "example_01",
|
||||
"origin": {
|
||||
"mimetype": "text/html",
|
||||
"binary_hash": 13782069548509991617,
|
||||
"binary_hash": 13726679883013609282,
|
||||
"filename": "example_01.html"
|
||||
},
|
||||
"furniture": {
|
||||
@ -58,7 +58,24 @@
|
||||
],
|
||||
"content_layer": "body",
|
||||
"name": "ordered list",
|
||||
"label": "ordered_list"
|
||||
"label": "list"
|
||||
},
|
||||
{
|
||||
"self_ref": "#/groups/2",
|
||||
"parent": {
|
||||
"$ref": "#/texts/2"
|
||||
},
|
||||
"children": [
|
||||
{
|
||||
"$ref": "#/texts/8"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/9"
|
||||
}
|
||||
],
|
||||
"content_layer": "body",
|
||||
"name": "ordered list start 42",
|
||||
"label": "list"
|
||||
}
|
||||
],
|
||||
"texts": [
|
||||
@ -110,6 +127,9 @@
|
||||
},
|
||||
{
|
||||
"$ref": "#/groups/1"
|
||||
},
|
||||
{
|
||||
"$ref": "#/groups/2"
|
||||
}
|
||||
],
|
||||
"content_layer": "body",
|
||||
@ -143,7 +163,7 @@
|
||||
"orig": "First item in unordered list",
|
||||
"text": "First item in unordered list",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/5",
|
||||
@ -157,7 +177,7 @@
|
||||
"orig": "Second item in unordered list",
|
||||
"text": "Second item in unordered list",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/6",
|
||||
@ -171,7 +191,7 @@
|
||||
"orig": "First item in ordered list",
|
||||
"text": "First item in ordered list",
|
||||
"enumerated": true,
|
||||
"marker": "1."
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/7",
|
||||
@ -185,7 +205,35 @@
|
||||
"orig": "Second item in ordered list",
|
||||
"text": "Second item in ordered list",
|
||||
"enumerated": true,
|
||||
"marker": "2."
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/8",
|
||||
"parent": {
|
||||
"$ref": "#/groups/2"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "list_item",
|
||||
"prov": [],
|
||||
"orig": "First item in ordered list with start",
|
||||
"text": "First item in ordered list with start",
|
||||
"enumerated": true,
|
||||
"marker": "42."
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/9",
|
||||
"parent": {
|
||||
"$ref": "#/groups/2"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "list_item",
|
||||
"prov": [],
|
||||
"orig": "Second item in ordered list with start",
|
||||
"text": "Second item in ordered list with start",
|
||||
"enumerated": true,
|
||||
"marker": "43."
|
||||
}
|
||||
],
|
||||
"pictures": [
|
||||
|
@ -12,4 +12,7 @@ Some background information here.
|
||||
- Second item in unordered list
|
||||
|
||||
1. First item in ordered list
|
||||
2. Second item in ordered list
|
||||
2. Second item in ordered list
|
||||
|
||||
42. First item in ordered list with start
|
||||
43. Second item in ordered list with start
|
@ -6,6 +6,6 @@ item-0 at level 0: unspecified: group _root_
|
||||
item-5 at level 3: list: group list
|
||||
item-6 at level 4: list_item: First item in unordered list
|
||||
item-7 at level 4: list_item: Second item in unordered list
|
||||
item-8 at level 3: ordered_list: group ordered list
|
||||
item-8 at level 3: list: group ordered list
|
||||
item-9 at level 4: list_item: First item in ordered list
|
||||
item-10 at level 4: list_item: Second item in ordered list
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "example_02",
|
||||
"origin": {
|
||||
"mimetype": "text/html",
|
||||
@ -58,7 +58,7 @@
|
||||
],
|
||||
"content_layer": "body",
|
||||
"name": "ordered list",
|
||||
"label": "ordered_list"
|
||||
"label": "list"
|
||||
}
|
||||
],
|
||||
"texts": [
|
||||
@ -140,7 +140,7 @@
|
||||
"orig": "First item in unordered list",
|
||||
"text": "First item in unordered list",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/5",
|
||||
@ -154,7 +154,7 @@
|
||||
"orig": "Second item in unordered list",
|
||||
"text": "Second item in unordered list",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/6",
|
||||
@ -168,7 +168,7 @@
|
||||
"orig": "First item in ordered list",
|
||||
"text": "First item in ordered list",
|
||||
"enumerated": true,
|
||||
"marker": "1."
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/7",
|
||||
@ -182,7 +182,7 @@
|
||||
"orig": "Second item in ordered list",
|
||||
"text": "Second item in ordered list",
|
||||
"enumerated": true,
|
||||
"marker": "2."
|
||||
"marker": ""
|
||||
}
|
||||
],
|
||||
"pictures": [],
|
||||
|
@ -10,9 +10,9 @@ item-0 at level 0: unspecified: group _root_
|
||||
item-9 at level 6: list_item: Nested item 1
|
||||
item-10 at level 6: list_item: Nested item 2
|
||||
item-11 at level 4: list_item: Second item in unordered list
|
||||
item-12 at level 3: ordered_list: group ordered list
|
||||
item-12 at level 3: list: group ordered list
|
||||
item-13 at level 4: list_item: First item in ordered list
|
||||
item-14 at level 5: ordered_list: group ordered list
|
||||
item-14 at level 5: list: group ordered list
|
||||
item-15 at level 6: list_item: Nested ordered item 1
|
||||
item-16 at level 6: list_item: Nested ordered item 2
|
||||
item-17 at level 4: list_item: Second item in ordered list
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "example_03",
|
||||
"origin": {
|
||||
"mimetype": "text/html",
|
||||
@ -75,7 +75,7 @@
|
||||
],
|
||||
"content_layer": "body",
|
||||
"name": "ordered list",
|
||||
"label": "ordered_list"
|
||||
"label": "list"
|
||||
},
|
||||
{
|
||||
"self_ref": "#/groups/3",
|
||||
@ -92,7 +92,7 @@
|
||||
],
|
||||
"content_layer": "body",
|
||||
"name": "ordered list",
|
||||
"label": "ordered_list"
|
||||
"label": "list"
|
||||
}
|
||||
],
|
||||
"texts": [
|
||||
@ -198,7 +198,7 @@
|
||||
"orig": "First item in unordered list",
|
||||
"text": "First item in unordered list",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/6",
|
||||
@ -212,7 +212,7 @@
|
||||
"orig": "Nested item 1",
|
||||
"text": "Nested item 1",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/7",
|
||||
@ -226,7 +226,7 @@
|
||||
"orig": "Nested item 2",
|
||||
"text": "Nested item 2",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/8",
|
||||
@ -240,7 +240,7 @@
|
||||
"orig": "Second item in unordered list",
|
||||
"text": "Second item in unordered list",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/9",
|
||||
@ -258,7 +258,7 @@
|
||||
"orig": "First item in ordered list",
|
||||
"text": "First item in ordered list",
|
||||
"enumerated": true,
|
||||
"marker": "1"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/10",
|
||||
@ -272,7 +272,7 @@
|
||||
"orig": "Nested ordered item 1",
|
||||
"text": "Nested ordered item 1",
|
||||
"enumerated": true,
|
||||
"marker": "1."
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/11",
|
||||
@ -286,7 +286,7 @@
|
||||
"orig": "Nested ordered item 2",
|
||||
"text": "Nested ordered item 2",
|
||||
"enumerated": true,
|
||||
"marker": "2."
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/12",
|
||||
@ -300,7 +300,7 @@
|
||||
"orig": "Second item in ordered list",
|
||||
"text": "Second item in ordered list",
|
||||
"enumerated": true,
|
||||
"marker": "2."
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/13",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "example_04",
|
||||
"origin": {
|
||||
"mimetype": "text/html",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "example_05",
|
||||
"origin": {
|
||||
"mimetype": "text/html",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "example_06",
|
||||
"origin": {
|
||||
"mimetype": "text/html",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "example_07",
|
||||
"origin": {
|
||||
"mimetype": "text/html",
|
||||
@ -169,7 +169,7 @@
|
||||
"orig": "Asia",
|
||||
"text": "Asia",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/1",
|
||||
@ -183,7 +183,7 @@
|
||||
"orig": "China",
|
||||
"text": "China",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/2",
|
||||
@ -197,7 +197,7 @@
|
||||
"orig": "Japan",
|
||||
"text": "Japan",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/3",
|
||||
@ -211,7 +211,7 @@
|
||||
"orig": "Thailand",
|
||||
"text": "Thailand",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/4",
|
||||
@ -229,7 +229,7 @@
|
||||
"orig": "Europe",
|
||||
"text": "Europe",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/5",
|
||||
@ -243,7 +243,7 @@
|
||||
"orig": "UK",
|
||||
"text": "UK",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/6",
|
||||
@ -257,7 +257,7 @@
|
||||
"orig": "Germany",
|
||||
"text": "Germany",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/7",
|
||||
@ -275,7 +275,7 @@
|
||||
"orig": "Switzerland",
|
||||
"text": "Switzerland",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/8",
|
||||
@ -289,7 +289,7 @@
|
||||
"orig": "Bern",
|
||||
"text": "Bern",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/9",
|
||||
@ -303,7 +303,7 @@
|
||||
"orig": "Aargau",
|
||||
"text": "Aargau",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/10",
|
||||
@ -321,7 +321,7 @@
|
||||
"orig": "Italy",
|
||||
"text": "Italy",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/11",
|
||||
@ -335,7 +335,7 @@
|
||||
"orig": "Piedmont",
|
||||
"text": "Piedmont",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/12",
|
||||
@ -349,7 +349,7 @@
|
||||
"orig": "Liguria",
|
||||
"text": "Liguria",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/13",
|
||||
@ -363,7 +363,7 @@
|
||||
"orig": "Africa",
|
||||
"text": "Africa",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
}
|
||||
],
|
||||
"pictures": [],
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "example_08",
|
||||
"origin": {
|
||||
"mimetype": "text/html",
|
||||
|
@ -56,7 +56,7 @@ groups:
|
||||
- $ref: '#/texts/27'
|
||||
- $ref: '#/texts/28'
|
||||
content_layer: body
|
||||
label: ordered_list
|
||||
label: list
|
||||
name: list
|
||||
parent:
|
||||
$ref: '#/body'
|
||||
@ -430,7 +430,7 @@ texts:
|
||||
content_layer: body
|
||||
enumerated: true
|
||||
label: list_item
|
||||
marker: '-'
|
||||
marker: ''
|
||||
orig: ''
|
||||
parent:
|
||||
$ref: '#/groups/2'
|
||||
@ -476,7 +476,7 @@ texts:
|
||||
content_layer: body
|
||||
enumerated: true
|
||||
label: list_item
|
||||
marker: '-'
|
||||
marker: ''
|
||||
orig: ''
|
||||
parent:
|
||||
$ref: '#/groups/2'
|
||||
@ -519,7 +519,7 @@ texts:
|
||||
content_layer: body
|
||||
enumerated: true
|
||||
label: list_item
|
||||
marker: '-'
|
||||
marker: ''
|
||||
orig: ''
|
||||
parent:
|
||||
$ref: '#/groups/2'
|
||||
@ -562,7 +562,7 @@ texts:
|
||||
content_layer: body
|
||||
enumerated: true
|
||||
label: list_item
|
||||
marker: '-'
|
||||
marker: ''
|
||||
orig: ''
|
||||
parent:
|
||||
$ref: '#/groups/2'
|
||||
@ -604,7 +604,7 @@ texts:
|
||||
content_layer: body
|
||||
enumerated: true
|
||||
label: list_item
|
||||
marker: '-'
|
||||
marker: ''
|
||||
orig: Open a Pull Request
|
||||
parent:
|
||||
$ref: '#/groups/2'
|
||||
@ -621,7 +621,7 @@ texts:
|
||||
strikethrough: false
|
||||
underline: false
|
||||
label: list_item
|
||||
marker: '-'
|
||||
marker: ''
|
||||
orig: Whole list item has same formatting
|
||||
parent:
|
||||
$ref: '#/groups/2'
|
||||
@ -633,7 +633,7 @@ texts:
|
||||
content_layer: body
|
||||
enumerated: true
|
||||
label: list_item
|
||||
marker: '-'
|
||||
marker: ''
|
||||
orig: ''
|
||||
parent:
|
||||
$ref: '#/groups/2'
|
||||
@ -693,7 +693,7 @@ texts:
|
||||
content_layer: body
|
||||
enumerated: false
|
||||
label: list_item
|
||||
marker: '-'
|
||||
marker: ''
|
||||
orig: ''
|
||||
parent:
|
||||
$ref: '#/groups/8'
|
||||
@ -729,7 +729,7 @@ texts:
|
||||
content_layer: body
|
||||
enumerated: false
|
||||
label: list_item
|
||||
marker: '-'
|
||||
marker: ''
|
||||
orig: ''
|
||||
parent:
|
||||
$ref: '#/groups/8'
|
||||
@ -878,4 +878,4 @@ texts:
|
||||
prov: []
|
||||
self_ref: '#/texts/48'
|
||||
text: Table Heading
|
||||
version: 1.4.0
|
||||
version: 1.5.0
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "ipa20180000016.xml",
|
||||
"origin": {
|
||||
"mimetype": "application/xml",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "ipa20200022300.xml",
|
||||
"origin": {
|
||||
"mimetype": "application/xml",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "lorem_ipsum",
|
||||
"origin": {
|
||||
"mimetype": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "multi_page",
|
||||
"origin": {
|
||||
"mimetype": "application/pdf",
|
||||
@ -534,7 +534,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/8",
|
||||
@ -565,7 +565,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/9",
|
||||
@ -684,7 +684,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/13",
|
||||
@ -715,7 +715,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/14",
|
||||
@ -834,7 +834,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/18",
|
||||
@ -865,7 +865,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/19",
|
||||
@ -896,7 +896,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/20",
|
||||
@ -1074,7 +1074,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/26",
|
||||
@ -1105,7 +1105,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/27",
|
||||
@ -1136,7 +1136,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/28",
|
||||
@ -1226,7 +1226,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/31",
|
||||
@ -1257,7 +1257,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/32",
|
||||
@ -1288,7 +1288,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/33",
|
||||
@ -1319,7 +1319,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/34",
|
||||
@ -1350,7 +1350,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/35",
|
||||
@ -1440,7 +1440,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/38",
|
||||
@ -1471,7 +1471,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/39",
|
||||
@ -1502,7 +1502,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/40",
|
||||
@ -1592,7 +1592,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/43",
|
||||
@ -1623,7 +1623,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/44",
|
||||
@ -1654,7 +1654,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/45",
|
||||
@ -1685,7 +1685,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/46",
|
||||
@ -1716,7 +1716,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/47",
|
||||
@ -1806,7 +1806,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/50",
|
||||
@ -1837,7 +1837,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/51",
|
||||
@ -1868,7 +1868,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/52",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "pa20010031492.xml",
|
||||
"origin": {
|
||||
"mimetype": "application/xml",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "pftaps057006474.txt",
|
||||
"origin": {
|
||||
"mimetype": "text/plain",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "pg06442728.xml",
|
||||
"origin": {
|
||||
"mimetype": "application/xml",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "picture_classification",
|
||||
"origin": {
|
||||
"mimetype": "application/pdf",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "powerpoint_bad_text",
|
||||
"origin": {
|
||||
"mimetype": "application/vnd.ms-powerpoint",
|
||||
|
@ -11,7 +11,7 @@ item-0 at level 0: unspecified: group _root_
|
||||
item-10 at level 2: paragraph: And baz things
|
||||
item-11 at level 2: paragraph: A rectangle shape with this text inside.
|
||||
item-12 at level 1: chapter: group slide-2
|
||||
item-13 at level 2: ordered_list: group list
|
||||
item-13 at level 2: list: group list
|
||||
item-14 at level 3: list_item: List item4
|
||||
item-15 at level 3: list_item: List item5
|
||||
item-16 at level 3: list_item: List item6
|
||||
@ -25,7 +25,7 @@ item-0 at level 0: unspecified: group _root_
|
||||
item-24 at level 3: list_item: Item A
|
||||
item-25 at level 3: list_item: Item B
|
||||
item-26 at level 2: paragraph: Maybe a list?
|
||||
item-27 at level 2: ordered_list: group list
|
||||
item-27 at level 2: list: group list
|
||||
item-28 at level 3: list_item: List1
|
||||
item-29 at level 3: list_item: List2
|
||||
item-30 at level 3: list_item: List3
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "powerpoint_sample",
|
||||
"origin": {
|
||||
"mimetype": "application/vnd.ms-powerpoint",
|
||||
@ -137,7 +137,7 @@
|
||||
],
|
||||
"content_layer": "body",
|
||||
"name": "list",
|
||||
"label": "ordered_list"
|
||||
"label": "list"
|
||||
},
|
||||
{
|
||||
"self_ref": "#/groups/4",
|
||||
@ -197,7 +197,7 @@
|
||||
],
|
||||
"content_layer": "body",
|
||||
"name": "list",
|
||||
"label": "ordered_list"
|
||||
"label": "list"
|
||||
},
|
||||
{
|
||||
"self_ref": "#/groups/7",
|
||||
@ -578,7 +578,7 @@
|
||||
"orig": "I1",
|
||||
"text": "I1",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/13",
|
||||
@ -607,7 +607,7 @@
|
||||
"orig": "I2",
|
||||
"text": "I2",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/14",
|
||||
@ -636,7 +636,7 @@
|
||||
"orig": "I3",
|
||||
"text": "I3",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/15",
|
||||
@ -665,7 +665,7 @@
|
||||
"orig": "I4",
|
||||
"text": "I4",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/16",
|
||||
@ -721,7 +721,7 @@
|
||||
"orig": "Item A",
|
||||
"text": "Item A",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/18",
|
||||
@ -750,7 +750,7 @@
|
||||
"orig": "Item B",
|
||||
"text": "Item B",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/19",
|
||||
@ -893,7 +893,7 @@
|
||||
"orig": "l1 ",
|
||||
"text": "l1 ",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/24",
|
||||
@ -922,7 +922,7 @@
|
||||
"orig": "l2",
|
||||
"text": "l2",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/25",
|
||||
@ -951,7 +951,7 @@
|
||||
"orig": "l3",
|
||||
"text": "l3",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/26",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "powerpoint_with_image",
|
||||
"origin": {
|
||||
"mimetype": "application/vnd.ms-powerpoint",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "redp5110_sampled",
|
||||
"origin": {
|
||||
"mimetype": "application/pdf",
|
||||
@ -1295,7 +1295,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/15",
|
||||
@ -1326,7 +1326,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/16",
|
||||
@ -1357,7 +1357,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/17",
|
||||
@ -1388,7 +1388,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/18",
|
||||
@ -1683,7 +1683,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/28",
|
||||
@ -1714,7 +1714,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/29",
|
||||
@ -1745,7 +1745,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/30",
|
||||
@ -1776,7 +1776,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/31",
|
||||
@ -1807,7 +1807,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/32",
|
||||
@ -1838,7 +1838,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/33",
|
||||
@ -1869,7 +1869,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/34",
|
||||
@ -1900,7 +1900,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/35",
|
||||
@ -1931,7 +1931,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/36",
|
||||
@ -2400,7 +2400,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/52",
|
||||
@ -2431,7 +2431,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/53",
|
||||
@ -2462,7 +2462,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/54",
|
||||
@ -2668,7 +2668,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/61",
|
||||
@ -2699,7 +2699,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/62",
|
||||
@ -2759,7 +2759,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/64",
|
||||
@ -3344,7 +3344,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/84",
|
||||
@ -3375,7 +3375,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/85",
|
||||
@ -3406,7 +3406,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/86",
|
||||
@ -5992,7 +5992,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/175",
|
||||
@ -6023,7 +6023,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/176",
|
||||
@ -6054,7 +6054,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/177",
|
||||
@ -6085,7 +6085,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/178",
|
||||
@ -6116,7 +6116,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/179",
|
||||
@ -6787,7 +6787,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/202",
|
||||
@ -6818,7 +6818,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/203",
|
||||
@ -6849,7 +6849,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/204",
|
||||
@ -7064,7 +7064,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/211",
|
||||
@ -7095,7 +7095,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/212",
|
||||
@ -7126,7 +7126,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/213",
|
||||
@ -7157,7 +7157,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/214",
|
||||
@ -7188,7 +7188,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/215",
|
||||
@ -7219,7 +7219,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/216",
|
||||
@ -7379,7 +7379,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/221",
|
||||
@ -7498,7 +7498,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/225",
|
||||
@ -7559,7 +7559,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/227",
|
||||
@ -7590,7 +7590,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/228",
|
||||
@ -7737,7 +7737,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/233",
|
||||
@ -7855,7 +7855,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/237",
|
||||
@ -7915,7 +7915,7 @@
|
||||
"formatting": null,
|
||||
"hyperlink": null,
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/239",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "right_to_left_01",
|
||||
"origin": {
|
||||
"mimetype": "application/pdf",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "right_to_left_02",
|
||||
"origin": {
|
||||
"mimetype": "application/pdf",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "right_to_left_03",
|
||||
"origin": {
|
||||
"mimetype": "application/pdf",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "sample_sales_data",
|
||||
"origin": {
|
||||
"mimetype": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "tablecell",
|
||||
"origin": {
|
||||
"mimetype": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
|
||||
@ -82,7 +82,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/1",
|
||||
@ -103,7 +103,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/2",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "test-01",
|
||||
"origin": {
|
||||
"mimetype": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "test_emf_docx",
|
||||
"origin": {
|
||||
"mimetype": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
|
||||
|
@ -29,64 +29,62 @@ item-0 at level 0: unspecified: group _root_
|
||||
item-24 at level 3: list_item: A report must also be submitted ... d Infectious Disease Reporting System.
|
||||
item-25 at level 2: paragraph:
|
||||
item-26 at level 1: list: group list
|
||||
item-27 at level 2: list_item:
|
||||
item-27 at level 1: paragraph:
|
||||
item-28 at level 1: paragraph:
|
||||
item-29 at level 1: paragraph:
|
||||
item-30 at level 1: paragraph:
|
||||
item-31 at level 1: paragraph:
|
||||
item-32 at level 1: paragraph:
|
||||
item-33 at level 1: section: group textbox
|
||||
item-34 at level 2: paragraph: Health Bureau:
|
||||
item-35 at level 2: paragraph: Upon receiving a report from the ... rt to the Centers for Disease Control.
|
||||
item-36 at level 2: list: group list
|
||||
item-37 at level 3: list_item: If necessary, provide health edu ... vidual to undergo specimen collection.
|
||||
item-38 at level 3: list_item: Implement appropriate epidemic p ... the Communicable Disease Control Act.
|
||||
item-39 at level 2: paragraph:
|
||||
item-40 at level 1: list: group list
|
||||
item-41 at level 2: list_item:
|
||||
item-42 at level 1: paragraph:
|
||||
item-43 at level 1: section: group textbox
|
||||
item-44 at level 2: paragraph: Department of Education:
|
||||
item-32 at level 1: section: group textbox
|
||||
item-33 at level 2: paragraph: Health Bureau:
|
||||
item-34 at level 2: paragraph: Upon receiving a report from the ... rt to the Centers for Disease Control.
|
||||
item-35 at level 2: list: group list
|
||||
item-36 at level 3: list_item: If necessary, provide health edu ... vidual to undergo specimen collection.
|
||||
item-37 at level 3: list_item: Implement appropriate epidemic p ... the Communicable Disease Control Act.
|
||||
item-38 at level 2: paragraph:
|
||||
item-39 at level 1: list: group list
|
||||
item-40 at level 1: paragraph:
|
||||
item-41 at level 1: section: group textbox
|
||||
item-42 at level 2: paragraph: Department of Education:
|
||||
Collabo ... vention measures at all school levels.
|
||||
item-43 at level 1: paragraph:
|
||||
item-44 at level 1: paragraph:
|
||||
item-45 at level 1: paragraph:
|
||||
item-46 at level 1: paragraph:
|
||||
item-47 at level 1: paragraph:
|
||||
item-48 at level 1: paragraph:
|
||||
item-49 at level 1: paragraph:
|
||||
item-50 at level 1: paragraph:
|
||||
item-51 at level 1: paragraph:
|
||||
item-52 at level 1: section: group textbox
|
||||
item-53 at level 2: inline: group group
|
||||
item-54 at level 3: paragraph: The Health Bureau will handle
|
||||
item-55 at level 3: paragraph: reporting and specimen collection
|
||||
item-56 at level 3: paragraph: .
|
||||
item-57 at level 2: paragraph:
|
||||
item-50 at level 1: section: group textbox
|
||||
item-51 at level 2: inline: group group
|
||||
item-52 at level 3: paragraph: The Health Bureau will handle
|
||||
item-53 at level 3: paragraph: reporting and specimen collection
|
||||
item-54 at level 3: paragraph: .
|
||||
item-55 at level 2: paragraph:
|
||||
item-56 at level 1: paragraph:
|
||||
item-57 at level 1: paragraph:
|
||||
item-58 at level 1: paragraph:
|
||||
item-59 at level 1: paragraph:
|
||||
item-60 at level 1: paragraph:
|
||||
item-61 at level 1: section: group textbox
|
||||
item-62 at level 2: paragraph: Whether the epidemic has eased.
|
||||
item-63 at level 2: paragraph:
|
||||
item-64 at level 1: paragraph:
|
||||
item-65 at level 1: section: group textbox
|
||||
item-66 at level 2: paragraph: Whether the test results are pos ... legally designated infectious disease.
|
||||
item-67 at level 2: paragraph: No
|
||||
item-68 at level 1: paragraph:
|
||||
item-69 at level 1: paragraph:
|
||||
item-70 at level 1: section: group textbox
|
||||
item-71 at level 2: paragraph: Yes
|
||||
item-72 at level 1: paragraph:
|
||||
item-73 at level 1: section: group textbox
|
||||
item-74 at level 2: paragraph: Yes
|
||||
item-75 at level 1: paragraph:
|
||||
item-76 at level 1: paragraph:
|
||||
item-77 at level 1: section: group textbox
|
||||
item-78 at level 2: paragraph: Case closed.
|
||||
item-79 at level 2: paragraph:
|
||||
item-80 at level 2: paragraph: The Health Bureau will carry out ... ters for Disease Control if necessary.
|
||||
item-81 at level 1: paragraph:
|
||||
item-82 at level 1: section: group textbox
|
||||
item-83 at level 2: paragraph: No
|
||||
item-84 at level 1: paragraph:
|
||||
item-85 at level 1: paragraph:
|
||||
item-86 at level 1: paragraph:
|
||||
item-59 at level 1: section: group textbox
|
||||
item-60 at level 2: paragraph: Whether the epidemic has eased.
|
||||
item-61 at level 2: paragraph:
|
||||
item-62 at level 1: paragraph:
|
||||
item-63 at level 1: section: group textbox
|
||||
item-64 at level 2: paragraph: Whether the test results are pos ... legally designated infectious disease.
|
||||
item-65 at level 2: paragraph: No
|
||||
item-66 at level 1: paragraph:
|
||||
item-67 at level 1: paragraph:
|
||||
item-68 at level 1: section: group textbox
|
||||
item-69 at level 2: paragraph: Yes
|
||||
item-70 at level 1: paragraph:
|
||||
item-71 at level 1: section: group textbox
|
||||
item-72 at level 2: paragraph: Yes
|
||||
item-73 at level 1: paragraph:
|
||||
item-74 at level 1: paragraph:
|
||||
item-75 at level 1: section: group textbox
|
||||
item-76 at level 2: paragraph: Case closed.
|
||||
item-77 at level 2: paragraph:
|
||||
item-78 at level 2: paragraph: The Health Bureau will carry out ... ters for Disease Control if necessary.
|
||||
item-79 at level 1: paragraph:
|
||||
item-80 at level 1: section: group textbox
|
||||
item-81 at level 2: paragraph: No
|
||||
item-82 at level 1: paragraph:
|
||||
item-83 at level 1: paragraph:
|
||||
item-84 at level 1: paragraph:
|
434
tests/data/groundtruth/docling_v2/textbox.docx.json
vendored
434
tests/data/groundtruth/docling_v2/textbox.docx.json
vendored
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "textbox",
|
||||
"origin": {
|
||||
"mimetype": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
|
||||
@ -65,6 +65,9 @@
|
||||
{
|
||||
"$ref": "#/groups/6"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/19"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/20"
|
||||
},
|
||||
@ -77,9 +80,6 @@
|
||||
{
|
||||
"$ref": "#/texts/23"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/24"
|
||||
},
|
||||
{
|
||||
"$ref": "#/groups/7"
|
||||
},
|
||||
@ -87,11 +87,17 @@
|
||||
"$ref": "#/groups/9"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/31"
|
||||
"$ref": "#/texts/29"
|
||||
},
|
||||
{
|
||||
"$ref": "#/groups/10"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/31"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/32"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/33"
|
||||
},
|
||||
@ -107,71 +113,65 @@
|
||||
{
|
||||
"$ref": "#/texts/37"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/38"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/39"
|
||||
},
|
||||
{
|
||||
"$ref": "#/groups/11"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/42"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/43"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/44"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/45"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/46"
|
||||
},
|
||||
{
|
||||
"$ref": "#/groups/13"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/49"
|
||||
"$ref": "#/texts/47"
|
||||
},
|
||||
{
|
||||
"$ref": "#/groups/14"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/52"
|
||||
"$ref": "#/texts/50"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/53"
|
||||
"$ref": "#/texts/51"
|
||||
},
|
||||
{
|
||||
"$ref": "#/groups/15"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/55"
|
||||
"$ref": "#/texts/53"
|
||||
},
|
||||
{
|
||||
"$ref": "#/groups/16"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/57"
|
||||
"$ref": "#/texts/55"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/58"
|
||||
"$ref": "#/texts/56"
|
||||
},
|
||||
{
|
||||
"$ref": "#/groups/17"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/62"
|
||||
"$ref": "#/texts/60"
|
||||
},
|
||||
{
|
||||
"$ref": "#/groups/18"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/62"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/63"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/64"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/65"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/66"
|
||||
}
|
||||
],
|
||||
"content_layer": "body",
|
||||
@ -280,11 +280,7 @@
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [
|
||||
{
|
||||
"$ref": "#/texts/19"
|
||||
}
|
||||
],
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"name": "list",
|
||||
"label": "list"
|
||||
@ -296,16 +292,16 @@
|
||||
},
|
||||
"children": [
|
||||
{
|
||||
"$ref": "#/texts/25"
|
||||
"$ref": "#/texts/24"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/26"
|
||||
"$ref": "#/texts/25"
|
||||
},
|
||||
{
|
||||
"$ref": "#/groups/8"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/29"
|
||||
"$ref": "#/texts/28"
|
||||
}
|
||||
],
|
||||
"content_layer": "body",
|
||||
@ -319,10 +315,10 @@
|
||||
},
|
||||
"children": [
|
||||
{
|
||||
"$ref": "#/texts/27"
|
||||
"$ref": "#/texts/26"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/28"
|
||||
"$ref": "#/texts/27"
|
||||
}
|
||||
],
|
||||
"content_layer": "body",
|
||||
@ -334,11 +330,7 @@
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [
|
||||
{
|
||||
"$ref": "#/texts/30"
|
||||
}
|
||||
],
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"name": "list",
|
||||
"label": "list"
|
||||
@ -350,7 +342,7 @@
|
||||
},
|
||||
"children": [
|
||||
{
|
||||
"$ref": "#/texts/32"
|
||||
"$ref": "#/texts/30"
|
||||
}
|
||||
],
|
||||
"content_layer": "body",
|
||||
@ -367,7 +359,7 @@
|
||||
"$ref": "#/groups/12"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/43"
|
||||
"$ref": "#/texts/41"
|
||||
}
|
||||
],
|
||||
"content_layer": "body",
|
||||
@ -380,14 +372,14 @@
|
||||
"$ref": "#/groups/11"
|
||||
},
|
||||
"children": [
|
||||
{
|
||||
"$ref": "#/texts/38"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/39"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/40"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/41"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/42"
|
||||
}
|
||||
],
|
||||
"content_layer": "body",
|
||||
@ -401,10 +393,10 @@
|
||||
},
|
||||
"children": [
|
||||
{
|
||||
"$ref": "#/texts/47"
|
||||
"$ref": "#/texts/45"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/48"
|
||||
"$ref": "#/texts/46"
|
||||
}
|
||||
],
|
||||
"content_layer": "body",
|
||||
@ -418,10 +410,10 @@
|
||||
},
|
||||
"children": [
|
||||
{
|
||||
"$ref": "#/texts/50"
|
||||
"$ref": "#/texts/48"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/51"
|
||||
"$ref": "#/texts/49"
|
||||
}
|
||||
],
|
||||
"content_layer": "body",
|
||||
@ -435,7 +427,7 @@
|
||||
},
|
||||
"children": [
|
||||
{
|
||||
"$ref": "#/texts/54"
|
||||
"$ref": "#/texts/52"
|
||||
}
|
||||
],
|
||||
"content_layer": "body",
|
||||
@ -449,7 +441,7 @@
|
||||
},
|
||||
"children": [
|
||||
{
|
||||
"$ref": "#/texts/56"
|
||||
"$ref": "#/texts/54"
|
||||
}
|
||||
],
|
||||
"content_layer": "body",
|
||||
@ -462,14 +454,14 @@
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [
|
||||
{
|
||||
"$ref": "#/texts/57"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/58"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/59"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/60"
|
||||
},
|
||||
{
|
||||
"$ref": "#/texts/61"
|
||||
}
|
||||
],
|
||||
"content_layer": "body",
|
||||
@ -483,7 +475,7 @@
|
||||
},
|
||||
"children": [
|
||||
{
|
||||
"$ref": "#/texts/63"
|
||||
"$ref": "#/texts/61"
|
||||
}
|
||||
],
|
||||
"content_layer": "body",
|
||||
@ -592,7 +584,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/6",
|
||||
@ -747,7 +739,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/17",
|
||||
@ -768,7 +760,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/18",
|
||||
@ -785,16 +777,14 @@
|
||||
{
|
||||
"self_ref": "#/texts/19",
|
||||
"parent": {
|
||||
"$ref": "#/groups/6"
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "list_item",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "",
|
||||
"text": "",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/20",
|
||||
@ -846,18 +836,6 @@
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/24",
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "",
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/25",
|
||||
"parent": {
|
||||
"$ref": "#/groups/7"
|
||||
},
|
||||
@ -876,7 +854,7 @@
|
||||
}
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/26",
|
||||
"self_ref": "#/texts/25",
|
||||
"parent": {
|
||||
"$ref": "#/groups/7"
|
||||
},
|
||||
@ -895,7 +873,7 @@
|
||||
}
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/27",
|
||||
"self_ref": "#/texts/26",
|
||||
"parent": {
|
||||
"$ref": "#/groups/8"
|
||||
},
|
||||
@ -913,10 +891,10 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/28",
|
||||
"self_ref": "#/texts/27",
|
||||
"parent": {
|
||||
"$ref": "#/groups/8"
|
||||
},
|
||||
@ -934,10 +912,10 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/29",
|
||||
"self_ref": "#/texts/28",
|
||||
"parent": {
|
||||
"$ref": "#/groups/7"
|
||||
},
|
||||
@ -949,21 +927,7 @@
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/30",
|
||||
"parent": {
|
||||
"$ref": "#/groups/9"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "list_item",
|
||||
"prov": [],
|
||||
"orig": "",
|
||||
"text": "",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/31",
|
||||
"self_ref": "#/texts/29",
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
@ -975,7 +939,7 @@
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/32",
|
||||
"self_ref": "#/texts/30",
|
||||
"parent": {
|
||||
"$ref": "#/groups/10"
|
||||
},
|
||||
@ -993,6 +957,30 @@
|
||||
"script": "baseline"
|
||||
}
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/31",
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "",
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/32",
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "",
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/33",
|
||||
"parent": {
|
||||
@ -1055,30 +1043,6 @@
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/38",
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "",
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/39",
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "",
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/40",
|
||||
"parent": {
|
||||
"$ref": "#/groups/12"
|
||||
},
|
||||
@ -1097,7 +1061,7 @@
|
||||
}
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/41",
|
||||
"self_ref": "#/texts/39",
|
||||
"parent": {
|
||||
"$ref": "#/groups/12"
|
||||
},
|
||||
@ -1116,7 +1080,7 @@
|
||||
}
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/42",
|
||||
"self_ref": "#/texts/40",
|
||||
"parent": {
|
||||
"$ref": "#/groups/12"
|
||||
},
|
||||
@ -1135,7 +1099,7 @@
|
||||
}
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/43",
|
||||
"self_ref": "#/texts/41",
|
||||
"parent": {
|
||||
"$ref": "#/groups/11"
|
||||
},
|
||||
@ -1146,6 +1110,30 @@
|
||||
"orig": "",
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/42",
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "",
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/43",
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "",
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/44",
|
||||
"parent": {
|
||||
@ -1160,30 +1148,6 @@
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/45",
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "",
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/46",
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "",
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/47",
|
||||
"parent": {
|
||||
"$ref": "#/groups/13"
|
||||
},
|
||||
@ -1202,7 +1166,7 @@
|
||||
}
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/48",
|
||||
"self_ref": "#/texts/46",
|
||||
"parent": {
|
||||
"$ref": "#/groups/13"
|
||||
},
|
||||
@ -1214,7 +1178,7 @@
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/49",
|
||||
"self_ref": "#/texts/47",
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
@ -1226,7 +1190,7 @@
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/50",
|
||||
"self_ref": "#/texts/48",
|
||||
"parent": {
|
||||
"$ref": "#/groups/14"
|
||||
},
|
||||
@ -1245,7 +1209,7 @@
|
||||
}
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/51",
|
||||
"self_ref": "#/texts/49",
|
||||
"parent": {
|
||||
"$ref": "#/groups/14"
|
||||
},
|
||||
@ -1264,7 +1228,7 @@
|
||||
}
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/52",
|
||||
"self_ref": "#/texts/50",
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
@ -1275,6 +1239,37 @@
|
||||
"orig": "",
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/51",
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "",
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/52",
|
||||
"parent": {
|
||||
"$ref": "#/groups/15"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "Yes",
|
||||
"text": "Yes",
|
||||
"formatting": {
|
||||
"bold": false,
|
||||
"italic": false,
|
||||
"underline": false,
|
||||
"strikethrough": false,
|
||||
"script": "baseline"
|
||||
}
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/53",
|
||||
"parent": {
|
||||
@ -1290,7 +1285,7 @@
|
||||
{
|
||||
"self_ref": "#/texts/54",
|
||||
"parent": {
|
||||
"$ref": "#/groups/15"
|
||||
"$ref": "#/groups/16"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
@ -1321,48 +1316,17 @@
|
||||
{
|
||||
"self_ref": "#/texts/56",
|
||||
"parent": {
|
||||
"$ref": "#/groups/16"
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "Yes",
|
||||
"text": "Yes",
|
||||
"formatting": {
|
||||
"bold": false,
|
||||
"italic": false,
|
||||
"underline": false,
|
||||
"strikethrough": false,
|
||||
"script": "baseline"
|
||||
}
|
||||
"orig": "",
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/57",
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "",
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/58",
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "",
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/59",
|
||||
"parent": {
|
||||
"$ref": "#/groups/17"
|
||||
},
|
||||
@ -1381,7 +1345,7 @@
|
||||
}
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/60",
|
||||
"self_ref": "#/texts/58",
|
||||
"parent": {
|
||||
"$ref": "#/groups/17"
|
||||
},
|
||||
@ -1393,7 +1357,7 @@
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/61",
|
||||
"self_ref": "#/texts/59",
|
||||
"parent": {
|
||||
"$ref": "#/groups/17"
|
||||
},
|
||||
@ -1411,6 +1375,37 @@
|
||||
"script": "baseline"
|
||||
}
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/60",
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "",
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/61",
|
||||
"parent": {
|
||||
"$ref": "#/groups/18"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "No",
|
||||
"text": "No",
|
||||
"formatting": {
|
||||
"bold": false,
|
||||
"italic": false,
|
||||
"underline": false,
|
||||
"strikethrough": false,
|
||||
"script": "baseline"
|
||||
}
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/62",
|
||||
"parent": {
|
||||
@ -1426,21 +1421,14 @@
|
||||
{
|
||||
"self_ref": "#/texts/63",
|
||||
"parent": {
|
||||
"$ref": "#/groups/18"
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "No",
|
||||
"text": "No",
|
||||
"formatting": {
|
||||
"bold": false,
|
||||
"italic": false,
|
||||
"underline": false,
|
||||
"strikethrough": false,
|
||||
"script": "baseline"
|
||||
}
|
||||
"orig": "",
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/64",
|
||||
@ -1453,30 +1441,6 @@
|
||||
"prov": [],
|
||||
"orig": "",
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/65",
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "",
|
||||
"text": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/66",
|
||||
"parent": {
|
||||
"$ref": "#/body"
|
||||
},
|
||||
"children": [],
|
||||
"content_layer": "body",
|
||||
"label": "paragraph",
|
||||
"prov": [],
|
||||
"orig": "",
|
||||
"text": ""
|
||||
}
|
||||
],
|
||||
"pictures": [],
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "unit_test_01",
|
||||
"origin": {
|
||||
"mimetype": "text/html",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "unit_test_formatting",
|
||||
"origin": {
|
||||
"mimetype": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
|
||||
@ -429,7 +429,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/14",
|
||||
@ -450,7 +450,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/15",
|
||||
@ -471,7 +471,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/16",
|
||||
@ -489,7 +489,7 @@
|
||||
"orig": "",
|
||||
"text": "",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/17",
|
||||
@ -583,7 +583,7 @@
|
||||
"orig": "",
|
||||
"text": "",
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/22",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "unit_test_headers",
|
||||
"origin": {
|
||||
"mimetype": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "unit_test_headers_numbered",
|
||||
"origin": {
|
||||
"mimetype": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "unit_test_lists",
|
||||
"origin": {
|
||||
"mimetype": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
|
||||
@ -456,7 +456,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/9",
|
||||
@ -477,7 +477,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/10",
|
||||
@ -498,7 +498,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/11",
|
||||
@ -551,7 +551,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/14",
|
||||
@ -572,7 +572,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/15",
|
||||
@ -593,7 +593,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/16",
|
||||
@ -646,7 +646,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/19",
|
||||
@ -667,7 +667,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/20",
|
||||
@ -688,7 +688,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/21",
|
||||
@ -709,7 +709,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/22",
|
||||
@ -730,7 +730,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/23",
|
||||
@ -751,7 +751,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/24",
|
||||
@ -804,7 +804,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/27",
|
||||
@ -825,7 +825,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/28",
|
||||
@ -846,7 +846,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/29",
|
||||
@ -899,7 +899,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/32",
|
||||
@ -920,7 +920,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/33",
|
||||
@ -941,7 +941,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/34",
|
||||
@ -962,7 +962,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/35",
|
||||
@ -1021,7 +1021,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/38",
|
||||
@ -1042,7 +1042,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/39",
|
||||
@ -1063,7 +1063,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/40",
|
||||
@ -1084,7 +1084,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/41",
|
||||
@ -1105,7 +1105,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/42",
|
||||
@ -1126,7 +1126,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/43",
|
||||
|
@ -302,7 +302,7 @@ item-0 at level 0: unspecified: group _root_
|
||||
item-288 at level 4: list_item: Rubber duck
|
||||
item-289 at level 2: section_header: Notes
|
||||
item-290 at level 3: section_header: Citations
|
||||
item-291 at level 4: ordered_list: group ordered list
|
||||
item-291 at level 4: list: group ordered list
|
||||
item-292 at level 5: list_item: ^ "Duckling". The American Herit ... n Company. 2006. Retrieved 2015-05-22.
|
||||
item-293 at level 5: list_item: ^ "Duckling". Kernerman English ... Ltd. 2000–2006. Retrieved 2015-05-22.
|
||||
item-294 at level 5: list_item: ^ Dohner, Janet Vorwald (2001). ... University Press. ISBN 978-0300138139.
|
||||
|
File diff suppressed because it is too large
Load Diff
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "word_image_anchors",
|
||||
"origin": {
|
||||
"mimetype": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "word_sample",
|
||||
"origin": {
|
||||
"mimetype": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
|
||||
@ -243,7 +243,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/7",
|
||||
@ -264,7 +264,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/8",
|
||||
@ -285,7 +285,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/9",
|
||||
@ -325,7 +325,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/11",
|
||||
@ -346,7 +346,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/12",
|
||||
@ -367,7 +367,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/13",
|
||||
@ -530,7 +530,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/21",
|
||||
@ -551,7 +551,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
},
|
||||
{
|
||||
"self_ref": "#/texts/22",
|
||||
@ -572,7 +572,7 @@
|
||||
"script": "baseline"
|
||||
},
|
||||
"enumerated": false,
|
||||
"marker": "-"
|
||||
"marker": ""
|
||||
}
|
||||
],
|
||||
"pictures": [
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "word_tables",
|
||||
"origin": {
|
||||
"mimetype": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
|
||||
|
4
tests/data/html/example_01.html
vendored
4
tests/data/html/example_01.html
vendored
@ -13,5 +13,9 @@
|
||||
<li>First item in ordered list</li>
|
||||
<li>Second item in ordered list</li>
|
||||
</ol>
|
||||
<ol start="42">
|
||||
<li>First item in ordered list with start</li>
|
||||
<li>Second item in ordered list with start</li>
|
||||
</ol>
|
||||
</body>
|
||||
</html>
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "webp-test",
|
||||
"origin": {
|
||||
"mimetype": "application/pdf",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "ocr_test",
|
||||
"origin": {
|
||||
"mimetype": "application/pdf",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "ocr_test_rotated_180",
|
||||
"origin": {
|
||||
"mimetype": "application/pdf",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "ocr_test_rotated_270",
|
||||
"origin": {
|
||||
"mimetype": "application/pdf",
|
||||
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"schema_name": "DoclingDocument",
|
||||
"version": "1.4.0",
|
||||
"version": "1.5.0",
|
||||
"name": "ocr_test_rotated_90",
|
||||
"origin": {
|
||||
"mimetype": "application/pdf",
|
||||
|
@ -41,12 +41,12 @@ def test_e2e_pptx_conversions():
|
||||
doc: DoclingDocument = conv_result.document
|
||||
|
||||
pred_md: str = doc.export_to_markdown()
|
||||
assert verify_export(pred_md, str(gt_path) + ".md"), "export to md"
|
||||
assert verify_export(pred_md, str(gt_path) + ".md", GENERATE), "export to md"
|
||||
|
||||
pred_itxt: str = doc._export_to_indented_text(
|
||||
max_text_len=70, explicit_tables=False
|
||||
)
|
||||
assert verify_export(pred_itxt, str(gt_path) + ".itxt"), (
|
||||
assert verify_export(pred_itxt, str(gt_path) + ".itxt", GENERATE), (
|
||||
"export to indented-text"
|
||||
)
|
||||
|
||||
|
8
uv.lock
8
uv.lock
@ -912,7 +912,7 @@ requires-dist = [
|
||||
{ name = "accelerate", marker = "extra == 'vlm'", specifier = ">=1.2.1,<2.0.0" },
|
||||
{ name = "beautifulsoup4", specifier = ">=4.12.3,<5.0.0" },
|
||||
{ name = "certifi", specifier = ">=2024.7.4" },
|
||||
{ name = "docling-core", extras = ["chunking"], specifier = ">=2.29.0,<3.0.0" },
|
||||
{ name = "docling-core", extras = ["chunking"], specifier = ">=2.39.0,<3.0.0" },
|
||||
{ name = "docling-ibm-models", specifier = ">=3.4.4,<4.0.0" },
|
||||
{ name = "docling-parse", specifier = ">=4.0.0,<5.0.0" },
|
||||
{ name = "easyocr", specifier = ">=1.7,<2.0" },
|
||||
@ -987,7 +987,7 @@ examples = [
|
||||
|
||||
[[package]]
|
||||
name = "docling-core"
|
||||
version = "2.38.1"
|
||||
version = "2.39.0"
|
||||
source = { registry = "https://pypi.org/simple" }
|
||||
dependencies = [
|
||||
{ name = "jsonref" },
|
||||
@ -1001,9 +1001,9 @@ dependencies = [
|
||||
{ name = "typer" },
|
||||
{ name = "typing-extensions" },
|
||||
]
|
||||
sdist = { url = "https://files.pythonhosted.org/packages/38/f7/33bb17aa13e73722bf18ecfb7f13d6fbfb384c22003209bd72708123b33f/docling_core-2.38.1.tar.gz", hash = "sha256:a0566df2316eec4d22953ca7dac839b926dd57549b4c07ac810e87dbbaf91a10", size = 146276, upload-time = "2025-06-20T12:28:48.422Z" }
|
||||
sdist = { url = "https://files.pythonhosted.org/packages/6a/8b/5613467523bed58d9f2b94220947783914b6d9910a8d20908cf148805427/docling_core-2.39.0.tar.gz", hash = "sha256:77530156c79c9000fe3104894935437d3e2d46dc0f567b5a500974d7c1a8b38b", size = 148005, upload-time = "2025-06-27T12:59:56.694Z" }
|
||||
wheels = [
|
||||
{ url = "https://files.pythonhosted.org/packages/f0/c5/fb2e24602db94ec02cc3ac8eb7b9665f2a5f61ff81866beb67aff95a353a/docling_core-2.38.1-py3-none-any.whl", hash = "sha256:6859313561030503e8b53aec535aa5edb765a679af76ce2e2c60722d78c6c613", size = 151570, upload-time = "2025-06-20T12:28:46.764Z" },
|
||||
{ url = "https://files.pythonhosted.org/packages/70/85/3d59ac46a47f62a0ed79e187c4163cecd2693d05006f771038db4781f9ff/docling_core-2.39.0-py3-none-any.whl", hash = "sha256:b7ce5142ab95bd8d5cfe5d7df167a96a6eb41d884f00ea42bb3dd8f40ade92ea", size = 152890, upload-time = "2025-06-27T12:59:55.327Z" },
|
||||
]
|
||||
|
||||
[package.optional-dependencies]
|
||||
|
Loading…
Reference in New Issue
Block a user