Pith. sign in

REVIEW 2 major objections 5 minor 1 cited by

PatentLMM: Large Multimodal Model for Generating Descriptions for Patent Figures

T0 review · 2 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Pretraining a vision encoder on patent-figure structure—nodes, labels, arrows, text—boosts multimodal description quality by 10.22 average-BLEU points over the best fine-tuned baseline on brief descriptions, and 4.43 on detailed ones.

desk verdict The dataset is the real contribution; the headline gain over LLaVA-1.5 is mostly OCR input, not the patent-specific encoder. read the letter →

arxiv 2501.15074 v1 pith:6PH2NYGS submitted 2025-01-25 cs.CV cs.AI

Shreya Shukla , Nakul Sharma , Manish Gupta , Anand Mishra This is my paper · ORCID
classification cs.CVcs.AI
keywords patentfiguredescriptionmultimodallargelanguagemodeldocumentimageunderstandingcaptioningmaskedmodelingvisionencoderpretrainingDesc-355Ktechnicaldiagrams
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Patent figures carry their meaning in sparse visual syntax—labeled nodes, arrows, figure labels, and OCR-able text—so generic captioning models trained on natural images describe them poorly. This paper tries to establish that the fix is not just fine-tuning the whole multimodal system, but pretraining the vision encoder itself on patent-figure structure. It contributes PatentDesc-355K, 355K patent figures paired with brief and detailed descriptions from over 60K US patents, and PatentLMM, which pairs a patent-pretrained encoder (PatentMME) with a patent-adapted LLaMA-2 (PatentLLaMA). On the test set, PatentLMM beats the best fine-tuned baseline by 10.22 absolute average-BLEU points for brief descriptions and 4.43 points for detailed descriptions. Because the code and data are released, the claim can be verified and reused.

What carries the argument

The load-bearing mechanism is PatentMME's pretraining scheme, which teaches the encoder to read a patent figure as a diagram rather than as a photograph. Its layout-aware masked image modeling (LAMIM) masks only image patches that contain at least one of five diagram elements—nodes, node labels, figure labels, text, arrows—so the model reconstructs informative content instead of blank margin; its patch-classification (PC) head labels every patch with those element categories; and masked language modeling ties the visual patches to OCR text. The weak supervision for PC comes from a Faster-RCNN detector trained on 350 manually annotated figures and run over the 900K+ pretraining figures. The pretrained encoder is then frozen and its representations are projected into the patent-adapted LLM, so the downstream decoder only ever sees patent-aware visual features.

What would settle it

Take a held-out set of several hundred patent figures sampled across assignees and drawing styles, run the trained Faster-RCNN detector, and measure precision and recall per element class; if arrow or node-label recall is far below the reported AP@50 of 92.52, the weak labels feeding the patch-classification objective are too noisy to explain the BLEU gains.

Watch

Extended reading notes

Core claim

The central claim is that domain-specific vision-encoder pretraining, not just task fine-tuning, is what makes a large multimodal model describe patent figures competently. PatentMME starts from the LayoutLMv3 document transformer and is pretrained on over 900K patent figures with three objectives: masked language modeling over OCR tokens, layout-aware masked image modeling that masks only patches containing nodes, node labels, figure labels, text, or arrows, and patch classification that tags each patch with those five element categories. PatentLLaMA is LLaMA-2 7B adapted to patent prose on the HUPD corpus, and PatentLMM freezes PatentMME, projects its outputs through an MLP, and fine-tunes PatentLLaMA with LoRA adapters. The ablations attribute the gain to each piece: the patch-classification objective adds over a point of average BLEU on brief descriptions, removing OCR tokens at inference collapses average BLEU from 44.59 to 9.83, and swapping the patent-adapted LLaMA for vanilla LLaMA-2 costs about three points.

Load-bearing premise

The patch-classification objective assumes the Faster-RCNN detector trained on 350 manually annotated figures labels nodes, node labels, figure labels, text, and arrows accurately across the 900K+ pretraining figures; if that detector is noisy or biased, the measured benefit of patent-specific encoder pretraining weakens.

Editorial extensions

If this is right

  • Patent-figure description is automatable to a practical degree: on the test set the model reaches 44.59 average BLEU for brief descriptions and 24.24 for detailed descriptions, and a GPT-4V evaluation rated it above LLaVA-1.5 on relevance, accuracy, completeness, and coverage.
  • The recipe generalizes within the paper's own ablations: each pretraining objective and each component (OCR tokens, patent-adapted LLM, frozen patent encoder) contributes a measurable gain, so removing any one should produce a predictable drop.
  • OCR is not optional: without OCR tokens at inference, average BLEU for brief descriptions falls from 44.59 to 9.83, which means any competing system for this task must solve text extraction from figures.
  • PatentDesc-355K provides a patent-disjoint train/validation/test split, so future models can be compared on unseen patents rather than on overlapping figures.
  • The GPT-4V zero-shot performance (18.68 avg BLEU brief, 18.26 detailed) shows a large general model still lags a task-trained smaller model, supporting the need for domain-specialized training.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Editorial extension: the same triplet of objectives—mask informative patches, classify diagram elements, model OCR tokens—could transfer to other sparse technical drawings, such as circuit schematics, flowcharts, or architecture diagrams, where arrows and labels carry most of the semantics.
  • A testable next step the paper does not run: feed higher-resolution or selectively upsampled patches around arrows and node labels, since the paper's own error analysis blames downsampling for misread wiggly arrows and hallucinated node labels.
  • Because detailed ground truths average around 1,700 tokens but evaluation clips them to 500, current BLEU numbers may understate how well long descriptions are generated; an evaluation that scores full-length outputs could rank models differently.
  • If the weak-label detector from 350 annotations is the bottleneck, a self-supervised alternative—using OCR text and figure structure to generate element labels—could remove the manual-annotation dependence while keeping the PC objective.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 5 minor

Summary. The paper introduces PatentDesc-355K, a dataset of roughly 355K patent figures paired with brief and detailed textual descriptions extracted from over 60K US patent documents, and PatentLMM, a multimodal model that combines a patent-specific vision encoder (PatentMME) with a patent-domain-adapted LLaMA (PatentLLaMA). PatentMME is initialized from LayoutLMv3 and pretrained on 900K+ patent figures with masked language modeling, layout-aware masked image modeling, and patch classification objectives; PatentLLaMA is LLaMA-2 fine-tuned on HUPD patent text. The authors report that PatentLMM outperforms fine-tuned baselines such as LLaVA-1.5 by 10.22 absolute Avg. BLEU points for brief descriptions and 4.43 points for detailed descriptions on the held-out test set, and they provide ablations on the pretraining objectives and on the use of OCR tokens. The paper includes qualitative case studies and an error analysis.

Significance. The dataset is a substantial contribution: it is roughly an order of magnitude larger than the existing PatFig dataset, is released in public, and is evaluated with a patent-level train/test split. The internal ablations (Table 3) show that adding the proposed MLM+LAMIM+PC objectives to LayoutLMv3 improves Avg. BLEU from 40.86 to 44.59, and Table 6 shows the value of patent-domain LLM adaptation. The paper also provides honest error analysis and failure cases. However, the headline claim that 'training a vision encoder specifically designed for patent figures significantly boosts performance' is not yet isolated from the effect of OCR token input, because the main comparison in Table 2 does not give the off-the-shelf LMM access to OCR text. If the OCR confound is resolved, the work would be a solid contribution to technical document captioning.

major comments (2)
  1. [Section 5.3, Table 4, Table 2] The central claim that the patent-specific encoder is responsible for the 10.22-point Avg. BLEU gain over fine-tuned LLaVA-1.5 (Table 2) is confounded by OCR tokens. PatentMME consumes OCR text tokens jointly with image patches (Section 4.1), whereas LLaVA-1.5 receives only image patches. Table 4 shows that when OCR tokens are removed from both training and inference, PatentLMM's brief-description Avg. BLEU drops to 28.30, which is below LLaVA-1.5's 34.37. The paper should report a baseline that combines a similarly sized off-the-shelf LMM with the same OCR token stream (e.g., LLaVA-1.5 with OCR text fed as additional tokens) to separate the contribution of the OCR modality from the contribution of the patent-specific encoder pretraining.
  2. [Appendix A.2] Detailed-description evaluation is performed on descriptions clipped to 500 tokens, even though the average detailed description in PatentDesc-355K is about 1,680 tokens. This means the reported BLEU/ROUGE/METEOR scores for the detailed task measure only the first 500 tokens of the generated output, and the claim that PatentLMM generates 'comprehensive' detailed descriptions is not supported for full-length outputs. Please report metrics on full-length descriptions (with appropriate length-robust evaluation) or explicitly scope the detailed-description results to the 500-token prefix.
minor comments (5)
  1. [Section C.3 and C.1] There are typos: 'desctiption' should be 'description' in Section C.3, and 'Avg. Blue' should be 'Avg. BLEU' in Section C.1.
  2. [Section 4.1, Eq. (2)] In Eq. (2), 'where pi denotes the correct masked image patches' should refer to 'ri' to match the notation in the equation.
  3. [Introduction] The sentence 'Please refer to Fig. 3 in the Appendix' appears to point to the wrong figure; the overview of patent figure elements is given in the Appendix figures (e.g., Fig. 6 in Appendix B), not Fig. 3, which shows the PatentLMM architecture.
  4. [Section 5.3] The statement 'a boost of ~8% across all metrics' is vague; please specify whether this is absolute or relative and cite the exact values from Table 2.
  5. [Table 2 and Table 5] No confidence intervals or significance tests are reported for the main comparisons. Given the large test set, a significance test for the key differences would strengthen the claims.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the central gain is evaluated on held-out patent figures against external baselines, and the ablations isolate the pretraining objectives rather than renaming a fitted constant.

full rationale

The paper's central claim is that a patent-specific vision encoder (PatentMME) improves description generation over fine-tuning an off-the-shelf LMM. This is tested on a held-out test split of PatentDesc-355K (17,336 images from patents excluded from training) against external baselines including LLaVA-1.5, MiniGPT-4, GIT, BLIP, and OFA. The key controlled comparison is Table 3, where starting from pretrained LayoutLMv3 the same downstream PatentLMM pipeline is ablated over pretraining objectives (LayoutLMv3 only, +MLM+LAMIM, +MLM+LAMIM+PC), showing a +3.73 Avg. BLEU improvement that is attributable to the encoder pretraining. The PC pretraining uses weak labels from a Faster-RCNN detector trained on 350 manually annotated figures, but those labels are upstream pretraining signals, not test-set targets or evaluation constants, so no fitted parameter is later reported as a prediction. The dataset itself is constructed from patent HTML documents with rule-based extraction and quality-checked on 100 samples; metric computation uses standard BLEU/ROUGE/METEOR against ground-truth descriptions. The only notable design concern is that PatentLMM consumes OCR tokens jointly with image patches whereas LLaVA-1.5 is image-only, and Table 4 shows OCR tokens are responsible for a large part of the absolute gain; however, this is a confound in the headline comparison, not a circular derivation. The paper's self-citation (Shukla et al. 2023) appears only in related-work context and is not load-bearing for the claimed contribution. No step reduces to its own input by definition, and no self-citation chain forces the result.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The central claim rests on standard ML assumptions (generalization from training data), plus domain-specific assumptions about OCR quality and the reliability of the weak-label detector. There are no invented physical entities. The free parameters are training and evaluation choices, none of which are fitted to make the result appear stronger; the clipping length does affect the detailed-description comparison.

free parameters (3)
  • Mask ratios for MLM (30%) and LAMIM (40%) = 0.3 and 0.4 respectively
    Chosen by hand for the pretraining objectives; affect how much text and image content is masked and are not derived from data.
  • Detailed description clipping length = 500 tokens
    Used to cap all detailed descriptions for evaluation, even though the average detailed description is ~1,680 tokens; this choice affects all reported detailed metrics.
  • Number of manually annotated figures for the visual element detector = 350 train / 50 test
    Arbitrary annotation budget for the Faster-RCNN that generates weak labels for the PC loss; the paper does not analyze sensitivity to this number.
assumptions (4)
  • domain assumption Faster-RCNN trained on 350 annotated patent figures produces weak labels accurate enough for pretraining across 900K+ figures.
    Invoked in Section 4.1 to generate ground-truth labels for the PC objective.
  • domain assumption Tesseract OCR and PaddleOCR extract text and figure labels from patent figures with sufficient accuracy.
    OCR feeds the MLM tokens and the figure-label matching in dataset construction (Sections 4.1 and A.1).
  • domain assumption The automated HTML-parsing heuristic correctly attributes brief and detailed descriptions to figures.
    The dataset construction in Appendix A.1 assumes that description-line tags and figref tags align with the OCR-extracted figure labels; validated only on 100 samples.
  • domain assumption BLEU, ROUGE, and METEOR are valid proxies for the quality of patent figure descriptions.
    The paper uses these n-gram overlap metrics as the primary evidence of improvement without a human evaluation of the final outputs.

how reviews work

0 comments
Cite this review

Pith. "Pith review of PatentLMM: Large Multimodal Model for Generating Descriptions for Patent Figures." pith.science (2026). https://pith.science/paper/6PH2NYGS

@misc{pith2026250115074,
  author       = {Pith},
  title        = {Pith review of: PatentLMM: Large Multimodal Model for Generating Descriptions for Patent Figures},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6PH2NYGS}},
  note         = {Machine review of arXiv:2501.15074}
}
read the original abstract

Writing comprehensive and accurate descriptions of technical drawings in patent documents is crucial to effective knowledge sharing and enabling the replication and protection of intellectual property. However, automation of this task has been largely overlooked by the research community. To this end, we introduce PatentDesc-355K, a novel large-scale dataset containing ~355K patent figures along with their brief and detailed textual descriptions extracted from more than 60K US patent documents. In addition, we propose PatentLMM - a novel multimodal large language model specifically tailored to generate high-quality descriptions of patent figures. Our proposed PatentLMM comprises two key components: (i) PatentMME, a specialized multimodal vision encoder that captures the unique structural elements of patent figures, and (ii) PatentLLaMA, a domain-adapted version of LLaMA fine-tuned on a large collection of patents. Extensive experiments demonstrate that training a vision encoder specifically designed for patent figures significantly boosts the performance, generating coherent descriptions compared to fine-tuning similar-sized off-the-shelf multimodal models. PatentDesc-355K and PatentLMM pave the way for automating the understanding of patent figures, enabling efficient knowledge sharing and faster drafting of patent documents. We make the code and data publicly available.

Figures

Figures reproduced from arXiv: 2501.15074 by the authors.

Figure 1
Figure 1. An example of generated and ground truth brief and detailed descriptions using our proposed PA [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. PATENTMME Architecture. We jointly process OCR tokens and visual embeddings to produce multimodal context￾aware embeddings. These contextual embeddings are optimized using our proposed MLM, LA-MIM and PC objectives. between these diagrammatic constituents is paramount for decoding the inventive concepts and technical specifications elucidated within the patent figures. We, therefore, build on the existing document i… view at source ↗
Figure 3
Figure 3. PATENTLMM Architecture. Language Instruction is a fixed prompt guiding the model to generate either brief or detailed descriptions. the OCR text tokens and optimize the model to predict the masked tokens, encouraging it to learn patent-specific tex￾tual semantics. This loss is computed as follows: LMLM(θ) = − X i∈Tm log pθ(ti | Rum, Tum), (1) where ti denotes the correct masked text tokens. (ii) Layout-Aware Masked … view at source ↗
Figures from the paper (14 more)
Figure 4
Figure 4. Figure 4: PATENTDESC-355K Analysis. (a) and (c): Word clouds of most common occurrences in brief and detailed descrip￾tions respectively. (b) and (d): frequency distribution of description lengths for the brief and detailed descriptions respectively. Brief - FIG. 10 illustrates …
Figure 5
Figure 5. Figure 5: Samples from our PATENTDESC-355K dataset showing ⟨patent figure, brief description, detailed description⟩ triplets [PITH_FULL_IMAGE:figures/full_fig_p011_5.png]
Figure 6
Figure 6. Figure 6: Annotations of patent image elements obtained using our visual element detection model on a selection of test samples. [PITH_FULL_IMAGE:figures/full_fig_p012_6.png]
Figure 7
Figure 7. Figure 7: Case Study 1: An example of generated and ground truth brief and detailed descriptions using our proposed [PITH_FULL_IMAGE:figures/full_fig_p015_7.png]
Figure 8
Figure 8. Figure 8: Case Study 2: An example of generated and ground truth brief and detailed descriptions using our proposed [PITH_FULL_IMAGE:figures/full_fig_p015_8.png]
Figure 9
Figure 9. Figure 9: Case Study 3: An example of generated and ground truth brief and detailed descriptions using our proposed [PITH_FULL_IMAGE:figures/full_fig_p016_9.png]
Figure 10
Figure 10. Figure 10: Case Study 4: An example of generated and ground truth brief and detailed descriptions using our proposed [PITH_FULL_IMAGE:figures/full_fig_p016_10.png]
Figure 11
Figure 11. Figure 11: Case Study 5: An example of generated and ground truth brief and detailed descriptions using our proposed [PITH_FULL_IMAGE:figures/full_fig_p017_11.png]
Figure 12
Figure 12. Figure 12: Case Study 6: An example of generated and ground truth brief and detailed descriptions using our proposed [PITH_FULL_IMAGE:figures/full_fig_p017_12.png]
Figure 13
Figure 13. Figure 13: Case Study 7: An example of generated and ground truth brief and detailed descriptions using our proposed [PITH_FULL_IMAGE:figures/full_fig_p018_13.png]
Figure 14
Figure 14. Figure 14: Case Study 8: An example of generated and ground truth brief and detailed descriptions using our proposed [PITH_FULL_IMAGE:figures/full_fig_p018_14.png]
Figure 15
Figure 15. Figure 15: Failure Cases for the brief descriptions generated by PA [PITH_FULL_IMAGE:figures/full_fig_p020_15.png]
Figure 16
Figure 16. Figure 16: Failure Case for the detailed description generated by PA [PITH_FULL_IMAGE:figures/full_fig_p020_16.png]
Figure 17
Figure 17. Figure 17: Failure Case for the detailed description generated by PA [PITH_FULL_IMAGE:figures/full_fig_p021_17.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. FlowPlan-G2P: A Structured Generation Framework for Transforming Scientific Papers into Patent Descriptions

    cs.CL 2026-01 unverdicted novelty 6.0 of 10

    FlowPlan-G2P decomposes scientific paper to patent conversion into concept graph induction, section-level planning, and graph-conditioned generation, outperforming direct proprietary models under a domain-specific leg...

Reference graph

Works this paper leans on

19 extracted references · 16 canonical work pages · cited by 1 Pith paper

  1. [1]

    To rectify this automatically, we compared the average length of OCR tokens extracted using PaddleOCR (Du et al

    Correcting Image Orientation : We identified that ∼40% of the analysed images were vertically oriented. To rectify this automatically, we compared the average length of OCR tokens extracted using PaddleOCR (Du et al. 2021) for the original image and the 90 ◦-rotated image, and saved the image with greater average OCR length

    work page 2021

  2. [2]

    Redundancy Removal : We eliminated the first occur- rence of representative figure images, which were re- peated twice for each patent

    work page

  3. [3]

    To maintain a focus on singular representative visuals per image, we extract figure labels using PaddleOCR (Du et al

    Discarding Multi-Figure Images : Around 7% of the analysed images had multiple figures per image. To maintain a focus on singular representative visuals per image, we extract figure labels using PaddleOCR (Du et al. 2021). Then, we remove a small proportion of im- ages containing multiple occurrences of figure labels

    work page 2021

  4. [4]

    Prior works (Tang, Boggust, and Satyanarayan 2023; Mahin- pei, Kostic, and Tanner 2022; Masry et al

    Graph/Plot/Chart Removal : Around 5% images in our analysed data depicted graphical plots. Prior works (Tang, Boggust, and Satyanarayan 2023; Mahin- pei, Kostic, and Tanner 2022; Masry et al. 2022; Liu et al. 2023a) have studied their captioning in detail through specialized handling, so we discard these images by training a ResNet-50-based binary classif...

    work page 2023

  5. [5]

    brief” with “detailed

    Publication Date Filtering: We observed a specific con- vention in HTML tags for patents published after 2004. So, to ensure consistency in HTML tags for easier de- scription extraction, we discarded patents published be- fore 2005. This resulted in our final set of patents pub- lished from Jan 2005 to Jan 2023. After these image-based pre-processing step...

    work page 2004

  6. [6]

    MiniGPT-4: Enhancing Vision-Language Under- standing with Advanced Large Language Models. In ICLR. Appendix A P ATENT DESC -355K A.1 Dataset Curation To create a comprehensive dataset, we crawled a diverse set of over 90K US patent documents published between 1900 and January 2023. This involved searching for vari- ous companies on Google Patents and down...

    work page 1900

  7. [100]

    The rack management system 100 communicates with managed devices 170

    The rack management system 100 includes a device discovery module 140, a rack management module 160, a rack management communication interface 150, and a user interface module 130. The rack management system 100 communicates with managed devices 170. The managed devices 170 may include any number of managed devices 170-1, 170-2, 170-3, . . . , 170-N. The ...

    work page

  8. [110]

    Each seller system 130 is associated with one or more sellers

    The central manager 110 is communicatively coupled to the seller systems 130, the buyer groups 140, the buyer systems 145, and the non-seller systems 150. Each seller system 130 is associated with one or more sellers. Each buyer group 140 is associated with one or more buyers. Each buyer system 145 is associated with one or more buyers. Each non-seller sy...

    work page

Show all 19 references
  1. [120]

    For instance, the KPI definition component 134 can be associated with an enterprise and can provide KPI definition(s) that are specific to the enterprise

    It is to be appreciated that the KPI definition component 134 can be implemented as a component within the server 120, as a separate server, etc. For instance, the KPI definition component 134 can be associated with an enterprise and can provide KPI definition(s) that are spec...

  2. [216]

    As illustrated, computing device 1 is used by a user to select one or more objects to share with a network service, such as network service 250. The network service may be a social networking site, a blog, a web page hosted by a service, or some other network location.Spreadsh...

  3. [220]

    The web browser 222 may be a web browser such as Internet Explorer, Mozilla Firefox, Safari, or other similar web browser

    The sharing manager 26 may manage sharing of spreadsheet content using a web browser 222 and an application 224. The web browser 222 may be a web browser such as Internet Explorer, Mozilla Firefox, Safari, or other similar web browser. The application 224 may be a software app...

  4. [240]

    The computing device 2 220 may include a web browser 222 and an application 224

    The computing device 1 210 may include a spreadsheet application 212, a sharing manager 26, and a user interface 216. The computing device 2 220 may include a web browser 222 and an application 224. The sharing manager 26 may be a software application that may manage sharing o...

  5. [2019]

    Nocaps: Novel object captioning at scale. In ICCV. Alayrac, J.-B.; Donahue, J.; Luc, P.; Miech, A.; Barr, I.; Has- son, Y .; Lenc, K.; Mensch, A.; Millican, K.; Reynolds, M.; et al. 2022. Flamingo: a visual language model for few-shot learning. In NeurIPS. Anderson, P.; He, X....

    2022 arXiv

  6. [2020]

    In KDD, 1192–1200

    Layoutlm: Pre-training of text and layout for docu- ment image understanding. In KDD, 1192–1200. Xu, Y .; Xu, Y .; Lv, T.; Cui, L.; Wei, F.; Wang, G.; Lu, Y .; Flo- rencio, D.; Zhang, C.; Che, W.; et al. 2021. LayoutLMv2: Multi-modal Pre-training for Visually-rich Document Un-...

    2021 arXiv

  7. [2022]

    In ACL (Findings), 2263–2279

    ChartQA: A Benchmark for Question Answering about Charts with Visual and Logical Reasoning. In ACL (Findings), 2263–2279. Papineni, K.; Roukos, S.; Ward, T.; and Zhu, W.-J. 2002. BLEU: a method for automatic evaluation of machine trans- lation. In ACL. Ramesh, A.; Pavlov, M.; ...

    2002

  8. [2023]

    In ICDAR

    Towards Making Flowchart Images Machine Inter- pretable. In ICDAR. Sidorov, O.; Hu, R.; Rohrbach, M.; and Singh, A. 2020. Textcaps: a dataset for image captioning with reading com- prehension. In ECCV. Suzgun, M.; Melas-Kyriazi, L.; Sarkar, S.; Kominers, S. D.; and Shieber, S....

    2020 arXiv

  9. [2024]

    LayoutLLM: Layout Instruction Tuning with Large Language Models for Document Understanding. In CVPR. Mahinpei, A.; Kostic, Z.; and Tanner, C. 2022. Linecap: Line charts for data visualization captioning models. In Vi- sualization and Visual Analytics (VIS). Masry, A.; Do, X. L...

    2022

  10. [2725]

    The application displays an entire list of the open orders window in the master trade screen

    Step 3415. The application displays an entire list of the open orders window in the master trade screen. Step 3420. The user can then scroll through the open order list and can focus on a particular open order. The user can also select the open orders function from function ba...

  11. [3440]

    Step 3445

    The user selects the desired open order from the list displayed in the open orders window. Step 3445. The user selects an operation from the open orders window. The application automatically cancels, changes, or deletes the selected open order. Step 3450. The application popul...

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.