Report generation method, apparatus, device, storage medium, and program product

Abstract

The application provides a report generation method, device, equipment, storage medium and program product, relates to the technical field of artificial intelligence, and the method comprises the following steps: based on a report source file, a chapter tree representing the report content structure is generated; based on the chapter tree, semantic analysis and structure planning are performed on each chapter to generate report design mode data; the report design mode data and set TSD data are fused to generate an executable design package; and based on the executable design package, a final report file is generated. Through semantic analysis and structure planning, the application realizes understanding of the deep intention of the report content; by fusing the design intention and the style specification, it is ensured that the generated result can be flexibly adapted to specific content requirements while complying with enterprise specifications, so that the determinacy of the generated result in the three dimensions of document structure, visual style and content semantics is realized on the premise of ensuring that the entire generation process is highly automated and intelligent.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a report generation method, apparatus, device, storage medium, and program product. Background Technology

[0002] Currently, in the context of intelligent content production and data analysis, generating structured, high-quality HTML (HyperText Markup Language) reports through automation can not only improve output efficiency but also significantly outperform manually produced documents in terms of consistency, reproducibility, and system maintainability.

[0003] However, existing automated report generation technologies still have significant limitations: traditional methods, such as template filling, while providing stable output, lack flexibility and struggle to adapt to diverse and semantically complex report content. Essentially, they remain manual design followed by programmatic filling, failing to achieve true intelligent generation. End-to-end methods, such as direct generation using Large Language Models (LLMs), offer improved content adaptability, but their output is unpredictable, frequently exhibiting formatting errors, style chaos, and structural omissions. Furthermore, they lack controllable verification and repair mechanisms, making it difficult to meet the stringent requirements of enterprise applications for stability, brand consistency, and audit traceability.

[0004] Therefore, how to ensure the accuracy of the generated results in terms of structure, style, and semantics while ensuring a high degree of automation in the generation process has become an urgent problem to be solved. Summary of the Invention

[0005] This application provides a report generation method, apparatus, device, storage medium, and program product to address the shortcomings of existing technologies that cannot ensure the accuracy of the generated results in terms of structure, style, and semantics while maintaining a high degree of automation in the generation process. It achieves determinism of the generated results in three dimensions: document structure, visual style, and content semantics.

[0006] This application provides a report generation method, including the following steps: Based on the report source file, generate a chapter tree representing the structure of the report content; Based on the chapter tree, semantic analysis and structural planning are performed on each chapter to generate report design pattern data; The report design pattern data and the set template and style definition TSD data are merged to generate an executable design package; Based on the executable design package, the final report file is generated.

[0007] According to a report generation method provided in this application, the step of fusing the report design pattern data and the set template and style definition (TSD) data to generate an executable design package includes: The parameterized rule set in the TSD data is parsed, and the style preferences carried in the report design pattern data are read to establish a style priority mapping relationship; wherein, in the style priority mapping relationship, the local style parameters of the report design pattern data have a higher priority than the global style parameters of the TSD data. Based on the style priority mapping relationship, the local style parameters and global style parameters are merged to generate unified style resolution data; Based on the component contract in the TSD data, the visual component instances defined in the report design pattern data are bound to the parameter interface that matches the component contract, and a component instantiation instruction is generated. The style resolution data, the component instantiation instructions, and the static resource list extracted from the TSD data are encapsulated into the executable design package.

[0008] According to a report generation method provided in this application, the step of binding visual component instances defined in the report design pattern data to parameter interfaces matching the component contracts based on the component contracts in the TSD data, and generating component instantiation instructions, includes: Based on the component type identifier of each visual component instance defined in the report design pattern data, a matching interface specification is searched in the component contract set of the TSD data; Based on the set of required data fields defined in the matched interface specification, verify the completeness of the data mapping relationship in the visual component instance; Based on predefined parameter synthesis rules, a complete set of rendering parameters is generated for the visual component instance; Based on the verified data mapping relationship and the complete rendering parameter set, the component instantiation instruction is generated.

[0009] According to a report generation method provided in this application, the step of performing semantic analysis and structural planning on each chapter based on the chapter tree to generate report design pattern data includes: Semantic analysis is performed on the text content of each chapter in the chapter tree to obtain the display target of each chapter; Based on the chapter tree and the display objectives of each chapter, the structural planning results of each chapter are determined; Based on the chapter tree, the display objectives of each chapter, and the structural planning results of each chapter, report design pattern data is generated.

[0010] According to a report generation method provided in this application, generating a final report file based on the executable design package includes: Based on the executable design package, content fragments corresponding to multiple visual components are generated asynchronously and concurrently. Perform layered verification and repair on each of the content segments; the layered verification includes unit-level verification, integration-level verification and global-level verification, and each level of verification is associated with an automatic repair or degradation strategy. The validated content fragments are assembled into the report template to generate the final report file.

[0011] According to a report generation method provided in this application, the step of generating a chapter tree representing the content structure of the report based on the report source file includes: The source file of the report is cleaned to remove redundant symbols and unify the text encoding; Based on predefined regular expression rules and semantic rules, the system identifies heading tags and paragraph boundaries in the cleaned text. The chapter tree is generated based on the title tags and the content paragraph boundaries.

[0012] This application also provides a report generation apparatus, including the following modules: The data parsing module is used to generate a chapter tree representing the structure of the report content based on the report source file; The semantic analysis and structure planning module is used to perform semantic analysis and structure planning on each chapter based on the chapter tree to generate report design pattern data; The fusion module is used to fuse the report design pattern data and the set template and style definition TSD data to generate an executable design package; The report generation module is used to generate the final report file based on the executable design package.

[0013] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the report generation method as described above.

[0014] This application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the report generation method as described above.

[0015] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the report generation method as described above.

[0016] The report generation method, apparatus, device, storage medium, and program product provided in this application generate a chapter tree representing the structure of the report content based on the report source file; perform semantic analysis and structural planning on each chapter based on the chapter tree to generate report design pattern data; integrate the report design pattern data with the set template and style definition TSD data to generate an executable design package; and generate the final report file based on the executable design package. This application achieves a deep understanding of the report content's intent through semantic analysis and structural planning; by integrating design intent with style specifications, it ensures that the generated results, while adhering to enterprise standards, can flexibly adapt to specific content needs. This solves the problems of overly rigid traditional template-filling methods and the strong randomness of results from end-to-end generation methods using large language models. Thus, while ensuring a high degree of automation and intelligence throughout the entire generation process, it achieves determinism in the three dimensions of document structure, visual style, and content semantics. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating the report generation method provided in this application.

[0019] Figure 2 This is a system architecture diagram of the report generation method provided in this application.

[0020] Figure 3 This is a schematic diagram of the report generation device provided in this application.

[0021] Figure 4 This is a schematic diagram of the structure of the electronic device provided in this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] Among related technologies, automatic HTML report generation methods suffer from the following problems: First, the generation process is either too rigid (template-based) or too random (LLM-based), neither of which can balance intelligence and stability; second, the lack of phased processing and structured validation mechanisms makes it difficult to effectively detect and correct errors; third, the performance bottleneck in generating long reports is significant, with insufficient concurrency capabilities; and finally, the output structure and style lack unified constraints, making it difficult to guarantee brand consistency. Related technologies fail to achieve a balance between "intelligent generation, efficient execution, and stable output."

[0024] Based on this, the technical solution of this application aims to solve the aforementioned technical problems. The core objective is to introduce a phased asynchronous generation and verification mechanism while maintaining the LLM's natural language understanding and design capabilities, thereby achieving comprehensive control over content, structure, and style. Through multi-stage task decomposition, asynchronous concurrent scheduling, and a combination of template constraints and structured validation, this application establishes an HTML report generation system that combines intelligent generation, high execution efficiency, and result stability. This makes the HTML code output process verifiable, scalable, and maintainable, fundamentally overcoming the technical shortcomings of existing solutions in terms of performance, controllability, and fault tolerance.

[0025] The following is combined with Figures 1-4 This application describes the report generation method, apparatus, device, storage medium, and program product.

[0026] Figure 1 This is a flowchart illustrating the report generation method provided in this application, such as... Figure 1 As shown, the method includes the following: Step 101: Based on the report source file, generate a chapter tree representing the structure of the report content.

[0027] The report source file refers to the electronic document submitted by the user that contains the original content of the report to be generated. Its format can be Markdown, plain text, or JSON with structured tags, etc.

[0028] The chapter tree is a tree-shaped skeleton data obtained after parsing the report source file. Its nodes represent logical units such as chapters and paragraphs of the report, and record the type, level, content and parent-child relationship of the nodes, which serve as the basic structure for subsequent semantic understanding and visual planning.

[0029] The source report file is cleaned and its structure is identified. Based on the identified tag hierarchy, a tree structure is constructed to form a chapter tree.

[0030] Step 102: Perform semantic analysis and structural planning on each chapter based on the chapter tree to generate report design pattern data.

[0031] Semantic analysis refers to the process of deeply understanding the text content attached to each chapter node based on a chapter tree, in order to identify and extract its core expressive intent and data display requirements.

[0032] Structural planning refers to the process of deciding the macro-layout and component composition of the visual presentation of each chapter node based on the hierarchical relationship of the chapter tree and the results of semantic analysis.

[0033] Report design pattern data refers to a structured, machine-readable intermediate data format that standardizes and encapsulates a complete design blueprint derived from semantic analysis and structural planning.

[0034] Semantic understanding is performed on the text content associated with each node in the chapter tree to identify the display target; based on the hierarchical structure of the chapter tree and the display target, a corresponding visual layout type is planned for each node; based on the display target and the visual layout type, structured report design pattern data is generated.

[0035] In one embodiment, the report design schema data is structured Report Design Schema data. The Report Design Schema expresses the report's semantic structure, defining report sections, component types, data mapping relationships, style preferences, and validation constraints. Specifically, the Report Design Schema is a semantic design middleware data structure used to describe the report's semantic intent, section structure, visualization requirements, and style constraints. This structure uses JSON Schema as an abstract form and consists of multiple first-level fields: meta, global_style, toc, sections, assets, and notes. ReportDesignSchema { meta: MetaInfo, global_style: GlobalStyle, toc: [TocEntry], sections: [Section], assets: AssetPolicy, notes: Notes}.

[0036] 1) meta: Used to describe the basic attributes and generation constraints of the report, facilitating version management and tracking, including 4 fields: report_id, title, author, and created_at.

[0037] 2) global_style: Used to describe global visual specifications, providing unified style constraints and template identifiers, including: template_id: template identifier, corresponding to the template file in the user specification module; brand_color: list of main color tones for the report; font: font definition for titles and body text, including font names and alternative fonts; page_margins: page margin settings; theme_variant: theme style (such as light, dark, corporate).

[0038] 3) `toc`: Defines the report chapter hierarchy and sorting, used to generate the navigation structure, including: `id`: unique chapter identifier; `title`: chapter title; `level`: hierarchy number (1 for first-level heading, 2 for second-level heading). 4) Sections: This is the core part of the schema, defining the semantic goals, data sources, and visualization design of the report, including: id: a unique identifier for the section; title: the section title; intent: a description of the section's generation intent, used for semantic guidance; content_source: the content source, including the type (text / data_query / file) and parameters; visuals: [VisualComponent], a list of visualization or table components defined in the section; render_hint: rendering hints (layout, component container type); children: a list of child sections with IDs.

[0039] The VisualComponent defines the structural dependencies between chapters and components, forming a semantic-to-executable configuration mapping: id: unique identifier for the component; type: component type, such as chart_bar, summary_table, map_choropleth; design_intent: semantic description of the component (e.g., "show month-on-month trend"); data_mapping: data field mapping relationship, such as {"x":"month","y":"sales"}; style_preference: local style preferences of the component, such as color scheme, margins, etc.; validation: validation rules, such as required_fields, min_rows, value_range.

[0040] 5) assets: Defines the allowed static resource paths and fallback strategies, including: allowed_paths: allowed material path patterns; fallback_logo: default fallback resource path.

[0041] 6) notes: is an unstructured or semi-structured container for comments and instructions, used to hold designer intent, business logic descriptions, and special processing instructions for the generation system that cannot or are inconvenient to express in strictly structured fields.

[0042] It should be understood that a schema possesses machine readability and interpretability, serving as a bridge between the design and production phases. Specifically, a schema is a structured, unambiguous data format that can be directly parsed and executed by a program.

[0043] Step 103: Merge the report design pattern data and the set template and style definition TSD data to generate an executable design package.

[0044] Template & Style Definition (TSD) data is a predefined, reusable knowledge base of design specifications. TSD data can include: Template files: include the overall report framework template, component templates, and placeholder definition files, which describe the layout and rendering logic of each part; Static resources: including company logo, color scheme files, icon library, background images, and font files; Parameterized rule set: Defines style parameters such as color, font, margin, shadow, and default color scheme of charts, and stores them in the form of hierarchical configuration files.

[0045] An executable design package is a standardized set of instructions generated after the fusion phase that can directly drive the report rendering engine. It instantiates an abstract semantic design blueprint and general style specifications into a set of specific, unambiguous, and immediately executable rendering tasks for the current specific report.

[0046] Based on predefined conflict resolution rules, style constraints from the report design pattern data and style specifications from the TSD data are merged to generate unified style data applicable to the current report; based on the component interface specifications defined in the TSD data, the visual component instances defined in the report design pattern data are adapted and bound into instantiation instructions that can be directly called by the rendering engine; the unified style data, instantiation instructions, and necessary resource reference information are integrated to generate an executable design package.

[0047] In one embodiment, the executable design package integrates semantic structure, template rules, material paths, and component instantiation instructions to ensure a controllable and traceable generation process. Technical definition of the executable design package: DesignPackage { report_id: string, resolved_style: ResolvedStyle, asset_manifest: AssetManifest, component_instructions: [ComponentInstruction], validation_contracts: [ValidationContract], metadata: PackageMetadata}.

[0048] The definitions of each field are as follows: 1) report_id: Consistent with meta.report_id in Report Design Schema, used to identify version association.

[0049] 2) resolved_style: This is the result of the style and design fusion algorithm, containing the final values ​​of global and local styles, including: color_palette: the final color scheme list (from template rules and local overriding); font_family: the font definition for the title and body text; border_radius: the global component corner radius parameter; spacing_unit: the layout spacing unit (pixels or relative units); chart_defaults: the general rendering parameters for the chart (legend, animation, tooltip).

[0050] 3) asset_manifest: Records all static resources available in the report generation, including: asset_id: resource identifier; path: resource file path; type: resource type (image / font / icon); hash: file checksum; fallback: fallback path.

[0051] 4) component_instructions: Describes the execution contract for each component during the generation phase, including: component: component type (e.g., chart_bar); data_binding: binding data fields to the data source; params: style parameters and rendering instructions; render_target: component insertion position (DOM node or placeholder ID).

[0052] 5) validation_contracts: Specifies the assertion rules after the report is generated, which are used for automatic detection by the report generation and validation modules. It includes: component_id: target component ID; checks: set of validation items, each defining the detection conditions and thresholds; severity: error level (warning / error / blocking); fix_strategy: fix or downgrade strategy (auto_fix, fallback, ignore).

[0053] 6) Metadata: Supports package-level tracing, source tracking, and regeneration, including: generated_at: generation timestamp; generator_version: fusion algorithm version; source_template: template ID used.

[0054] Step 104: Based on the executable design package, generate the final report file.

[0055] The final report document is an HTML file that can be directly rendered and displayed in a web browser. The HTML file is a single HTML document that includes inline styles, embedded scripts, and coded resources.

[0056] Based on the instantiation instruction set in the executable design package, the corresponding rendering engine or code generator is invoked in parallel to produce raw content blocks such as HTML fragments, chart configurations, and table code. For each generated content block, a preset multi-layered validation is performed, covering at least syntax correctness, data integrity, and resource accessibility. For content blocks that fail validation, automatic repair or downgrading is performed according to the repair strategy associated in the executable design package. All content blocks that pass validation are assembled into the corresponding report template framework according to the layout and dependency relationships defined in the executable design package to synthesize a complete HTML document. The HTML document is output as the final report file, or converted to other formats such as PDF as required.

[0057] The report generation method provided in this application generates a chapter tree representing the structure of the report content based on the report source file; performs semantic analysis and structural planning on each chapter based on the chapter tree to generate report design pattern data; integrates the report design pattern data with the set TSD data to generate an executable design package; and generates the final report file based on the executable design package. This application achieves a deep understanding of the report content's intent through semantic analysis and structural planning; by integrating design intent with style specifications, it ensures that the generated results, while adhering to enterprise standards, can flexibly adapt to specific content needs. This solves the problems of overly rigid traditional template-filling methods and the strong randomness of results from end-to-end generation methods using large language models. Thus, while ensuring a high degree of automation and intelligence throughout the entire generation process, it achieves determinism in the three dimensions of document structure, visual style, and content semantics.

[0058] Based on the above embodiments, the step of fusing the report design pattern data and the set template and style definition TSD data to generate an executable design package includes: Parse the parameterized rule set in the TSD data and read the style preferences carried in the report design pattern data to establish a style priority mapping relationship; Based on the style priority mapping relationship, the local style parameters and global style parameters are merged to generate unified style resolution data; Based on the component contract in the TSD data, the visual component instances defined in the report design pattern data are bound to the parameter interface that matches the component contract, and a component instantiation instruction is generated. The style resolution data, the component instantiation instructions, and the static resource list extracted from the TSD data are encapsulated into the executable design package.

[0059] It should be understood that a parameterized rule set is a computable set of rules stored in TSD data used to define visual styles.

[0060] Style priority mapping is a dynamic decision-making framework built during the integration process to resolve style rule conflicts. In style priority mapping, local style parameters from Report Design Schema data have higher priority than global style parameters from TSD data. For example, when a local style parameter from Report Design Schema, targeting a specific chapter or component, conflicts with a global style parameter from TSD, applicable to a template or component type, the former's defined value becomes the final effective value, while the latter only takes effect as the default value if the former is not defined.

[0061] The parameterized rule set in the TSD data is parsed, and the style preferences carried in the report design pattern data are read to establish a style priority mapping relationship. For example, the basic rule set defined as global styles is extracted from the style_rules field of the TSD data; the user preference set defined as local styles is extracted from the global_style and sections[*].visuals[*].style_preference fields of the report design pattern data; the definitions of the same style attribute (such as color, font_family) in the basic rule set and the user preference set are compared to detect rule conflicts; a clear priority mapping relationship is established based on a predefined conflict resolution meta-rule, which is: user preference set > basic rule set > system default value; the priority mapping relationship is organized into a data structure that can be efficiently queried by subsequent merging algorithms; the data structure explicitly records the source order and decision path of the final effective value for each conflicting or inherited style attribute.

[0062] Based on style priority mapping, local and global style parameters are merged to generate unified style resolution data. For example, all style attributes defined in local or global style parameters are iterated over. For each attribute, the style priority mapping is queried to determine the source of its highest priority valid value, and the final value of the attribute is determined accordingly. For attributes whose determination originates from a parameterized rule set, the calculation logic, variable substitution, or conditional judgment defined in the rule set is executed to parse out the specific static value of the attribute. All determined and parsed style attributes and their final values ​​are assembled into a flat, conflict-free set of key-value pairs, forming style resolution data. The structure of this data is independent of any source and represents a standardized final style description. The style resolution data is associated with the corresponding component type and chapter identifier in the executable design package to ensure accurate querying and application in subsequent binding stages.

[0063] Based on the component contract in the TSD data, the visual component instances defined in the report design pattern data are bound to the parameter interface that matches the component contract, generating component instantiation instructions.

[0064] The style resolution data, component instantiation instructions, and static asset manifest extracted from the TSD data are encapsulated into an executable design package. For example, a data object conforming to a predefined DesignPackage pattern is created as a container; this pattern mandates the inclusion of three root fields: resolved_style (style resolution data), component_instructions (component instantiation instruction set), and asset_manifest (static asset manifest). The style resolution data, component instantiation instruction set, and static asset manifest are validated for format and integrity. After successful validation, the three are serialized and populated into the corresponding root fields of the container. The generated metadata is injected into the container, including at least: a unique report identifier, a generation timestamp, and the version identifiers of the Report Design Schema and TSD used. Simultaneously, the validation rules defined in the report design pattern data and the structural constraints defined in the component contracts are merged to form a validation_contracts array, which is then injected into the container. The fully populated container object is serialized into a standard JSON text file or binary encoded stream as the final, independently distributable executable design package output.

[0065] This application embodiment integrates a flexible design blueprint with corporate specifications into a directly executable instruction package through a fusion process of intelligent adjudication style, contract binding components, and standardized encapsulation, ensuring that the output meets personalized needs while adhering to brand specifications.

[0066] Based on the above embodiments, the step of binding the visual component instance defined in the report design pattern data to a parameter interface matching the component contract based on the component contract in the TSD data, and generating a component instantiation instruction, includes: Based on the component type identifier of each visual component instance defined in the report design pattern data, a matching interface specification is searched in the component contract set of the TSD data; Based on the set of required data fields defined in the matched interface specification, verify the completeness of the data mapping relationship in the visual component instance; Based on predefined parameter synthesis rules, a complete set of rendering parameters is generated for the visual component instance; Based on the verified data mapping relationship and the complete rendering parameter set, the component instantiation instruction is generated.

[0067] It should be understood that a visual component instance refers to a specific object defined in the `sections[*].visuals` array of the report design pattern data. It fully describes a visual element to be generated, including at least its unique identifier, semantic intent, component type, and data mapping relationship.

[0068] Component type identifiers are labels or symbols used to uniquely distinguish different types of visual components within a system.

[0069] A component contract is an element of the component_contracts array in TSD data. It specifies all the interface specifications required for rendering a component of a certain type (identified by the component_type field), including required data fields, supported style parameters, default parameter values, and parameter constraints.

[0070] The interface specification refers to the complete set of rules defined by the component contract successfully matched from the TSD based on the component type identifier of the visual component instance during the binding process. The system will use this specification to verify the completeness of the instance data, synthesize rendering parameters for the instance, and ultimately generate executable instructions.

[0071] Based on the component type identifier of each visual component instance defined in the report's design pattern data, a matching interface specification is searched in the component contract set of the TSD data. For example, the value of the `type` field of the current visual component instance is extracted as the precise query key; each contract object in the `component_contracts` array of the TSD data is traversed, and the `component_type` field value of each contract object is matched against the query key; if a contract object with a `component_type` exactly equal to the query key is found, the match is considered successful, and the entire content of that contract object is output as the interface specification of the current instance; if no matching item is found, a fallback matching process is triggered: a contract defining a common or alternative component type is searched in the contract set; if the fallback matching still fails, an error log is generated and component-level fallback or skip processing is triggered. Successfully matched interface specifications are cached in the context of this fusion task for quick reuse of subsequent visual component instances of the same type, improving processing efficiency.

[0072] Based on the set of required data fields defined in the matched interface specification, the completeness of the data mapping relationship in the visual component instance is verified. For example, the required_fields list in the matched interface specification is extracted and compared with the key set defined by the data_mapping object in the current visual component instance; it is determined whether the key set of data_mapping is a superset or equal set of the required_fields list; that is, it is checked whether each field in required_fields has a corresponding key definition in data_mapping; if it is determined to be complete, the verification passes and proceeds to the next synthesis step; if it is determined to be incomplete, the list of missing required fields is recorded and an automatic completion process is triggered: attempting to obtain default values ​​from the default_params in the interface specification or the associated context data for completion; if automatic completion is not possible, the instance is marked as verification failed, and an instance-level degradation or error handling process is triggered. For the field values ​​already provided in data_mapping, pre-validation is performed according to the data type, value range, or format defined in param_constraints in the interface specification, and warnings are issued for obviously non-compliant values ​​or attempts are made to perform standardization conversion.

[0073] Based on predefined parameter composition rules, a complete set of rendering parameters is generated for the visual component instance. For example, all possible parameters related to the visual component instance are collected from the following three sources: Source A (instance preference): extracting explicitly defined parameters from the instance's own style_preference field; Source B (global resolution): querying global style parameters applicable to this component type from the style resolution data; Source C (contract default): obtaining predefined default parameters from the default_params field of the matched interface specification. Based on predefined parameter synthesis rules, different values ​​for the same parameter name obtained from the three sources are synthesized. The rules stipulate the priority order as: Source A > Source B > Source C; that is, if Source A is defined, its value is used; if Source A is undefined but Source B is defined, the value of Source B is used; if neither Source A nor Source B is defined, the value of Source C is used. Each synthesized parameter value is compared and verified with the constraints defined in the param_constraints field of the interface specification. Values ​​that do not conform to the constraints are automatically corrected or safely replaced according to the constraint rules. All synthesized, verified and corrected parameters are organized into a standard key-value pair object, which is output as the complete rendering parameter set of this visual component instance.

[0074] Based on the validated data mapping relationship and the complete rendering parameter set, a component instantiation instruction is generated. For example, an instruction template associated with the component type of the current visual component instance is obtained; this template defines the data structure framework of the final instruction; the validated data_mapping (data mapping relationship) and the complete rendering parameter set are used as the core content of data_binding and params, and filled into the corresponding fields of the instruction template; the unique identifier (id), component type (type), and its target rendering position (render_target) in the report of the current visual component instance are injected into the instruction template; the filled instruction template is encapsulated into a self-describing, independently executable data object, which is output as the component instantiation instruction for the visual component instance; the instruction at least includes the following fields: component (component type), component_id (instance identifier), data_binding (data binding), params (rendering parameters), and render_target (rendering target).

[0075] This application's embodiments utilize interface contracts to ensure standardized component calls, and intelligent verification and parameter synthesis to guarantee instruction quality and consistency. This allows for flexible fulfillment of personalized design needs while avoiding randomness and uncertainty in the rendering stage, providing a stable and controllable core conversion capability for generating high-quality automated reports.

[0076] Based on the above embodiments, the step of performing semantic analysis and structural planning on each chapter based on the chapter tree to generate report design pattern data includes: Semantic analysis is performed on the text content of each chapter in the chapter tree to obtain the display target of each chapter; Based on the chapter tree and the display objectives of each chapter, the structural planning results of each chapter are determined; Based on the chapter tree, the display objectives of each chapter, and the structural planning results of each chapter, report design pattern data is generated.

[0077] The presentation objective refers to the core intent and constraints, extracted from the semantic analysis of the text content of a report section, regarding how that section of content should be visualized. Presentation objectives include trend analysis, comparative analysis, and geographic distribution displays.

[0078] From the chapter tree, extract the original text content associated with each chapter node to form a text sequence to be analyzed. Perform at least one of the following analyses on the text sequence: ① Intent classification: determine whether the core semantics of the text is "trend analysis," "comparative explanation," "composition display," "distribution description," or "summary summary"; ② Key entity and indicator extraction: identify the core business entities, data indicators, time periods, and geographical regions mentioned in the text; ③ Relationship and pattern judgment: analyze the comparison, ranking, association, or causal relationships between entities and indicators. Based on the results of semantic feature recognition, comprehensively generate the display objectives for the chapter; whereby the display objective is a structured instruction description, which at least includes visualization type suggestions and core data dimensions.

[0079] In one embodiment, the intent classification step can be implemented by calling a pre-trained natural language understanding model or a rule-based keyword matching model. It should be understood that the pre-trained natural language understanding model is a large language model fine-tuned for a text classification task, taking the chapter text as input and outputting predefined intent category labels and confidence scores. The rule-based keyword matching model maintains an intent-keyword mapping table, determining the intent category by statistically analyzing the frequency and weight of keywords associated with various intents in the text. For example, based on system configuration or the length and complexity of the chapter text, the decision is made to use either the pre-trained natural language understanding model or the rule-based keyword matching model for classification. When the natural language understanding model is used, the chapter text is fed into the model as input, and the model outputs at least one intent category label and its corresponding confidence score. When the keyword matching model is used, the predefined intent-keyword weight mapping table is loaded, the chapter text is segmented and stemmed, its matching score with each intent category in the mapping table is calculated, and the intent category with the highest score is output. The validity of the intent category output by the model is verified. When the confidence score of the natural language understanding model is lower than the preset threshold, the model is automatically switched to the keyword matching model for verification or reclassification, and the verification result is used as the final intent classification result.

[0080] Based on the chapter tree and the display goals of each chapter, the structural planning results for each chapter are determined. For example, based on the current chapter's hierarchy in the chapter tree and the visual complexity implied by its display goals, a macro-level page layout template is selected for the chapter. The layout template library predefines various layout formats, including single-column flow, two-column contrast, primary and secondary partitioning, and grid tiling. According to the current chapter's display goals, one or more visual component types best suited to achieving those goals are matched from a predefined component type library, serving as the recommended component set for the chapter. For each component in the recommended component set, a rendering placeholder is allocated within the selected page layout template, and the potential data flow or interaction dependencies between these components are determined. The structural planning result is generated by encapsulating the selected layout template, the matched set of visual component types, and the placeholder and dependency information for each component into the structural planning result for that chapter.

[0081] Based on the chapter tree, the presentation goals of each chapter, and the structural planning results of each chapter, report design pattern data is generated. For example, an empty data frame conforming to the predefined ReportDesignSchema pattern is created, and its meta and toc fields are populated with document meta information extracted from the chapter tree; the template identifier and global style preferences associated with the report design pattern data are populated into the global_style field of the data frame; each chapter node in the chapter tree is traversed, a corresponding entry is created in the sections array of the data frame for each node, and the following information is populated into each entry: id and title: copied from chapter tree nodes; intent: Enter a textual or structured description of the presentation objectives for this section; The `visuals` array: Based on the structural planning results of this chapter, a `VisualComponent` object is created for each planned visual component; the `type` field of each `VisualComponent` object is filled with the component type matched in the planning results, and the `design_intent` field is filled with the component-level intent description obtained from the refinement of the chapter's display objectives; render_hint: Enter the layout template identifier selected in the structural planning results for this section.

[0082] Fill the corresponding fields of the chapter or component with the hierarchical relationship (children field) in the chapter tree, as well as the data mapping relationship and validation constraints extracted from semantic analysis and structural planning; serialize the fully populated data framework into standard JSON format as the final report design pattern data output.

[0083] This application's embodiments understand the content intent through semantic analysis, achieve adaptive visual layout through structural planning, and ultimately generate unambiguous design specification data. This ensures that the automated generation process is both highly intelligent and follows design logic, resolving the contradiction between intelligence and controllability in traditional methods.

[0084] Based on the above embodiments, generating the final report file based on the executable design package includes: Based on the executable design package, content fragments corresponding to multiple visual components are generated asynchronously and concurrently. Perform layered verification and repair on each of the content segments; the layered verification includes unit-level verification, integration-level verification and global-level verification, and each level of verification is associated with an automatic repair or degradation strategy. The validated content fragments are assembled into the report template to generate the final report file.

[0085] It should be understood that layered verification refers to a progressive quality assurance mechanism that moves from fine to coarse and from local to global. It ensures the reliability of generated content by setting verification points and repair strategies at different levels of abstraction.

[0086] Cell-level validation refers to the validation of the inherent correctness of a single, independent piece of content (such as an HTML snippet, a chart configuration JSON object, or a table code block). The validation objectives of cell-level validation are syntactic correctness, data structure integrity, and data contract compliance. For example, validating whether a line chart configuration is missing a yAxis field, or whether a table contains negative sales figures.

[0087] Integration-level validation refers to the process of verifying dependencies, resource references, and interaction compatibility among multiple content fragments within a combined context. The validation objectives of integration-level validation are dependency integrity, resource reference validity, and conflict detection. For example, it verifies whether a total value referenced in a summary table matches the sum calculated in another detail chart; or whether two components import different versions of the same JavaScript library.

[0088] Global-level verification refers to the verification of the overall quality and performance of the final product after assembling all content fragments into a complete report page, under conditions close to a real user environment. The verification objectives of global-level verification are renderability, performance metrics, and stylistic consistency. For example, it checks whether the final assembled system can start normally, meets performance standards, and conforms to the design drawings.

[0089] Each level of verification is associated with an automatic repair or degradation strategy. It should be understood that automatic repair or degradation strategies are pre-configured handling plans for different levels and types of quality defects. Their core objective is to maintain the continuity of the production process and optimize output results to the greatest extent possible through automated operations, while ensuring the core value of the final deliverable. The automatic repair strategy aims to correct defective content to an ideal state that fully conforms to the original design specifications and quality standards. It is suitable for scenarios where the cause of the defect is clear and reversible corrective measures exist. The automatic degradation strategy is applicable when defects cannot be repaired or the repair costs (such as time and resources) are too high. In this case, the system proactively and systematically reduces the requirements for certain non-core functions or experiences in exchange for the reliable delivery of core functions.

[0090] Based on the executable design package, multiple content fragments corresponding to visual components are generated asynchronously and concurrently. For example, the component instantiation instruction set in the executable design package is parsed, each instruction is transformed into an independent rendering task, and all tasks are submitted to the asynchronous task scheduling queue. The asynchronous task scheduling queue allocates multiple rendering tasks concurrently to the corresponding rendering engines for execution based on available computing resources. The rendering engines include at least one of the following: a) Chart rendering engine: used to generate HTML fragments or Canvas drawing instructions corresponding to the chart based on the chart configuration data; b) Table rendering engine: used to generate HTML code for structured tables based on table parameters; c) Text and rich media rendering engine: used to generate HTML fragments of formatted text, lists, or embedded media. The execution status of each rendering task is monitored, and successfully generated content fragments are collected. For tasks that fail to execute, error information is recorded and the corresponding fault tolerance or degradation processing flow defined in the executable design package is triggered.

[0091] The asynchronous task scheduling queue groups or sorts rendering tasks based on the component type or resource dependencies defined in the component instantiation instructions, in order to optimize overall generation efficiency and avoid resource conflicts.

[0092] Layered verification and repair are performed on each content segment. For example, following a local to global order, quality assessments are performed on content segments or combinations thereof at three levels: unit level, integration level, and global level. Each level of assessment focuses on quality defects of different scope and nature. For defects found at any quality assessment level, corresponding repair, retry, or downgrade operations are automatically executed based on a predefined set of handling rules for that level. After handling, the quality assessment at its current level and the affected higher levels is re-executed, forming an iterative control flow of "assessment-handling-reassessment" until all levels of assessment pass or the termination condition is triggered. Specifically, unit-level assessment focuses on the correctness of the internal structure of a single content segment; integration-level assessment focuses on the coordination of dependencies and interoperability between multiple content segments; and global-level assessment focuses on the deliverability and performance of the overall report page.

[0093] Optionally, repair operations defined in the handling rule base take precedence over degradation operations; degradation operations are only triggered when repair fails or the cost is too high.

[0094] The validated content fragments are assembled into the report template to generate the final report file. For example, the overall report framework template associated with the template_id in the executable design package is loaded, and the style variables in the template are initialized and populated according to the unified style data in the executable design package; the component instantiation instructions in the executable design package are traversed, and the corresponding content placeholders are located in the instantiated template according to the render_target (rendering target identifier) ​​specified in each instruction; the validated content fragments are precisely injected into the placeholder positions; according to the static resource list in the executable design package, static resources such as CSS style files, JavaScript script files, and images and fonts are associated with the template in an inline or external manner to form a complete, self-contained HTML document; the HTML document is output as the final report file; or, a headless browser or document conversion engine is called to render the HTML document and convert it into a PDF file before outputting it.

[0095] This application's embodiments resolve the core contradiction of the trade-off between efficiency, quality, and stability in automated report generation through a collaborative mechanism of concurrent generation, intelligent verification, automatic repair, and standardized assembly.

[0096] Based on the above embodiments, generating a chapter tree representing the structure of the report content based on the report source file includes: The source file of the report is cleaned to remove redundant symbols and unify the text encoding; Based on predefined regular expression rules and semantic rules, the system identifies heading tags and paragraph boundaries in the cleaned text. The chapter tree is generated based on the title tags and the content paragraph boundaries.

[0097] Predefined regular expression rules refer to a set of pre-written expressions stored in the system's rule base, used to match and capture specific pattern strings in text. They are primarily used to accurately identify explicit, formatted structural tags in a document. For example, they can be used to identify Markdown headings, list items, or specific data table separators.

[0098] Predefined semantic rules refer to a set of logical judgment conditions pre-set based on linguistic features, text statistical features, or domain knowledge. They are mainly used to infer the logical structure and semantic boundaries of text when explicit formatting marks are lacking. For example, a sequence of periods, question marks, and exclamation marks followed by spaces or line breaks and the first letter of the next sentence being capitalized can be identified as sentence boundaries, and then combined with the number of sentences to aggregate them into paragraphs.

[0099] Text cleaning is performed on the report source files. For example, the original character encoding of the report source files is detected and converted to a unified character encoding format within the system. Based on a predefined set of non-text character filtering rules, invisible control characters, irrelevant formatting symbols, and metadata tags are removed from the report source files. While filtering out redundant symbols, tags used to characterize the document structure are identified and retained, and similar tags are standardized in format. Specifically, the non-text character filtering rule set is configured to differentiate between files of different source formats. For Markdown files, hash symbols, asterisks, and hyphens are retained for structure identification; for plain text files, control characters are primarily filtered. Format standardization includes unifying different types of line breaks into the same character and normalizing the number of spaces around identified heading tags.

[0100] Based on predefined regular expression rules and semantic rules, heading tags and content paragraph boundaries in the cleaned text are identified. For example, by running a set of pre-compiled regular expression patterns, the cleaned text stream is scanned to match and extract heading tags at different levels and their corresponding heading text; wherein, the regular expression patterns are configured to recognize at least two different levels of heading syntax. The portions of the text stream located between two consecutive heading tags, as well as text blocks separated by consecutive blank lines, are initially identified as candidate paragraph blocks; for continuous text that is difficult to segment due to the lack of explicit delimiters, predefined semantic rules are applied for analysis to determine potential paragraph boundaries; wherein, the semantic rules include at least one of the following: segmentation based on a statistical threshold of sentence length; segmentation based on the occurrence of specific paragraph starting keywords or phrases; and determining topic transition points based on a topic coherence model.

[0101] A chapter tree is generated based on heading tags and content paragraph boundaries. For example, a chapter node is created for each identified heading tag, and a content node is created for each text block within an identified content paragraph boundary. Each node is assigned a unique identifier and records its type, associated text content, and position information in the original text stream. The parent-child nesting relationship between chapter nodes is determined according to the hierarchical order of heading tags, constructing a hierarchical skeleton for the chapter nodes. A higher-level heading node is the parent container for all nodes following it up to the next same or higher-level heading. Each content node is associated with and attached to the nearest and deepest-level chapter node based on its position in the original text stream, becoming a child node of that chapter node. The chapter nodes and content nodes, along with their hierarchical and hierarchical relationships, are organized into a tree-like data structure. This structure starts from the root node and forms a hierarchical relationship through the node's child node reference list, thus forming the chapter tree.

[0102] In one embodiment, the tree data structure can conform to a predefined ContentSkeleton pattern, where each node is uniquely identified by node_id and its child node identifier list is referenced by the children field, and the node type field is used to distinguish between chapter nodes and content nodes.

[0103] This application's embodiments ensure input consistency through standardized text cleaning, and achieve structural parsing of diverse formats by using a combination of regular expression rules and semantic rules. The resulting structured chapter tree provides a reliable and traceable skeletal foundation for subsequent intelligent processing.

[0104] To further explain the report generation method proposed in this application, please refer to the following embodiments.

[0105] This application specifically proposes a method and system for automatic HTML generation based on multi-stage asynchronous parsing and template-driven architecture, aiming to automate the generation of high-quality HTML reports from natural language or Markdown reports. This solution, through a layered architecture design and parallel execution mechanism, breaks down the report generation process into multiple independently executable and verifiable stages. Each stage defines clear responsibilities, execution timing, processing methods, and data interaction paths, thereby significantly improving overall generation speed and system reliability while ensuring the quality and structural consistency of the generated results.

[0106] refer to Figure 2 , Figure 2 This is a system architecture diagram of the report generation method provided in this application, which mainly includes the following functional modules: (1) Input parsing module: used to receive and parse the original report input, and identify the chapter structure and semantic information; (2) Intent understanding and report design module: Based on the language model, the report theme, structure and visual requirements are analyzed to generate the report design data structure (Report Design Schema). (3) User Material and Specification Management Module: Manages enterprise templates, static resources and parameterized visual rule sets to form template and style definitions; (4) Style and Design Integration Module: Responsible for integrating Report Design Schema with TSD in a standardized manner and outputting an executable design package. (5) Report generation and verification module: Based on the Design Package, HTML fragments are generated and layered verification is performed to ensure the correctness of the syntax, semantics and style of the output content; (6) Template assembly and output module: Assemble the verified fragments into the specified template structure to generate the final HTML report and optional PDF file.

[0107] The modules communicate with each other through a unified JSON format data structure, forming a closed-loop system from input to output.

[0108] The entire report generation process includes five stages: input parsing, design generation, style integration, report generation and verification, and template assembly and output.

[0109] (1) Input parsing stage: The input parsing module receives the report source file (such as Markdown, natural language or structured data) submitted by the user and performs the following steps on it: The text cleaning unit is responsible for removing redundant symbols and unifying character encoding; The hierarchical parsing unit extracts the title hierarchy and chapter boundaries based on regular expressions and semantic rules (such as distinguishing first-level and second-level chapters by different numbers of #), and generates a chapter tree; The output result is a standardized "content skeleton structure", which includes chapters and paragraphs.

[0110] (2) Intent Understanding and Report Design Stage: Based on the skeletal structure of the input content, the intent understanding and report design module uses language models and semantic rules to identify the report intent, data type, and display objectives, and outputs a semantic design blueprint. The intent understanding and report design module includes a semantic analysis subunit, a structure planning subunit, and a design generation subunit. Specifically, the system first performs semantic extraction on the input text through the semantic analysis subunit to identify the display objectives (such as trend analysis, comparative analysis, geographical distribution display, etc.), then constructs the chapter hierarchy through the structure planning subunit, and finally generates the Report Design Schema through the design generation subunit.

[0111] (3) User Material and Specification Management Stage: The user material and specification management module is the core foundation for achieving style controllability and personalized output in this application. This module stores and manages three types of information: Template files: include the overall report framework template, component templates, and placeholder definition files, which describe the layout and rendering logic of each part; Static resources: including company logo, color scheme files, icon library, background images, and font files; Parameterized rule set: Defines style parameters such as color, font, margin, shadow, and default color scheme of charts, and stores them in the form of hierarchical configuration files.

[0112] This application designs a TSD data structure to express templates and specification information. This structure uniformly manages template definitions, resource paths, and style parameters for use by upper-level modules. The modules provide API interfaces for template retrieval, material loading, and rule querying, and support access permission verification and version control.

[0113] (4) Style and Design Integration Stage: The Style and Design Integration module receives the Report Design Schema from the Intent Understanding and Report Design module and the TSD from the User Material and Specification Management module, executes the rule-based integration algorithm, and generates a unified executable design package. The Design Package is the output of the Style and Design Integration module and the direct input of the Report Generation and Verification module. It integrates semantic structure, template rules, material paths, and component instantiation instructions to ensure that the generation process is controllable and traceable.

[0114] (5) Report Generation and Validation Phase: The report generation and validation module performs report content generation and quality validation based on the Design Package. The validation goal is to ensure that each generated fragment (HTML fragment, Chart JSON, Table HTML) satisfies validation_contracts in terms of syntax, semantics, and constraints. Validation adopts a four-step loop of "assertion + repair + retry + degradation" until it passes or the error limit is reached. The system adopts an asynchronous concurrency mechanism, with each component instance corresponding to an independent generation task. HTML fragments, chart configurations, or table code are generated by the language model or rendering engine. A three-layer validation algorithm is used: 1) Unit Validation: Checks HTML syntax, JSON structure, required fields, and data contracts. Specifically, HTML syntax checks include: tag closure, attribute quote matching, and prevention of inline script errors (static parser). DOM ID validation checks ID uniqueness (within the current document scope), and performs suffixing if conflicts occur (e.g., id_1, id_2). JSON / JS configuration validation (charts): JSON parse validation, required field existence, field type checks (number / string / array), and enum value constraints (e.g., color_palette must be in the optional list). Data contract validation checks required fields, minimum number of rows, and data range according to validation_contracts (e.g., sales_value >= 0).

[0115] Repair strategies (unit level): Syntax errors: Adopt the principle of minimal modification (add closing tags, fix quotation marks, escape special characters). Missing fields: If a default mapping exists (provided by the component contract), automatically fill it in; otherwise, use a downgraded template (simple_table / placeholder_chart) and log a warning. Insufficient data: Apply the downgrade strategy specified in notes.designer_comments (e.g., "downgrade to a Top 5 list").

[0116] 2) Integration Validation: Detects component dependencies, script conflicts, and the validity of resource references. Specifically, dependency validation: Verifies the existence of the chart data source (data query results are available) and the existence of reference indexes in the reference table. Resource reference validation: Verifies the accessibility of resource paths and compliance with size / formatting requirements. Interaction conflict detection: Detects script naming conflicts and global CSS variable conflicts.

[0117] Repair strategy (integration level): Replace materials using the fallback provided by asset_manifest; encapsulate script conflicts using namespaces (component-level self-encapsulation); if the data source is missing, trigger "asynchronous data acquisition" or fall back to static text summary (depending on the strategy).

[0118] 3) Global Validation: Perform a quick rendering test to check page performance and style consistency. Specifically, renderability check: Perform a quick rendering test on the generated HTML in a headless browser or lightweight renderer (check for errors and blank rendering areas). Performance threshold check: Check if the overall page size, total number of chart scripts, and estimated first-screen rendering time are within the SLA. Style consistency check: Sample and compare whether styles conform to resolved_style, such as whether the main color is consistent and whether the font matches.

[0119] Global Repair / Degradation: If the renderability test fails, automatically roll back step by step: first remove unnecessary scripts → then replace complex charts with static images → finally, if it still fails, generate a "lightweight" HTML containing only text and tables and report the problem for manual review.

[0120] The validation process follows a "detect-repair-retry-degradation" strategy. The system first attempts to automatically fix errors (such as adding closing labels or filling in default parameters). If this still fails, it automatically degrades to using simplified components (such as replacing dynamic charts with static tables). All validation actions are logged for traceability and performance statistics.

[0121] (6) Template Assembly and Output Stage: The template assembly and output module receives the validated content fragments, inserts them into the template placeholders, and generates the final report file. The module performs four steps: template parsing, content insertion, resource validation, and file export. The output HTML report can be rendered directly in a browser or converted to PDF as needed. After assembly, the system generates version information and execution logs to support reproduction and comparison.

[0122] This application achieves a deep understanding of the report content's underlying intent through semantic analysis and structural planning. By integrating design intent with style specifications, it ensures that the generated results, while adhering to corporate standards, can flexibly adapt to specific content needs. This solves the problems of overly rigid traditional template filling methods and the strong randomness of end-to-end generation methods using large language models. Thus, while ensuring a high degree of automation and intelligence throughout the entire generation process, it achieves determinism in the generated results across the three dimensions of document structure, visual style, and content semantics.

[0123] The report generation apparatus provided in this application is described below. The report generation apparatus described below and the report generation method described above can be referred to in correspondence.

[0124] refer to Figure 3 The report generation apparatus provided in this application includes: Data parsing module 301 is used to generate a chapter tree representing the structure of the report content based on the report source file; The semantic analysis and structural planning module 302 is used to perform semantic analysis and structural planning on each chapter based on the chapter tree to generate report design pattern data; The fusion module 303 is used to fuse the report design pattern data and the set template and style definition TSD data to generate an executable design package; The report generation module 304 is used to generate a final report file based on the executable design package.

[0125] The report generation apparatus provided in this application generates a chapter tree representing the structure of the report content based on the report source file; performs semantic analysis and structural planning on each chapter based on the chapter tree to generate report design pattern data; integrates the report design pattern data with the set TSD data to generate an executable design package; and generates the final report file based on the executable design package. This application achieves a deep understanding of the report content's intent through semantic analysis and structural planning; by integrating design intent with style specifications, it ensures that the generated results, while adhering to enterprise standards, can flexibly adapt to specific content needs. This solves the problems of overly rigid traditional template-filling methods and the strong randomness of end-to-end generation methods using large language models. Thus, while ensuring a high degree of automation and intelligence throughout the entire generation process, it achieves determinism in the three dimensions of document structure, visual style, and content semantics.

[0126] In one embodiment, the fusion module 303 is further configured to: The parameterized rule set in the TSD data is parsed, and the style preferences carried in the report design pattern data are read to establish a style priority mapping relationship; wherein, in the style priority mapping relationship, the local style parameters of the report design pattern data have a higher priority than the global style parameters of the TSD data. Based on the style priority mapping relationship, the local style parameters and global style parameters are merged to generate unified style resolution data; Based on the component contract in the TSD data, the visual component instances defined in the report design pattern data are bound to the parameter interface that matches the component contract, and a component instantiation instruction is generated. The style resolution data, the component instantiation instructions, and the static resource list extracted from the TSD data are encapsulated into the executable design package.

[0127] In one embodiment, the fusion module 303 is further configured to: Based on the component type identifier of each visual component instance defined in the report design pattern data, a matching interface specification is searched in the component contract set of the TSD data; Based on the set of required data fields defined in the matched interface specification, verify the completeness of the data mapping relationship in the visual component instance; Based on predefined parameter synthesis rules, a complete set of rendering parameters is generated for the visual component instance; Based on the verified data mapping relationship and the complete rendering parameter set, the component instantiation instruction is generated.

[0128] In one embodiment, the semantic analysis and structural planning module 302 is further configured to: Semantic analysis is performed on the text content of each chapter in the chapter tree to obtain the display target of each chapter; Based on the chapter tree and the display objectives of each chapter, the structural planning results of each chapter are determined; Based on the chapter tree, the display objectives of each chapter, and the structural planning results of each chapter, report design pattern data is generated.

[0129] In one embodiment, the report generation module 304 is further configured to: Based on the executable design package, content fragments corresponding to multiple visual components are generated asynchronously and concurrently. Perform layered verification and repair on each of the content segments; the layered verification includes unit-level verification, integration-level verification and global-level verification, and each level of verification is associated with an automatic repair or degradation strategy. The validated content fragments are assembled into the report template to generate the final report file.

[0130] In one embodiment, the data parsing module 301 is further configured to: The source file of the report is cleaned to remove redundant symbols and unify the text encoding; Based on predefined regular expression rules and semantic rules, the system identifies heading tags and paragraph boundaries in the cleaned text. The chapter tree is generated based on the title tags and the content paragraph boundaries.

[0131] Figure 4 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 4 As shown, the electronic device may include a processor 410, a communications interface 420, a memory 430, and a communication bus 440, wherein the processor 410, communications interface 420, and memory 430 communicate with each other via the communication bus 440. The processor 410 can call logical instructions in the memory 430 to execute a report generation method, which includes: generating a chapter tree representing the structure of the report content based on the report source file; performing semantic analysis and structural planning on each chapter based on the chapter tree to generate report design pattern data; fusing the report design pattern data with the set template and style definition (TSD) data to generate an executable design package; and generating the final report file based on the executable design package.

[0132] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0133] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the report generation method provided by the above methods. The method includes: generating a chapter tree representing the structure of the report content based on the report source file; performing semantic analysis and structural planning on each chapter based on the chapter tree to generate report design pattern data; fusing the report design pattern data and the set template and style definition (TSD) data to generate an executable design package; and generating the final report file based on the executable design package.

[0134] In another aspect, this application also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the report generation method provided by the above methods. The method includes: generating a chapter tree representing the structure of the report content based on a report source file; performing semantic analysis and structural planning on each chapter based on the chapter tree to generate report design pattern data; fusing the report design pattern data and set template and style definition (TSD) data to generate an executable design package; and generating a final report file based on the executable design package.

[0135] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0136] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0137] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A report generation method, characterized in that, include: Based on the report source file, generate a chapter tree representing the structure of the report content; Based on the chapter tree, semantic analysis and structural planning are performed on each chapter to generate report design pattern data; The report design pattern data and the set template and style definition TSD data are merged to generate an executable design package; Based on the executable design package, the final report file is generated.

2. The report generation method according to claim 1, characterized in that, The process of fusing the report design pattern data and the set template and style definition TSD data to generate an executable design package includes: The parameterized rule set in the TSD data is parsed, and the style preferences carried in the report design pattern data are read to establish a style priority mapping relationship; wherein, in the style priority mapping relationship, the local style parameters of the report design pattern data have a higher priority than the global style parameters of the TSD data. Based on the style priority mapping relationship, the local style parameters and global style parameters are merged to generate unified style resolution data; Based on the component contract in the TSD data, the visual component instances defined in the report design pattern data are bound to the parameter interface that matches the component contract, and a component instantiation instruction is generated. The style resolution data, the component instantiation instructions, and the static resource list extracted from the TSD data are encapsulated into the executable design package.

3. The report generation method according to claim 2, characterized in that, The step of binding visual component instances defined in the report design pattern data to parameter interfaces matching the component contracts based on the component contracts, and generating component instantiation instructions, includes: Based on the component type identifier of each visual component instance defined in the report design pattern data, a matching interface specification is searched in the component contract set of the TSD data; Based on the set of required data fields defined in the matched interface specification, verify the completeness of the data mapping relationship in the visual component instance; Based on predefined parameter synthesis rules, a complete set of rendering parameters is generated for the visual component instance; Based on the verified data mapping relationship and the complete rendering parameter set, the component instantiation instruction is generated.

4. The report generation method according to claim 1, characterized in that, The step of performing semantic analysis and structural planning on each chapter based on the chapter tree to generate report design pattern data includes: Semantic analysis is performed on the text content of each chapter in the chapter tree to obtain the display target of each chapter; Based on the chapter tree and the display objectives of each chapter, the structural planning results of each chapter are determined; Based on the chapter tree, the display objectives of each chapter, and the structural planning results of each chapter, report design pattern data is generated.

5. The report generation method according to claim 1, characterized in that, The process of generating the final report file based on the executable design package includes: Based on the executable design package, content fragments corresponding to multiple visual components are generated asynchronously and concurrently. Perform layered verification and repair on each of the content segments; the layered verification includes unit-level verification, integration-level verification and global-level verification, and each level of verification is associated with an automatic repair or degradation strategy. The validated content fragments are assembled into the report template to generate the final report file.

6. The report generation method according to claim 1, characterized in that, The process of generating a chapter tree representing the structure of the report content based on the report source file includes: The source file of the report is cleaned to remove redundant symbols and unify the text encoding; Based on predefined regular expression rules and semantic rules, the system identifies heading tags and paragraph boundaries in the cleaned text. The chapter tree is generated based on the title tags and the content paragraph boundaries.

7. A report generation device, characterized in that, include: The data parsing module is used to generate a chapter tree representing the structure of the report content based on the report source file; The semantic analysis and structure planning module is used to perform semantic analysis and structure planning on each chapter based on the chapter tree to generate report design pattern data; The fusion module is used to fuse the report design pattern data and the set template and style definition TSD data to generate an executable design package; The report generation module is used to generate the final report file based on the executable design package.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the report generation method as described in any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the report generation method as described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the report generation method as described in any one of claims 1 to 6.

Images