A multi-format label generation method, system and storage medium

Abstract

The application provides a multi-format label generation method, system and storage medium. The method comprises: receiving label configuration information input through a visualization interface, parsing the label configuration information to generate a corresponding declarative rule description language; arranging and executing a dynamic data processing flow based on the declarative rule description language to obtain dynamic data from multiple data sources; performing a caching operation on component instances used in the dynamic data processing flow according to a predefined caching strategy to obtain reusable cache instances during execution of the dynamic data processing flow; fusing the dynamic data and the cache instances and rendering an internal document model through a precompiled instruction sequence; and inputting the internal document model into a multi-format output pipeline to perform conversion processing through a format filter and output at least two final label files in different formats. The application can flexibly and efficiently output multiple format files with consistent styles.

Description

Technical Field

[0001] This application relates to the field of document generation technology, and in particular to a method, system and storage medium for generating multi-format tags. Background Technology

[0002] In the field of automated document generation technology, especially in scenarios requiring batch generation of logistics waybills, product labels, and enterprise reports, existing technologies typically employ programmatic development using document libraries such as iText. Traditional solutions often define the structure and style of label templates through hard coding, tightly coupling dynamic data acquisition logic, format conversion rules, and specific rendering output code. This approach makes template creation and modification heavily reliant on developers, preventing business users from making independent adjustments. Furthermore, changes in dynamic data sources or new output format requirements necessitate in-depth modifications to the core generation code, leading to high system iteration costs and slow response times. In addition, to generate label files in different formats, existing solutions usually require the introduction of multiple independent tools or libraries, facing issues such as style distortion and excessively large file sizes due to redundant resource usage during the conversion process. Therefore, existing label generation methods suffer from tight coupling across multiple stages, including template definition, data processing, resource management, and format output, resulting in inflexible overall configuration, low resource utilization, and difficulty in efficiently adapting to diverse format output requirements. Summary of the Invention

[0003] In order to flexibly and efficiently output multiple format files with consistent styles, this application provides a method, system and storage medium for generating multi-format tags.

[0004] Firstly, this embodiment provides a method for generating multi-format tags, the method comprising:

[0005] Receive tag configuration information input through a visual interface, parse the tag configuration information to generate a corresponding declarative rule description language;

[0006] Based on the declarative rule description language, a dynamic data processing flow is orchestrated and executed to obtain dynamic data from multiple data sources;

[0007] When executing the dynamic data processing flow, the component instances used in the dynamic data processing flow are cached according to a predefined caching strategy to obtain reusable cache instances.

[0008] The dynamic data and the cached instance are merged and rendered using a pre-compiled instruction sequence to generate an internal document model;

[0009] The internal document model is input into a multi-format output pipeline for conversion processing through a format filter to output a final tag file in at least two different formats.

[0010] In some embodiments, parsing the tag configuration information to generate the corresponding declarative rule description language includes:

[0011] The tag configuration information is parsed to extract configuration elements that include at least field identifiers, data source definitions, format conversion rules, and conditional rendering rules;

[0012] The configuration elements are converted into corresponding declarative statements according to the predefined syntax mapping rules. Specifically, a declarative data source statement describing the data acquisition path is generated according to the field identifier and the data source definition. A declarative conversion statement containing ordered operation steps is generated according to the format conversion rules. A declarative conditional statement containing logical conditions and execution actions is generated according to the conditional rendering rules.

[0013] The declarative data source statement, declarative transformation statement, and declarative conditional statement are combined and encapsulated to form a declarative rule description language.

[0014] In some embodiments, orchestrating and executing a dynamic data processing flow based on the declarative rule description language to obtain dynamic data from multiple data sources includes:

[0015] The declarative data source statement is instantiated into a corresponding data acquisition operation unit, the declarative transformation statement is instantiated into a corresponding data transformation operation unit, and the declarative conditional statement is instantiated into a corresponding conditional execution operation unit.

[0016] The data input-output relationship between the data acquisition operation unit, the data transformation operation unit, and the conditional execution operation unit is analyzed to construct a process topology structure that represents their dependencies and execution order;

[0017] Based on the process topology, multiple data acquisition operation units that have no dependencies are combined into a parallel acquisition group;

[0018] According to the process topology, data acquisition operation units, data transformation operation units, and conditional execution operation units with dependencies are sequentially connected to form a sequential processing chain;

[0019] A dynamic data processing flow is generated based on the parallel acquisition group and the sequential processing chain.

[0020] The dynamic data processing flow is executed to obtain dynamic data from multiple data sources.

[0021] In some embodiments, the step of caching component instances used in the dynamic data processing flow according to a predefined caching strategy to obtain reusable cache instances during the execution of the dynamic data processing flow includes:

[0022] Determine whether the component instances in the dynamic data processing flow are marked as reusable;

[0023] If so, generate a unique cache identifier containing a content hash value based on the attribute information of the component instance, and query the predefined multi-level cache pool based on the unique cache identifier;

[0024] If the unique cache identifier is not found in the high-speed memory cache, then query the persistent disk cache;

[0025] If the unique cache identifier is matched in the persistent disk cache, the corresponding cache instance is loaded into the high-speed memory cache.

[0026] If neither is found, a new component instance is created, and the new component instance is associated with the unique cache identifier and stored in both the high-speed memory cache and the persistent disk cache.

[0027] According to the preset lifecycle management strategy, the cache instances in the high-speed memory cache are monitored and evicted to obtain reusable cache instances.

[0028] In some embodiments, fusing the dynamic data and the cached instance and rendering an internal document model using a pre-compiled instruction sequence includes:

[0029] Obtain the JSON template corresponding to the tag configuration information, and precompile the JSON template into a precompiled instruction sequence that can be directly executed to drive document generation operations;

[0030] The dynamic data obtained from the dynamic data processing flow is filled into the corresponding position of the template using the pre-compiled instruction sequence, and the cache instance is called to perform style rendering to generate the initial document model;

[0031] After inserting the pagination identifier, the corresponding component instance in the cache instance is automatically introduced according to the reusable component identifier marked in the tag configuration information, and the component instance is rendered at the specified position of the subsequent page to generate an internal document model with a continuous document structure.

[0032] In some embodiments, inputting the internal document model to a multi-format output pipeline for conversion processing via a format filter to output a final tag file in at least two different formats includes:

[0033] A high-fidelity internal model is generated based on the internal document model and the pre-compiled instruction sequence;

[0034] The high-fidelity internal model is input into a unified format output pipeline;

[0035] According to the output format requirements corresponding to the label configuration information, at least two corresponding format conversion filters are called from the preset format conversion filter set. The format conversion filter set includes at least a PDF filter for directly outputting the high-fidelity internal model, an image conversion filter for converting the high-fidelity internal model into an image format, and a vector conversion filter for converting the high-fidelity internal model into a vector graphic.

[0036] The high-fidelity internal model is converted in parallel or serially using the at least two format conversion filters that are invoked, and the cache instance is shared during the processing to output final tag files in at least two different formats with consistent styles.

[0037] In some embodiments, receiving tag configuration information input via a visual interface includes:

[0038] Based on the canvas configured in the visual interface, the layout constraints of the components placed by the user in the canvas by dragging and dropping are checked in real time to obtain the initial configuration information with regular position.

[0039] In response to the simulation parameters that the user binds to the dynamic fields in the initial configuration information, the system requests simulation data from the background service based on the simulation parameters, and merges the simulation data with the initial configuration information to generate a visual preview information containing real data.

[0040] When the user confirms saving, the label configuration information corresponding to the visual preview information is verified for compliance. Once the verification is successful, the label configuration information is received.

[0041] In some embodiments, after outputting final tag files in at least two different formats, the method further includes: obtaining full-process status data of the generation task, and generating a verification report containing resource usage and format consistency based on the full-process status data.

[0042] Secondly, this embodiment provides a multi-format tag generation system, the system comprising: a parsing module, a processing module, a fusion module, and a generation module; wherein,

[0043] The parsing module is used to receive tag configuration information input through a visual interface, parse the tag configuration information to generate a corresponding declarative rule description language;

[0044] The processing module is used to orchestrate and execute a dynamic data processing flow based on the declarative rule description language to obtain dynamic data from multiple data sources; when executing the dynamic data processing flow, the component instances used in the dynamic data processing flow are cached according to a predefined caching strategy to obtain reusable cache instances;

[0045] The fusion module is used to fuse the dynamic data and the cache instance and generate an internal document model by rendering it through a pre-compiled instruction sequence;

[0046] The generation module is used to input the internal document model into a multi-format output pipeline for conversion processing through a format filter to output a final tag file in at least two different formats.

[0047] Thirdly, this embodiment provides a computer-readable storage medium having a computer program stored thereon that can run on a processor, wherein when the computer program is executed by the processor, it implements a multi-format tag generation method as described in the first aspect.

[0048] By employing the above method, this application receives tag configuration information input through a visual interface, parses the tag configuration information to generate a corresponding declarative rule description language. Based on the declarative rule description language, a dynamic data processing flow is orchestrated and executed to obtain dynamic data from multiple data sources. During the execution of the dynamic data processing flow, component instances used in the dynamic data processing flow are cached according to a predefined caching strategy to obtain reusable cache instances. The dynamic data and cache instances are merged and rendered using a pre-compiled instruction sequence to generate an internal document model. The internal document model is input to a multi-format output pipeline for conversion processing via a format filter to output final tag files in at least two different formats. Attached Figure Description

[0049] Figure 1 This is a flowchart of a multi-format label generation method provided in this application.

[0050] Figure 2 This is a flowchart of the method for generating a corresponding declarative rule description language by parsing tag configuration information, as provided in this application.

[0051] Figure 3 This application provides a method block diagram for orchestrating and executing a dynamic data flow based on a declarative rule description language to obtain dynamic data from multiple data sources.

[0052] Figure 4 This application provides a method block diagram for fusing dynamic data and cached instances and generating an internal document model through rendering a pre-compiled instruction sequence.

[0053] Figure 5 This is a schematic diagram of the connection of a multi-format label generation system provided in this application. Detailed Implementation

[0054] To better understand the purpose, technical solutions, and advantages of this application, it has been described and illustrated below with reference to the accompanying drawings and embodiments. However, those skilled in the art should understand that this application can be implemented without these details. It will be apparent to those skilled in the art that various modifications can be made to the embodiments disclosed in this application, and the general principles defined in this application can be applied to other embodiments and application scenarios without departing from the principles and scope of this application. Therefore, this application is not limited to the illustrated embodiments, but is consistent with the broadest scope claimed in this application.

[0055] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0056] Figure 1 This is a flowchart illustrating a multi-format label generation method provided in this application. For example... Figure 1 As shown, a method for generating multi-format tags includes the following steps:

[0057] Step S100: Receive the tag configuration information input through the visual interface, parse the tag configuration information to generate the corresponding declarative rule description language.

[0058] This application describes the process from the generation perspective. To generate multi-format labels, it is first necessary to receive label configuration information. Receiving label configuration information input through a visual interface includes the following steps:

[0059] Step S101: Based on the canvas configured in the visual interface, perform real-time layout constraint verification on the components placed in the canvas by the user through dragging and dropping to obtain the initial configuration information with regular position.

[0060] Step S102: In response to the simulation parameters bound by the user to the dynamic fields in the initial configuration information, the system requests simulation data from the background service based on the simulation parameters, and merges the simulation data with the initial configuration information to generate a visual preview information containing real data.

[0061] Step S103: When the user confirms the save, the label configuration information corresponding to the visual preview information is verified for compliance. After the verification is passed, the label configuration information is received.

[0062] Specifically, the canvas in the visual configuration interface integrates a layout constraint engine. When users add or move components such as text boxes, images, and tables on the canvas through drag-and-drop operations, the layout constraint engine runs in real time and calculates the geometric relationships between the components and the canvas boundaries, as well as between components themselves. The layout constraint engine automatically recommends and aligns to reference lines, achieving equidistant distribution and margin snapping, thereby ensuring that multiple field components are vertically left-aligned and horizontally spaced evenly. This process is real-time, providing users with visual feedback during drag-and-drop, guiding them to generate templates with well-organized layouts that conform to printing or display standards. This transforms professional typesetting work, which originally relied on manual visual inspection and adjustment, into a standardized operation completed automatically, ensuring that even non-technical personnel can efficiently produce high-quality initial configuration information.

[0063] Then, dynamic field configuration is performed. Users can input simulated parameters in the configuration interface. After capturing these parameters, the configuration layer sends a request to the backend simulated data service according to predefined interface specifications. This service parses the parameters and returns the corresponding simulated data. Subsequently, the obtained real simulated data is dynamically filled into the corresponding dynamic field positions on the canvas, and the canvas is immediately re-rendered to generate a visual preview containing the real data content, font, color, and layout. This transforms configuration verification from a static demonstration preview to a dynamic data preview. Business personnel can intuitively and accurately see the final tag generation effect during the configuration phase, achieving configuration-as-verification and reducing rework costs caused by data binding errors or format mismatches.

[0064] When the user is satisfied with the preview and clicks save, the data is not saved directly. Instead, an asynchronous verification control process is triggered. This process performs compliance checks on the tag configuration information to be saved. The checks include, but are not limited to, verifying that all dynamic fields are bound to valid data sources or default values; verifying that all required attributes of components are complete; and performing conflict detection based on canvas size and component position to confirm whether there is any risk of component overlap or content exceeding page boundaries. These verification rules are executed automatically in the background. Only when all verification items pass is the tag configuration information officially received and persistently saved. This intercepts incomplete, inconsistent, or potentially rendering-problematic invalid configurations, ensuring the receipt of high-quality tag configuration information.

[0065] After configuring and validating the tag template through the visual interface, the received and compliant tag configuration information is passed to the rule conversion stage. This transforms the interface-oriented configuration information into a standardized description form that is independent of programming languages ​​and can be directly parsed and executed by the rule engine—a declarative rule description language. Figure 2 This is a flowchart illustrating the method for generating a corresponding declarative rule description language by parsing tag configuration information, as provided in this application. For example... Figure 2As shown, parsing tag configuration information to generate the corresponding declarative rule description language includes the following steps:

[0066] Step S104: Parse the tag configuration information to extract configuration elements that include at least field identifiers, data source definitions, format conversion rules, and conditional rendering rules.

[0067] Step S105: The configuration elements are converted into corresponding declarative statements according to the predefined semantic mapping rules. Specifically, a declarative data source statement describing the data acquisition path is generated based on the field identifier and data source definition. A declarative conversion statement containing ordered operation steps is generated based on the format conversion rules. A declarative conditional statement containing logical conditions and execution actions is generated based on the conditional rendering rules.

[0068] Step S106: Combine and encapsulate the declarative data source statement, declarative transformation statement, and declarative conditional statement to form a declarative rule description language.

[0069] Specifically, after receiving the tag configuration information, the generator starts a parser that traverses the structure of the configuration information according to a predefined pattern. First, it identifies and extracts the field identifiers corresponding to all components marked as dynamic fields; these identifiers are unique codes for the components within the template. Second, for each dynamic field, the parser locates its associated configuration node and extracts the data source definition. This definition specifies the data acquisition method, such as an SQL query from a specific database table, a Redis cache key, or the address and parameters of an HTTP interface. Next, the parser extracts the format conversion rules configured for the field. These rules describe a series of processing steps required after data acquisition, such as date formatting, numerical precision adjustment, string concatenation, or currency symbol addition. Finally, the parser extracts conditional rendering rules, which define instructions that determine the final rendering style of the component based on specific data values ​​or logical conditions. This precisely deconstructs the user-defined visual configuration on the front end into a series of structured, computer-understandable configuration elements.

[0070] After extracting the configuration elements, the generation end calls a transformation engine. Based on a set of predefined semantic mapping rules, it maps each type of configuration element into statement fragments conforming to the syntax of a declarative rule description language. This transformation process is deterministic; for field identifiers and data source definitions, the transformation engine generates declarative data source statements. These statements precisely describe the complete data acquisition path, abstracting database queries and API calls into standard source types and parameter descriptions without including specific implementation code. For format conversion rules, the transformation engine generates declarative conversion statements. These statements encapsulate one or more format conversion operations, such as number formatting and prefixing, into an ordered list of steps, clearly specifying the order of operations. For conditional rendering rules, the transformation engine generates declarative conditional statements. These statements clearly express what rendering action should be performed if a field meets a specific logical condition. Thus, fragmented configuration elements are systematically transformed into declarative statements with clear semantic boundaries and independent management capabilities.

[0071] Finally, the generation end assembles the declarative data source statements, declarative transformation statements, and declarative conditional statements generated for the same dynamic field or related logical groups according to predefined combination logic. The assembly process ensures the correctness of the data flow; for example, fields referenced in conditional statements must have been defined by the data source statements. After encapsulation, a complete declarative rule description language is formed. This language typically manifests as a structured data object, fully carrying all business logic from data acquisition and processing to final rendering conditions. However, it does not contain any specific programming language instructions and serves as the sole input to the rule engine layer, achieving complete separation between configuration information and the underlying generation code. This constructs a clear and standardized intermediate transformation layer, seamlessly connecting front-end visual configuration with back-end rule execution. By parsing and converting configuration information into a unified declarative rule description language, complete decoupling of data logic and business code is achieved. Business users only need to make declarative configurations of what to do in the visual interface, without needing to know the technical details of what to do. Subsequent data acquisition, transformation and conditional rendering are all automatically executed by the rule engine after parsing the description language, which greatly increases flexibility and maintainability. Rules can be stored independently, managed in a versioned manner, and can be intuitively understood and adjusted by non-technical personnel, reducing code design work.

[0072] Step S200: Organize and execute a dynamic data processing flow based on a declarative rule description language to obtain dynamic data from multiple data sources.

[0073] After configuring and validating the tag template through a visual interface and converting the tag configuration information into a declarative rule description language, the process enters the orchestration and execution stage of the dynamic data processing flow. This transforms the declarative rule description into an executable, optimized, and efficient data processing flow, thereby enabling intelligent acquisition and processing of dynamic data from multiple data sources. Figure 3 This application provides a method block diagram for orchestrating and executing a dynamic data flow based on a declarative rule description language to obtain dynamic data from multiple data sources. For example... Figure 3 As shown, orchestrating and executing a dynamic data processing flow based on a declarative rule description language to obtain dynamic data from multiple data sources includes the following steps:

[0074] Step S201: Instantiate the declarative data source statement into the corresponding data acquisition operation unit, the declarative transformation statement into the corresponding data transformation operation unit, and the declarative conditional statement into the corresponding conditional execution operation unit.

[0075] Step S202: Analyze the data input and output relationships between the data acquisition operation unit, the data transformation operation unit, and the conditional execution operation unit to construct a process topology structure that represents their dependencies and execution order.

[0076] Step S203: Combine multiple data acquisition operation units that have no dependency relationship into a parallel acquisition group according to the process topology.

[0077] Step S204: According to the process topology, the data acquisition operation unit, data transformation operation unit and conditional execution operation unit with dependencies are connected in sequence to form a sequential processing chain.

[0078] Step S205: Generate a dynamic data processing flow based on the parallel acquisition group and the sequential processing chain orchestration.

[0079] Step S206: Execute the dynamic data processing flow to obtain dynamic data from multiple data sources.

[0080] Specifically, upon receiving a declarative rule description language, the rule engine first initiates an instantiation process. For declarative data source statements, the rule engine dynamically loads and initializes the corresponding data acquisition driver or connector based on the defined source type and parameter configuration, packaging it into a data acquisition operation unit with independent execution capabilities. This data acquisition operation unit encapsulates the logic for establishing connections, constructing queries or requests, executing acquisition operations, and handling basic network or database exceptions. Similarly, for declarative transformation statements, the rule engine parses and instantiates its internally defined ordered operation steps, such as formatting, calculation, and concatenation, into a data transformation operation unit. This data transformation operation unit is responsible for executing each step of the transformation logic sequentially. For declarative conditional statements, the rule engine parses them into conditional execution operation units, which contain built-in condition judgment logic and associated rendering or data processing operations. This transforms abstract declarative statements into concrete, schedulable execution entities, laying the foundation for subsequent process orchestration.

[0081] After instantiating all operation units, the rule engine launches a static analyzer. This static analyzer traverses all operation units, parsing their configuration information to identify the input data dependencies and output data products of each unit. Based on these input-output relationships, the analyzer constructs a process topology in the form of a directed acyclic graph. In this process topology, nodes represent individual operation units, and directed edges represent data flow directions, clearly revealing the dependencies between units. For example, a data transformation operation unit may need the output of a data acquisition operation unit as its input, while the execution of a conditional execution operation unit may depend on the result of a preceding data transformation operation unit. Constructing this process topology is a key prerequisite for achieving intelligent process orchestration, enabling a clear understanding of the entire data processing landscape.

[0082] Then, based on the established process topology, the process orchestrator in the engine identifies all data acquisition operation units that have no direct or indirect dependencies on each other. These units can perform their data acquisition tasks independently without blocking each other. The encoder intelligently groups these units into one or more parallel acquisition groups. During process execution, all data acquisition operation units within the same parallel acquisition group are scheduled to execute concurrently in a thread pool, simultaneously sending requests to their respective data sources. This fully utilizes the parallel processing capabilities of the device's computing resources, significantly reducing the total time spent acquiring data from multiple independent data sources.

[0083] Next, for operation units with dependencies within the process topology, the encoder chains them together to form one or more sequential processing chains based on the order of data flow. Each chain represents a continuous data processing pipeline. For example, a classic chain might begin with a data acquisition operation unit, transmitting its output to one or more data transformation operation units for processing. The logical judgments of these conditional execution operation units determine the final data format or trigger subsequent actions. Sequential processing chains ensure that dependent operations are executed in the correct logical order, guaranteeing the accuracy and consistency of data processing.

[0084] The process encoder integrates and assembles all the parallel acquisition groups and sequential processing chains identified above, generating a complete and structured dynamic data processing flow. This flow defines the execution blueprint for all operations—which operations can be executed in parallel, which must be executed sequentially, and how data is merged between different branches at key nodes. This flow is the final solution that can be directly interpreted and executed by the engine.

[0085] Finally, the execution engine loads the dynamically generated data processing flow and schedules its execution according to its definition. The first step involves concurrently starting all tasks in the parallel acquisition groups. The second step, based on dependencies, triggers the execution of each sequential processing chain in turn. The engine manages the entire execution process, including data transfer, monitoring the execution status of each operation unit, handling exceptions such as network timeouts and data format errors, and retrying or downgrading according to predefined strategies. The third step, when the entire process is complete, involves the engine aggregating the output of all operation units to generate a structured dynamic data set, preparing for subsequent document rendering. This approach first transforms the data processing logic from a static description to dynamic executable units through instantiation and process topology analysis, automatically clarifying complex dependencies. It then distinguishes between dependency-free parallel tasks and dependency-dependent sequential tasks, and through a hybrid orchestration model of parallel acquisition groups and sequential processing chains, maximizes the use of concurrency while ensuring the correctness of data logic, improving data processing efficiency in multi-data source scenarios. Finally, the entire orchestration and execution process is transparent to the rule configurator. Business users only need to care about the declarative description of what to do, while the complex scheduling and optimization of how to do it are automatically completed by the backend, which further enhances the low-code feature and improves flexibility and maintainability.

[0086] Step S300: When executing the dynamic data processing flow, cache the component instances used in the dynamic data processing flow according to the predefined caching strategy to obtain reusable cache instances.

[0087] While acquiring dynamic data during the dynamic data processing flow, intelligent caching operations are performed on component instances used in the flow according to a predefined caching strategy to improve resource utilization efficiency and generation performance. Specifically, caching component instances used in the dynamic data processing flow according to the predefined caching strategy to obtain reusable cached instances includes the following steps:

[0088] Step S301: Determine whether the component instance in the dynamic data processing flow is marked as reusable.

[0089] Step S302: If yes, generate a unique cache identifier containing a content hash value based on the attribute information of the component instance, and query the predefined multi-level cache pool based on the unique cache identifier.

[0090] Step S303: If the unique cache identifier is not found in the high-speed memory cache, query the persistent disk cache.

[0091] Step S304: If a unique cache identifier is found in the persistent disk cache, the corresponding cache instance is loaded into the high-speed memory cache.

[0092] In step S305, if neither is found, a new component instance is created, and the new component instance is associated with the unique cache identifier and stored in both the high-speed memory cache and the persistent disk cache.

[0093] Step S306: According to the preset lifecycle management strategy, monitor and evict cache instances in the high-speed memory cache to obtain reusable cache instances.

[0094] Specifically, during the parsing and execution of dynamic data processing, whenever a component instance, such as an image object, font object, or style object, needs to be loaded, it first checks whether the component has been marked with a reusable attribute during the visual configuration phase by the user or the system. This mark is part of the component's metadata and is passed to the rule engine layer along with the tag configuration information. Only when a component instance is explicitly marked as reusable will it enter the subsequent cache management process. Otherwise, it will be used as a one-time instance and released after use.

[0095] If a cache instance matching the unique cache identifier is not found in the high-speed memory cache, the search will continue in the predefined second-level cache, namely the persistent disk cache. The persistent disk cache stores the cache instance and its unique cache identifier in the server's non-volatile storage medium as a serialized file.

[0096] When a serialized file matching the unique cache identifier is found in the persistent disk cache, the file is deserialized, a complete component instance is reconstructed, and then this component instance is loaded into the high-speed memory cache and associated with the unique cache identifier for fast subsequent access, thereby avoiding repeated operations of loading resources from the original database.

[0097] If the unique cache identifier is found in both the high-speed memory cache and the persistent disk cache, it indicates that this component instance is being used for the first time. Based on the component type and attribute information, the corresponding resource loader will be invoked to create a brand new component instance. After successful instance creation, it is immediately associated with the generated unique cache identifier, and then a dual-write operation is performed. On one hand, the component instance is stored in the high-speed memory cache; on the other hand, it is serialized and stored in the persistent disk cache. This achieves separate storage of hot and warm data, laying the foundation for subsequent reuse.

[0098] Finally, to ensure the efficiency and stability of the high-speed memory cache, a low-priority background daemon thread is run to continuously monitor the cache usage and memory pressure. This thread tracks the access frequency and time of cache instances based on a Least Recently Used (LRU) algorithm. When memory usage exceeds a preset threshold, the daemon thread automatically initiates a cache cleanup process, prioritizing the removal of the least recently accessed cache instances. Before removal, the daemon thread verifies whether the instance has been persisted to disk. Persistent instances can be safely removed directly from memory, as they can be quickly restored from disk when needed. For non-persistent instances, a strategy determines whether to serialize them to disk before removal. This dynamic monitoring and eviction mechanism maintains a set of the most active and reusable cache instances in memory, achieving efficient resource recycling. This ensures that identical physical resources referenced by different templates or different locations within the same template are loaded and stored only once globally, achieving maximum resource reuse. Secondly, the multi-level caching strategy balances access speed and storage capacity. Frequently used hot data resides in memory for fast access, while infrequently used hot data is stored on disk to save valuable memory space. This maintains stable low memory usage and high response speed under high-concurrency tasks. Finally, the automated storage monitoring and eviction mechanism requires no manual intervention and can dynamically optimize cache content based on real-time load. This prevents memory overflow risks and ensures cache hit rate, thereby improving overall throughput, scalability, and resource utilization efficiency.

[0099] Step S400: The dynamic data and cached instances are merged and rendered using a pre-compiled instruction sequence to generate an internal document model.

[0100] After acquiring dynamic data and intelligently caching component instances, the document synthesis stage begins. This stage efficiently and accurately integrates loose dynamic data and reusable style resources into a complete document entity that can be further output, according to a user-defined template structure. Figure 4 This is a block diagram of a method provided in this application for fusing dynamic data and cached instances and rendering an internal document model using a pre-compiled instruction sequence. For example... Figure 4 As shown, fusing dynamic data and cached instances and rendering an internal document model using a pre-compiled instruction sequence includes the following steps:

[0101] Step S401: Obtain the JSON template corresponding to the tag configuration information, and precompile the JSON template into a precompiled instruction sequence that can be directly executed to drive the document generation operation.

[0102] Step S402: Use the pre-compiled instruction sequence to fill the dynamic data obtained from the dynamic data processing flow into the corresponding position of the template, and call the cache instance to perform style rendering to generate the initial document model.

[0103] Step S403: After inserting the pagination identifier, the corresponding component instance in the cache instance is automatically imported according to the reusable component identifier marked in the tag configuration information, and the component instance is rendered at the specified position of the subsequent page to generate an internal document model with a continuous document structure.

[0104] Specifically, before rendering begins, the generator first retrieves the corresponding JSON template description file from the template repository based on the unique identifier in the received tag configuration information. Then, a pre-compiler is started to perform deep parsing and transformation of the JSON template. The pre-compiler translates and organizes the static layout information, attribute configurations, and placeholders for dynamic fields into a linear, compact sequence of pre-compiled instructions according to a predefined, efficient internal opcode specification. This sequence of pre-compiled instructions is essentially an ordered set of atomic document manipulation commands, directly reflecting the core API call logic of the underlying document generation library, but eliminating the overhead of repeated parsing of the original JSON structure at runtime. Thus, through this pre-compilation process, the interpreted template description is transformed into a sequence of pre-compiled instructions that can be efficiently and directly executed by the rendering engine.

[0105] The rendering engine loads and executes the pre-compiled instruction sequence generated above. The engine executes each instruction sequentially. When an instruction indicates the need for dynamic content population, the engine precisely locates and extracts the corresponding data value from the structured dynamic data set output by the rules engine based on the dynamic field identifier embedded in the instruction. Because the pre-compiled instruction sequence clearly defines the target location and context for data insertion, the data population process is direct and efficient. When rendering static styles or reusable components, the engine does not recreate resource instances based on attribute descriptions. Instead, it executes another type of instruction, which directly requests and retrieves stored component instances through a unique cache identifier carried in the query request or embedded within the instruction. The engine then binds and merges the dynamic data with these cache instances, calls the drawing interface of the underlying document library, and gradually builds an initial document model containing all content and styles in memory. This ensures the global uniqueness of resources with the same style and enables rapid data and style synthesis.

[0106] Finally, for tags containing dynamic tables, long lists, or other content that may span multiple pages, the initial document model triggers pagination logic during rendering. When the content exceeds the capacity of a single page, the rendering engine automatically inserts pagination markers. The key lies in the continuous rendering processing after pagination, which involves detecting which components in the current template are marked as reusable. When generating a new page, the rendering engine does not start a separate rendering process. Instead, guided by the pre-compiled instruction sequence and tag configuration information, it automatically identifies reusable component markers that need to reappear on subsequent pages. The engine then requests the cache instances corresponding to these markers from the cache pool again and renders them precisely to their predetermined positions on the new page. Simultaneously, dynamic content spanning multiple pages continues to be smoothly populated and rendered based on the pre-compiled instruction sequence. Thus, an internal document model for a multi-page document is constructed, ensuring consistency in style across all pages and avoiding repeated embedding of components on each page by reusing cache instances, generating a structurally complete, resource-light, and layout-continuous internal document model. By precompiling the JSON template into a sequence of instructions, template parsing is decoupled from runtime rendering, eliminating the overhead of parsing, traversing, and validating JSON on each generation. This significantly improves the startup and execution efficiency of the rendering engine, especially for complex templates or high-concurrency generation scenarios. Furthermore, during rendering, precompiled instructions directly call cached instances, enabling a seamless integration of dynamic data and instantiated, reusable style resources. This not only ensures absolute consistency of fixed style elements across multiple pages but also fundamentally avoids the linear growth in file size caused by repeatedly embedding the same resources across multiple pages. Combined with a component caching strategy, the final generated document's internal model maintains visual design consistency while achieving optimal storage space optimization, providing a high-quality, lightweight intermediate representation foundation for efficient and flexible output of various file formats.

[0107] Step S500: Input the internal document model into the multi-format output pipeline for conversion processing through a format filter to output a final tag file in at least two different formats.

[0108] After fusing dynamic data with cached instances through a pre-compiled instruction sequence to generate a structurally complete and resource-light internal document model, this model contains all the content and style information of the tags, but it is not the final business file itself. To meet the differentiated file format requirements of different application scenarios, the internal document model will be input into a multi-format output pipeline. After a series of format filter conversions, it will finally output at least two different formatted tag files with strictly consistent styles, either in parallel or serially. The process of inputting the internal document model into the multi-format output pipeline for format filter conversion to output at least two different formatted tag files includes the following steps:

[0109] Step S501: Generate a high-fidelity internal model based on the internal document model and the pre-compiled instruction sequence.

[0110] Step S502: Input the high-fidelity internal model into the unified format output pipeline.

[0111] Step S503: Based on the output format requirements corresponding to the label configuration information, call at least two corresponding format conversion filters from the preset format conversion filter set. The format conversion filter set includes at least a PDF filter for directly outputting the high-fidelity internal model, an image conversion filter for converting the high-fidelity internal model into an image format, and a vector conversion filter for converting the high-fidelity internal model into a vector graphic.

[0112] Step S504: Perform parallel or serial conversion processing on the high-fidelity internal model using at least two format conversion filters that have been invoked, and share cache instances during the processing to output final tag files in at least two different formats with consistent styles.

[0113] Specifically, the internal document model generated in the previous step, containing specific content and resource references, is deeply bound and enhanced with the pre-compiled instruction sequence that defines its structure and rendering logic, forming a high-fidelity intermediate representation independent of any specific output format—the high-fidelity internal model. That is, the generation end does not directly use the original internal document model, which may contain runtime state, for format conversion; instead, it initiates a model encapsulation process. This process is based on the page tree structure, coordinate information, text flow, and all references to cached instances in the internal document model, combined with the atomic rendering operations and their execution order defined by the pre-compiled instruction sequence. These two parts of information are integrated and serialized to construct a self-describing, platform-neutral high-fidelity internal model. This model accurately records the geometric attributes, style attributes, and hierarchical and sequential relationships of each visual element, ensuring complete information fidelity from content to style, laying a solid foundation for subsequent lossless conversion to any target format.

[0114] After generating a high-fidelity internal model, it is used as a data source and injected into a pre-built, standardized format output pipeline. This pipeline employs a pipeline filter architecture, with its inlet receiving a unified high-fidelity internal model and its outlet connecting to different file output streams. At the core of the pipeline is a scalable filter chain. All necessary format conversion operations are performed by connecting the appropriate format conversion filter to this pipeline. This ensures that regardless of the output format, the starting point for conversion is the same authoritative, high-fidelity intermediate representation, fundamentally eliminating the risk of style deviations caused by inconsistent conversion sources and providing a unified scheduling and management entry point for the processing flow.

[0115] While sending the high-fidelity internal model into the format output pipeline, the system dynamically filters and calls from a pre-defined set of format conversion filters based on the output format requirements specified in the tag configuration information associated with the current generation task. This set is a pluggable component library that includes at least the following core format conversion filters: PDF filter, image conversion filter, and vector conversion filter. The PDF filter directly identifies and processes the high-fidelity internal model, accurately reconstructing the PDF document structure, embedding fonts, locating images, and outputting a standard PDF file by calling the underlying PDF document library API. Essentially, it compiles the internal model back to its most faithful original document format. The image conversion filter converts the high-fidelity internal model into a bitmap image. Its working principle is to first use the same rendering engine as the PDF filter to rasterize the high-fidelity internal model page by page on a virtual canvas in memory, generating a high-resolution bitmap image buffer, and then outputting it as a PNG or JPEG image file according to the configured encoding parameters. The vector conversion filter generates vector graphics formats. It parses the graphic drawing instructions and text descriptions in the high-fidelity internal model and converts them into SVG documents composed of vector elements such as paths and text. This is suitable for web display scenarios that require infinite scaling and small file size. Depending on the requirements, at least two different format conversion filters from the above set are invoked simultaneously and connected to the format output pipeline sequentially or in parallel.

[0116] After receiving multiple invoked format conversion filters, the format output pipeline initiates the conversion processing flow. To improve overall throughput, the pipeline scheduler arranges for different format conversion tasks that are independent of each other to be executed in parallel. Each format conversion filter processes a copy or reference to the same high-fidelity internal model in an independent worker thread or process. When performing rendering operations, all format conversion filters do not reload or create resource instances such as fonts and images based on the resource descriptions in the model. Instead, they request the already instantiated and cached component objects from a unified multi-level cache pool through the cache instance identifier recorded in the model. Thus, a physical font file or image has only one instance in memory, which is shared and referenced by multiple conversion processes such as PDF rendering and PNG rendering. Through this mechanism of shared cache instances, not only is the repeated loading of resources and memory consumption during the generation of different format files avoided, but more importantly, it ensures that the final output tag files of different formats such as PDF files, PNG images, and SVG graphics are completely consistent in all style details such as font representation, image content, and color space, achieving style-consistent output. Finally, the format output pipeline collects the data streams processed by each filter and writes them to the corresponding file storage or returns them directly to the caller, thereby efficiently and collaboratively completing the task of generating multi-format tags.

[0117] Preferably, after outputting the final tag file in at least two different formats, the method further includes: obtaining the full-process status data of the generation task, and generating a verification report containing resource usage and format consistency based on the full-process status data.

[0118] Specifically, a lightweight state tracker is launched when the generation task begins. This state tracker is embedded in key nodes of the dynamic data processing flow, caching operations, pre-compiled instruction sequence rendering, and multi-format output pipeline. During the execution of the dynamic data processing flow, the state tracker records the execution status, time consumption, and whether retry or degradation strategies are triggered for each data acquisition operation unit, data transformation operation unit, and conditional execution operation unit. During caching operations, it records the query hit rate of each level of cache, the number of cache instance loading and creation, and cache eviction events. During the pre-compiled instruction sequence rendering stage, it records the template parsing time, dynamic data filling time, and pagination calculation information. In the multi-format output pipeline, it records the start time, processing time, and output file size of each format conversion filter. All state data is accompanied by a timestamp and a unique task identifier, and is sent in real time to the central state aggregation service for aggregation and storage in the form of a structured log stream.

[0119] After the task is completed, the verification report generator extracts the full-process status dataset related to the task from the central status aggregation service and performs multi-dimensional analysis. Resource usage analysis includes: counting the total number of component instances cached in memory during task execution and their total memory usage, comparing it with the theoretical resource usage without a caching strategy, and calculating the memory saving ratio; counting the number of cache instances successfully reused in persistent disk cache and their corresponding original resource sizes, quantifying the optimization effect at the input / output level; and counting the number of shared references to the same cache instance when each format conversion filter in the multi-format output pipeline is executed, verifying the actual achievement of zero resource duplication. Format consistency verification includes: extracting the corresponding rendering area of ​​the same content element in different format final tag files from the multi-format output pipeline, such as the same coordinate area of ​​the same text block in PDF files and PNG images, and performing pixel-level or content-level comparison using image and text parsing technology to verify its font, font size, color, position, and whether there is any deformation or distortion; at the same time, the verification report will include comparison screenshots or difference data of key areas and use consistency scores for quantitative display. Finally, all analysis results and verification data are automatically integrated into a structured electronic report, which includes a task overview, performance metrics, anomaly alerts, and optimization suggestions. On the one hand, based on detailed resource usage data, operations personnel can accurately assess the actual effectiveness of caching strategies, identify resource consumption hotspots, and provide data support for subsequent system tuning and capacity planning, thereby continuously improving the system's resource utilization efficiency and economy. On the other hand, automated multi-format consistency verification fundamentally ensures strict uniformity in style and content for output files in different formats such as PDF and PNG, eliminating business risks caused by differences introduced during conversion and enhancing the reliability and professionalism of system output. Furthermore, this closed-loop verification mechanism provides a self-verification and continuous improvement capability, making the process of large-scale, high-concurrency tag generation tasks transparent, controllable, and continuously optimizable while maintaining high-quality output.

[0120] Figure 5 This is a schematic diagram illustrating the connection of a multi-format label generation system provided in this application. For example... Figure 5 As shown, a multi-format label generation system includes: a parsing module, a processing module, a fusion module, and a generation module.

[0121] The system comprises the following modules: A parsing module receives tag configuration information input through a visual interface and parses it to generate a corresponding declarative rule description language. A processing module orchestrates and executes a dynamic data processing flow based on the declarative rule description language to obtain dynamic data from multiple data sources. During the execution of the dynamic data processing flow, it caches component instances used in the flow according to a predefined caching strategy to obtain reusable cached instances. A fusion module merges the dynamic data and cached instances and renders them using a pre-compiled instruction sequence to generate an internal document model. A generation module inputs the internal document model into a multi-format output pipeline, where it undergoes format filtering to output a final tag file in at least two different formats.

[0122] The other functions performed by the parsing module, processing module, fusion module, and generation module, as well as the technical details of each function, are the same as or similar to the corresponding features in the multi-format tag generation method described above, so they will not be repeated here.

[0123] This application also provides a computer storage medium storing a computer program that, when run on a computer, enables the computer to execute the steps in the multi-format label generation method described above.

[0124] It should be understood that although the steps in the flowcharts in the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order requirement for the execution of these steps, and they may be performed in other orders.

[0125] The above description is only a partial embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for generating multi-format tags, characterized in that, The method includes: Receive tag configuration information input through a visual interface, parse the tag configuration information to generate a corresponding declarative rule description language; Based on the declarative rule description language, a dynamic data processing flow is orchestrated and executed to obtain dynamic data from multiple data sources; When executing the dynamic data processing flow, the component instances used in the dynamic data processing flow are cached according to a predefined caching strategy to obtain reusable cache instances. The dynamic data and the cached instance are merged and rendered using a pre-compiled instruction sequence to generate an internal document model; The internal document model is input into a multi-format output pipeline for conversion processing via a format filter to output a final tag file in at least two different formats; The step of fusing the dynamic data and the cached instance and generating an internal document model through rendering using a pre-compiled instruction sequence includes: Obtain the JSON template corresponding to the tag configuration information, and precompile the JSON template into a precompiled instruction sequence that can be directly executed to drive document generation operations; The dynamic data obtained from the dynamic data processing flow is filled into the corresponding position of the template using the pre-compiled instruction sequence, and the cache instance is called to perform style rendering to generate the initial document model; After inserting the pagination identifier, the corresponding component instance in the cache instance is automatically introduced according to the reusable component identifier marked in the tag configuration information, and the component instance is rendered at the specified position of the subsequent page to generate an internal document model with a continuous document structure.

2. The method according to claim 1, characterized in that, The process of parsing the tag configuration information to generate the corresponding declarative rule description language includes: The tag configuration information is parsed to extract configuration elements that include at least field identifiers, data source definitions, format conversion rules, and conditional rendering rules; The configuration elements are converted into corresponding declarative statements according to the predefined syntax mapping rules. Specifically, a declarative data source statement describing the data acquisition path is generated according to the field identifier and the data source definition. A declarative conversion statement containing ordered operation steps is generated according to the format conversion rules. A declarative conditional statement containing logical conditions and execution actions is generated according to the conditional rendering rules. The declarative data source statement, declarative transformation statement, and declarative conditional statement are combined and encapsulated to form a declarative rule description language.

3. The method according to claim 2, characterized in that, The process of orchestrating and executing a dynamic data processing flow based on the declarative rule description language to obtain dynamic data from multiple data sources includes: The declarative data source statement is instantiated into a corresponding data acquisition operation unit, the declarative transformation statement is instantiated into a corresponding data transformation operation unit, and the declarative conditional statement is instantiated into a corresponding conditional execution operation unit. The data input-output relationship between the data acquisition operation unit, the data transformation operation unit, and the conditional execution operation unit is analyzed to construct a process topology structure that represents their dependencies and execution order; Based on the process topology, multiple data acquisition operation units that have no dependencies are combined into a parallel acquisition group; According to the process topology, data acquisition operation units, data transformation operation units, and conditional execution operation units with dependencies are sequentially connected to form a sequential processing chain; A dynamic data processing flow is generated based on the parallel acquisition group and the sequential processing chain. The dynamic data processing flow is executed to obtain dynamic data from multiple data sources.

4. The method according to claim 3, characterized in that, The step of caching component instances used in the dynamic data processing flow according to a predefined caching strategy to obtain reusable cache instances during the execution of the dynamic data processing flow includes: Determine whether the component instances in the dynamic data processing flow are marked as reusable; If so, generate a unique cache identifier containing a content hash value based on the attribute information of the component instance, and query the predefined multi-level cache pool based on the unique cache identifier; If the unique cache identifier is not found in the high-speed memory cache, then query the persistent disk cache; If the unique cache identifier is matched in the persistent disk cache, the corresponding cache instance is loaded into the high-speed memory cache. If neither is found, a new component instance is created, and the new component instance is associated with the unique cache identifier and stored in both the high-speed memory cache and the persistent disk cache. According to the preset lifecycle management strategy, the cache instances in the high-speed memory cache are monitored and evicted to obtain reusable cache instances.

5. The method according to claim 1, characterized in that, The step of inputting the internal document model into a multi-format output pipeline for conversion processing via a format filter to output a final tag file in at least two different formats includes: A high-fidelity internal model is generated based on the internal document model and the pre-compiled instruction sequence; The high-fidelity internal model is input into a unified format output pipeline; According to the output format requirements corresponding to the label configuration information, at least two corresponding format conversion filters are called from the preset format conversion filter set. The format conversion filter set includes at least a PDF filter for directly outputting the high-fidelity internal model, an image conversion filter for converting the high-fidelity internal model into an image format, and a vector conversion filter for converting the high-fidelity internal model into a vector graphic. The high-fidelity internal model is converted in parallel or serially using the at least two format conversion filters that are invoked, and the cache instance is shared during the processing to output final tag files in at least two different formats with consistent styles.

6. The method according to claim 1, characterized in that, The receipt of tag configuration information input through the visual interface includes: Based on the canvas configured in the visual interface, the layout constraints of the components placed by the user in the canvas by dragging and dropping are checked in real time to obtain the initial configuration information with regular position. In response to the simulation parameters that the user binds to the dynamic fields in the initial configuration information, the system requests simulation data from the background service based on the simulation parameters, and merges the simulation data with the initial configuration information to generate a visual preview information containing real data. When the user confirms saving, the label configuration information corresponding to the visual preview information is verified for compliance. Once the verification is successful, the label configuration information is received.

7. The method according to claim 1, characterized in that, The output includes, after specifying at least two different formats of final tag files, the following: Obtain the full-process status data of the generated task, and generate a verification report including resource usage and format consistency based on the full-process status data.

8. A multi-format label generation system, characterized in that, The system includes: a parsing module, a processing module, a fusion module, and a generation module; wherein, The parsing module is used to receive tag configuration information input through a visual interface, parse the tag configuration information to generate a corresponding declarative rule description language; The processing module is used to orchestrate and execute a dynamic data processing flow based on the declarative rule description language to obtain dynamic data from multiple data sources; when executing the dynamic data processing flow, the component instances used in the dynamic data processing flow are cached according to a predefined caching strategy to obtain reusable cache instances. The fusion module is used to fuse the dynamic data and the cache instance and generate an internal document model by rendering it through a pre-compiled instruction sequence; The generation module is used to input the internal document model into a multi-format output pipeline for conversion processing through a format filter to output a final tag file in at least two different formats; The step of fusing the dynamic data and the cached instance and generating an internal document model through a pre-compiled instruction sequence includes: Obtain the JSON template corresponding to the tag configuration information, and precompile the JSON template into a precompiled instruction sequence that can be directly executed to drive document generation operations; The dynamic data obtained from the dynamic data processing flow is filled into the corresponding position of the template using the pre-compiled instruction sequence, and the cache instance is called to perform style rendering to generate the initial document model; After inserting the pagination identifier, the corresponding component instance in the cache instance is automatically introduced according to the reusable component identifier marked in the tag configuration information, and the component instance is rendered at the specified position of the subsequent page to generate an internal document model with a continuous document structure.

9. A computer-readable storage medium having a computer program stored thereon that can run on a processor, characterized in that, When the computer program is executed by the processor, it implements a multi-format tag generation method as described in any one of claims 1 to 7.

Images