A report template automatic generation method and system based on multi-stage semantic understanding

Abstract

This invention relates to the field of report design and data processing technology, specifically a method and system for automatically generating report templates based on multi-stage semantic understanding. The method includes: generating a physical layout intermediate representation with percentage coordinates; constructing layout-aware prompts to guide a large language model to perform joint reasoning combining spatial relationships, visual styles, and linguistic semantics, identifying and matching label / field roles, and outputting a semantic layout intermediate representation; converting the semantic layout into a JRXML file that strictly follows the JasperReportsXML schema definition order based on coordinate mapping rules and a component mapping table; performing static compilation checks and repairs on the generated JRXML using an LLM; and establishing an LLM self-repairing closed loop with Jasper compiler errors as feedback, until a successfully compileable template is generated. This invention achieves end-to-end automated conversion from static PDFs to dynamic Jasper templates, significantly improving the efficiency and accuracy of report template development.

Description

Technical Field

[0001] This invention relates to the field of report design and data processing technology, and in particular to a method and system for automatically generating report templates based on multi-stage semantic understanding. Background Technology

[0002] In enterprise information systems, JasperReports (an open-source reporting library based on Java, primarily used to generate dynamic reports that can be embedded in applications) is a widely used open-source reporting engine. Its template files (JRXML, an XML format file) allow developers to define rich layouts and data binding logic. However, manually creating or replicating JasperReports templates from PDF layout sketches or historical PDF reports provided by business departments is a time-consuming, tedious, and error-prone task. It requires developers to have in-depth knowledge of syntax (such as strict XML schema definition (XSD) order, band mechanism, coordinate system) and accurate layout restoration capabilities.

[0003] The existing technology has the following main shortcomings: Optical Character Recognition (OCR) + Manual Processing: General OCR technology can only extract text, completely losing vector graphics (such as table lines and borders) and accurate layout information (such as alignment and spatial position) in PDFs. It still needs to be redrawn manually in the JasperReports designer, which is inefficient.

[0004] Simple format conversion tools: Some tools attempt to convert PDFs to Hypertext Markup Language (HTML) or images, but fail to generate JRXML files that conform to JasperReports strict syntax (XSD) and compilation requirements. In particular, they cannot handle core issues such as field binding, striped layout, and vector path conversion.

[0005] Traditional rule matching: Text matching methods based on fixed rules cannot adapt to PDF reports with different styles and layouts, have poor generalization ability, and have low accuracy in recognizing complex tables and label-field pairing relationships.

[0006] Therefore, there is an urgent need for a technical solution that can intelligently understand the semantics of PDF layouts and automatically generate high-fidelity JasperReports templates that can be directly compiled. Summary of the Invention

[0007] This invention proposes a method and system for automatically generating report templates based on multi-stage semantic understanding, aiming to solve the technical problem that existing general OCR technologies can only extract text, completely losing vector graphics (such as table lines and borders) and accurate layout information in PDFs.

[0008] In a first aspect, the present invention provides a method for automatically generating report templates based on multi-stage semantic understanding, including: S1, performing type detection and structured parsing on the input portable document format report file, extracting text blocks, graphic paths and their original coordinates, converting the coordinate system into a percentage coordinate system based on page size, and generating an intermediate representation of the physical layout; S2, compress the physical layout intermediate representation, construct layout-aware prompts and input them into the large language model LLM; the large language model combines the spatial relationship, visual style and language semantics of the text to perform role recognition and semantic annotation on the text blocks, and generate a semantic layout intermediate representation containing tags, fields and table structures. S3. Based on the preset component mapping rules and coordinate conversion formula, the elements in the semantic layout intermediate representation are mapped to the corresponding JasperReports components, and JRXML files are generated in strict order as defined by the JasperReportsXML schema. S4, the JRXML file is input into an LLM-driven repair module, which checks and repairs the JRXML file for document structure description XSD order compliance, page height constraints, font extension specifications and coordinate consistency, and outputs the corrected JRXML file; S5. Compile the corrected JRXML file. If compilation fails, input the compilation error log and the current JRXML file into the LLM driver's repair module for targeted repair. Iterate until compilation succeeds, and output the final compilable JasperReports report template. The technical effect of the automatic report template generation method based on multi-stage semantic understanding disclosed in this invention is as follows: through multi-stage collaborative processing, especially by introducing LLM for layout semantic understanding and compilation closed-loop self-repair, end-to-end fully automatic conversion from unstructured PDF to compileable and data-binding JasperReports templates is realized, which greatly improves the efficiency and reliability of report template development.

[0009] Furthermore, the type detection and structured parsing in S1 specifically include: S11 performs type detection on PDF pages based on three-dimensional features of text layer density, image density, and layout complexity, and routes the pages to different parsing strategies according to the detection results. S12 uses the PyMuPDF parsing engine to not only extract text blocks, but also parse the drawing path commands in the PDF, converting the path commands into standard line and rectangular geometric primitives; S13, repair the degraded path by filling the path with a height or width close to zero into a horizontal or vertical line; S14 converts the original coordinates from point units in the PDF, with the bottom left corner as the origin, to a percentage of the page width and height, with the top left corner as the origin.

[0010] Furthermore, in step S2, the layout-aware prompt words encode each element into an element identifier, font size, and a compressed format of text content. The large language model outputs structured JavaScript object representation data, which includes the identifier, role, and semantic name of each element, as well as the identifier reference of the tag element bound to the field element.

[0011] Furthermore, the coordinate conversion formula in S3 is: C pt =Size×C percent / 100; Among them, C pt Here are the component coordinates, Size is the page size, and C... percent These are percentage coordinates for the component, with the origin of these percentage coordinates being the top left corner of the page.

[0012] Furthermore, S3 also includes the process of converting graphic paths in the PDF into JasperReports components: for rectangular paths, they are decomposed into four independent straight line components; for multi-segment polyline paths, they are decomposed into a series of straight line components connected end to end.

[0013] Furthermore, in S4, the large language model-driven repair module is forced to perform repairs in the following priority order: first, repair the XSD order and missing nodes; second, repair the band height and page constraints; then, repair the font extension configuration; and finally, fine-tune the coordinate out-of-bounds and element overlap.

[0014] Furthermore, the LLM-driven repair module in S5 performs targeted repairs based on specific compilation error types. The correspondence between error types and repair strategies includes: field not found error corresponds to completing or adjusting the field declaration order; font not found error corresponds to modifying the font name to a specified extended font; and band height overflow error corresponds to shrinking the band height or adjusting the element coordinates.

[0015] Furthermore, after step S3, a data generation step is also included: based on the field definitions in the generated JRXML file and combined with the field semantics in the semantic layout intermediate representation, a JavaScript object representation data file containing reasonable example values ​​is automatically generated to verify the data binding function of the template.

[0016] Secondly, the present invention provides an automatic report template generation system based on multi-stage semantic understanding, the system being used to implement the method, the system comprising: The physical layout parsing module is used to perform type detection and structured parsing on the input portable document format report file, extract the text blocks, graphic paths and their original coordinates, convert the coordinate system into a percentage coordinate system based on the page size, and generate an intermediate physical layout representation. The semantic understanding and annotation module is used to compress the physical layout intermediate representation and construct layout-aware prompts for input into the large language model (LLM). The large language model combines the spatial relationships, visual styles and linguistic semantics of the text to perform role recognition and semantic annotation on the text blocks, generating a semantic layout intermediate representation containing tags, fields and table structures. The Jasper template generation module is used to map the elements in the semantic layout intermediate representation to the corresponding JasperReports components according to the preset component mapping rules and coordinate conversion formulas, and generate JRXML files in strict order as defined by the JasperReportsXML schema. The static inspection and repair module is used to input the JRXML file into an LLM-driven repair module. This module checks and repairs the JRXML file for compliance with document structure description XSD order, page height constraints, font extension specifications, and coordinate consistency, and outputs a corrected JRXML file. The dynamic compilation self-repair closed-loop module is used to compile the corrected JRXML file. If the compilation fails, the compilation error log and the current JRXML file are input into the LLM driver's repair module again for targeted repair. The process is iterated until the compilation is successful, and the final compilable JasperReports report template is output.

[0017] The technical effect of the system disclosed in this invention is that it constructs an automated system that integrates PDF physical parsing, LLM semantic understanding, Jasper template generation, static inspection and dynamic repair, which can intelligently and with high fidelity convert static report PDFs into dynamic business report templates that can be directly used.

[0018] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method. By embedding the above-mentioned innovative method into a computer-readable storage medium, this invention enables convenient deployment and operation on any computing device with processing capabilities, thereby achieving the widespread promotion and standardized application of automated report template generation technology. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating an automatic report template generation method based on multi-stage semantic understanding proposed in an embodiment of the present invention. Figure 2 A schematic diagram of the semantic understanding stage provided in this embodiment of the invention; Figure 3 This is a schematic diagram of the self-healing closed-loop process provided in an embodiment of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Addressing the technical problem mentioned in the background section that general OCR technologies can only extract text, completely losing vector graphics (such as table lines and borders) and accurate layout information in PDFs, this invention aims to overcome the shortcomings of existing technologies by providing a method for automatically generating report templates based on multi-stage semantic understanding. This method achieves end-to-end, automated, and high-fidelity conversion from static PDFs to dynamic JasperReports templates. (References) Figures 1 to 3 As shown, the specific steps include: The first stage, PDF recognition and structured parsing, involves detecting PDF types (such as scanned documents and complex layouts) through multi-feature fusion and employing the PyMuPDF deep parsing engine to extract text blocks and vector graphics paths (such as lines and rectangles). Through degenerate path repair and coordinate normalization (converting to page-based percentage coordinates with the top-left origin), an intermediate representation (LayoutIR) accurately describing the PDF's physical layout is generated.

[0022] The input is a PDF file. First, PDF type detection is performed. The system calculates three features: the number of characters in the page's `get_text()` function (text layer density), the ratio of the number of `get_images()` functions to the page area (image density), and the entropy of the spatial distribution of text blocks (layout complexity). Based on threshold logic, the PDF is routed to different parsing strategies: if there are images but no text, optical character recognition (OCR) is prioritized; if the complexity is high or there is a suspected table, enhanced parsing is used.

[0023] For pages routed to OCR (i.e., scanned images or plain images), the system not only performs OCR to extract text but also simultaneously launches an image recognition module. This module employs computer vision techniques, such as Canny edge detection, Hough transform, and Line Segment Detection (LSD), to detect lines, rectangles, and table borders from the image. For detected lines, its start and end coordinates are calculated; for rectangles, its four corner points are recorded; for table structures, cell regions are further identified by analyzing line intersections to construct the table's grid layout. All detected graphic elements are converted into vector path representations and merged with the text blocks extracted by OCR. Subsequently, these elements also undergo degenerate path repair and coordinate normalization (converted to a percentage coordinate system with the top-left origin) to generate a physical layout intermediate representation consistent with PDF parsing. Thus, whether it's a native PDF or a scanned image, the system can obtain accurate physical layout information, laying the foundation for subsequent semantic understanding.

[0024] For native PDFs or complex page layouts, the core is PyMuPDF enhanced parsing. Unlike ordinary text extraction, this system calls the underlying API to obtain the sequence of drawing commands (such as 'm' for movement, 'l' for drawing lines, 're' for rectangles, and 'c' for curves) in the page. The system is designed with a parser to recognize these commands: the 're' command is directly recognized as a rectangle; a sequence consisting of 'm', three 'l' commands, and 'h' (closed) is also recognized as a rectangle; consecutive 'm' and 'l' commands are recognized as polylines. For each recognized graphic, its bounding box (bbox) is calculated.

[0025] Next, degenerate path repair is performed. For paths with a bbox width or height less than a threshold (e.g., 0.5pt), the system repairs them as straight lines: if the width is close to zero, it is considered a vertical line (x1=x2), and if the height is close to zero, it is considered a horizontal line (y1=y2).

[0026] Finally, coordinate standardization is performed. The original PDF coordinates have the origin at the bottom left corner (Y-axis upwards) and the unit is points (pt). The system uniformly converts them to a percentage coordinate system with the origin at the top left corner (Y-axis downwards). This is to align with the JasperReports coordinate system and achieve scaling independence. The conversion formula is: C pt =Size×C percent / 100; where C pt Here are the component coordinates, Size is the page size, and C... percentThe percentage coordinates for each component are provided, with the origin of these percentage coordinates being the top-left corner of the page. The output is structured JSON (physical layout representation), containing information such as the type of each element, its bounding box percentage coordinates, text content, and font. Technical benefits: This stage solves the problem of accurately extracting complete layout information, including vector graphics, from PDFs, providing a "physical truth" foundation for subsequent semantic understanding, especially by preserving the geometric information of table lines, which is impossible with traditional OCR solutions.

[0027] The second stage, LLM semantic understanding and annotation, compresses the physical layout intermediate representation from the first stage into a "coordinate-text" sequence, constructing layout-aware prompts. Leveraging the powerful multimodal (spatial, visual, textual) reasoning capabilities of Large Language Models (LLM), it identifies the business roles (Labels or Fields) of text blocks, performs Label-Field pairing, and recognizes structures such as tables and groupings, outputting a semantic layout intermediate representation (SemanticLayoutIR). The specific process is as follows: The input is the physical layout intermediate representation in JSON format for the first stage. The system first performs layout compression on the physical layout intermediate representation, converting each element into a single line containing coordinates, styles, and content. For example, a text tag block located in the upper left corner of the page with the content "Invoice Number" might be compressed into the following format: [L001](5.2,3.1)-(15.8,4.5)11pt Invoice Number. This format allows the LLM to intuitively perceive the spatial relationships between elements.

[0028] Then, construct layout-aware prompts for input into the LLM. These prompts explicitly require the LLM to reason using three types of evidence: 1) Spatial relationship evidence: such as labels typically being to the left of fields, headers above data, and vertical alignment of elements within columns. 2) Visual style evidence: such as bold text or large fonts potentially indicating titles or labels. 3) Linguistic semantic evidence: understanding the meaning of business terms such as "number" and "total."

[0029] LLM is constrained to output structured JSON. For each text element, its role (LABEL or FIELD) and semantic name (e.g., invoice_no_label, invoice_no) must be labeled. For FIELD, the identifier (id) of its associated LABEL must also be specified through the boundTo field. LLM also needs to identify table areas and output a matrix of element IDs corresponding to the header row and table data rows.

[0030] The output is a semantic layout intermediate representation, which adds business semantic roles and relationships to each element based on the physical layout. Technical effect: This stage leverages the powerful reasoning capabilities of LLM to transform meaningless coordinate text blocks into report models (Labels / Fields / Tables) with business meaning, achieving a leap from "physical layout" to "semantic layout," which is the core prerequisite for generating data-binding templates. Its accuracy far exceeds that of matching methods based on fixed rules.

[0031] The third stage involves Jasper template generation: establishing semantic elements to the JasperReports component (such as...). <statictext> , <textfield> , <line>The mapping rules are as follows: Percentage coordinates are deterministically converted to Jasper point (pt) coordinates, and the PDF path is broken down into Jasper lines. All elements are arranged strictly according to the order defined in JasperReportsXSD. <title> The band (for absolute positioning) generates the initial JRXML file.< / title>

[0032] The input is the semantic layout intermediate representation of the second stage. The core of this stage is mapping and transformation.

[0033] First, perform a reverse coordinate conversion. Convert the percentage coordinates back to the point (pt) coordinates required by Jasper. Since the origin of the percentage coordinate system used in the second stage is already at the top left corner, and the Y-axis is downward, the conversion formula is direct and consistent: x_pt = page_width_pt x_percent / 100;y_pt=page_height_pt y_percent / 100. The width and height conversions are similar. This ensures that the generated element positions correspond precisely to their original positions in the PDF.

[0034] Next, perform component mapping. Based on the preset mapping table: role=LABEL-> <statictext>;role=FIELD-> <textfield>; type = path and pathType = line -> <line>;type=image-> For rectangular and complex paths, the system performs decomposition: it reads the point sequence of the path and generates a path for every two adjacent points. <line>Elements. A PDF rectangle will be converted into four elements. <line>This allows for the perfect reproduction of table lines in Jasper.

[0035] Then, the JRXML abstract syntax tree is constructed according to the strict order of JasperReports 6.20.0 XSD. The order is enforced as follows: <property> , <style>,<parameter>,<queryString>?,<field>,...,<title>?,...,<detail>（必须存在）,...。系统将所有从PDF解析出的元素（<staticText>,<textField>,<line>,<image>）都放置在<title>带区（Band）内。<detail>带区仅保留一个高度为1的空带区以满足编译要求。这种"TitleBand绝对定位策略”有效规避了Jasper动态带区（如Detail分页）对固定版式的破坏。

[0036] 最后，根据FIELD元素的semanticName，在根节点下生成对应的<fieldname="..." / >声明，并在对应的<textField>中生成表达式<![CDATA[$F{...}]]>。技术效果：本阶段解决了将语义模型转化为合规、可编译Jasper模板的"最后一公里”问题。其确定的坐标换算、路径拆解和严格的XSD顺序控制，确保了生成模板的几何保真度和语法正确性，这是传统"拼凑XML”方法无法保证的。

[0037] 第四阶段，LLM静态检查与修复：将生成的JRXML输入一个由LLM驱动的智能修复模块。该模块扮演"静态编译检查器”角色，依据预设的强制约束（XSD顺序、页面高度约束、字体扩展规范、坐标合法性）对JRXML进行审查和最小化修复。

[0038] 输入为第三阶段生成的初始JRXML字符串。本模块由一个具有固定规则提示词的LLM驱动。

[0039] 该LLM被设定为"JasperReports专家”，并强制其按优先级顺序执行检查与修复：XSD顺序与结构修复（最高优先级）：检查并重排根节点下所有子元素，必须确保存在<detail><bandheight="1" / >< / detail>。

[0040] 页面与带区（Band）高度约束修复：计算availableHeight=pageHeight-topMargin-bottomMargin。检查<title>带区等所有带区的height属性，确保band.height<=availableHeight。若超限，则等比缩放或裁剪带区高度，并相应调整带区内元素的坐标，确保y+height<=band.height。

[0041] 字体扩展强制修复：删除所有pdfFontName属性。确保存在默认样式<stylename="base"isDefault="true"fontName="NotoSansCJKjp"... / >。遍历所有<textElement>，确保其内的<font>标签显式设置了fontName="NotoSansCJKjp"。这解决了中文字体渲染问题。

[0042] 坐标微调（最低优先级，最小改动）：检查元素是否超出页面或带区边界，进行clamp操作。检测元素间是否存在严重重叠，仅进行小幅度纵向偏移（如+20）以消除重叠。

[0043] LLM最终只输出修复后的完整JRXML，不做任何解释。技术效果：本阶段作为一道智能质检关卡，能自动化地修正前序阶段可能产生的各种合规性、可用性问题，显著提升了生成模板的一次通过率，降低了后续闭环的迭代压力。

[0044] 第五阶段，动态编译自修复闭环：尝试编译修复后的JRXML。若编译或渲染失败，则将具体的错误日志和当前JRXML反馈给LLM修复模块。LLM分析错误语义，进行针对性修复，并重新尝试编译。此过程循环迭代，直至JRXML成功编译并生成PDF，形成一个以编译器为验证节点的自驱动收敛闭环。

[0045] 如图3所示。输入为第四阶段修复后的JRXML和一个示例JSON数据源。

[0046] 程序化编译与执行：系统调用JasperCompileManager.compileReport()编译JRXML，并调用JasperFillManager.fillReport()尝试生成PDF。此步骤捕获所有异常（JRException,FontException等）。

[0047] 错误分析与LLM定向修复：若编译或填充失败，系统将当前JRXML和详细的错误日志作为输入，再次调用第四阶段的LLM修复模块。但此次提示词会强调"针对当前错误进行修复”。LLM需要理解错误语义，例如：Fieldnotfound:invoice_no：错误语义是字段声明缺失或名称不匹配。修复策略是在<field>列表中添加或修正对应字段。

[0048] net.sf.jasperreports.engine.design.JRValidationException:Theelementstyleisnotallowedatthislocation：错误语义是XSD顺序错误。修复策略是调整<style>节点的位置。

[0049] Font'HeiseiMin-W3'isnotavailabletotheJVM：错误语义是字体不可用。修复策略是将字体名统一改为NotoSansCJKjp。

[0050] Theband(title)istoolargetofitonasinglepage：错误语义是带区（Band）高度溢出。修复策略是减少title带区的height。LLM根据错误信息生成一个针对性最小修复的新JRXML。

[0051] 迭代与收敛：用修复后的JRXML回到步骤1重新编译。此过程循环。由于Jasper编译错误是有限的，且每次修复都解决至少一个具体问题，因此这是一个单调收敛的过程，最终必然输出一个可成功编译和执行的JRXML模板及对应的PDF输出。技术效果：本阶段创造性地将编译器反馈与LLM修复能力结合，形成了一个自驱动的优化闭环。它解决了自动化生成中难以预料的边缘案例和复杂错误，保证了系统输出的最终模板100%可用，这是本方案可靠性的终极保障。

[0052] 更进一步的的方案，本发明还包含一个数据生成步骤。在第三阶段生成JRXML后，系统会解析所有<field>声明。然后，结合第二阶段语义化中间表示中字段的语义（如invoice_no）和可能的静态样例值，自动生成一个匹配的JSON数据文件。例如，为invoice_no生成”KMJT000001998069”，为日期字段生成”2026-01-12”，为数值字段生成1或100.0。这生成了一个"数据契约”，用于立即验证模板的数据填充功能，确保生成的PDF不是空值，提升了端到端验证的完整性。

[0053] 基于同一发明构思，本发明实施例提供了一种基于多阶段语义理解的报表模板自动生成系统，所述系统用于实现所述方法，所述系统包括：物理版式解析模块，用于对输入的便携式文档格式报表文件进行类型检测与结构化解析，提取其中的文本块、图形路径及其原始坐标，将坐标系统一转换为基于页面尺寸的百分比坐标系，生成物理版式中间表示；语义理解与标注模块，用于将所述物理版式中间表示进行格式压缩，构造版式感知提示词输入至大语言模型LLM；所述大语言模型结合文本的空间关系、视觉样式和语言语义，对文本块进行角色识别与语义标注，生成包含标签、字段、表格结构的语义化版式中间表示；Jasper模板生成模块，用于根据预设的组件映射规则与坐标换算公式，将所述语义化版式中间表示中的元素映射为对应的JasperReports组件，并按照JasperReportsXML架构定义的严格顺序生成JRXML文件；静态检查与修复模块，用于将所述JRXML文件输入至一个LLM驱动的修复模块，该模块对JRXML文件进行文档结构描述XSD顺序合规性、页面高度约束、字体扩展规范及坐标一致性的检查与修复，输出修正后的JRXML文件；动态编译自修复闭环模块，用于编译所述修正后的JRXML文件，若编译失败，则将编译错误日志与当前JRXML文件再次输入所述LLM驱动的修复模块进行定向修复，迭代执行直至编译成功，输出最终可编译的JasperReports报表模板。

[0054] 基于同一发明构思，本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现所述方法的步骤。本发明通过将上述创新方法固化于计算机可读存储介质，使得任何具备处理能力的计算设备均可便捷地部署和运行，从而实现了报表模板自动化生成技术的广泛推广与标准化应用。

[0055] 本文已经公开了示例实施例，并且虽然采用了具体术语，但它们仅用于并仅应当被解释为一般说明性含义，并且不用于限制的目的。在一些实例中，对本领域技术人员显而易见的是，除非另外明确指出，否则可单独使用与特定实施例相结合描述的特征、特性和 / 或元素，或可与其他实施例相结合描述的特征、特性和 / 或元件组合使用。因此，本领域技术人员将理解，在不脱离由所附的权利要求阐明的本发明的范围的情况下，可进行各种形式和细节上的改变。< / style> < / property> < / line> < / line> < / line> < / textfield> < / statictext> < / line> < / textfield> < / statictext>

Claims

1. A method for automatically generating report templates based on multi-stage semantic understanding, characterized in that, include: S1 performs type detection and structured parsing on the input portable document format report file, extracts the text blocks, graphic paths and their original coordinates, converts the coordinate system into a percentage coordinate system based on the page size, and generates an intermediate representation of the physical layout. S2, compress the physical layout intermediate representation, construct layout-aware prompts and input them into the large language model LLM; the large language model combines the spatial relationship, visual style and language semantics of the text to perform role recognition and semantic annotation on the text blocks, and generate a semantic layout intermediate representation containing tags, fields and table structures. S3. Based on the preset component mapping rules and coordinate conversion formula, the elements in the semantic layout intermediate representation are mapped to the corresponding JasperReports components, and JRXML files are generated in strict order as defined by the JasperReportsXML schema. S4, the JRXML file is input into an LLM-driven repair module, which checks and repairs the JRXML file for document structure description XSD order compliance, page height constraints, font extension specifications and coordinate consistency, and outputs the corrected JRXML file; S5. Compile the corrected JRXML file. If the compilation fails, input the compilation error log and the current JRXML file into the LLM driver's repair module again for targeted repair. Iterate until the compilation is successful and output the final compileable JasperReports report template.

2. The method according to claim 1, characterized in that, The type detection and structured parsing in S1 specifically include: S11 performs type detection on PDF pages based on three-dimensional features of text layer density, image density, and layout complexity, and routes the pages to different parsing strategies according to the detection results. S12 uses the PyMuPDF parsing engine to not only extract text blocks, but also parse the drawing path commands in the PDF, converting the path commands into standard line and rectangular geometric primitives; S13, repair the degraded path, and fill in the path with a height or width close to zero as a horizontal or vertical line; S14 converts the original coordinates from point units in the PDF, with the bottom left corner as the origin, to a percentage of the page width and height, with the top left corner as the origin.

3. The method according to claim 1, characterized in that, In step S2, the layout-aware prompt words encode each element into an element identifier, font size, and a compressed format of text content. The large language model outputs structured JavaScript object representation data, which includes the identifier, role, and semantic name of each element, as well as the identifier reference of the tag element bound to the field element.

4. The method according to claim 1, characterized in that, The coordinate transformation formula in S3 is: C pt =Size×C percent / 100; Among them, C pt Here are the component coordinates, Size is the page size, and C... percent These are percentage coordinates for the component, with the origin of these percentage coordinates being the top left corner of the page.

5. The method according to claim 1, characterized in that, The S3 also includes the process of converting graphic paths in the PDF into JasperReports components: for rectangular paths, they are decomposed into four independent straight line components; for multi-segment polyline paths, they are decomposed into a series of straight line components connected end to end.

6. The method according to claim 1, characterized in that, In S4, the large language model-driven repair module is forced to perform repairs in the following priority order: first, repair the XSD order and missing nodes; second, repair the band height and page constraints; then, repair the font extension configuration; and finally, fine-tune the coordinate out-of-bounds and element overlap.

7. The method according to claim 1, characterized in that, The repair module of the LLM driver in S5 performs targeted repairs based on the specific compilation error type. The correspondence between the error type and the repair strategy includes: field not found error corresponds to completing or adjusting the field declaration order; font not found error corresponds to modifying the font name to the specified extended font; and band height overflow error corresponds to shrinking the band height or adjusting the element coordinates.

8. The method according to claim 1, characterized in that, The step S3 is followed by a data generation step: based on the field definitions in the generated JRXML file and combined with the field semantics in the semantic layout intermediate representation, a JavaScript object representation data file containing reasonable example values ​​is automatically generated to verify the data binding function of the template.

9. A report template automatic generation system based on multi-stage semantic understanding, characterized in that, The system is used to implement the method according to any one of claims 1-8, the system comprising: The physical layout parsing module is used to perform type detection and structured parsing on the input portable document format report file, extract the text blocks, graphic paths and their original coordinates, convert the coordinate system into a percentage coordinate system based on the page size, and generate an intermediate physical layout representation. The semantic understanding and annotation module is used to compress the physical layout intermediate representation and construct layout-aware prompts for input into the large language model (LLM). The large language model combines the spatial relationships, visual styles and linguistic semantics of the text to perform role recognition and semantic annotation on the text blocks, generating a semantic layout intermediate representation containing tags, fields and table structures. The Jasper template generation module is used to map the elements in the semantic layout intermediate representation to the corresponding JasperReports components according to the preset component mapping rules and coordinate conversion formulas, and generate JRXML files in strict order as defined by the JasperReportsXML schema. The static inspection and repair module is used to input the JRXML file into an LLM-driven repair module. This module checks and repairs the JRXML file for compliance with document structure description XSD order, page height constraints, font extension specifications, and coordinate consistency, and outputs a corrected JRXML file. The dynamic compilation self-repair closed-loop module is used to compile the corrected JRXML file. If the compilation fails, the compilation error log and the current JRXML file are input into the LLM driver's repair module again for targeted repair. The process is iterated until the compilation is successful, and the final compilable JasperReports report template is output.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 8.

Images