Page online printing method and system based on custom form data model

Abstract

The application provides a page online printing method and system based on a self-defined form data model, the system comprising a form designer, which is used for drag-and-drop operation on the front end to generate a required form style, and generates JSON Schema data describing the form structure and style according to the required form style; a data model conversion engine, which is used for parsing the JSON Schema data to map form components to PDF elements, and generates PDF rendering instructions according to the PDF elements; and a PDF document renderer, which is used for performing rendering according to the PDF rendering instructions to generate a PDF document. The application introduces JSON Schema as unified metadata for design and printing, and uses the data model conversion engine as a core processor, thereby realizing full-link automation and decoupling from form design to data storage and then to PDF printing, and solving the problems of low development efficiency and high maintenance cost in the traditional scheme.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of computer software engineering, and particularly relates to a page online printing method and system based on a self-defined form data model. BACKGROUND

[0002] In OA approval, expense reimbursement and other business scenarios, there are a large number of needs to convert online filled form data into standardized PDF documents. The traditional scheme needs developers to develop a printing template for each form, and when the form structure is adjusted, the code needs to be modified again, which cannot adapt to the rapid iteration of business needs.

[0003] The prior art mainly has two technical routes when dealing with dynamic form printing needs, but they cannot meet the rapid iteration of business needs due to architectural defects.

[0004] 1. Backend template engine scheme (such as Freemarker, Velocity)

[0005] The technical essence of this scheme is the backend splicing of static templates and dynamic data, and its shortcomings are rooted in its technical architecture:

[0006] Shortcoming 1: Template and front-end component separation

[0007] Technical reason: This scheme is based on the separation of front-end and back-end technology stacks. The front-end uses JavaScript / HTML / CSS technology stack to generate interactive forms and produce data, while the back-end uses Java and other languages technology stack to render PDF through another set of template syntax (such as FTL, VM). There is a lack of unified, machine-readable metadata description as a bridge between the two systems. Data transmission relies on the implicit contract defined by the developer, which cannot be understood and processed by automated tools.

[0008] Consequence: It leads to high coupling and low development efficiency. Any change in form structure requires front-end and back-end developers to modify and test separately, which is costly and prone to errors.

[0009] Shortcoming 2: Style needs to be defined repeatedly

[0010] Technical reason: CSS (front-end style system) and back-end PDF generation style system are two completely heterogeneous style models. CSS has complex features such as layering, inheritance, and responsiveness, while PDF templates usually only support basic inline styles or limited style sheets. There is no automatic style conversion and compilation mechanism between the two.

[0011] Consequence: Developers have to do two completely independent style development work, to ensure visual consistency manually. This not only causes a lot of duplication of effort, but also makes UI review and style adjustment extremely cumbersome, which seriously hinders design iteration.

[0012] Disadvantage 3: Modification requires redeployment

[0013] Technical reason: Template files are considered part of the static source code of the application, tightly coupled with business logic code. Its modification, release must follow the traditional software deployment process.

[0014] Consequence: The adjustment of the print function cannot be independently updated. A small typesetting optimization requires full-process construction and deployment, which greatly damages the business agility and is contrary to the "continuous iteration, rapid delivery" concept pursued by modern SaaS products.

[0015] 2. Pure front-end PDF library solution (such as jsPDF)

[0016] The technical essence of this solution is to use imperative code to drive PDF generation on the front end, and its disadvantages are determined by the programming model:

[0017] Disadvantage 1: Layout code is coupled with business logic

[0018] Technical reason: This solution uses the imperative (Imperative) programming paradigm. Developers must specify the coordinates and styles of each data point in the PDF page by writing detailed code (such as doc.text(amount, 100, 200)). These layout codes that describe "how to draw" (How) are highly intertwined with business codes (such as getting form data formData.amount) that describe "what data" (What) in the same scope.

[0019] Consequence: Code readability and maintainability are extremely poor. Changes to print logic require deep business code to find and modify, violating the separation of concerns (Separation of Concerns) design principle, making the code difficult to understand and refactor.

[0020] Disadvantage 2: Cannot dynamically adapt to changes in form structure

[0021] Technical reason: This is a natural result of Disadvantage 1. Since the layout logic is hard-coded, its understanding of the form structure is fixed and static. It cannot perceive or respond to the dynamically generated, structure-variable JSON Schema produced by the form designer.

[0022] Consequence: make the flexibility of the front-end form designer "suddenly stop" at the printing link. After the user adjusts the form in the form designer, the print output is still the old version style, and the developer must intervene to modify the code. The "dynamic" advantage of the dynamic form is completely offset. SUMMARY

[0023] In view of the above situation, the main purpose of the present application is to propose a page online printing method and system based on a custom form data model, realizing the whole process zero code automation from "form design" to "data filling" to "PDF printing", completely eliminating the need for manual development of print templates, thereby greatly improving the development efficiency, enabling the rapid iteration of business, to solve the above technical problems.

[0024] The present application proposes a page online printing system based on a custom form data model, which comprises a form designer, a data model conversion engine and a PDF document renderer;

[0025] The form designer is used for:

[0026] In the front end, a drag-and-drop operation is performed to generate the required form style, and a JSON Schema data describing the form structure and style is generated according to the required form style;

[0027] The data model conversion engine is in communication connection with the form designer, and is used for:

[0028] The JSON Schema data is parsed to map the form components to PDF elements, and PDF rendering instructions are generated according to the PDF elements;

[0029] The PDF document renderer is in communication connection with the data model conversion engine, and is used for:

[0030] In the back end, rendering is performed according to the PDF rendering instructions to generate a PDF document.

[0031] The present application also proposes a page online printing method based on a custom form data model, which comprises the following steps:

[0032] Step 1, based on the form designer, performing a drag-and-drop operation in the front end to generate the required form style, and generating a JSON Schema data describing the form structure and style according to the required form style;

[0033] Step 2, based on the data model conversion engine, parsing the JSON Schema data to map the form components to PDF elements, and generating PDF rendering instructions according to the PDF elements;

[0034] Step 3, based on the PDF document renderer, rendering is performed according to the PDF rendering instructions in the backend to generate a PDF document.

[0035] Compared with the prior art, the beneficial effects of the present application are as follows:

[0036] 1, The present application adopts a visual form designer to generate a unified, machine-readable JSONSchema by dragging. The Schema completely defines the structure of the form (component type, hierarchical relationship), layout (grid, sorting) and style.

[0037] Because the print output is completely driven by the JSON Schema, which is automatically generated by the form designer through dragging. The "design state" of the form is described by this unique Schema, and the output of the "print state" is also completely based on the same Schema. Therefore, the design and printing of the form share the same data source. Developers do not need to write any backend template or frontend PDF layout code for each form, which completely eliminates the development work of print templates and realizes "zero code" configuration of the printing function.

[0038] And because the print content and style come from the same JSON Schema generated from the form designer, when adjusting the form structure (adding or deleting fields, adjusting the order) in the form designer, the JSON Schema is updated in real time, and when printing, the data model conversion engine is based on the latest Schema for conversion. Therefore, the PDF of the print output will automatically and in real time adapt to any structural adjustment of the form, without any manual intervention and code modification, realizing perfect adaptation to the dynamic changes of the form structure and ensuring real-time consistency between printing and design.

[0039] 2, The data model conversion engine of the present application undertakes all intelligent work of parsing Schema, mapping components, converting styles and calculating layout. Because of the existence of the data model conversion engine, the front-end business logic (form filling, submission) and the back-end / front-end PDF generation logic are completely decoupled. The PDF document renderer no longer cares about how the business data comes, it only needs to receive standardized rendering instructions from the conversion engine.

[0040] Because the style of the form online rendering and the style of the print output are derived from the same set of style definitions in the JSON Schema. The style conversion engine is responsible for adapting this set of unified style definitions to the Web and PDF two output environments respectively. Therefore, from the root, the dilemma of maintaining two sets of styles in the traditional scheme is avoided, realizing the "what you see is what you get" printing effect, and naturally guaranteeing the style consistency between the design state and the print state.

[0041] The component mapping rule (component->PDF element) and the style conversion rule (CSS->PDF style) of the application are predefined and configurable. This means that when a new component is added, the component mapping rule needs to be extended, and the core engine and renderer code do not need to be modified.

[0042] And the business logic and the printing logic are decoupled through the data model conversion engine, so they can be developed and iterated independently. Modifying the business function will not affect the printing module, and vice versa. New component types only need to register a converter in the rule library to support printing. Therefore, the system has good scalability and can easily meet future business component needs.

[0043] Since the core of the entire printing scheme is the rules and JSON Schema data of the data model conversion engine, they are essentially configuration information or data. Therefore, modifying the form design and printing effect only requires updating the JSON Schema and rule configuration, without modifying the core code of the application. The adjustment of the printing template can be hot updated without the need to redeploy the entire application, greatly improving the operation and maintenance efficiency and business agility, and realizing the avoidance of deployment dependency and supporting real-time updates.

[0044] 4、In summary: the application introduces JSON Schema as unified metadata for design and printing, and designs a powerful data model conversion engine as the core processor, and ingeniously uses field Code as a bridge to dynamically associate component definitions at design time with instance data at runtime. This mechanism realizes the full-link automation and decoupling from form design to data storage to PDF printing, and fundamentally solves the pain points of low development efficiency, high maintenance cost and inability to adapt to rapid business changes of traditional solutions.

[0045] Additional aspects and advantages of the application will be given in part in the following description, some will become apparent from the following description, or will be understood by those skilled in the art from the embodiments of the application. BRIEF DESCRIPTION OF DRAWINGS

[0046] Figure 1 The architecture diagram of the online printing system based on the custom form data model according to the application is shown in the figure;

[0047] Figure 2 The architecture diagram of the data model conversion engine is shown in the figure;

[0048] Figure 3 The flowchart of the online printing method based on the custom form data model according to the application is shown in the figure. DETAILED DESCRIPTION

[0049] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0050] These and other aspects of the embodiments of the present invention will become clear from the following description and accompanying drawings. In these descriptions and drawings, some specific embodiments of the present invention are specifically disclosed to illustrate some ways of implementing the principles of the embodiments of the present invention; however, it should be understood that the scope of the embodiments of the present invention is not limited thereto.

[0051] Please see Figure 1 This embodiment provides an online page printing system based on a custom form data model. The system includes: a form designer, a data model conversion engine, and a PDF document renderer.

[0052] Form designer, used for:

[0053] Drag-and-drop operations are performed on the front end to generate the required form style, and based on the required form style, JSON Schema (data model) data describing the form structure and style is generated;

[0054] The data model transformation engine, which communicates with the form designer, is used for:

[0055] Parse the JSON Schema data to map form components to PDF elements, and generate PDF rendering instructions based on the PDF elements;

[0056] The PDF document renderer communicates with the data model conversion engine for:

[0057] On the backend, rendering is performed according to PDF rendering instructions to generate a PDF document.

[0058] like Figure 1 As shown, the form designer in this embodiment uses a front-end style system: users configure the form interface by dragging and dropping. Its output is not the final HTML, but a JSON Schema describing the form structure and style.

[0059] Data Model Conversion Engine: The core of this invention. It is an independent processing module (which can be located in the front end or back end) responsible for receiving JSON Schema and form data, and outputting a set of instructions that a PDF document renderer can understand.

[0060] PDF document renderer: A standard PDF generator. It does not care about business logic, only responsible for executing the drawing instructions from the data model conversion engine to generate the final PDF file.

[0061] Design-time:

[0062] The form designer generates a JSON Schema, which defines the structure, style information, and data identity of the form. The JSON Schema data includes the following fields:

[0063] The component Type field identifies the type of form component;

[0064] The style field defines the style information of the component;

[0065] The children field describes the nested structure of the component;

[0066] The field Code field associates the form component with the database field.

[0067] The field Code field here (e.g. reimbursement_amount) is consistent with the field code of the data table in the backend database designed to store the data of this form instance. After the form designer saves the form after dragging and dropping, this data table is also automatically generated, without manual binding. For example, if there is a field named amount in the database table, the field Code field of the corresponding component in the JSON Schema must also be amount. This establishes a contract between design and storage.

[0068] Run-time:

[0069] After the user fills out the form and submits it, the data is persisted in the form of a key-value pair of field Code:field Value to the corresponding field in the instance data table.

[0070] When printing is needed, the system reads the data of this form instance from the database to form a form data object (Form Data, such as {"amount":"500.00","applicant":"Zhang San"}).

[0071] Print-time:

[0072] The data model conversion engine receives both the JSON Schema (design-time metadata) and the form data object (run-time data).

[0073] The data model conversion engine dynamically fuses the two in the parsing and conversion process through a common field Code. For example, when an input box component with a field Code of amount is encountered, the data model conversion engine will look up the value of amount ("500.00") in the form data object and take the value as the text content displayed in the final PDF.

[0074] As shown in Figure 2 As a preferred embodiment of the present application, the data model conversion engine includes a parsing module, a mapping and conversion module, and a layout calculation module.

[0075] The parsing module is configured to parse the JSON Schema data to construct a form component tree according to the description of the form structure and style in the JSON Schema data, and obtain style information corresponding to each component node in the form component tree.

[0076] The input is: JSON Schema (from the form designer)

[0077] Form data object (from the database, {field Code:field Value})

[0078] The processing process is: read and verify the legality of the JSON Schema, identify the component Type, children, style, and other key fields therein.

[0079] Parsing: read the JSON Schema and construct an initial component tree in memory according to the component Type, children, style, and other fields.

[0080] Data binding: traverse the initial component tree. For each component node containing a field Code, use the field Code as a key to look up the input form data object to obtain the corresponding field Value. Then inject the field Value into the component node.

[0081] The output is: a component tree structure constructed in memory (Component Tree). This tree completely reflects the nested hierarchical relationship of the form. For example, a grid layout (Grid) node will have multiple column (Column) nodes, and each column node will contain specific input box (Input) components.

[0082] A Data-Bound Component Tree. At this point, each leaf node in the tree not only knows its type and style, but also knows the specific data value it is ultimately going to render. For example, an input box node from {component Type:'input',field Code:'amount'} becomes {component Type:'input',field Code:'amount',value:'500.00'}.

[0083] A mapping and conversion module, configured to: convert each component node in the form component tree and corresponding style information into PDF-compatible style instructions according to a predefined component-PDF mapping rule, to generate a PDF element.

[0084] The input thereof is the data-bound component tree output by the parsing and data binding module.

[0085] The processing procedure is as follows:

[0086] Component mapping: traverse each component node in the form component tree, and according to the component Type thereof, query a predefined component-PDF rule library to determine the corresponding PDF element type (for example, input->text, image->image).

[0087] Data extraction: according to the PDF element type, extract the content required by the PDF element from the current component node. For example, for a drop-down selection box, not only the value selected by the user is extracted, but also the corresponding label text is found according to the options configuration.

[0088] Style conversion: call a style conversion engine to convert each component node in the form component tree and corresponding style information (in this embodiment, a front-end style system is adopted, and the style information of each component node in the form component tree is a CSS style attribute in the component node, such as fontSize, color, margin) into PDF-compatible style instructions.

[0089] The output thereof is a preliminary PDF element object set with content and style.

[0090] A layout calculation module, configured to: perform dynamic page layout calculation according to the PDF element and generate PDF rendering instructions.

[0091] The input thereof is the PDF element set output by the mapping and conversion module.

[0092] The processing procedure is as follows:

[0093] 1. Initialization: Set PDF page size, margins, etc.

[0094] 2. Flow layout calculation: In a flow layout manner. Starting from the top-left corner, traverse each element in sequence:

[0095] Calculate element size: Especially for text elements, calculate their total width and total height after line breaks.

[0096] Determine element position: Determine the position and size (width, height) of the element according to the remaining space on the current page. If the space is insufficient, automatically wrap or insert a page break.

[0097] Handle complex layout:

[0098] Table: Dynamically calculate column width, handle colspan and rowspan, and ensure that table headers are automatically repeated when crossing pages.

[0099] Flexible box: Simulate CSS Flexbox layout to align and distribute space to child elements.

[0100] Generate instructions: Encapsulate the final position, size (width, height), and content style of each element calculated into underlying drawing instructions that can be directly executed by the PDF document renderer.

[0101] Its output is: A complete set of PDF rendering instructions containing precise coordinates.

[0102] Preferably, the JSON Schema data is parsed to construct a form component tree according to the description of the form structure and style in the JSON Schema data, including the following steps:

[0103] According to the component Type field, identify the current component type;

[0104] According to the children field, identify whether the current component contains child components to determine the hierarchical relationship of the tree;

[0105] According to the style field, extract the style information of the current component;

[0106] According to the current component type and the style information of the current component, create a corresponding node object in memory;

[0107] According to the hierarchical relationship of the tree, assemble the node objects into a tree-shaped data structure to obtain the initial component tree;

[0108] When the user fills in the form instance according to the required form style, the form instance is stored in the backend database and exists in the form of key-value pairs of field Code:field Value;

[0109] For each component node containing the field Code field in the initial component tree, use the field Code field as the key to find the form instance object in the backend database, obtain the corresponding field Value, and then inject the fieldValue into the current component node to obtain the form component tree.

[0110] Preferably, according to the predefined component-PDF mapping rules, converting each component node and the corresponding style information in the form component tree into PDF-compatible style instructions to generate PDF elements specifically includes the following steps:

[0111] The predefined component-PDF mapping rules are stored in the rule library. The predefined component-PDF mapping rules include component mapping rules and style conversion rules. The component mapping rules are used to map the component type of the component node to a PDF element; for example: the correspondence between the form component type (such as 'input') and the PDF element type (such as 'text'); the rule for extracting the content (value, label) required for the PDF element from the form component configuration.

[0112] For example: when parsing { component Type:'select', label: 'Gender', model: 'gender', options: [ {value:'male', label: 'Male'},... ]}, and the user data is {gender:'male'}, the component mapping rule will guide the engine to find the option with the value'male', and finally output the PDF text element: { type: 'text', content: 'Gender: Male'}.

[0113] The style conversion rule is used to convert the style information of the component node into PDF-compatible style instructions; for example: converting CSS's font-size: '14px', color: '#333', text-align: 'center' into PDFKit's fontSize: 14, color: '#333', align: 'center' respectively.

[0114] Traverse each component node of the form component tree, query the component mapping rule according to the component Type field, and determine the PDF element type corresponding to the current component node;

[0115] According to the PDF element type, content required for extracting the PDF element from the current component node is obtained, and a PDF element with content is obtained;

[0116] According to the style conversion rule, the style information in the current component node is converted into a PDF-compatible style instruction based on the PDF element with content, so as to calculate a PDF element set containing content and style.

[0117] Preferably, according to the PDF element, the dynamic page layout calculation is performed and the PDF rendering instruction is generated, and the specific steps include the following steps:

[0118] The size and margin parameters of the PDF page are initialized;

[0119] Based on the flow layout algorithm, the position and size of each PDF element in the PDF page are calculated;

[0120] When the PDF element contains a table, the column width of the table is dynamically calculated;

[0121] The merging operation of the cells in the table is parsed and rendered, and the merging operation includes the colspan (column merging) operation and the rowspan (row merging) operation;

[0122] When the current page space is insufficient, a page break is automatically inserted and the layout is continued on a new page to obtain the PDF rendering instruction.

[0123] Please refer to Figure 3 The embodiment also provides a page online printing method based on a custom form data model, and the method comprises the following steps:

[0124] Step 1: Based on the form designer, a drag-and-drop operation is performed on the front end to generate a required form style, and a JSON Schema data describing the form structure and style is generated according to the required form style;

[0125] Step 2: Based on the data model conversion engine, the JSON Schema data is parsed to map the form component to a PDF element, and a PDF rendering instruction is generated according to the PDF element;

[0126] Step 3: Based on the PDF document renderer, the rendering is performed on the back end according to the PDF rendering instruction to generate a PDF document.

[0127] In addition to the present application, other research directions have also been developed, but there are some limitations, for example:

[0128] Scheme one: server dynamic template generation scheme:

[0129] This approach tries to find a balance between the traditional backend template and the core approach of this invention. It acknowledges the central role of JSON Schema, but still puts the most complex conversion and rendering work on the server side.

[0130] DETAILED DESCRIPTION:

[0131] Core idea: The frontend still generates JSON Schema through the form designer. But when the user requests printing, the frontend sends the JSON Schema and Form Data to a dedicated template generation service on the backend.

[0132] WORKFLOW:

[0133] Step A: The frontend submits (JSON Schema + Form Data) to the backend.

[0134] Step B: The template generator on the backend dynamically generates a template file (e.g., a Freemarker.ftl file or an HTML snippet) in memory based on the received JSON Schema.

[0135] Step C: The backend's standard PDF rendering engine (such as Flying Saucer + Freemarker) uses this newly generated template in memory and the submitted Form Data to immediately render a PDF.

[0136] Step D: The generated PDF binary stream is returned to the frontend.

[0137] EXAMPLE:

[0138] A JSON Schema of a reimbursement form is sent to the backend.

[0139] The template generator recognizes that there is a table component in the Schema and dynamically generates a Freemarker loop code:

[0140] <#list items as item>...${item.amount}...< / #list>.

[0141] Then, the Freemarker engine executes this newly generated code to output the final PDF.

[0142] ADVANTAGES:

[0143] 1. Relieve the pressure on the frontend: The complex PDF generation and layout calculation work is taken over by the server, which has low requirements on the performance of the client browser.

[0144] 2. Utilize mature backend ecosystem: Directly use the powerful and stable template engine and PDF library of the backend, with rich features (such as more accurate control of fonts and pagination).

[0145] 3. Partial decoupling: Compared to the pure backend solution, it no longer needs to pre-write and deploy template files for each form. Templates are dynamically generated, so they also have some adaptability.

[0146] Disadvantages:

[0147] 1. Incomplete solution to style consistency: The dynamically generated template on the server still needs a set of style definitions. This set of styles is either converted from the Schema's style object (still requiring a conversion engine) or still needs to be defined separately, still risking maintaining two sets of styles.

[0148] 2. Network overhead and performance bottleneck: Each print request needs to upload the possibly large JSON Schema and form data to the server and wait for the server to complete the entire process of template construction and rendering. The response speed is affected by the network and server load. In high-concurrency scenarios, dynamically generating templates may become a performance bottleneck.

[0149] 3. Architectural complexity: A dedicated "dynamic template generator" needs to be introduced in the backend, increasing the overall complexity of the system.

[0150] Comparison with the invention: This solution is a compromise. It recognizes the core value of Schema, but fails to abstract and solidify the "conversion" core intellectual work, still relying on dynamic generation each time, so it is not as consistent and performant as the client-side conversion solution of the invention.

[0151] Solution Two: Pure Frontend Virtual DOM Rendering Solution:

[0152] This solution is more aggressive, fully embracing modern front-end technologies, trying to complete all work within the browser.

[0153] Detailed description:

[0154] Core idea: No explicit "data model conversion engine" is needed, but the Virtual DOM (Virtual DOM) and Server-Side Rendering (SSR) ideas of the front-end framework (such as Vue, React) are used.

[0155] Workflow:

[0156] Step A: Front-end form designer generates JSON Schema.

[0157] Step B: Write a special, UI-less form rendering component. This component does not render the form to the web page like a normal component, but receives JSON Schema and Form Data as input.

[0158] Step C: When printing, call the render method of this special component, but its output target is not the real web DOM, but a virtual, hidden DOM tree (HTML structure in memory).

[0159] Step D: Use libraries like html2pdf.js or html2canvas+jsPDF to directly convert this virtual DOM tree into a PDF.

[0160] Example:

[0161] In Vue, you can create a PrintRenderer component whose template is dynamically generated based on JSON Schema. Calling this.$refs.printRenderer.$el can get the complete DOM node it generates.

[0162] Although this component is invisible on the page (display:none), its DOM structure is already fully generated in memory.

[0163] The html2pdf.js library receives this DOM node as input and directly "prints" it into a PDF.

[0164] Advantages:

[0165] 1. Extreme style consistency: Since the PDF is directly converted from the (virtual) DOM, its style is completely controlled by CSS, achieving 100% "what you see is what you get", almost no need to worry about style conversion problems.

[0166] 2. Natural development mode: For front-end developers, using familiar frameworks and HTML / CSS to control layout, the mental model is simpler and the learning cost is low.

[0167] Disadvantages:

[0168] 1. Weak layout control: Libraries like html2pdf.js are essentially "screenshots" of HTML to PDF, and have very weak control over advanced PDF features such as pagination, cross-page table header repetition, and element precise positioning. Often elements are truncated, layout is disordered, etc.

[0169] 2. Performance and quality issues: Rendering a large number of DOM nodes (especially large tables) and converting them consumes a lot of browser resources, which can cause page lag or even crashes. The generated PDF file may be large in size, and the print quality may not be as clear as that of professional PDF libraries.

[0170] 3. Cannot be used outside the browser environment: This solution relies heavily on the browser engine and cannot be used in server environments such as Node.js, limiting its application scenarios (such as scenarios that require backend batch generation of PDFs).

[0171] Dynamic adaptability is questionable: Although it can theoretically adapt to schema changes, complex layouts (such as cell merging) still require corresponding logic to be written in the front-end rendering component to handle, which is essentially still coupled to a certain extent.

[0172] Solution Three: This solution is a Beta version based on intermediate HTML template conversion:

[0173] This solution is an important predecessor and feasibility verification version of the present invention. Its core idea is: since it is too difficult to generate PDF instructions directly, why not first convert them into the HTML we are most familiar with, and then use mature tools to convert HTML to PDF.

[0174] (I) Detailed description:

[0175] Core idea: Keep the core concept of the data model conversion engine, but instead of outputting PDF rendering instructions, output a complete HTML string. Then use a very stable backend HTML-to-PDF tool (such as wkhtmltopdf or Puppeteer) to finally convert this HTML to PDF.

[0176] (ii) Workflow:

[0177] Step B101: Form designer generates JSON Schema. (Consistent with the present invention)

[0178] Step B102: Parse JSON Schema and build component tree. (Consistent with the present invention)

[0179] Step B103: Convert each form component to corresponding HTML tags and styles according to mapping rules.

[0180] Step B104: Concatenate the entire component tree into a complete HTML document string (including <style>标签和内联样式）。

[0181] 步骤B105：将这个HTML字符串发送到后端服务。

[0182] 步骤B106：后端服务调用wkhtmltopdf命令行工具或Puppeteer，将接收到的HTML渲染为PDF。

[0183] 步骤B107：后端将生成的PDF返回给前端。

[0184] 例子：

[0185] 转换规则示例：一个配置为{component Type:'input',label:'姓名',...}的组件，会被转换为：

[0186] html

[0187]

[0188] <label class="field-label">姓名：< / label>

[0189] {{formData.userName}}

[0190]

[0191] 输出示例：数据模型转换引擎最终会生成一个如下结构的HTML：

[0192] <!DOCTYPE html>

[0193] <html>

[0194] <head>

[0195] <style>

[0196] .field-container { margin-bottom: 10px;}

[0197] .field-label { font-weight: bold; width: 80px; display:inline-block;}

[0198] .field-value { ...}

[0199] / * 所有样式都被嵌入到此 * /

[0200] < / style>

[0201]

[0202]

[0203]

[0204] <!-- All converted HTML content goes here -->

[0205] ... Zhang San ... ...

[0206]

[0207]

[0208]

[0209] The backend service replaces the placeholders like {{formData.userName}} with real form data (or fills in the data in memory with Puppeteer) and generates the PDF.

[0210] Advantages:

[0211] 1. Significantly reduce development difficulty (initially): No need to deeply understand complex PDF underlying APIs (such as PDFKit, jsPDF underlying commands). Front-end developers are best at writing HTML and CSS, so it's very fast to develop component-to-HTML mapping rules, and the prototype verification period is short.

[0212] 2. Style consistency is well guaranteed: Since HTML / CSS is used as an intermediate carrier, the power of CSS can be fully utilized to achieve complex styles, and the final output PDF is very close to the form designer preview in visual effect.

[0213] 3. Use very stable conversion tools: wkhtmltopdf and Puppeteer are well-tested HTML-to-PDF tools that provide good support for pagination, headers and footers, etc., saving a lot of work in implementing underlying PDF rendering.

[0214] Disadvantages:

[0215] 1. Performance bottleneck and resource consumption: This is the most fatal disadvantage. Each print request needs to start a browser instance (or process) on the server to render HTML and generate PDF. This is an extremely heavy operation, and in high-concurrency scenarios, server memory and CPU resources will be quickly exhausted, causing the system to be unable to scale.

[0216] 2. Layout control is still not accurate: HTML is designed for flowing web pages, and PDF is for fixed-size paper. This results in uncontrollable pagination and element truncation during the conversion process. Although CSS properties such as page-break-inside: avoid; can be used for some control, it is not very flexible and cannot meet advanced professional requirements such as "keep table rows from splitting pages", "repeat table headers across pages", etc.

[0217] 3. Dynamic computing capability is weak: The essence of this scheme is "template replacement", which lacks real dynamic layout calculation. For example, it is impossible to accurately calculate the actual height of a piece of text after line break and dynamically adjust the position of subsequent elements accordingly. The layout relies more on the flow layout of CSS than on accurate calculation.

[0218] 4. Network transmission overhead: The very large HTML string (containing a large number of inline styles) needs to be transmitted between the front end and the back end, increasing the network overhead.

[0219] 5. Complex architecture: Although PDF libraries are avoided, a heavy backend service is introduced, and the system architecture becomes complex. There is also a cost to deploy and maintain dependencies such as wkhtmltopdf.

[0220] Conclusion:

[0221] The Beta version scheme based on intermediate HTML templates is a prototype for quickly verifying the concept, but it cannot be used in a production environment. It successfully proves the feasibility of the data model conversion engine, the core idea, but its serious defects in performance, accurate control, and professionalism force the team to conduct more in-depth technical research and ultimately develop the present invention, which directly generates PDF instructions, is more elegant, more powerful, and more professional. Disclosing this Beta version in the patent can clearly show the evolution path of the technical scheme and reflect its non-obviousness and creativity.

[0222] In summary: Scheme one fails to completely solve the problems of style consistency and server performance bottleneck; scheme two has inherent defects in layout accuracy, performance, and professionalism; and the Beta version scheme has serious defects in performance, accurate control, and professionalism. After thorough demonstration, the implementation scheme proposed by the present invention, which takes the data model conversion engine as the core, is finally selected because it achieves the best balance in flexibility, consistency, performance, and professionalism.

[0223] It should be understood that although each step in the flowchart of each embodiment of the present invention is displayed in sequence according to the arrow, these steps are not necessarily executed in the order indicated by the arrow. Unless otherwise specified in this document, the execution of these steps is not strictly limited in sequence, and these steps can be executed in other orders. Moreover, at least part of the steps in each embodiment can include multiple sub-steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages is not necessarily sequential, but can be executed in rotation or alternation with at least part of other steps or sub-steps or stages of other steps.

[0224] It should be appreciated that parts of the present application can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, several steps or methods can be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented in hardware, and as in another embodiment, any of the following technologies, or a combination thereof, can be used: discrete logic circuitry having logic gates for implementing logic functions upon an application of data signals, application specific integrated circuits having appropriate combinational logic gates, programmable gate arrays (PGA), field programmable gate arrays (FPGA), and the like.

[0225] In the description of the present specification, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example", or "some examples" and the like means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the present specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Also, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0226] The above-described embodiments only express several implementation manners of the present application, which are described in a more specific and detailed manner, but cannot be understood as a limitation on the patent scope of the present application. It should be noted that, for those skilled in the art, several modifications and improvements can be made without departing from the concept of the present application, which are all within the protection scope of the present application. Therefore, the patent protection scope of the present application should be subject to the appended claims.

Claims

1. A page online printing system based on a custom form data model, characterized in that, The system comprises a form designer, a data model conversion engine and a PDF document renderer; The form designer is configured to: perform a drag-and-drop operation on the front end to generate a desired form style, and generate JSON Schema data describing the form structure and style according to the desired form style; The data model conversion engine, in communication with the form designer, is configured to: parse the JSON Schema data to map form components to PDF elements and generate PDF rendering instructions according to the PDF elements; The PDF document renderer, in communication with the data model conversion engine, is configured to: perform rendering on the back end according to the PDF rendering instructions to generate a PDF document; The JSON Schema data comprises the following fields: a component Type field for identifying the type of a form component; a style field for defining style information of the component; a children field for describing the nested structure of the component; a field Code field for associating the form component with a database field; The data model conversion engine comprises a parsing module, a mapping and conversion module and a layout calculation module; The parsing module is configured to parse the JSON Schema data to construct a form component tree according to the description of the form structure and style in the JSON Schema data, and obtain style information corresponding to each component node in the form component tree; The mapping and conversion module is configured to convert each component node in the form component tree and the corresponding style information into PDF-compatible style instructions according to a predefined component-PDF mapping rule, to generate PDF elements; The layout calculation module is configured to perform dynamic page layout calculation and generate PDF rendering instructions according to the PDF elements; The parsing of the JSON Schema data to construct a form component tree according to the description of the form structure and style in the JSON Schema data comprises the following steps: identifying the current component type according to the component Type field; identifying whether the current component contains a sub-component according to the children field, to determine the hierarchical relationship of the tree; extracting the style information of the current component according to the style field; creating a corresponding node object in memory according to the type of the current component and the style information of the current component; assembling the node objects into a tree-shaped data structure according to the hierarchical relationship of the tree, to obtain an initial component tree; When a user fills in a form instance according to a desired form style, the form instance is stored in a back-end database and exists in the form of a key-value pair of field Code:field Value; each component node in the initial component tree that contains a field Code field is used to look up the form instance object in the back-end database using the field Code as a key, to obtain the corresponding field Value, and then the field Value is injected into the current component node, to obtain a form component tree.

2. The system according to claim 1, wherein, The predefined component-PDF mapping rules are stored in a rule library, and the predefined component-PDF mapping rules include component mapping rules and style conversion rules, the component mapping rules are used for mapping the component type of the component node to a PDF element, and the style conversion rules are used for converting the style information of the component node to a PDF-compatible style instruction.

3. The system according to claim 2, wherein, According to the predefined component-PDF mapping rules, the component nodes in the form component tree and the corresponding style information are converted into PDF-compatible style instructions to generate PDF elements, and the method specifically includes the following steps: Traverse each component node of the form component tree, query the component mapping rules according to the component Type field, and determine the PDF element type corresponding to the current component node; According to the PDF element type, extract the content required by the PDF element from the current component node to obtain a PDF element with content; According to the style conversion rules, the style information in the current component node is converted into PDF-compatible style instructions based on the PDF element with content to calculate a PDF element set containing content and style.

4. The system according to claim 3, wherein, According to the PDF element, the dynamic page layout calculation is performed and the PDF rendering instructions are generated, and the method specifically includes the following steps: Initialize the size and margin parameters of the PDF page; Based on the flow layout algorithm, the position and size of each PDF element in the PDF page are calculated; When the current page space is insufficient, a page break is automatically inserted and the layout is continued on a new page to obtain the PDF rendering instructions.

5. The system according to claim 4, wherein, When the PDF element contains a table, the following steps are further included in the dynamic page layout calculation process: Dynamically calculate the column width of the table; Parse and render the merging operation of the cells in the table, and the merging operation includes the colspan operation and the rowspan operation.

6. A method for realizing online printing of a page based on a custom form data model, characterized in that, The method is used to realize the online printing system based on the custom form data model according to any one of claims 1 to 5, and the method includes the following steps: Step 1, based on the form designer, a drag-and-drop operation is performed on the front end to generate a required form style, and a JSON Schema data describing the form structure and style is generated according to the required form style; Step 2, based on the data model conversion engine, the JSON Schema data is parsed to map the form component to a PDF element, and a PDF rendering instruction is generated according to the PDF element; Step 3, based on the PDF document renderer, the rendering is performed according to the PDF rendering instruction on the back end to generate a PDF document.

Images