mirror of
https://github.com/docling-project/docling.git
synced 2025-06-27 05:20:05 +00:00
chore: propagate docling-core fixes
Signed-off-by: Panos Vagenas <pva@zurich.ibm.com>
This commit is contained in:
Panos Vagenas
parent
de56523974
commit
99d8572f6d
36
poetry.lock
generated
36
poetry.lock
generated
@ -948,33 +948,37 @@ files = [
|
||||
|
||||
[[package]]
|
||||
name = "docling-core"
|
||||
version = "2.28.0"
|
||||
version = "2.28.1"
|
||||
description = "A python library to define and validate data types in Docling."
|
||||
optional = false
|
||||
python-versions = "<4.0,>=3.9"
|
||||
files = [
|
||||
{file = "docling_core-2.28.0-py3-none-any.whl", hash = "sha256:f1a01446996b90c4c151ec0ad247283888e6372f9dac0e356d06f8b9838ca4ca"},
|
||||
{file = "docling_core-2.28.0.tar.gz", hash = "sha256:16a762c251063839d7b20624cd6f89c2488872377f8546b037e604606014fb66"},
|
||||
]
|
||||
python-versions = "^3.9"
|
||||
files = []
|
||||
develop = false
|
||||
|
||||
[package.dependencies]
|
||||
jsonref = ">=1.1.0,<2.0.0"
|
||||
jsonschema = ">=4.16.0,<5.0.0"
|
||||
latex2mathml = ">=3.77.0,<4.0.0"
|
||||
pandas = ">=2.1.4,<3.0.0"
|
||||
jsonref = "^1.1.0"
|
||||
jsonschema = "^4.16.0"
|
||||
latex2mathml = "^3.77.0"
|
||||
pandas = "^2.1.4"
|
||||
pillow = ">=10.0.0,<12.0.0"
|
||||
pydantic = ">=2.6.0,<2.10.0 || >2.10.0,<2.10.1 || >2.10.1,<2.10.2 || >2.10.2,<3.0.0"
|
||||
pydantic = ">=2.6.0,<3.0.0,!=2.10.0,!=2.10.1,!=2.10.2"
|
||||
pyyaml = ">=5.1,<7.0.0"
|
||||
semchunk = {version = ">=2.2.0,<3.0.0", optional = true, markers = "extra == \"chunking\" or extra == \"chunking-openai\""}
|
||||
tabulate = ">=0.9.0,<0.10.0"
|
||||
transformers = {version = ">=4.34.0,<5.0.0", optional = true, markers = "extra == \"chunking\""}
|
||||
semchunk = {version = "^2.2.0", optional = true}
|
||||
tabulate = "^0.9.0"
|
||||
transformers = {version = "^4.34.0", optional = true}
|
||||
typer = ">=0.12.5,<0.16.0"
|
||||
typing-extensions = ">=4.12.2,<5.0.0"
|
||||
typing-extensions = "^4.12.2"
|
||||
|
||||
[package.extras]
|
||||
chunking = ["semchunk (>=2.2.0,<3.0.0)", "transformers (>=4.34.0,<5.0.0)"]
|
||||
chunking-openai = ["semchunk (>=2.2.0,<3.0.0)", "tiktoken (>=0.9.0,<0.10.0)"]
|
||||
|
||||
[package.source]
|
||||
type = "git"
|
||||
url = "https://github.com/docling-project/docling-core.git"
|
||||
reference = "8d79a0990cecbafe17802ae31878c539a150773e"
|
||||
resolved_reference = "8d79a0990cecbafe17802ae31878c539a150773e"
|
||||
|
||||
[[package]]
|
||||
name = "docling-ibm-models"
|
||||
version = "3.4.2"
|
||||
@ -8002,4 +8006,4 @@ vlm = ["accelerate", "transformers", "transformers"]
|
||||
[metadata]
|
||||
lock-version = "2.0"
|
||||
python-versions = "^3.9"
|
||||
content-hash = "9571b777eaeff16151ca2a54f6ebb0b986bb0cc112701199eb8eb98211523b08"
|
||||
content-hash = "06c05e0b47eed4e38dc8e2bbd8bf44a7e3b47519e3d32aca9022ece7922a076b"
|
||||
|
||||
@ -46,7 +46,7 @@ packages = [{ include = "docling" }]
|
||||
######################
|
||||
python = "^3.9"
|
||||
pydantic = "^2.0.0"
|
||||
docling-core = {version = "^2.26.0", extras = ["chunking"]}
|
||||
docling-core = { git = "https://github.com/docling-project/docling-core.git", extras = ["chunking"], rev = "8d79a0990cecbafe17802ae31878c539a150773e" }
|
||||
docling-ibm-models = "^3.4.0"
|
||||
docling-parse = "^4.0.0"
|
||||
filetype = "^1.2.0"
|
||||
|
||||
@ -23,6 +23,7 @@
|
||||
<location><page_1><loc_52><loc_37><loc_88><loc_45></location>
|
||||
<caption>Figure 1: Picture of a table with subtle, complex features such as (1) multi-column headers, (2) cell with multi-row text and (3) cells with no content. Image from PubTabNet evaluation set, filename: 'PMC2944238 004 02'.</caption>
|
||||
</figure>
|
||||
<caption><location><page_1><loc_50><loc_29><loc_89><loc_35></location>Figure 1: Picture of a table with subtle, complex features such as (1) multi-column headers, (2) cell with multi-row text and (3) cells with no content. Image from PubTabNet evaluation set, filename: 'PMC2944238 004 02'.</caption>
|
||||
<table>
|
||||
<location><page_1><loc_52><loc_37><loc_88><loc_45></location>
|
||||
<row_0><col_0><body>0</col_0><col_1><body>1 2 1</col_1><col_2><body>1 2 1</col_2><col_3><body>1 2 1</col_3><col_4><body>1 2 1</col_4></row_0>
|
||||
@ -57,6 +58,7 @@
|
||||
<location><page_3><loc_51><loc_68><loc_90><loc_90></location>
|
||||
<caption>Figure 2: Distribution of the tables across different table dimensions in PubTabNet + FinTabNet datasets</caption>
|
||||
</figure>
|
||||
<caption><location><page_3><loc_50><loc_64><loc_89><loc_66></location>Figure 2: Distribution of the tables across different table dimensions in PubTabNet + FinTabNet datasets</caption>
|
||||
<paragraph><location><page_3><loc_50><loc_59><loc_71><loc_60></location>balance in the previous datasets.</paragraph>
|
||||
<paragraph><location><page_3><loc_50><loc_21><loc_89><loc_58></location>The PubTabNet dataset contains 509k tables delivered as annotated PNG images. The annotations consist of the table structure represented in HTML format, the tokenized text and its bounding boxes per table cell. Fig. 1 shows the appearance style of PubTabNet. Depending on its complexity, a table is characterized as "simple" when it does not contain row spans or column spans, otherwise it is "complex". The dataset is divided into Train and Val splits (roughly 98% and 2%). The Train split consists of 54% simple and 46% complex tables and the Val split of 51% and 49% respectively. The FinTabNet dataset contains 112k tables delivered as single-page PDF documents with mixed table structures and text content. Similarly to the PubTabNet, the annotations of FinTabNet include the table structure in HTML, the tokenized text and the bounding boxes on a table cell basis. The dataset is divided into Train, Test and Val splits (81%, 9.5%, 9.5%), and each one is almost equally divided into simple and complex tables (Train: 48% simple, 52% complex, Test: 48% simple, 52% complex, Test: 53% simple, 47% complex). Finally the TableBank dataset consists of 145k tables provided as JPEG images. The latter has annotations for the table structure, but only few with bounding boxes of the table cells. The entire dataset consists of simple tables and it is divided into 90% Train, 3% Test and 7% Val splits.</paragraph>
|
||||
<paragraph><location><page_3><loc_50><loc_10><loc_89><loc_20></location>Due to the heterogeneity across the dataset formats, it was necessary to combine all available data into one homogenized dataset before we could train our models for practical purposes. Given the size of PubTabNet, we adopted its annotation format and we extracted and converted all tables as PNG images with a resolution of 72 dpi. Additionally, we have filtered out tables with extreme sizes due to small</paragraph>
|
||||
@ -88,10 +90,12 @@
|
||||
<location><page_5><loc_12><loc_77><loc_85><loc_90></location>
|
||||
<caption>Figure 3: TableFormer takes in an image of the PDF and creates bounding box and HTML structure predictions that are synchronized. The bounding boxes grabs the content from the PDF and inserts it in the structure.</caption>
|
||||
</figure>
|
||||
<caption><location><page_5><loc_8><loc_72><loc_89><loc_74></location>Figure 3: TableFormer takes in an image of the PDF and creates bounding box and HTML structure predictions that are synchronized. The bounding boxes grabs the content from the PDF and inserts it in the structure.</caption>
|
||||
<figure>
|
||||
<location><page_5><loc_9><loc_36><loc_47><loc_67></location>
|
||||
<caption>Figure 4: Given an input image of a table, the Encoder produces fixed-length features that represent the input image. The features are then passed to both the Structure Decoder and Cell BBox Decoder . During training, the Structure Decoder receives 'tokenized tags' of the HTML code that represent the table structure. Afterwards, a transformer encoder and decoder architecture is employed to produce features that are received by a linear layer, and the Cell BBox Decoder. The linear layer is applied to the features to predict the tags. Simultaneously, the Cell BBox Decoder selects features referring to the data cells (' < td > ', ' < ') and passes them through an attention network, an MLP, and a linear layer to predict the bounding boxes.</caption>
|
||||
</figure>
|
||||
<caption><location><page_5><loc_8><loc_14><loc_47><loc_33></location>Figure 4: Given an input image of a table, the Encoder produces fixed-length features that represent the input image. The features are then passed to both the Structure Decoder and Cell BBox Decoder . During training, the Structure Decoder receives 'tokenized tags' of the HTML code that represent the table structure. Afterwards, a transformer encoder and decoder architecture is employed to produce features that are received by a linear layer, and the Cell BBox Decoder. The linear layer is applied to the features to predict the tags. Simultaneously, the Cell BBox Decoder selects features referring to the data cells (' < td > ', ' < ') and passes them through an attention network, an MLP, and a linear layer to predict the bounding boxes.</caption>
|
||||
<paragraph><location><page_5><loc_50><loc_63><loc_89><loc_68></location>forming classification, and adding an adaptive pooling layer of size 28*28. ResNet by default downsamples the image resolution by 32 and then the encoded image is provided to both the Structure Decoder , and Cell BBox Decoder .</paragraph>
|
||||
<paragraph><location><page_5><loc_50><loc_48><loc_89><loc_62></location>Structure Decoder. The transformer architecture of this component is based on the work proposed in [31]. After extensive experimentation, the Structure Decoder is modeled as a transformer encoder with two encoder layers and a transformer decoder made from a stack of 4 decoder layers that comprise mainly of multi-head attention and feed forward layers. This configuration uses fewer layers and heads in comparison to networks applied to other problems (e.g. "Scene Understanding", "Image Captioning"), something which we relate to the simplicity of table images.</paragraph>
|
||||
<paragraph><location><page_5><loc_50><loc_31><loc_89><loc_47></location>The transformer encoder receives an encoded image from the CNN Backbone Network and refines it through a multi-head dot-product attention layer, followed by a Feed Forward Network. During training, the transformer decoder receives as input the output feature produced by the transformer encoder, and the tokenized input of the HTML ground-truth tags. Using a stack of multi-head attention layers, different aspects of the tag sequence could be inferred. This is achieved by each attention head on a layer operating in a different subspace, and then combining altogether their attention score.</paragraph>
|
||||
@ -167,6 +171,7 @@
|
||||
<location><page_8><loc_50><loc_77><loc_91><loc_88></location>
|
||||
<caption>b. Structure predicted by TableFormer, with superimposed matched PDF cell text:</caption>
|
||||
</figure>
|
||||
<caption><location><page_8><loc_9><loc_73><loc_63><loc_74></location>b. Structure predicted by TableFormer, with superimposed matched PDF cell text:</caption>
|
||||
<table>
|
||||
<location><page_8><loc_9><loc_63><loc_49><loc_72></location>
|
||||
<caption>Text is aligned to match original for ease of viewing</caption>
|
||||
@ -196,10 +201,12 @@
|
||||
<location><page_8><loc_8><loc_44><loc_35><loc_52></location>
|
||||
<caption>Figure 6: An example of TableFormer predictions (bounding boxes and structure) from generated SynthTabNet table.</caption>
|
||||
</figure>
|
||||
<caption><location><page_8><loc_10><loc_41><loc_87><loc_42></location>Figure 6: An example of TableFormer predictions (bounding boxes and structure) from generated SynthTabNet table.</caption>
|
||||
<figure>
|
||||
<location><page_8><loc_35><loc_44><loc_61><loc_52></location>
|
||||
<caption>Figure 5: One of the benefits of TableFormer is that it is language agnostic, as an example, the left part of the illustration demonstrates TableFormer predictions on previously unseen language (Japanese). Additionally, we see that TableFormer is robust to variability in style and content, right side of the illustration shows the example of the TableFormer prediction from the FinTabNet dataset.</caption>
|
||||
</figure>
|
||||
<caption><location><page_8><loc_8><loc_54><loc_89><loc_59></location>Figure 5: One of the benefits of TableFormer is that it is language agnostic, as an example, the left part of the illustration demonstrates TableFormer predictions on previously unseen language (Japanese). Additionally, we see that TableFormer is robust to variability in style and content, right side of the illustration shows the example of the TableFormer prediction from the FinTabNet dataset.</caption>
|
||||
<figure>
|
||||
<location><page_8><loc_63><loc_44><loc_89><loc_52></location>
|
||||
</figure>
|
||||
@ -269,6 +276,7 @@
|
||||
<location><page_12><loc_9><loc_81><loc_89><loc_91></location>
|
||||
<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_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>
|
||||
@ -373,6 +381,7 @@
|
||||
<location><page_14><loc_52><loc_55><loc_87><loc_89></location>
|
||||
<caption>Figure 13: Table predictions example on colorful table.</caption>
|
||||
</figure>
|
||||
<caption><location><page_14><loc_52><loc_52><loc_88><loc_53></location>Figure 13: Table predictions example on colorful table.</caption>
|
||||
<table>
|
||||
<location><page_14><loc_52><loc_40><loc_85><loc_46></location>
|
||||
<caption>Figure 14: Example with multi-line text.</caption>
|
||||
@ -433,4 +442,5 @@
|
||||
<location><page_16><loc_11><loc_37><loc_86><loc_68></location>
|
||||
<caption>Figure 17: Example of long table. End-to-end example from initial PDF cells to prediction of bounding boxes, post processing and prediction of structure.</caption>
|
||||
</figure>
|
||||
<caption><location><page_16><loc_8><loc_33><loc_89><loc_36></location>Figure 17: Example of long table. End-to-end example from initial PDF cells to prediction of bounding boxes, post processing and prediction of structure.</caption>
|
||||
</document>
|
||||
@ -365,6 +365,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/2"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
308.862,
|
||||
232.72709999999995,
|
||||
545.11517,
|
||||
277.49963
|
||||
],
|
||||
"page": 1,
|
||||
"span": [
|
||||
0,
|
||||
220
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 1: Picture of a table with subtle, complex features such as (1) multi-column headers, (2) cell with multi-row text and (3) cells with no content. Image from PubTabNet evaluation set, filename: 'PMC2944238 004 02'.",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"name": "Table",
|
||||
"type": "table",
|
||||
@ -904,6 +927,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/3"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
308.862,
|
||||
503.3020900000001,
|
||||
545.11511,
|
||||
524.16364
|
||||
],
|
||||
"page": 3,
|
||||
"span": [
|
||||
0,
|
||||
104
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 2: Distribution of the tables across different table dimensions in PubTabNet + FinTabNet datasets",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
@ -1282,11 +1328,57 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/4"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
50.111992,
|
||||
567.03308,
|
||||
545.10846,
|
||||
588.01422
|
||||
],
|
||||
"page": 5,
|
||||
"span": [
|
||||
0,
|
||||
212
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 3: TableFormer takes in an image of the PDF and creates bounding box and HTML structure predictions that are synchronized. The bounding boxes grabs the content from the PDF and inserts it in the structure.",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"name": "Picture",
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/5"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
50.112,
|
||||
111.72906,
|
||||
286.36597,
|
||||
264.2171900000001
|
||||
],
|
||||
"page": 5,
|
||||
"span": [
|
||||
0,
|
||||
745
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 4: Given an input image of a table, the Encoder produces fixed-length features that represent the input image. The features are then passed to both the Structure Decoder and Cell BBox Decoder . During training, the Structure Decoder receives 'tokenized tags' of the HTML code that represent the table structure. Afterwards, a transformer encoder and decoder architecture is employed to produce features that are received by a linear layer, and the Cell BBox Decoder. The linear layer is applied to the features to predict the tags. Simultaneously, the Cell BBox Decoder selects features referring to the data cells (' < td > ', ' < ') and passes them through an attention network, an MLP, and a linear layer to predict the bounding boxes.",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
@ -2214,6 +2306,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/7"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
53.811783000000005,
|
||||
575.89355,
|
||||
385.93451,
|
||||
583.76672
|
||||
],
|
||||
"page": 8,
|
||||
"span": [
|
||||
0,
|
||||
79
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "b. Structure predicted by TableFormer, with superimposed matched PDF cell text:",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"name": "Table",
|
||||
"type": "table",
|
||||
@ -2252,11 +2367,57 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/8"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
62.595001,
|
||||
324.36508,
|
||||
532.63049,
|
||||
333.27164
|
||||
],
|
||||
"page": 8,
|
||||
"span": [
|
||||
0,
|
||||
112
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 6: An example of TableFormer predictions (bounding boxes and structure) from generated SynthTabNet table.",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"name": "Picture",
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/9"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
50.112,
|
||||
426.35013,
|
||||
545.11377,
|
||||
471.12265
|
||||
],
|
||||
"page": 8,
|
||||
"span": [
|
||||
0,
|
||||
397
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 5: One of the benefits of TableFormer is that it is language agnostic, as an example, the left part of the illustration demonstrates TableFormer predictions on previously unseen language (Japanese). Additionally, we see that TableFormer is robust to variability in style and content, right side of the illustration shows the example of the TableFormer prediction from the FinTabNet dataset.",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"name": "Picture",
|
||||
"type": "figure",
|
||||
@ -3707,6 +3868,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/11"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
50.112,
|
||||
605.63605,
|
||||
545.11371,
|
||||
626.49762
|
||||
],
|
||||
"page": 12,
|
||||
"span": [
|
||||
0,
|
||||
245
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "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.",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
@ -4517,6 +4701,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/16"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
315.79001,
|
||||
411.40909,
|
||||
538.18524,
|
||||
420.31564
|
||||
],
|
||||
"page": 14,
|
||||
"span": [
|
||||
0,
|
||||
55
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 13: Table predictions example on colorful table.",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"name": "Table",
|
||||
"type": "table",
|
||||
@ -4675,6 +4882,29 @@
|
||||
"name": "Picture",
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/23"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
50.112,
|
||||
262.80108999999993,
|
||||
545.11383,
|
||||
283.66263
|
||||
],
|
||||
"page": 16,
|
||||
"span": [
|
||||
0,
|
||||
153
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 17: Example of long table. End-to-end example from initial PDF cells to prediction of bounding boxes, post processing and prediction of structure.",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
}
|
||||
],
|
||||
"figures": [
|
||||
|
||||
@ -18,6 +18,7 @@
|
||||
<location><page_1><loc_53><loc_34><loc_90><loc_68></location>
|
||||
<caption>Figure 1: Four examples of complex page layouts across different document categories</caption>
|
||||
</figure>
|
||||
<caption><location><page_1><loc_52><loc_29><loc_91><loc_32></location>Figure 1: Four examples of complex page layouts across different document categories</caption>
|
||||
<subtitle-level-1><location><page_1><loc_52><loc_24><loc_62><loc_25></location>KEYWORDS</subtitle-level-1>
|
||||
<paragraph><location><page_1><loc_52><loc_21><loc_91><loc_23></location>PDF document conversion, layout segmentation, object-detection, data set, Machine Learning</paragraph>
|
||||
<subtitle-level-1><location><page_1><loc_52><loc_18><loc_66><loc_19></location>ACM Reference Format:</subtitle-level-1>
|
||||
@ -44,6 +45,7 @@
|
||||
<location><page_3><loc_14><loc_72><loc_43><loc_88></location>
|
||||
<caption>Figure 2: Distribution of DocLayNet pages across document categories.</caption>
|
||||
</figure>
|
||||
<caption><location><page_3><loc_9><loc_68><loc_48><loc_70></location>Figure 2: Distribution of DocLayNet pages across document categories.</caption>
|
||||
<paragraph><location><page_3><loc_9><loc_54><loc_48><loc_64></location>to a minimum, since they introduce difficulties in annotation (see Section 4). As a second condition, we focussed on medium to large documents ( > 10 pages) with technical content, dense in complex tables, figures, plots and captions. Such documents carry a lot of information value, but are often hard to analyse with high accuracy due to their challenging layouts. Counterexamples of documents not included in the dataset are receipts, invoices, hand-written documents or photographs showing "text in the wild".</paragraph>
|
||||
<paragraph><location><page_3><loc_9><loc_36><loc_48><loc_53></location>The pages in DocLayNet can be grouped into six distinct categories, namely Financial Reports , Manuals , Scientific Articles , Laws & Regulations , Patents and Government Tenders . Each document category was sourced from various repositories. For example, Financial Reports contain both free-style format annual reports 2 which expose company-specific, artistic layouts as well as the more formal SEC filings. The two largest categories ( Financial Reports and Manuals ) contain a large amount of free-style layouts in order to obtain maximum variability. In the other four categories, we boosted the variability by mixing documents from independent providers, such as different government websites or publishers. In Figure 2, we show the document categories contained in DocLayNet with their respective sizes.</paragraph>
|
||||
<paragraph><location><page_3><loc_9><loc_23><loc_48><loc_35></location>We did not control the document selection with regard to language. The vast majority of documents contained in DocLayNet (close to 95%) are published in English language. However, DocLayNet also contains a number of documents in other languages such as German (2.5%), French (1.0%) and Japanese (1.0%). While the document language has negligible impact on the performance of computer vision methods such as object detection and segmentation models, it might prove challenging for layout analysis methods which exploit textual features.</paragraph>
|
||||
@ -76,6 +78,7 @@
|
||||
<location><page_4><loc_9><loc_32><loc_48><loc_61></location>
|
||||
<caption>Figure 3: Corpus Conversion Service annotation user interface. The PDF page is shown in the background, with overlaid text-cells (in darker shades). The annotation boxes can be drawn by dragging a rectangle over each segment with the respective label from the palette on the right.</caption>
|
||||
</figure>
|
||||
<caption><location><page_4><loc_9><loc_23><loc_48><loc_30></location>Figure 3: Corpus Conversion Service annotation user interface. The PDF page is shown in the background, with overlaid text-cells (in darker shades). The annotation boxes can be drawn by dragging a rectangle over each segment with the respective label from the palette on the right.</caption>
|
||||
<paragraph><location><page_4><loc_9><loc_15><loc_48><loc_20></location>we distributed the annotation workload and performed continuous quality controls. Phase one and two required a small team of experts only. For phases three and four, a group of 40 dedicated annotators were assembled and supervised.</paragraph>
|
||||
<paragraph><location><page_4><loc_9><loc_11><loc_48><loc_14></location><location><page_4><loc_9><loc_11><loc_48><loc_14></location>Phase 1: Data selection and preparation. Our inclusion criteria for documents were described in Section 3. A large effort went into ensuring that all documents are free to use. The data sources include publication repositories such as arXiv$^{3}$, government offices, company websites as well as data directory services for financial reports and patents. Scanned documents were excluded wherever possible because they can be rotated or skewed. This would not allow us to perform annotation with rectangular bounding-boxes and therefore complicate the annotation process.</paragraph>
|
||||
<paragraph><location><page_4><loc_52><loc_36><loc_91><loc_52></location>Preparation work included uploading and parsing the sourced PDF documents in the Corpus Conversion Service (CCS) [22], a cloud-native platform which provides a visual annotation interface and allows for dataset inspection and analysis. The annotation interface of CCS is shown in Figure 3. The desired balance of pages between the different document categories was achieved by selective subsampling of pages with certain desired properties. For example, we made sure to include the title page of each document and bias the remaining page selection to those with figures or tables. The latter was achieved by leveraging pre-trained object detection models from PubLayNet, which helped us estimate how many figures and tables a given page contains.</paragraph>
|
||||
@ -123,6 +126,7 @@
|
||||
<location><page_6><loc_53><loc_67><loc_90><loc_89></location>
|
||||
<caption>Figure 5: Prediction performance (mAP@0.5-0.95) of a Mask R-CNN network with ResNet50 backbone trained on increasing fractions of the DocLayNet dataset. The learning curve flattens around the 80% mark, indicating that increasing the size of the DocLayNet dataset with similar data will not yield significantly better predictions.</caption>
|
||||
</figure>
|
||||
<caption><location><page_6><loc_52><loc_57><loc_91><loc_65></location>Figure 5: Prediction performance (mAP@0.5-0.95) of a Mask R-CNN network with ResNet50 backbone trained on increasing fractions of the DocLayNet dataset. The learning curve flattens around the 80% mark, indicating that increasing the size of the DocLayNet dataset with similar data will not yield significantly better predictions.</caption>
|
||||
<paragraph><location><page_6><loc_52><loc_49><loc_91><loc_52></location>paper and leave the detailed evaluation of more recent methods mentioned in Section 2 for future work.</paragraph>
|
||||
<paragraph><location><page_6><loc_52><loc_39><loc_91><loc_49></location>In this section, we will present several aspects related to the performance of object detection models on DocLayNet. Similarly as in PubLayNet, we will evaluate the quality of their predictions using mean average precision (mAP) with 10 overlaps that range from 0.5 to 0.95 in steps of 0.05 (mAP@0.5-0.95). These scores are computed by leveraging the evaluation code provided by the COCO API [16].</paragraph>
|
||||
<subtitle-level-1><location><page_6><loc_52><loc_36><loc_76><loc_37></location>Baselines for Object Detection</subtitle-level-1>
|
||||
@ -216,6 +220,7 @@
|
||||
<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>
|
||||
</figure>
|
||||
<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>
|
||||
|
||||
@ -430,6 +430,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/0"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
317.95499,
|
||||
232.48476000000005,
|
||||
559.80579,
|
||||
251.91701
|
||||
],
|
||||
"page": 1,
|
||||
"span": [
|
||||
0,
|
||||
84
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 1: Four examples of complex page layouts across different document categories",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
@ -964,6 +987,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/1"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
53.79800000000001,
|
||||
536.45276,
|
||||
294.04373,
|
||||
555.88501
|
||||
],
|
||||
"page": 3,
|
||||
"span": [
|
||||
0,
|
||||
69
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 2: Distribution of DocLayNet pages across document categories.",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
@ -1227,6 +1273,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/2"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
53.79800000000001,
|
||||
185.68075999999996,
|
||||
295.64874,
|
||||
237.99000999999998
|
||||
],
|
||||
"page": 4,
|
||||
"span": [
|
||||
0,
|
||||
281
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 3: Corpus Conversion Service annotation user interface. The PDF page is shown in the background, with overlaid text-cells (in darker shades). The annotation boxes can be drawn by dragging a rectangle over each segment with the respective label from the palette on the right.",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
@ -1808,6 +1877,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/4"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
317.95499,
|
||||
449.71581999999995,
|
||||
559.80579,
|
||||
512.98401
|
||||
],
|
||||
"page": 6,
|
||||
"span": [
|
||||
0,
|
||||
329
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 5: Prediction performance (mAP@0.5-0.95) of a Mask R-CNN network with ResNet50 backbone trained on increasing fractions of the DocLayNet dataset. The learning curve flattens around the 80% mark, indicating that increasing the size of the DocLayNet dataset with similar data will not yield significantly better predictions.",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
@ -2702,6 +2794,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/5"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
62.323874999999994,
|
||||
343.73517,
|
||||
318.50473,
|
||||
349.71457
|
||||
],
|
||||
"page": 9,
|
||||
"span": [
|
||||
0,
|
||||
89
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Text Caption List-Item Formula Table Section-Header Picture Page-Header Page-Footer Title",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
|
||||
@ -13,6 +13,7 @@
|
||||
<location><page_2><loc_24><loc_46><loc_76><loc_74></location>
|
||||
<caption>Fig. 1. Comparison between HTML and OTSL table structure representation: (A) table-example with complex row and column headers, including a 2D empty span, (B) minimal graphical representation of table structure using rectangular layout, (C) HTML representation, (D) OTSL representation. This example demonstrates many of the key-features of OTSL, namely its reduced vocabulary size (12 versus 5 in this case), its reduced sequence length (55 versus 30) and a enhanced internal structure (variable token sequence length per row in HTML versus a fixed length of rows in OTSL).</caption>
|
||||
</figure>
|
||||
<caption><location><page_2><loc_22><loc_75><loc_79><loc_84></location>Fig. 1. Comparison between HTML and OTSL table structure representation: (A) table-example with complex row and column headers, including a 2D empty span, (B) minimal graphical representation of table structure using rectangular layout, (C) HTML representation, (D) OTSL representation. This example demonstrates many of the key-features of OTSL, namely its reduced vocabulary size (12 versus 5 in this case), its reduced sequence length (55 versus 30) and a enhanced internal structure (variable token sequence length per row in HTML versus a fixed length of rows in OTSL).</caption>
|
||||
<paragraph><location><page_2><loc_22><loc_34><loc_79><loc_43></location>today, table detection in documents is a well understood problem, and the latest state-of-the-art (SOTA) object detection methods provide an accuracy comparable to human observers [7,8,10,14,23]. On the other hand, the problem of table structure recognition (TSR) is a lot more challenging and remains a very active area of research, in which many novel machine learning algorithms are being explored [3,4,5,9,11,12,13,14,17,18,21,22].</paragraph>
|
||||
<paragraph><location><page_2><loc_22><loc_16><loc_79><loc_34></location>Recently emerging SOTA methods for table structure recognition employ transformer-based models, in which an image of the table is provided to the network in order to predict the structure of the table as a sequence of tokens. These image-to-sequence (Im2Seq) models are extremely powerful, since they allow for a purely data-driven solution. The tokens of the sequence typically belong to a markup language such as HTML, Latex or Markdown, which allow to describe table structure as rows, columns and spanning cells in various configurations. In Figure 1, we illustrate how HTML is used to represent the table-structure of a particular example table. Public table-structure data sets such as PubTabNet [22], and FinTabNet [21], which were created in a semi-automated way from paired PDF and HTML sources (e.g. PubMed Central), popularized primarily the use of HTML as ground-truth representation format for TSR.</paragraph>
|
||||
<paragraph><location><page_3><loc_22><loc_73><loc_79><loc_85></location>While the majority of research in TSR is currently focused on the development and application of novel neural model architectures, the table structure representation language (e.g. HTML in PubTabNet and FinTabNet) is usually adopted as is for the sequence tokenization in Im2Seq models. In this paper, we aim for the opposite and investigate the impact of the table structure representation language with an otherwise unmodified Im2Seq transformer-based architecture. Since the current state-of-the-art Im2Seq model is TableFormer [9], we select this model to perform our experiments.</paragraph>
|
||||
@ -30,6 +31,7 @@
|
||||
<location><page_5><loc_22><loc_57><loc_78><loc_71></location>
|
||||
<caption>Fig. 2. Frequency of tokens in HTML and OTSL as they appear in PubTabNet.</caption>
|
||||
</figure>
|
||||
<caption><location><page_5><loc_24><loc_71><loc_77><loc_72></location>Fig. 2. Frequency of tokens in HTML and OTSL as they appear in PubTabNet.</caption>
|
||||
<paragraph><location><page_5><loc_22><loc_33><loc_79><loc_54></location>Obviously, HTML and other general-purpose markup languages were not designed for Im2Seq models. As such, they have some serious drawbacks. First, the token vocabulary needs to be artificially large in order to describe all plausible tabular structures. Since most Im2Seq models use an autoregressive approach, they generate the sequence token by token. Therefore, to reduce inference time, a shorter sequence length is critical. Every table-cell is represented by at least two tokens ( <td> and </td> ). Furthermore, when tokenizing the HTML structure, one needs to explicitly enumerate possible column-spans and row-spans as words. In practice, this ends up requiring 28 different HTML tokens (when including column- and row-spans up to 10 cells) just to describe every table in the PubTabNet dataset. Clearly, not every token is equally represented, as is depicted in Figure 2. This skewed distribution of tokens in combination with variable token row-length makes it challenging for models to learn the HTML structure.</paragraph>
|
||||
<paragraph><location><page_5><loc_22><loc_27><loc_79><loc_32></location>Additionally, it would be desirable if the representation would easily allow an early detection of invalid sequences on-the-go, before the prediction of the entire table structure is completed. HTML is not well-suited for this purpose as the verification of incomplete sequences is non-trivial or even impossible.</paragraph>
|
||||
<paragraph><location><page_5><loc_22><loc_16><loc_79><loc_26></location>In a valid HTML table, the token sequence must describe a 2D grid of table cells, serialised in row-major ordering, where each row and each column have the same length (while considering row- and column-spans). Furthermore, every opening tag in HTML needs to be matched by a closing tag in a correct hierarchical manner. Since the number of tokens for each table row and column can vary significantly, especially for large tables with many row- and column-spans, it is complex to verify the consistency of predicted structures during sequence</paragraph>
|
||||
@ -50,6 +52,7 @@
|
||||
<location><page_7><loc_27><loc_65><loc_73><loc_79></location>
|
||||
<caption>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>
|
||||
</figure>
|
||||
<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>
|
||||
@ -70,6 +73,7 @@
|
||||
<location><page_8><loc_23><loc_25><loc_77><loc_36></location>
|
||||
<caption>Fig. 4. Architecture sketch of the TableFormer model, which is a representative for the Im2Seq approach.</caption>
|
||||
</figure>
|
||||
<caption><location><page_8><loc_22><loc_36><loc_79><loc_39></location>Fig. 4. Architecture sketch of the TableFormer model, which is a representative for the Im2Seq approach.</caption>
|
||||
<paragraph><location><page_8><loc_22><loc_16><loc_79><loc_22></location>We rely on standard metrics such as Tree Edit Distance score (TEDs) for table structure prediction, and Mean Average Precision (mAP) with 0.75 Intersection Over Union (IOU) threshold for the bounding-box predictions of table cells. The predicted OTSL structures were converted back to HTML format in</paragraph>
|
||||
<paragraph><location><page_9><loc_22><loc_81><loc_79><loc_85></location>order to compute the TED score. Inference timing results for all experiments were obtained from the same machine on a single core with AMD EPYC 7763 CPU @2.45 GHz.</paragraph>
|
||||
<subtitle-level-1><location><page_9><loc_22><loc_78><loc_52><loc_79></location>5.1 Hyper Parameter Optimization</subtitle-level-1>
|
||||
@ -104,12 +108,14 @@
|
||||
<location><page_10><loc_27><loc_16><loc_74><loc_44></location>
|
||||
<caption>Fig. 5. The OTSL model produces more accurate bounding boxes with less overlap (E) than the HTML model (D), when predicting the structure of a sparse table (A), at twice the inference speed because of shorter sequence length (B),(C). "PMC2807444_006_00.png" PubTabNet. μ</caption>
|
||||
</figure>
|
||||
<caption><location><page_10><loc_22><loc_44><loc_79><loc_50></location>Fig. 5. The OTSL model produces more accurate bounding boxes with less overlap (E) than the HTML model (D), when predicting the structure of a sparse table (A), at twice the inference speed because of shorter sequence length (B),(C). "PMC2807444_006_00.png" PubTabNet. μ</caption>
|
||||
<paragraph><location><page_10><loc_37><loc_15><loc_38><loc_16></location>μ</paragraph>
|
||||
<paragraph><location><page_10><loc_49><loc_12><loc_49><loc_14></location>≥</paragraph>
|
||||
<figure>
|
||||
<location><page_11><loc_28><loc_20><loc_73><loc_77></location>
|
||||
<caption>Fig. 6. Visualization of predicted structure and detected bounding boxes on a complex table with many rows. The OTSL model (B) captured repeating pattern of horizontally merged cells from the GT (A), unlike the HTML model (C). The HTML model also didn't complete the HTML sequence correctly and displayed a lot more of drift and overlap of bounding boxes. "PMC5406406_003_01.png" PubTabNet.</caption>
|
||||
</figure>
|
||||
<caption><location><page_11><loc_22><loc_78><loc_79><loc_84></location>Fig. 6. Visualization of predicted structure and detected bounding boxes on a complex table with many rows. The OTSL model (B) captured repeating pattern of horizontally merged cells from the GT (A), unlike the HTML model (C). The HTML model also didn't complete the HTML sequence correctly and displayed a lot more of drift and overlap of bounding boxes. "PMC5406406_003_01.png" PubTabNet.</caption>
|
||||
<subtitle-level-1><location><page_12><loc_22><loc_84><loc_36><loc_85></location>6 Conclusion</subtitle-level-1>
|
||||
<paragraph><location><page_12><loc_22><loc_74><loc_79><loc_81></location>We demonstrated that representing tables in HTML for the task of table structure recognition with Im2Seq models is ill-suited and has serious limitations. Furthermore, we presented in this paper an Optimized Table Structure Language (OTSL) which, when compared to commonly used general purpose languages, has several key benefits.</paragraph>
|
||||
<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>
|
||||
|
||||
@ -340,6 +340,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/0"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
134.765,
|
||||
591.77942,
|
||||
480.59189,
|
||||
665.66583
|
||||
],
|
||||
"page": 2,
|
||||
"span": [
|
||||
0,
|
||||
574
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Fig. 1. Comparison between HTML and OTSL table structure representation: (A) table-example with complex row and column headers, including a 2D empty span, (B) minimal graphical representation of table structure using rectangular layout, (C) HTML representation, (D) OTSL representation. This example demonstrates many of the key-features of OTSL, namely its reduced vocabulary size (12 versus 5 in this case), its reduced sequence length (55 versus 30) and a enhanced internal structure (variable token sequence length per row in HTML versus a fixed length of rows in OTSL).",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
@ -644,6 +667,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/1"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
145.60701,
|
||||
562.78821,
|
||||
469.75223000000005,
|
||||
570.92072
|
||||
],
|
||||
"page": 5,
|
||||
"span": [
|
||||
0,
|
||||
73
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Fig. 2. Frequency of tokens in HTML and OTSL as they appear in PubTabNet.",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
@ -1017,6 +1063,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/2"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
134.765,
|
||||
636.15033,
|
||||
480.5874,
|
||||
666.2008100000002
|
||||
],
|
||||
"page": 7,
|
||||
"span": [
|
||||
0,
|
||||
207
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "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",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
@ -1390,6 +1459,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/3"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
134.76501,
|
||||
288.26035,
|
||||
480.59082,
|
||||
307.35187
|
||||
],
|
||||
"page": 8,
|
||||
"span": [
|
||||
0,
|
||||
104
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Fig. 4. Architecture sketch of the TableFormer model, which is a representative for the Im2Seq approach.",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
@ -1658,6 +1750,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/4"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
134.765,
|
||||
352.28284,
|
||||
480.59106,
|
||||
394.40988
|
||||
],
|
||||
"page": 10,
|
||||
"span": [
|
||||
0,
|
||||
270
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Fig. 5. The OTSL model produces more accurate bounding boxes with less overlap (E) than the HTML model (D), when predicting the structure of a sparse table (A), at twice the inference speed because of shorter sequence length (B),(C). \"PMC2807444_006_00.png\" PubTabNet. \u03bc",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
@ -1709,6 +1824,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/5"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
134.765,
|
||||
614.23236,
|
||||
480.58838000000003,
|
||||
666.2008100000002
|
||||
],
|
||||
"page": 11,
|
||||
"span": [
|
||||
0,
|
||||
390
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Fig. 6. Visualization of predicted structure and detected bounding boxes on a complex table with many rows. The OTSL model (B) captured repeating pattern of horizontally merged cells from the GT (A), unlike the HTML model (C). The HTML model also didn't complete the HTML sequence correctly and displayed a lot more of drift and overlap of bounding boxes. \"PMC5406406_003_01.png\" PubTabNet.",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
|
||||
@ -10,6 +10,7 @@
|
||||
<location><page_1><loc_12><loc_10><loc_52><loc_31></location>
|
||||
<caption>Figure 7-26. Self-locking nuts.</caption>
|
||||
</figure>
|
||||
<caption><location><page_1><loc_12><loc_8><loc_31><loc_9></location>Figure 7-26. Self-locking nuts.</caption>
|
||||
<paragraph><location><page_1><loc_54><loc_85><loc_95><loc_94></location>the most common ranges in size for No. 6 up to 1 / 4 inch, the Rol-top ranges from 1 / 4 inch to 1 / 6 inch, and the bellows type ranges in size from No. 8 up to 3 / 8 inch. Wing-type nuts are made of anodized aluminum alloy, cadmium-plated carbon steel, or stainless steel. The Rol-top nut is cadmium-plated steel, and the bellows type is made of aluminum alloy only.</paragraph>
|
||||
<paragraph><location><page_1><loc_54><loc_83><loc_55><loc_85></location>.</paragraph>
|
||||
<subtitle-level-1><location><page_1><loc_54><loc_82><loc_76><loc_83></location>Stainless Steel Self-Locking Nut</subtitle-level-1>
|
||||
@ -20,4 +21,5 @@
|
||||
<location><page_1><loc_54><loc_11><loc_94><loc_46></location>
|
||||
<caption>Figure 7-27. Stainless steel self-locking nut.</caption>
|
||||
</figure>
|
||||
<caption><location><page_1><loc_54><loc_8><loc_81><loc_10></location>Figure 7-27. Stainless steel self-locking nut.</caption>
|
||||
</document>
|
||||
@ -206,6 +206,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/0"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
72.0,
|
||||
60.99040200000002,
|
||||
184.14828,
|
||||
71.80239900000004
|
||||
],
|
||||
"page": 1,
|
||||
"span": [
|
||||
0,
|
||||
31
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 7-26. Self-locking nuts.",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
@ -348,6 +371,29 @@
|
||||
"name": "Picture",
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/1"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
321.0,
|
||||
63.010403,
|
||||
481.64931999999993,
|
||||
73.82240300000001
|
||||
],
|
||||
"page": 1,
|
||||
"span": [
|
||||
0,
|
||||
46
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 7-27. Stainless steel self-locking nut.",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
}
|
||||
],
|
||||
"figures": [
|
||||
|
||||
@ -5,11 +5,13 @@
|
||||
<location><page_1><loc_22><loc_36><loc_78><loc_62></location>
|
||||
<caption>Figure 1: This is an example image.</caption>
|
||||
</figure>
|
||||
<caption><location><page_1><loc_37><loc_32><loc_63><loc_33></location>Figure 1: This is an example image.</caption>
|
||||
<paragraph><location><page_1><loc_22><loc_15><loc_78><loc_30></location>Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.</paragraph>
|
||||
<paragraph><location><page_2><loc_22><loc_66><loc_78><loc_84></location>Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.</paragraph>
|
||||
<figure>
|
||||
<location><page_2><loc_36><loc_36><loc_64><loc_65></location>
|
||||
<caption>Figure 2: This is an example image.</caption>
|
||||
</figure>
|
||||
<caption><location><page_2><loc_37><loc_33><loc_63><loc_34></location>Figure 2: This is an example image.</caption>
|
||||
<paragraph><location><page_2><loc_22><loc_15><loc_78><loc_31></location>Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum.</paragraph>
|
||||
</document>
|
||||
@ -96,6 +96,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/0"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
226.89101,
|
||||
254.01826000000005,
|
||||
384.3548,
|
||||
262.86505
|
||||
],
|
||||
"page": 1,
|
||||
"span": [
|
||||
0,
|
||||
35
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 1: This is an example image.",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
@ -147,6 +170,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/1"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
226.89101,
|
||||
259.94226000000003,
|
||||
384.3548,
|
||||
268.78903
|
||||
],
|
||||
"page": 2,
|
||||
"span": [
|
||||
0,
|
||||
35
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 2: This is an example image.",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
|
||||
@ -87,6 +87,7 @@
|
||||
<location><page_7><loc_22><loc_13><loc_89><loc_53></location>
|
||||
<caption>Figure 1-2 Existing row and column controls</caption>
|
||||
</figure>
|
||||
<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>
|
||||
@ -150,6 +151,7 @@
|
||||
<location><page_10><loc_22><loc_48><loc_89><loc_86></location>
|
||||
<caption>Figure 3-1 CREATE PERMISSION SQL statement</caption>
|
||||
</figure>
|
||||
<caption><location><page_10><loc_22><loc_47><loc_56><loc_48></location>Figure 3-1 CREATE PERMISSION SQL statement</caption>
|
||||
<subtitle-level-1><location><page_10><loc_22><loc_43><loc_35><loc_44></location>Column mask</subtitle-level-1>
|
||||
<paragraph><location><page_10><loc_22><loc_37><loc_89><loc_43></location>A column mask is a database object that manifests a column value access control rule for a specific column in a specific table. It uses a CASE expression that describes what you see when you access the column. For example, a teller can see only the last four digits of a tax identification number.</paragraph>
|
||||
<caption><location><page_11><loc_22><loc_90><loc_67><loc_91></location>Table 3-1 summarizes these special registers and their values.</caption>
|
||||
@ -172,6 +174,7 @@
|
||||
<location><page_11><loc_22><loc_25><loc_49><loc_51></location>
|
||||
<caption>Figure 3-5 Special registers and adopted authority</caption>
|
||||
</figure>
|
||||
<caption><location><page_11><loc_22><loc_24><loc_56><loc_25></location>Figure 3-5 Special registers and adopted authority</caption>
|
||||
<subtitle-level-1><location><page_11><loc_11><loc_20><loc_40><loc_21></location>3.2.2 Built-in global variables</subtitle-level-1>
|
||||
<paragraph><location><page_11><loc_22><loc_15><loc_85><loc_18></location>Built-in global variables are provided with the database manager and are used in SQL statements to retrieve scalar values that are associated with the variables.</paragraph>
|
||||
<paragraph><location><page_11><loc_22><loc_9><loc_87><loc_13></location>IBM DB2 for i supports nine different built-in global variables that are read only and maintained by the system. These global variables can be used to identify attributes of the database connection and used as part of the RCAC logic.</paragraph>
|
||||
@ -215,6 +218,7 @@
|
||||
<location><page_14><loc_10><loc_79><loc_89><loc_88></location>
|
||||
<caption>Figure 3-10 Column masks shown in System i Navigator</caption>
|
||||
</figure>
|
||||
<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>
|
||||
@ -230,16 +234,19 @@
|
||||
<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>
|
||||
<figure>
|
||||
<location><page_15><loc_22><loc_40><loc_89><loc_85></location>
|
||||
<caption>Figure 4-68 Visual Explain with RCAC enabled</caption>
|
||||
</figure>
|
||||
<caption><location><page_15><loc_22><loc_38><loc_53><loc_39></location>Figure 4-68 Visual Explain with RCAC enabled</caption>
|
||||
<figure>
|
||||
<location><page_15><loc_11><loc_16><loc_83><loc_30></location>
|
||||
<caption>Figure 4-69 Index advice with no RCAC</caption>
|
||||
</figure>
|
||||
<caption><location><page_15><loc_11><loc_15><loc_37><loc_16></location>Figure 4-69 Index advice with no RCAC</caption>
|
||||
<paragraph><location><page_16><loc_11><loc_11><loc_82><loc_91></location>THEN C . CUSTOMER_TAX_ID WHEN QSYS2 . VERIFY_GROUP_FOR_USER ( SESSION_USER , 'TELLER' ) = 1 THEN ( 'XXX-XX-' CONCAT QSYS2 . SUBSTR ( C . CUSTOMER_TAX_ID , 8 , 4 ) ) WHEN QSYS2 . VERIFY_GROUP_FOR_USER ( SESSION_USER , 'CUSTOMER' ) = 1 THEN C . CUSTOMER_TAX_ID ELSE 'XXX-XX-XXXX' END ENABLE ; CREATE MASK BANK_SCHEMA.MASK_DRIVERS_LICENSE_ON_CUSTOMERS ON BANK_SCHEMA.CUSTOMERS AS C FOR COLUMN CUSTOMER_DRIVERS_LICENSE_NUMBER RETURN CASE WHEN QSYS2 . VERIFY_GROUP_FOR_USER ( SESSION_USER , 'ADMIN' ) = 1 THEN C . CUSTOMER_DRIVERS_LICENSE_NUMBER WHEN QSYS2 . VERIFY_GROUP_FOR_USER ( SESSION_USER , 'TELLER' ) = 1 THEN C . CUSTOMER_DRIVERS_LICENSE_NUMBER WHEN QSYS2 . VERIFY_GROUP_FOR_USER ( SESSION_USER , 'CUSTOMER' ) = 1 THEN C . CUSTOMER_DRIVERS_LICENSE_NUMBER ELSE '*************' END ENABLE ; CREATE MASK BANK_SCHEMA.MASK_LOGIN_ID_ON_CUSTOMERS ON BANK_SCHEMA.CUSTOMERS AS C FOR COLUMN CUSTOMER_LOGIN_ID RETURN CASE WHEN QSYS2 . VERIFY_GROUP_FOR_USER ( SESSION_USER , 'ADMIN' ) = 1 THEN C . CUSTOMER_LOGIN_ID WHEN QSYS2 . VERIFY_GROUP_FOR_USER ( SESSION_USER , 'CUSTOMER' ) = 1 THEN C . CUSTOMER_LOGIN_ID ELSE '*****' END ENABLE ; CREATE MASK BANK_SCHEMA.MASK_SECURITY_QUESTION_ON_CUSTOMERS ON BANK_SCHEMA.CUSTOMERS AS C FOR COLUMN CUSTOMER_SECURITY_QUESTION RETURN CASE WHEN QSYS2 . VERIFY_GROUP_FOR_USER ( SESSION_USER , 'ADMIN' ) = 1 THEN C . CUSTOMER_SECURITY_QUESTION WHEN QSYS2 . VERIFY_GROUP_FOR_USER ( SESSION_USER , 'CUSTOMER' ) = 1 THEN C . CUSTOMER_SECURITY_QUESTION ELSE '*****' END ENABLE ; CREATE MASK BANK_SCHEMA.MASK_SECURITY_QUESTION_ANSWER_ON_CUSTOMERS ON BANK_SCHEMA.CUSTOMERS AS C FOR COLUMN CUSTOMER_SECURITY_QUESTION_ANSWER RETURN CASE WHEN QSYS2 . VERIFY_GROUP_FOR_USER ( SESSION_USER , 'ADMIN' ) = 1 THEN C . CUSTOMER_SECURITY_QUESTION_ANSWER WHEN QSYS2 . VERIFY_GROUP_FOR_USER ( SESSION_USER , 'CUSTOMER' ) = 1 THEN C . CUSTOMER_SECURITY_QUESTION_ANSWER ELSE '*****' END ENABLE ; ALTER TABLE BANK_SCHEMA.CUSTOMERS ACTIVATE ROW ACCESS CONTROL ACTIVATE COLUMN ACCESS CONTROL ;</paragraph>
|
||||
<paragraph><location><page_18><loc_47><loc_94><loc_68><loc_96></location>Back cover</paragraph>
|
||||
<subtitle-level-1><location><page_18><loc_4><loc_82><loc_73><loc_91></location>Row and Column Access Control Support in IBM DB2 for i</subtitle-level-1>
|
||||
|
||||
@ -1601,6 +1601,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/8"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
136.8,
|
||||
91.85700199999997,
|
||||
316.44727,
|
||||
100.18200000000002
|
||||
],
|
||||
"page": 7,
|
||||
"span": [
|
||||
0,
|
||||
43
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 1-2 Existing row and column controls",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
@ -2375,6 +2398,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/9"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
136.8,
|
||||
369.53699,
|
||||
341.97659,
|
||||
377.862
|
||||
],
|
||||
"page": 10,
|
||||
"span": [
|
||||
0,
|
||||
42
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 3-1 CREATE PERMISSION SQL statement",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
@ -2615,6 +2661,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/10"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
136.8,
|
||||
186.95709,
|
||||
341.25662,
|
||||
195.2821
|
||||
],
|
||||
"page": 11,
|
||||
"span": [
|
||||
0,
|
||||
50
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 3-5 Special registers and adopted authority",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
@ -3200,6 +3269,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/11"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
64.800003,
|
||||
610.13702,
|
||||
293.13809,
|
||||
618.46198
|
||||
],
|
||||
"page": 14,
|
||||
"span": [
|
||||
0,
|
||||
52
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 3-10 Column masks shown in System i Navigator",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
@ -3458,6 +3550,29 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/12"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
64.800003,
|
||||
134.63710000000003,
|
||||
347.43054,
|
||||
142.96210999999994
|
||||
],
|
||||
"page": 14,
|
||||
"span": [
|
||||
0,
|
||||
65
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 3-11 Selecting the EMPLOYEES table from System i Navigator",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
@ -3509,11 +3624,57 @@
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/13"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
136.8,
|
||||
303.117,
|
||||
327.09329,
|
||||
311.44202
|
||||
],
|
||||
"page": 15,
|
||||
"span": [
|
||||
0,
|
||||
44
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 4-68 Visual Explain with RCAC enabled",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"name": "Picture",
|
||||
"type": "figure",
|
||||
"$ref": "#/figures/14"
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
"bbox": [
|
||||
64.800003,
|
||||
116.15710000000001,
|
||||
227.10149,
|
||||
124.48209999999995
|
||||
],
|
||||
"page": 15,
|
||||
"span": [
|
||||
0,
|
||||
37
|
||||
],
|
||||
"__ref_s3_data": null
|
||||
}
|
||||
],
|
||||
"text": "Figure 4-69 Index advice with no RCAC",
|
||||
"type": "caption",
|
||||
"payload": null,
|
||||
"name": "Caption",
|
||||
"font": null
|
||||
},
|
||||
{
|
||||
"prov": [
|
||||
{
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user