Test question rendering processing method, test question editing rendering system and electronic device

Abstract

The application provides a test question rendering processing method, a test question editing rendering system and an electronic device. The method comprises the following steps: constructing a structured test question rendering model by using unstructured test question data; wherein the structured test question rendering model is a data structure for recording test question content and test question content association information by means of a node tree structure, and the structured test question rendering model defines node types and node attributes in the node tree in accordance with unified test question data definition standards and processing logic definition standards; editing a test question based on the structured test question rendering model; and rendering the edited structured test question rendering model to display the test question data. The above method can improve the uniformity and accuracy of the rendering results of test question content on different terminals and devices.

Description

Technical Field

[0001] This application relates to the field of smart education technology, and in particular to a test question rendering processing method, a test question editing and rendering system, and an electronic device. Background Technology

[0002] In document processing and typesetting technologies in the education field, especially in educational test question editing and rendering scenarios involving multiple platform environments, there is a general technical need to process test question content with high precision and standardization, and to ensure that it presents a consistent display effect on different terminals and devices.

[0003] To meet the above requirements, related technologies often use HTML (Hypertext Markup Language) formatted test data as the medium for editing and rendering. Specifically, in the test question processing stage, a rich text editor that combines HTML and ContentEditable technologies is usually used; in the test question rendering stage, it generally relies on platform-specific rendering engines such as WebView components or browser kernels to parse the HTML and generate the final visual view.

[0004] However, because HTML is an unstructured markup language designed for web page display and offers flexible expression, different platforms or browser engines have inherent differences in their parsing and rendering rules, leading to limitations in test question processing solutions based on it. Specifically, the same test question content, after the same editing, may generate HTML code with inconsistent structures; the same HTML test question, when rendered on different platforms or environments, can easily produce inconsistencies in layout, element alignment, and even style presentation. These issues make it difficult to ensure cross-platform, highly consistent editing and rendering of test question data. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a test question rendering processing method, a test question editing and rendering system, and an electronic device, which can improve the uniformity and accuracy of the rendering results of test question content on different terminals and devices.

[0006] The first aspect of this application provides a method for processing test question rendering, including: A structured test question rendering model is constructed using unstructured test question data. The structured test question rendering model is a data structure that records test question content and related information of test question content in a structured way through a node tree. The structured test question rendering model follows a unified test question data definition standard and processing logic definition standard to define the node type and node attributes in the node tree. Question editing is performed based on the aforementioned structured question rendering model; The edited structured test question rendering model is rendered to display the test question data.

[0007] In some implementations, the structured test question rendering model includes data description nodes and document nodes; The data description node is used to store the test question data content; The document node is used to store the metadata of the structured test question rendering model.

[0008] In some implementations, the structured test question rendering model also includes layout nodes and / or business-customized nodes; The layout node is used to store the layout information of the test questions; The business customization node is used to store business metadata or business logic information.

[0009] In some implementations, it is applied to a test question editing and rendering system, which includes a model conversion engine, a test question editor, a test question layout engine, and a test question rendering engine; The method of constructing a structured test question rendering model using unstructured test question data includes: The model conversion engine uses unstructured test data to construct a structured test rendering model; The process of editing test questions based on the structured test question rendering model includes: The question editor edits and / or typesets questions based on the structured question rendering model; or, the question typesetting engine typesets questions based on the structured question rendering model. The step of rendering the edited structured test question rendering model to display the test question data includes: The test question rendering engine renders the edited structured test question rendering model to display the test question data.

[0010] In some implementations, the test question editing and rendering system includes test question resource production-side equipment and test question resource consumption-side equipment; The model conversion engine and the question editor are deployed in the question resource production side device, and the question rendering engine is deployed in the question resource consumption side device. or, The model conversion engine, the question layout engine, and the question rendering engine are deployed in the question resource consumption side device. or, The model conversion engine and the question editor are deployed in the question resource production side device, and the model conversion engine, the question layout engine and the question rendering engine are deployed in the question resource consumption side device.

[0011] In some implementations, the unstructured test data includes test data in HTML format; The method of constructing a structured test question rendering model using unstructured test question data includes: The HTML-formatted test data is converted to obtain a test data tree. The information recorded in the nodes of the test question data tree is transformed so that the information recorded in the nodes of the test question data tree conforms to the information requirements of the structured test question rendering model; According to the preset mapping rules, the test question data tree is mapped to a structured test question rendering model.

[0012] In some implementations, the construction of a structured test rendering model using unstructured test data further includes: Before performing format conversion on the HTML format test data, the HTML format test data is preprocessed to remove duplicate and unusable data content. And / or, According to the preset normalization rules, the structured test question rendering model obtained by mapping is post-processed; wherein, the normalization rules include at least one of the following rules: ensuring that text nodes are nested within paragraph nodes, eliminating nesting between paragraph nodes, ensuring that inline nodes are not located at the beginning or end of a line, and adding anchor points to floating image nodes.

[0013] In some implementations, the editing of test question content is based on the structured test question rendering model, including: Upon receiving a user edit event, the user edit event is sent to the processor, so that the processor converts the user edit event into an atomic operation on the structured test question rendering model, and performs the edit operation corresponding to the user edit event by executing the atomic operation; The atomic operations include at least one of setting a selection area, inserting a node, splitting a node, merging a node, moving a node, deleting a node, inserting text, deleting text, and setting a node.

[0014] In some implementations, sending the user edit event to the processor upon receiving the user edit event includes: Listen for user edit events in the editor's root container, and after a user edit event is detected, convert the coordinates of the user edit event to coordinates inside the editor; Based on the coordinates of the user edit event, the target node corresponding to the user edit event is determined by querying the layout view model; The user edit event and the target node are distributed to the processor.

[0015] In some implementations, after constructing a structured test item rendering model using unstructured test item data, the method further includes: The structured test question rendering model is used to generate unstructured test question data, wherein the unstructured test question data includes test question data in HTML format.

[0016] In some implementations, the structured question rendering model is used to generate the HTML-formatted question data, including: The structured test question rendering model is preprocessed to ensure that the data structure in the structured test question rendering model conforms to the data structure requirements of HTML; Starting from the root node of the structured test question rendering model, the nodes are traversed, and the data in the traversed nodes is converted into HTML format data; The HTML format data corresponding to each node of the structured test question rendering model is concatenated to obtain test question data in HTML format.

[0017] In some implementations, question layout is performed based on the structured question rendering model, including: In the case where the test question layout includes mixed layout of images and text, spatial segmentation is performed based on the image to be laid out to determine the available width range of the current row; Determine whether the text to be formatted can fit within the available width range; If it is determined that the text content to be formatted cannot be placed within the available width range, backtrack to the previous line, increase its height, and recalculate the starting position of the current line and the available width range of the current line.

[0018] In some implementations, question layout is performed based on the structured question rendering model, including: When the test question layout includes table layout, the column width is determined according to the table content; Based on the column widths of the table, the table content is reformatted to determine the row height of each cell in the table; Based on the column width of the table and the row height of each cell, the size of the merged cell and the coordinates of each cell are calculated and determined.

[0019] In some implementations, question layout is performed based on the structured question rendering model, including: When the test question layout includes flexible box layout of test question content blocks, space is allocated and arranged for the sub-items within the flexible box container according to the main axis direction of the flexible box container, the elasticity coefficient of the sub-items, and the alignment of the sub-items.

[0020] In some implementations, the edited structured question rendering model is rendered to display the question data, including: Starting from the root node of the structured test question rendering model, the node tree of the structured test question rendering model is traversed according to the depth-first principle, and the rendering results of child nodes are collected. Match the corresponding rendering component and generate view fragments based on the node type of each child node; The view fragments are assembled into a complete view according to the hierarchy, which includes at least a background layer, a main content layer, and an embedded element layer.

[0021] A second aspect of this application provides a test question editing and rendering system, including: Model conversion engine, question editor, question layout engine, and question rendering engine; The model conversion engine is used to construct a structured test question rendering model using unstructured test question data. The structured test question rendering model is a data structure that records test question content and related information of test question content in a structured way through a node tree. The structured test question rendering model defines the node types and node attributes in the node tree according to a unified test question data definition standard and processing logic definition standard. The question editor is used to edit question content and / or format questions based on the structured question rendering model; The test question formatting engine is used to format test questions based on the structured test question rendering model. The test question rendering engine is used to render the edited structured test question rendering model to display the test question data.

[0022] A third aspect of this application provides an electronic device, including a memory and a processor; The memory is connected to the processor and is used to store programs; The processor is used to implement the above-described test question rendering method by running the program in the memory.

[0023] The test question rendering method provided in this application introduces a structured test question rendering model as a unified data medium, and performs format conversion, editing, and rendering operations based on this model. This scheme utilizes unstructured test question data from diverse sources to construct a platform-independent structured test question rendering model that follows predefined standards, ensuring that all subsequent editing and rendering processes are based on this unified data structure. This fundamentally eliminates inconsistencies caused by the diversity of original data formats and differences in rendering logic across different platforms, ensuring a high degree of uniformity and accuracy in the rendering results of test question content on different terminals and devices. Simultaneously, this application uses a unified structured test question rendering model to provide a stable and consistent data foundation for test question editing operations, simplifying the implementation complexity of test question editing logic and improving the processing efficiency and cross-platform compatibility of test question resources. Attached Figure Description

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

[0025] Figure 1 This is a schematic diagram of the structure of a test question editing and rendering system provided in an embodiment of this application.

[0026] Figure 2 This is a flowchart illustrating a test question rendering method provided in an embodiment of this application.

[0027] Figure 3 This is a schematic diagram of a structured test question rendering model provided in an embodiment of this application.

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

[0029] In the field of document processing and typesetting technology, especially in the editing, typesetting, and rendering of test questions in the education sector, the common approach to achieving the presentation and interaction of test content across multiple platforms is to use unstructured HTML (Hypertext Markup Language) format as the storage and manipulation medium for test data. This approach is widely adopted primarily because it leverages the general compatibility of HTML within the Web ecosystem and, by combining it with ContentEditable technology, provides basic rich text editing capabilities, allowing users to directly process test content in a WYSIWYG manner within a browser or browser-like environment.

[0030] However, when this solution is applied to educational scenarios with stringent requirements for cross-platform rendering consistency, editing accuracy, typesetting performance, and business customization, its performance is less than ideal. Specifically, the existing solution leverages the universality of the Web ecosystem for basic editing and display. Its use of HTML, an unstructured and flexible data carrier, inevitably compromises the standardization and consistency of data across editing, typesetting, and rendering stages. For example, in cross-platform (e.g., different browser engines, learning machines, WebView components) test question rendering scenarios, when encountering the same HTML test question, the above solution can result in subtle differences in the parsing and rendering of HTML tags and CSS styles by different platform rendering engines. This manifests as inconsistent display of visual elements such as font size, text and image positions, and table borders on different terminals. Furthermore, in the editing stage, the same bolding operation may generate different bolding values ​​depending on the editor. <strong>The use of various HTML expressions such as "font-weight" or "font-weight" creates a non-standard data source, which may lead to inconsistencies in subsequent processing.

[0031] The root cause of the problems in existing solutions lies in the lack of a unified, structured internal data representation standard throughout the entire process, from test question generation (production side) to final display (consumer side). These existing solutions directly or indirectly manipulate unstructured HTML test question data at each processing stage. However, HTML itself is not designed to carry high-precision, highly logical educational content; its flexible syntax and platform-dependent rendering characteristics are the fundamental reasons for data inconsistencies and operational complexity across multiple stages.

[0032] To address the aforementioned technical issues, this application provides a different technical approach to achieve end-to-end processing of test questions from generation to rendering and display. Its core concept lies in defining a structured Question Rendering Model (QRM) that adheres to unified standards for question data definition and processing logic definition as the sole carrier of test question data. Based on this model, the conversion, editing, and rendering processes of test question data are reconstructed. This fundamentally eliminates inconsistencies in multiple stages caused by inconsistent data formats and platform differences, while retaining cross-platform processing capabilities.

[0033] In other words, this application provides a technical architecture centered on a structured data model to solve technical problems such as rendering inconsistencies, complex editing operations, and customization difficulties caused by the non-standardization of carriers during the cross-platform editing, typesetting, and rendering of test data. It achieves the technical effects of standardization, high consistency, and high scalability in the entire test data processing chain.

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

[0035] This application provides a method for rendering test questions. Among other things, Figure 1 This diagram illustrates an exemplary implementation environment of the test question rendering processing method provided in this application.

[0036] See Figure 1 The diagram shown is a structural schematic of a test question editing and rendering system. This system can include test question resource production-side devices and test question resource consumption-side devices, which communicate with each other via a network.

[0037] Among them, test question resource production side equipment usually refers to the software platform used to generate and process test questions, such as a web-based subject resource test question processing system.

[0038] Test question resource consumption side devices typically refer to business terminals that need to use and present test questions, such as learning machines, intelligent grading machines, or another web application.

[0039] In the embodiments of this application, "device" refers to any hardware entity capable of performing computing and data processing functions, such as, but not limited to: servers, personal computers, tablets, smartphones, embedded learning devices, or combinations thereof, etc.

[0040] The test question resource production-side equipment can deploy a model conversion engine and a test question editor. The model conversion engine receives unstructured test question data (such as HTML format) imported externally or generated internally, and converts it into the structured test question rendering model (QRM) provided in this application. The test question editor loads this QRM, providing users with a visual editing interface; all user editing operations directly affect the underlying QRM data structure. After editing, the production side can persistently store the QRM and selectively convert it back to HTML format using the editor's built-in serialization capability to meet backward compatibility or specific distribution needs.

[0041] In the test question resource consumption-side device, the deployed components can be flexibly configured according to the scenario. In some embodiments, a test question layout engine and a test question rendering engine can be deployed. In this case, the consumer side receives QRM data output from the production side. The layout engine performs layout calculations on the QRM and outputs layout position data containing the precise coordinates of each element, which is then converted into a visual interface by the rendering engine. In other embodiments, if the consumer side still needs to process legacy HTML data, a model conversion engine can also be deployed to first convert the HTML into QRM before handing it over to the layout and rendering engines for processing. In addition, the model conversion engine deployed on the consumer side can also provide an application programming interface (API) for customized modifications to the QRM to meet specific rendering needs, such as adjusting image positions.

[0042] In the embodiments of this application, the term "engine" refers to any software or a combination of software and hardware that can perform specific data processing or computation functions. For example, it may include, but is not limited to: an independent process, a dynamic link library (DLL), a microservice, or a set of tightly coupled functions, etc.

[0043] The various engines in the aforementioned test question editing and rendering system can exist in the form of software modules, libraries, or services. Data transfer between them is carried out through predefined data interfaces and data structures, thereby realizing a complete closed loop from test question production to consumption.

[0044] Figure 2 The diagram shown is a schematic flowchart of a test question rendering processing method provided in an embodiment of this application. This method can be performed by... Figure 1 The test question editing and rendering system shown is being executed.

[0045] See Figure 2 As shown in the embodiment of this application, the test question rendering processing method includes: S101. Construct a structured test question rendering model using unstructured test question data.

[0046] The structured test question rendering model uses a node tree to record the test question content and related information in a structured data structure. Furthermore, the structured test question rendering model follows a unified test question data definition standard and processing logic definition standard to define the node types and node attributes in the node tree.

[0047] The aforementioned unstructured test data may include, but is not limited to, test data in HTML format, plain text format, or other custom-formatted test description files.

[0048] In some specific embodiments of this application, the term "structured question rendering model" broadly refers to any data structure capable of representing question content and its associated information in a standardized and hierarchical manner. For example, it may include, but is not limited to, a node tree, a multidimensional graph, or a key-value pair set with a specific pattern, as long as the type and attributes of its nodes (or vertices, entries) conform to a set of preset, unified question content representation standards (question data definition standards) and model operation standards (processing logic definition standards). This set of standards predefines how various elements that may appear in the question (such as text, images, formulas, tables) should be represented as nodes in the model, and what attributes these nodes should possess, thereby ensuring that any compliant structured question rendering model (QRM) instance can be consistently understood and operated in different processing engines.

[0049] Specifically, in this embodiment, the structured question rendering model QRM described above adopts a tree structure, designed as a node tree. The root node of the tree is usually a document node. Each node is a JavaScript object, containing "type" (node ​​type), "children" (array of child nodes), and a series of type-related "attributes". The standard for defining question data is reflected in the enumeration and specification of "type" and "attributes". For example, it is stipulated that the "bold" style is uniformly represented by a boolean type "bold" property, whose value can only be "0" or "1" (or "true" or "false"), thereby eliminating the "bold" style in HTML. <strong>The coexistence of multiple expressions such as "" and "font-weight" leads to ambiguity. The processing logic definition standard specifies the legal operation set and its semantics for each node type. For example, the child nodes of the "paragraph" node can only be inline type nodes such as "text", "inline image", and "formula". This constrains the processing logic of the typesetting engine, so that it does not need to handle illegal nested structures.

[0050] The above-mentioned operation of constructing a structured test rendering model using unstructured test data can be performed by... Figure 1 The model conversion engine in the test question editing and rendering system shown is being executed.

[0051] The specific means by which the model conversion engine implements the above-mentioned "construction" function can include: at the software level, the model conversion engine can receive an HTML string as input, parse it into an intermediate data tree (such as a simplified representation of the Document Object Model DOM) by calling an HTML parser (such as a third-party library or a self-developed parser), and then traverse the intermediate tree according to predefined mapping rules, convert each element and style information into a node object that conforms to the QRM standard, and construct a QRM node tree according to the original relationship.

[0052] S102. Edit test questions based on the structured test question rendering model.

[0053] The aforementioned question editing based on a structured question rendering model refers broadly to any processing procedure that responds to user editing operations, uses the QRM as its data source and operation target, and specifically includes editing question content and / or formatting questions based on the structured question rendering model. For example, this may include, but is not limited to: capturing user editing events through a graphical user interface (GUI), then parsing the events into a series of predefined operation instructions (or atomic operations, basic instruction sets, micro-operations) on the QRM node tree, and updating the QRM by executing these instructions.

[0054] In some embodiments, the operation of step S102 can be performed by the question editor, and the editing operation is performed directly on the QRM instead of directly manipulating the HTML, which can ensure the consistency of the data at the source of editing.

[0055] Specifically, the core function of the question editor is to map complex user interface interactions (such as mouse clicks, drags, keyboard input, and menu clicks) into atomic operations on the QRM. For example, when a user selects a piece of text and clicks the "Bold" button, the editor triggers two atomic operations: first, a "split_node" operation, which splits the text node containing the selected text at the start and end points of the selection; then, a "set_node" operation, which sets the "bold" attribute of the text node corresponding to the selected portion to "1". All these atomic operations (such as inserting nodes, deleting nodes, merging nodes, and setting attributes) are predefined, minimal units of modification to the QRM structure. They enable precise execution of any editing action and facilitate the implementation of undo / redo functionality.

[0056] S103. Render the edited structured test question rendering model to display the test question data.

[0057] In this application embodiment, "rendering" refers to any process that can convert the data content carried by the structured test question rendering model into a visually perceptible output. For example, it may include, but is not limited to: drawing using Canvas or SVG in a web browser, creating views by calling native UI frameworks (such as UIKit, Android View) on a mobile device, or generating fixed-layout documents such as PDFs, etc.

[0058] In some embodiments, after editing the test questions through the test question editor in step S102, the edited structured test question rendering model can be directly sent to the test question rendering engine, which will then render the test questions according to the edited structured test question rendering model to achieve the rendering and display of the test question data carried by the structured test question rendering model.

[0059] In another embodiment, the rendering process of step S103 can be further divided into two sub-stages: layout and final rendering, which are executed by the question layout engine and the question rendering engine, respectively.

[0060] The test question layout engine receives the edited QRM as input. Based on the content and style information contained therein, combined with the size constraints of the target display area, it runs complex layout algorithms (such as text wrapping, mixed text and image layout, table calculation, etc.) to calculate the precise coordinates and size of each character, image, table cell and other elements in the test question on the page, forming "layout position data".

[0061] The test question rendering engine then consumes this "layout position data," converts it into pixels on the terminal screen, and generates the final visual test question interface.

[0062] It is understandable that the unified QRM standard defined in step S101 provides a unique and reliable data foundation for the precise editing in step S102 and the consistent rendering in step S103. QRM, as a data intermediary throughout the process, ensures that the results of editing operations are directly recorded in a standardized model, while typesetting and rendering are calculated and output based on the same standard model. This completely severs the transmission path of the differences in unstructured source data (such as HTML) to subsequent stages. The synergy of these three elements ensures that the data flow throughout the entire process, from a single editing operation to the final pixel-level display on multiple platforms, is standardized and predictable, thus jointly solving the fundamental technical problem of inconsistent cross-platform processing of test questions.

[0063] As described above, the test question rendering method provided in this application introduces a structured test question rendering model as a unified data intermediary, and performs test question data format conversion, editing, and rendering operations based on this model. This solution utilizes unstructured test question data from diverse sources to construct a platform-independent structured test question rendering model that follows predefined standards, ensuring that all subsequent editing and rendering processes are based on this unified data structure. This fundamentally eliminates inconsistencies caused by the diversity of original data formats and differences in rendering logic across different platforms, ensuring a high degree of uniformity and accuracy in the rendering results of test question content on different terminals and devices. Simultaneously, this application employs a unified structured test question rendering model to provide a stable and consistent data foundation for test question editing operations, simplifying the implementation complexity of test question editing logic and improving the processing efficiency and cross-platform compatibility of test question resources.

[0064] like Figure 3 As shown, an exemplary structure of a structured test question rendering model is disclosed in another embodiment of this application.

[0065] See Figure 3 The structured test question rendering model disclosed in this embodiment includes data description nodes and document nodes. The data description nodes store the test question data content, while the document nodes store the metadata of the structured test question rendering model. This design aims to separate the test question content itself from the metadata of the description document, making the model structure clearer.

[0066] Specifically, data description nodes constitute the main body of the QRM node tree, directly corresponding to the visible content of the test questions. For example, a node representing a paragraph, a node representing text, a node representing an image, a node representing a table, and a node representing a formula all belong to data description nodes. Document nodes are typically the root node of the QRM tree or located below the root node, and their child nodes contain the entire document's data description node tree. Document nodes themselves can contain attributes such as the author, creation time, and modification time of the structured test question rendering model, used to store metadata related to the test question content.

[0067] In other embodiments, the metadata of the structured test rendering model can be directly attached as an attribute to the root node instead of creating a separate document node type; or a separate key-value store associated with the node tree can be used to store the metadata. For example, in a graph-based QRM implementation, the metadata can be stored on a dedicated "document" vertex and connected to other content vertices via edges.

[0068] To further optimize the structured question rendering model (QRM)'s support for question layout and business logic, the structured question rendering model used to carry question data also includes layout nodes and / or business customization nodes. Layout nodes store layout information for the question content; business customization nodes store business metadata or business logic information.

[0069] The introduction of layout nodes allows QRM to describe more complex page layouts. For example, Flexbox layout can be implemented using a layout node with the "type" of "flex". This node can contain properties such as main axis direction and main axis alignment. Its child nodes are layout nodes with the "type" of "flex-item", and each "flex-item" node contains a data description node or a data description node tree as its content. When the layout engine encounters a "flex" node, it calls a specific Flexbox layout algorithm to handle the arrangement of its child items. By introducing layout nodes, complex page layout requirements (such as multi-column and side-by-side layouts) can be described at the QRM layer, eliminating the dependence on specific HTML / CSS syntax.

[0070] Customized business nodes provide powerful extensibility for the model. For example, a node with the "type" "math-problem" can be customized for a math problem. Besides containing child nodes with content such as the question stem and options, this node can also have custom attributes such as difficulty and knowledge points. Another example is a node with the "type" "interactive-quiz," whose attributes include the business logic identifier that triggers answer verification. These customized nodes can be recognized and processed by the question editor and question formatting engine through a plugin mechanism, thus meeting the specific needs of various vertical businesses without modifying the core engine.

[0071] The aforementioned layout nodes and business customization nodes can be flexibly added or deleted in QRM according to requirements.

[0072] By adopting the aforementioned node type system, the Structured Question Rendering Model (QRM) provided in this application embodiment is not only a content container but also a comprehensive data model capable of simultaneously carrying content, layout description, and business semantics. This further helps to solve the problem of diverse and ever-changing customized needs in educational question processing, thereby synergistically strengthening the overall technical effect of achieving end-to-end consistency and scalability through a unified model in this application embodiment.

[0073] To make the system architecture of the test question rendering processing method provided in this application clearer and to clarify the collaborative relationships of each functional component in different deployment scenarios, this application also provides corresponding system architecture embodiments. As mentioned above, the test question rendering processing method provided in this application can be applied to a test question editing and rendering system. In a specific system architecture embodiment, such as Figure 1 As shown, the test question editing and rendering system includes a model conversion engine, a test question editor, a test question layout engine, and a test question rendering engine.

[0074] Based on the above-described test question editing and rendering system, the step of constructing a structured test question rendering model using unstructured test question data (step S101) includes: the model conversion engine constructing a structured test question rendering model using unstructured test question data. The step of editing test questions based on the structured test question rendering model (step S102) includes: the test question editor editing test question content and / or test question layout based on the structured test question rendering model; or, the test question layout engine layouting test questions based on the structured test question rendering model. This means that the layout function can be integrated into the editor (for real-time preview during editing) or run as an independent component (for pure rendering scenarios). The step of rendering the edited structured test question rendering model to display the test question data (step S103) includes: the test question rendering engine rendering the edited structured test question rendering model to display the test question data.

[0075] For details on the specific processing procedures of each of the above steps, please refer to the descriptions of other embodiments.

[0076] Regarding the deployment of these engines on test question resource production and consumption devices, embodiments of this application provide a variety of flexible configuration schemes to adapt to different business flows.

[0077] The first deployment method involves deploying the model conversion engine and the question editor on the question resource production side device, and deploying the question rendering engine on the question resource consumption side device. In this method, after the production side completes the conversion and editing of the QRM, it directly sends the QRM to the consumption side. The consumption side may use the system's native or lightweight renderer to directly parse and render the QRM.

[0078] The second deployment method involves deploying the model conversion engine, the question layout engine, and the question rendering engine on the question resource consumption-side device. In this method, the production side may only output HTML question data, while the consumption side possesses complete QRM processing capabilities, responsible for converting HTML to QRM, and then performing layout and rendering. This is suitable for scenarios requiring compatibility with large amounts of historical HTML data and where the consumption-side device has sufficient computing power.

[0079] The third deployment method involves deploying the model conversion engine and the question editor on the question resource production side device, and deploying the model conversion engine, the question layout engine, and the question rendering engine on the question resource consumption side device. This is a hybrid mode where the production side produces and stores the QRM, and the consumption side can either directly render the QRM or customize and modify the QRM as needed (using the API provided by the conversion engine on the consumption side) before layout and rendering. This provides maximum flexibility.

[0080] Those skilled in the art will understand that the aforementioned engines can also be deployed entirely on cloud servers, providing capabilities to clients via remote service calls; or, in a standalone application, these engines can all be integrated into a single application process.

[0081] Another embodiment of this application discloses a specific process for constructing a standardized QRM using unstructured HTML format test question data.

[0082] First, the HTML-formatted test data undergoes format conversion to obtain a test data tree. This test data tree is an intermediate data structure, such as a simplified DOM tree, reflecting the tag nesting relationships of the original HTML, but it does not yet conform to the QRM standard. In practice, an open-source HTML parser can be called to parse the HTML string into a syntax tree.

[0083] To improve conversion quality, HTML-formatted test data can be preprocessed before conversion. Preprocessing aims to remove duplicate and unusable data.

[0084] Specifically, the preprocessing described above may include: removing characters such as zero-width characters and emojis that may affect business usage through string manipulation methods; consolidating redundant spaces between tags and consecutive soft line breaks after paragraphs, retaining only one valid copy of the content; and identifying and converting certain customized tags with special business meanings that cannot be used directly. For example, if a tag with a specific class name is identified... If the blanks in a fill-in-the-blank question are represented by tags, then feature matching is used to convert them into a QRM-mappable "blank" tag structure, preparing for subsequent conversions.

[0085] Next, the information recorded in the nodes of the question data tree is transformed to conform to the information requirements of the structured question rendering model. For example, image nodes in QRM must contain width and height attributes; otherwise, they cannot participate in layout. However, some images in HTML do not explicitly declare their dimensions. For such images, the remote loading link of the image must be obtained first, the actual size of the image is obtained after loading, and finally, the size information is saved to an intermediate data structure for use in subsequent steps. Similarly, if a formula image node with the "data-latex" attribute is identified, its content (LaTeX string) needs to be extracted, wrapped with necessary delimiters, and a text node is created using this value, replacing the original formula image node. Furthermore, business-customized tag attributes (such as special tags identifying mathematical formulas) existing in historical HTML data also need to be identified, their values ​​extracted, and saved to a unified extended field in this step to ensure that business information is not lost.

[0086] Then, according to preset mapping rules, the test question data tree is mapped to a structured test question rendering model. The aforementioned mapping rules can be a set of predefined conversion tables from HTML / CSS features to QRM node types and attributes.

[0087] For example, element mapping rules define the correspondence between HTML tags and editor node types. For block-level tags, paragraph tags (p, div) correspond to paragraph nodes; table-related tags (table, tr, td, th) correspond to table, row, and cell nodes respectively; and the image tag (img) corresponds to image nodes. For inline tags, bold (strong / b), italic (em / i), strikethrough (s / del), underline (u), inline code (code), and superscript / subscript (sup / sub) do not generate independent nodes; instead, they attach corresponding formatting attributes to the text.

[0088] Style mapping rules define the correspondence between CSS styles and the editor's internal formatting, covering multiple levels: Text level: Font size (font-size), color (color), font family (font-family), background color (background-color), etc., are directly mapped to their corresponding properties. For example, `font-size: 14pt` will be stored as the internal font size value after unit conversion. Paragraph level: Text alignment (text-align) is mapped to left, right, and center alignment; first-line indent (text-indent) is converted to indentation characters using em or pixel values. Table level: Table width supports both percentage and fixed values; border styles (solid, dotted, dashed, double) are mapped to single line, dotted line, dashed line, and double line respectively; border merging mode, cell spacing, and padding all have corresponding rules. Image level: Properties such as width, height, float direction, and vertical alignment are extracted. For example, an image with `float: left` set will be automatically converted to a floating anchor image. Furthermore, some styles have even finer-grained value mappings. Taking underline as an example, the five line styles in CSS—solid, dotted, dashed, wavy, and double—correspond to single line, dotted line, dash, wavy line, and double line in the editor, respectively.

[0089] Attribute mapping rules define the correspondence between HTML element attributes and internal editor attributes. For example, the `src` and `alt` attributes of an image map to the image URL and alternative text, respectively; the `rowspan` and `colspan` attributes of a cell map to the number of rows to merge vertically and the number of columns to merge horizontally; and the `cellspacing` and `cellpadding` attributes of a table map to cell spacing and padding. All elements also support carrying custom extended data via the `data-ext-data` attribute.

[0090] Special content recognition rules: For special content such as mathematical formulas, the system uses text pattern matching for identification. For example, content in the format of \(...\) or \[...\] will be automatically recognized as inline formulas or indented formulas and converted into dedicated formula nodes.

[0091] In addition, there is a default value fallback rule. When the source content lacks explicit style information, the default value fallback rule sets default values ​​for each attribute to ensure consistent output. For example, underlines are defaulted to a single black line, table borders are defaulted to a single black line, paragraphs are defaulted to left alignment, and formulas are defaulted to a font size of 16.

[0092] By applying these rules one by one, a complete QRM node tree is gradually constructed during the depth-first traversal of the intermediate tree.

[0093] To ensure that the generated QRM fully meets the structural requirements necessary for downstream engine processing, in another embodiment, after the QRM is obtained through the above processing mapping, post-processing can be performed according to preset normalization rules. These normalization rules are designed to force the QRM to meet certain strong structural constraints. For example, the rules may include: ensuring that text nodes are nested within paragraph nodes (free text nodes will be automatically wrapped in a paragraph node), removing one or more consecutive soft line breaks at the end of a paragraph, eliminating nesting between paragraph nodes (elevating nested paragraphs), ensuring that inline nodes (such as bold text) are not located at the beginning or end of a line or adjacent to each other (inserting zero-width spaces or adjusting the structure if necessary), adding anchor points to floating image nodes (to meet the requirements of mixed text and image layout algorithms), and ensuring that anchor points must be located before the paragraph they belong to, etc. These post-processing steps are like performing a "syntax check" and "automatic correction" on the generated QRM, making it fully compliant with the "test data definition standard," clearing structural obstacles for subsequent editing, typesetting, and rendering.

[0094] By adopting the complete conversion process described above, which includes preprocessing, structured parsing, information supplementation, rule mapping, and postprocessing, this embodiment can ensure that the conversion from free and flexible HTML to strictly regulated QRM has the characteristics of high fidelity, predictability, and high quality, which is a key prerequisite for solving the consistency of subsequent editing, typesetting, and rendering.

[0095] Another embodiment of this application discloses how to accurately map and apply editing operations on the user interface to an abstract QRM data structure in a QRM-based editor. In this embodiment, editing test content based on the structured test rendering model can specifically include: upon receiving a user editing event, sending the user editing event to a processor, so that the processor converts the user editing event into atomic operations on the structured test rendering model, and implementing the editing operation corresponding to the user editing event by executing the atomic operations.

[0096] The atomic operations include at least one of the following: set_selection, insert_node, split_node, merge_node, move_node, delete_node, insert_text, delete_text, and set_node (used to set node attributes).

[0097] Illustrated with a specific example: Suppose the user double-clicks and selects the three characters "this question" in the sentence "Please answer the answer to this question" in the editor interface, and then clicks the "Bold" button from the toolbar. After the above user editing event is captured by the question editor, the question editor sends this editing event to the processor. The processor will generate and sequentially execute two atomic operations: The first is to split the node (split_node), that is, split the original text node into three consecutive text nodes (the front part, the selected part, the back part) at the start and end positions of the selection area. For example, split the text node of "Please answer the answer to this question" into three text nodes "Please answer", "this question", and "the answer", and all three inherit the attributes of the original node (no format) and jointly serve as the child nodes of the paragraph; The second is to set the node (set_node), specifically, use the path of the text node representing the selected part as the target and set its attributes. For example, set the "bold" attribute of the text node "this question" to "1". After these atomic operations are executed, the underlying QRM data is updated and the bold style is recorded.

[0098] In the above manner, all question editing operations are abstracted into atomic operations, facilitating the subsequent implementation of the undo and restore functions.

[0099] In order to efficiently and accurately locate the target of the user's editing and manage the complex event handling logic, the embodiment of this application adopts a location-based event delegation mechanism to distribute the received user editing event to the corresponding processor.

[0100] Specifically, when the question editor receives a user editing event, it uses a location-based event delegation mechanism to send the user editing event to the processor, which specifically includes the following processing steps: First, listen for user editing events in the editor root container, and after detecting a user editing event, convert the coordinates of the user editing event into internal editor coordinates.

[0101] Specifically, the editor uniformly listens for native events such as mouse clicks, movements, and keyboard presses on its outermost DOM container (root container), rather than binding listeners separately for each internal element, which greatly improves performance.

[0102] The coordinate transformation is completed in two steps: First, screen coordinates → container coordinates: Subtract the container's offset within the document from the event's page coordinates, and add the container's scroll offset to obtain the event's relative position within the editor container. Second, container coordinates → page volume coordinates (i.e., LVM coordinate system): Scan the positions of each page from bottom to top using the container's vertical coordinate to determine which page the event falls on. Then subtract the page's header height and padding, and divide by the scaling factor to restore the screen pixel distance to the logical units used by the layout engine, obtaining the precise coordinates within the page content area. Furthermore, for events in the header and footer areas, similar coordinate conversions are performed with reference to their respective rectangular areas.

[0103] Next, based on the coordinates of the user edit event, the target node corresponding to the user edit event is determined by querying the Layout View Model (LVM).

[0104] The Layout View Model (LVM) is the output of the test question layout engine. It is a tree that corresponds to the QRM structure, but each node additionally contains layout information after layout calculation, including node type (such as paragraph, line, text, table, image, etc.), the path in the corresponding QRM, the bounding box (position and size) after layout, layout number (used for keyboard navigation), etc.

[0105] Starting from the LVM page root node, a "back-to-forward" traversal order (corresponding to drawing hierarchy from high to low) is used to perform collision detection between points and rectangles. If a point falls within the bounding box of an LVM node, that node is recorded, and the detection continues recursively in its child nodes until the deepest hitting node is found. Ultimately, a node path is obtained from the LVM root node to the deepest hitting node, and this path precisely corresponds to the target node in the QRM.

[0106] Then, the user edit event and the target node are distributed to the processor.

[0107] Specifically, event dispatching distributes events and the found target node paths to registered handlers sequentially according to predefined priorities. Priorities can be set as follows: Level 1, handlers for specific DOM elements (such as custom handlers bound to image zoom handles); Level 2, handlers for specific QRM node types (such as image type handlers for image clicks, and table type handlers for cell clicks); Level 3, the default global handler (such as handling cursor positioning and selection updates).

[0108] The distribution order is first-level priority, second-level priority, and third-level priority. Distribution stops when any processor returns a termination signal. In addition, the system maintains event states (such as click counts, drag states, key modifiers, and input method states) to support complex interactions such as double-clicking, dragging, and combined input.

[0109] By employing the aforementioned event delegation mechanism based on coordinate transformation and LVM query, this embodiment achieves efficient and accurate event processing for dynamically generated and structurally complex test questions. This processing method tightly couples user interaction with the underlying QRM data model through layout results (LVM), ensuring that every interface operation is accurately mapped to the correct data node. This provides a guarantee for precise atomic operations, thereby fundamentally improving the reliability of editing and the user experience.

[0110] To ensure that the structured question rendering model (QRM) provided in this application can interact with widely used legacy systems and non-QRM format data, enabling bidirectional data flow, another embodiment of this application provides a question rendering processing method that further includes: generating unstructured question data using the structured question rendering model, wherein the unstructured question data includes HTML format question data. This capability is commonly referred to as QRM serialization or export.

[0111] The above-described process of generating unstructured test data using the structured test rendering model QRM can be implemented by a model conversion engine or by a test editor.

[0112] Specifically, converting the structured test question rendering model into test question data in HTML format may include the following steps: First, the structured test question rendering model is preprocessed to ensure that the data structure in the structured test question rendering model conforms to the data structure requirements of HTML.

[0113] For example, the anchor nodes used in QRM to implement mixed text and image layouts do not have a direct counterpart in HTML. During the preprocessing stage, the images attached to the anchor nodes need to be moved to appropriate positions in adjacent paragraphs, and then the anchor nodes themselves need to be removed to ensure that the subsequent transformation processing is a clean and directly mappable structure.

[0114] Then, node traversal (such as depth-first traversal) is performed starting from the root node of the structured test question rendering model, and the data in the traversed nodes is converted into HTML format data.

[0115] Specifically, the process starts from the root node of the QRM and traverses the nodes, performing type checks and distributing the data for each node encountered. For text nodes, HTML special characters (such as < and &) are first escaped, and then style tags are applied in sequence, such as bold, italics, strikethrough, subscripts and superscripts, emphasis marks, underline, font color, etc. Each tag is implemented through a rule-matching mechanism: each text attribute is checked to see if it matches a certain rule. If it matches, the corresponding HTML tag is wrapped, ultimately forming a nested structure from the inside out.

[0116] For an element node, first recursively process all child nodes to obtain the child HTML, then search for the conversion function corresponding to the current node type in the rule registry, and pass the child HTML to generate the complete element HTML.

[0117] Finally, the HTML format data corresponding to each node of the structured test question rendering model are concatenated to obtain complete HTML format test question data.

[0118] All the HTML fragments generated by the traversal are concatenated in the traversal order to form the final HTML string.

[0119] By providing this reverse conversion capability, embodiments of this application ensure a smooth technology transition and backward compatibility. The production side can use advanced QRM for editing and storage, and export it as standard HTML when needed for use by consumer-side systems that have not yet been upgraded. This reduces the cost and risk of technology migration, making the unified model architecture provided by embodiments of this application more practical.

[0120] In another embodiment, a test question formatting engine is disclosed that performs test question formatting based on a structured test question rendering model, specifically including the following processing steps: Step 1: Preprocessing The test question formatting engine traverses the document tree and handles pre-processing transformations for special nodes. This primarily involves pre-splitting formulas to facilitate line breaks in long formulas and calling preprocessing hooks from plugins.

[0121] Step 2, Measurement Calculation Calculate the width, height, and relative offset for each element, processing them according to their type: For character elements, use a text calculation engine to calculate character metrics (width, rise, fall, etc.); for paragraph elements, use text and image integration for line breaks; for table elements, calculate row and column dimensions using table layout; for Flex container elements, calculate child item allocation; for anchor (floating image) elements, perform offset transformations and cache them. For general block-level elements: their width is taken from the parent container's width, their offset is taken from the sum of the parent container's internal offsets, and after processing child nodes, update their own height with the sum of child node heights. For business extension nodes: call their own process hook.

[0122] Step 3, Pagination Layout Core pagination logic: The height is incremented block by block; when the height exceeds the page limit, a new page is created by inserting a page break. It handles paragraph page breaks, multi-column page breaks, and Flex page breaks, adhering to the non-split property constraint and keeping related blocks on the same page.

[0123] Step 4, Post-processing The cleanup after pagination is completed is invoked if the business-customized node has a defined post-processing hook; this is a post-extension point for layout, allowing the business-customized node to post-process or fine-tune the layout result after pagination / segmentation is completed and before absolute coordinate calculation.

[0124] Step 5, Absolute Positioning Traverse all nodes page by page, accumulating the relative offsets into absolute coordinates for direct use by the rendering layer. Block-level elements are positioned by adding the cumulative height of child nodes to the top coordinates of the parent container, while inline elements are positioned by the baseline coordinates.

[0125] To address the complex issue of mixed text and image layout in the test question layout process, another embodiment discloses: test question layout based on the structured test question rendering model, including: when the test question layout includes mixed layout of images and text, executing a mixed text and image layout backtracking algorithm.

[0126] Specifically, the algorithm first performs spatial segmentation based on the image to be laid out in order to determine the available width range of the current row.

[0127] When the test question formatting engine processes a paragraph containing floating images, it maintains a list of space occupancy for these floating elements. While formatting each line in the paragraph, the algorithm checks which of all floating images overlap vertically with the line's area, based on the vertical coordinates of the line's starting point. For each overlapping floating image, the algorithm records the horizontal range it occupies (e.g., a left-side floating image occupies [0, 150] logical units). These occupied ranges are "subtracted" from the total line width, resulting in a series of non-contiguous available width ranges, such as [[150, 500]] (if only the left-side floating image is present) or [[0, 200], [350, 500]] (if there are middle floating images).

[0128] Next, it is determined whether the text content to be formatted can be placed within the available width range.

[0129] The typesetting engine attempts to fit words or characters into the available space of the current line step by step. The cursor moves from left to right within the available space. If the width of the phrase to be inserted exceeds the remaining width of the current available space, it attempts to jump to the beginning of the next available space to continue placing it. If all available spaces are insufficient to accommodate the phrase, it is considered an "overflow".

[0130] If it is determined that the text content to be formatted cannot fit within the available width range, the algorithm executes the core backtracking adjustment step: backtracking to the previous line, increasing its height, and recalculating the starting position of the current line and the available width range of the current line. This operation "pushes down" the current line as a whole by increasing the height of the previous line to avoid the obstruction area of ​​floating elements.

[0131] Let's illustrate with a concrete example: Suppose the page width is 500pt, and there's a floating image on the right side, with its top at Y=60pt and bottom at Y=160pt, occupying a horizontal space of [300, 500]. The current paragraph already has two lines, with a cumulative height of 50pt. The third line starts at Y=50pt. At this point, the available width for the third line is only [0, 300]. If we want to put an inline image with a width of 400pt in the third line, the 300pt available space is clearly insufficient. The algorithm enters the backtracking process: 1) Find the previous line (the second line), calculate the distance from the top of the current line (50pt) to the next anchor point boundary (i.e., the bottom of the floating image 160pt), the difference is 110pt.

[0132] 2) Increase the height of the second line by 110pt. This makes the total height of the paragraph 50 + 110 = 160pt, and the vertical starting position of the current line is pushed to 160pt—just past the bottom edge of the floating image.

[0133] 3) Recalculate the available width of the current row. Since the starting width of the current row is 160pt, it no longer overlaps vertically with the floating image, and the available width is restored to the complete [0, 500], so the 400pt inline image can be placed normally.

[0134] If the content is still obscured by other floating elements after a backtracking, the algorithm will continue to search for the next anchor point boundary and recursively retry, gradually pushing the content to a lower position until enough space is found or the preset maximum number of retries (e.g., 10 times) is reached to prevent infinite loops.

[0135] Through this "spatial segmentation-overflow detection-backtracking adjustment-recursive retry" processing mechanism, the embodiments of this application effectively solve the problem of abnormal text wrapping layout caused by floating elements, and achieve complex and precise mixed text and image layout effects.

[0136] To address the issue of precise layout of complex tables in the test question formatting process, another embodiment discloses: test question formatting based on the structured test question rendering model, including: when the test question formatting includes table layout, executing a table layout algorithm.

[0137] Specifically, the algorithm first determines the column widths of the table based on the table content.

[0138] The algorithm first obtains the width of the table's container and the table's own width settings (which may be a fixed value or a percentage). Then, it pre-layouts the content of each cell: assuming infinite column widths, it typeset the text, images, and other content within the cells, measuring the natural width required for each cell's content. Next, based on these natural widths, cell merging, and table width constraints, it calculates the actual rendered width of each column using a specific allocation strategy (such as proportional allocation or meeting minimum values). This process may require iterations; for example, first allocating a base column width to unmerged cells, then handling the impact of merged cells on column width.

[0139] Then, based on the column widths of the table, the table content is reformatted to determine the row height of each cell in the table.

[0140] Once the column width is determined, the algorithm uses the actual column width as a constraint to formally reformat the content of each cell. This reformatization takes into account factors such as text wrapping, paragraph height, and image scaling to calculate the content height of each cell within the given width. Then, combining the cell padding and table row height settings (such as minimum row height and fixed row height), the final row height is determined.

[0141] For vertically merged cells, special handling is required: the height of the starting cell needs to be calculated based on the sum of the heights of all the rows it spans. For example, suppose there is a 3-row, 3-column table where B1:B2 are vertically merged (meaning B1:B2 spans 2 rows), but A1 and C1 each span 1 row. Therefore, the height of the first row is determined by the larger of A1 and C1. After all row heights are determined, the height of the starting cell is then updated to the sum of the heights of the rows it spans, ensuring that the merged cell exactly covers the corresponding row area.

[0142] Finally, based on the column width of the table and the row height of each cell, the size of the merged cell and the coordinates of each cell are calculated and determined.

[0143] Once all row and column dimensions are determined, the algorithm begins calculating the precise position of each cell. Starting from the top-left corner of the table, the column widths are accumulated horizontally, and the row heights are accumulated vertically to calculate the coordinates of the top-left corner of each cell. For merged cells, their width is the sum of the widths of the columns they span, their height is the sum of the heights of the rows they span, and their coordinates are determined by their starting row and column.

[0144] By following this strict order of "calculating column width first, then row height, and finally coordinates", the embodiments of this application ensure the orderliness of table layout calculation and the accuracy of the results, effectively solving problems such as misalignment and size calculation errors in multi-platform rendering of complex tables containing merged cells.

[0145] In order to achieve flexible container-level layout in the test question layout process, another embodiment discloses: test question layout based on the structured test question rendering model, including: when the test question layout includes flexible box layout of test question content blocks, executing a flexible box layout algorithm.

[0146] Specifically, the algorithm allocates space and arranges the items within the elastic box container based on the main axis direction of the elastic box container, the elasticity coefficient of the items, and the alignment of the items.

[0147] When the test question layout engine encounters a QRM node (layout node) of type "flex", it activates the algorithm. The child items (flex-items) within the container can contain any block-level elements such as paragraph text, images, tables, formulas, and even nested containers. Typical applications include displaying multiple questions side by side and splitting text and images into left and right columns.

[0148] The specific algorithm process mainly includes three stages: size allocation, alignment adjustment, and page splitting.

[0149] Size allocation stage: The containers are arranged according to the main axis direction (flex-direction, such as horizontal or vertical) (horizontal or vertical arrangement). The total size of the containers in the main axis direction is calculated, and the padding, border, and child item spacing are subtracted to obtain the available space.

[0150] For sub-items with set elasticity coefficients, the algorithm allocates the remaining available space according to the proportion of each sub-item's elasticity coefficient. For example, if there is 300px of remaining space and the elasticity coefficients of two sub-items are 1 and 2 respectively, then they will receive 100px and 200px of space respectively.

[0151] For items without a set elasticity coefficient, the algorithm first performs a trial layout of each item using the full width of the container, measures the actual size of its content (such as the content width), and then allocates container space according to the proportion of the content size to ensure that items with more content get more space.

[0152] When using the elasticity coefficient in the vertical direction, if the actual content height of a sub-item exceeds the proportionally allocated height, the algorithm adopts an intelligent greedy strategy to handle it: sort all sub-items in descending order of actual height, check them one by one, allocate space according to the actual height of the sub-item and deduct it from the remaining space for the sub-item whose actual height exceeds the allocated amount; allocate the remaining space proportionally to the sub-items that do not exceed the limit, so as to ensure that the oversized content is not compressed.

[0153] During the alignment adjustment phase: Alignment is performed along the main axis, controlling the distribution of child items along the main axis. Six modes are supported: FlexStart: Child items are arranged sequentially next to the container's start point; FlexEnd: Child items are arranged sequentially next to the container's end point; Center: Child items are centered with equal margins on both ends; SpaceBetween: The first and last child items are flush with the container's edge, with the remaining space evenly distributed between the child items; SpaceAround: Each child item receives equal spacing on both sides, with the spacing between adjacent child items being twice the edge spacing; SpaceEvenly: All spacing is completely equal, including the spacing between child items and the container's edge.

[0154] Alignment along the cross axis controls the positioning of child items in the direction perpendicular to the main axis. It supports four modes: Stretch: Stretches all child items along the cross axis to the size of the largest child item, making their height or width uniform; Center: Centers the child items along the cross axis; FlexStart: Aligns the child items to the start of the cross axis; FlexEnd: Aligns the child items to the end of the cross axis.

[0155] All alignment calculations are performed on the available space after deducting the spacing between sub-items.

[0156] Page splitting phase: When the content of the flex container exceeds the height of a single page, the algorithm will check the nodes in each sub-item one by one, split the divisible nodes (such as paragraphs) at the page boundary, and move the indivisible nodes (such as images) to the next page as a whole, and generate a new flex container on the new page to continue the layout, so as to maintain the consistency of the layout structure of each page.

[0157] By introducing a flexible box layout algorithm, the embodiments of this application enable the layout of test question content blocks to no longer be limited to a single vertical flow layout. It can easily achieve advanced layout effects such as multi-column side-by-side, left and right columns for text and images, and equal division layout, which greatly enhances the flexibility and expressiveness of test question layout.

[0158] In another embodiment of this application, rendering the edited structured test question rendering model to display the test question data may include the following processing steps: First, starting from the root node of the structured test question rendering model, the node tree of the structured test question rendering model is traversed according to the depth-first principle to collect the rendering results of child nodes.

[0159] After receiving the Layout View Model (LVM) with absolute coordinates from the question layout engine, the question rendering engine performs a depth-first traversal starting from the page nodes. For each node, it recursively processes all its child nodes, collecting the view fragments (rendering artifacts) they generate. During the traversal, embedded elements such as images and formulas are not mixed into the main text artifacts. Instead, they are collected in a global embedding cache (Embedded Map) using unique identifiers, managed separately from the main text content, facilitating subsequent layered assembly and incremental updates.

[0160] Next, the corresponding rendering component is matched according to the node type of each child node, and a view fragment is generated.

[0161] The test rendering engine maintains a component registry, mapping node types to specific rendering components (functions or classes). When a node is encountered, the engine looks up the corresponding component, passing the node's coordinates, styles, content, and collected child node fragments as parameters. The component is responsible for generating the view fragment corresponding to that node, which may be a DOM element, a native view object, or a set of drawing instructions. To significantly improve performance, the rendering templates for these components can be pre-compiled and cached during engine initialization, amortizing the template parsing cost from each render to the initialization phase, allowing runtime to directly call the pre-compiled rendering functions.

[0162] Then, the view fragments are assembled into a complete view according to the hierarchy, which includes at least a background layer, a text content layer, and an embedded element layer.

[0163] The test rendering engine does not flatten and mix all elements for rendering. Instead, it layers elements according to their visual hierarchy and type, assembling all outputs into a complete view structure from bottom to top: background layer, header layer, footer layer, text alignment layer, body content layer, embedded element layer, and selection highlight layer. For example, the background layer contains the page background color or texture; the header and footer layers contain the corresponding header and footer content; the body content layer contains the main text, paragraphs, and tables; and the embedded element layer specifically contains images, formulas, floating elements, etc., retrieved from the embedding cache. Placing images and other elements in a separate layer helps optimize rendering performance (such as utilizing GPU hardware acceleration) and handle layer stacking relationships. All layers are stacked together using absolute positioning (coordinates calculated by the layout engine) to form a complete page view.

[0164] For pages with existing views, the rendering engine will compare tags and attempt to reuse unchanged embedded elements, updating only the changed attributes to achieve incremental updates of embedded elements and reduce unnecessary view operations.

[0165] Furthermore, in some embodiments, the test question rendering engine also includes visibility determination logic to achieve deferred rendering. The test question rendering engine calculates the current visible area, traverses all pages, and performs an intersection check between the top coordinates and height of each page and the visible area: if the bottom of the page is higher than the top of the visible area, or the top of the page is lower than the bottom of the visible area, it is determined to be invisible. The engine only performs synchronous, immediate rendering on pages within this visible area. For pages outside the visible area, they are placed in a deferred rendering queue and rendered gradually when the browser is idle, utilizing an idle period scheduling mechanism. When the user scrolls, the engine dynamically checks which pages have entered the visible area and renders them immediately. This on-demand rendering strategy greatly shortens the initial load time of long documents (such as test papers with dozens of pages) and improves the smoothness of interaction.

[0166] By employing the aforementioned layered assembly, template pre-compilation (spreading the template parsing cost from each rendering to the initialization stage), incremental updates of embedded elements, and rendering scheduling strategies based on the visible area, this embodiment significantly improves rendering performance, especially for long documents or complex questions, while ensuring rendering quality. It solves the stuttering problem caused by rendering all content at once in traditional solutions and optimizes the user experience.

[0167] The following example illustrates the processing procedure of the test question rendering method provided in this application.

[0168] Suppose a teacher on an online education platform needs to create a test paper containing complex mathematical formulas, charts, and multiple-choice questions, and wants this test paper to maintain a completely consistent visual appearance across the web-based editing backend, the student's PC browser, tablet app, and offline downloaded PDF.

[0169] On the test question resource production side (the web-based editing backend used by teachers), teachers import a historical test question from the resource library, stored in HTML format. The model conversion engine immediately converts this HTML into a QRM. Teachers then modify the question in the QRM-based editor: inserting a complex LaTeX formula using the formula editor, dragging an image to set right-side wrapping, and adjusting the column width of a table. All these operations are converted into atomic operations on the QRM by the test question editor. The test question editor calls the typesetting engine in real time for previewing, allowing teachers to immediately see the precise text and image integration and table effects. After editing, the system stores the final QRM in the database.

[0170] On the test question resource consumption side (student end), there are several scenarios. Student A uses a PC browser to access the platform to complete the questions. The platform backend directly sends the QRM data to the frontend. The frontend deploys a layout engine and a rendering engine. The engine consumes the QRM and smoothly renders the test question interface in the browser, completely consistent with the editing backend, including complex formulas and precise image wrapping. Student B uses a tablet app. The app integrates a lightweight layout and rendering engine, also receiving QRM data and calling native drawing APIs for high-performance rendering. Scrolling is smooth, and there are no WebView compatibility issues. Student C needs to print out their review materials. The platform server uses the layout engine to layout the QRM data and then calls the rendering engine to generate a high-precision PDF document with a neat format, indistinguishable from the screen display.

[0171] In this scenario, the test question rendering method provided in this application ensures that the data format remains consistent throughout the entire process from test question production to multi-terminal consumption, and the processing logic remains consistent, completely eliminating the rendering differences between platforms caused by traditional HTML solutions. Teachers do not need to worry about formatting errors, students receive a consistent learning experience, and platform maintenance costs are reduced due to the unified technology stack.

[0172] Based on the same inventive concept as the above-described method embodiments, this application also provides a test question editing and rendering system. This system includes a model conversion engine, a test question editor, a test question layout engine, and a test question rendering engine.

[0173] The model conversion engine is used to construct a structured test question rendering model using unstructured test question data.

[0174] The question editor is used to edit question content and / or format questions based on the structured question rendering model.

[0175] The test question layout engine is used to layout test questions based on the structured test question rendering model.

[0176] The test question rendering engine is used to render the edited structured test question rendering model to display the test question data.

[0177] The specific functions, interaction relationships, and technical effects of the collaborative work of each engine can be found in the descriptions in the foregoing method embodiments, and will not be repeated here. Those skilled in the art will understand that the various parts of this system can be integrated into a single electronic device or distributed across multiple electronic devices, collaborating through a communication network.

[0178] Another embodiment of this application also provides an electronic device, see [link to relevant documentation] Figure 4 As shown, the device includes: Memory 200 and processor 210; The memory 200 is connected to the processor 210 and is used to store programs; The processor 210 is used to implement the test question rendering processing method disclosed in any of the above embodiments by running the program stored in the memory 200.

[0179] Specifically, the aforementioned electronic device may also include: a bus, a communication interface 220, an input device 230, and an output device 240.

[0180] The processor 210, memory 200, communication interface 220, input device 230, and output device 240 are interconnected via a bus. Among them: A bus can include a pathway for transmitting information between various components of a computer system.

[0181] Processor 210 can be a general-purpose processor, such as a general-purpose central processing unit (CPU), a microprocessor, etc., or an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program of the present invention. It can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0182] Processor 210 may include a main processor, as well as a baseband chip, modem, etc.

[0183] The memory 200 stores a program that executes the technical solution of this invention, and may also store an operating system and other key business functions. Specifically, the program may include program code, which includes computer operation instructions. More specifically, the memory 200 may include read-only memory (ROM), other types of static storage devices capable of storing static information and instructions, random access memory (RAM), other types of dynamic storage devices capable of storing information and instructions, disk storage, flash memory, etc.

[0184] Input device 230 may include a device for receiving user input data and information, such as a keyboard, mouse, camera, scanner, light pen, voice input device, touch screen, pedometer, or gravity sensor.

[0185] Output device 240 may include devices that allow information to be output to a user, such as a display screen, printer, speaker, etc.

[0186] The communication interface 220 may include a device that uses any transceiver to communicate with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Network (WLAN), etc.

[0187] The processor 210 executes the program stored in the memory 200 and calls other devices, which can be used to implement each step of any of the test question rendering processing methods provided in the above embodiments of this application.

[0188] The electronic device can be either the aforementioned test resource production-side device or test resource consumption-side device, or it can be a server or high-performance terminal that has both functions.

[0189] In addition to the methods and devices described above, embodiments of this application may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps of the test question rendering processing method described in any of the above embodiments of this specification.

[0190] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0191] Furthermore, embodiments of this application may also be storage media storing a computer program, which, when run by a processor, causes the processor to execute the steps of the test question rendering processing method described in any of the above embodiments of this specification.

[0192] For the foregoing method embodiments, in order to simplify the description, they are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to this application, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0193] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For apparatus embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0194] The steps in the methods of the various embodiments of this application can be adjusted, merged, or deleted in order according to actual needs, and the technical features described in each embodiment can be replaced or combined.

[0195] The modules and sub-modules in the various embodiments of the present application's devices and terminals can be merged, divided, and deleted according to actual needs.

[0196] It should be understood that the disclosed terminals, devices, and methods can be implemented in other ways, given the several embodiments provided in this application. For example, the terminal embodiments described above are merely illustrative. For instance, the division of modules or sub-modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple sub-modules or modules may be combined or integrated into another module, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0197] The modules or submodules described as separate components may or may not be physically separate. The components that constitute a module or submodule may or may not be physical modules or submodules; that is, they may be located in one place or distributed across multiple network modules or submodules. Some or all of the modules or submodules can be selected to achieve the purpose of this embodiment's solution, depending on actual needs.

[0198] Furthermore, the functional modules or sub-modules in the various embodiments of this application can be integrated into one processing module, or each module or sub-module can exist physically separately, or two or more modules or sub-modules can be integrated into one module. The integrated modules or sub-modules described above can be implemented in hardware or in the form of software functional modules or sub-modules.

[0199] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0200] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software unit executed by a processor, or a combination of both. The software unit can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0201] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0202] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.< / strong> < / strong>

Claims

1. A test question rendering processing method, characterized in that, include: A structured test question rendering model is constructed using unstructured test question data. The structured test question rendering model is a data structure that records test question content and related information of test question content in a structured way through a node tree. The structured test question rendering model follows a unified test question data definition standard and processing logic definition standard to define the node type and node attributes in the node tree. Question editing is performed based on the aforementioned structured question rendering model; The edited structured test question rendering model is rendered to display the test question data.

2. The method according to claim 1, characterized in that, The structured test question rendering model includes data description nodes and document nodes; The data description node is used to store the test question data content; The document node is used to store the metadata of the structured test question rendering model.

3. The method according to claim 2, characterized in that, The structured test question rendering model also includes layout nodes and / or business customization nodes; The layout node is used to store the layout information of the test questions; The business customization node is used to store business metadata or business logic information.

4. The method according to claim 1, characterized in that, It is applied to a test question editing and rendering system, which includes a model conversion engine, a test question editor, a test question layout engine, and a test question rendering engine; The method of constructing a structured test question rendering model using unstructured test question data includes: The model conversion engine uses unstructured test data to construct a structured test rendering model; The process of editing test questions based on the structured test question rendering model includes: The question editor edits and / or typesets questions based on the structured question rendering model; or, the question typesetting engine typesets questions based on the structured question rendering model. The step of rendering the edited structured test question rendering model to display the test question data includes: The test question rendering engine renders the edited structured test question rendering model to display the test question data.

5. The method according to claim 4, characterized in that, The test question editing and rendering system includes test question resource production-side equipment and test question resource consumption-side equipment; The model conversion engine and the question editor are deployed in the question resource production side device, and the question rendering engine is deployed in the question resource consumption side device. or, The model conversion engine, the question layout engine, and the question rendering engine are deployed in the question resource consumption side device. or, The model conversion engine and the question editor are deployed in the question resource production side device, and the model conversion engine, the question layout engine and the question rendering engine are deployed in the question resource consumption side device.

6. The method according to any one of claims 1 to 5, characterized in that, The unstructured test data includes test data in HTML format; The method of constructing a structured test question rendering model using unstructured test question data includes: The HTML-formatted test data is converted to obtain a test data tree. The information recorded in the nodes of the test question data tree is transformed so that the information recorded in the nodes of the test question data tree conforms to the information requirements of the structured test question rendering model; According to the preset mapping rules, the test question data tree is mapped to a structured test question rendering model.

7. The method according to claim 6, characterized in that, The method of constructing a structured test rendering model using unstructured test data also includes: Before performing format conversion on the HTML format test data, the HTML format test data is preprocessed to remove duplicate and unusable data content. And / or, According to the preset normalization rules, the structured test question rendering model obtained by mapping is post-processed; wherein, the normalization rules include at least one of the following rules: ensuring that text nodes are nested within paragraph nodes, eliminating nesting between paragraph nodes, ensuring that inline nodes are not located at the beginning or end of a line, and adding anchor points to floating image nodes.

8. The method according to any one of claims 1 to 5, characterized in that, Editing test content based on the structured test rendering model includes: Upon receiving a user edit event, the user edit event is sent to the processor, so that the processor converts the user edit event into an atomic operation on the structured test question rendering model, and performs the edit operation corresponding to the user edit event by executing the atomic operation; The atomic operations include at least one of setting a selection area, inserting a node, splitting a node, merging a node, moving a node, deleting a node, inserting text, deleting text, and setting a node.

9. The method according to claim 8, characterized in that, The step of sending the user edit event to the processor upon receiving the user edit event includes: Listen for user edit events in the editor's root container, and after a user edit event is detected, convert the coordinates of the user edit event to coordinates inside the editor; Based on the coordinates of the user edit event, the target node corresponding to the user edit event is determined by querying the layout view model; The user edit event and the target node are distributed to the processor.

10. The method according to claim 1, characterized in that, After constructing a structured test item rendering model using unstructured test item data, the method further includes: The structured test question rendering model is used to generate unstructured test question data, wherein the unstructured test question data includes test question data in HTML format.

11. The method according to claim 10, characterized in that, Generating the HTML-formatted test data using the structured test rendering model includes: The structured test question rendering model is preprocessed to ensure that the data structure in the structured test question rendering model conforms to the data structure requirements of HTML; Starting from the root node of the structured test question rendering model, the nodes are traversed, and the data in the traversed nodes is converted into HTML format data; The HTML format data corresponding to each node of the structured test question rendering model is concatenated to obtain test question data in HTML format.

12. The method according to claim 4, characterized in that, Question layout based on the aforementioned structured question rendering model includes: In the case where the test question layout includes mixed layout of images and text, spatial segmentation is performed based on the image to be laid out to determine the available width range of the current row; Determine whether the text to be formatted can fit within the available width range; If it is determined that the text content to be formatted cannot be placed within the available width range, backtrack to the previous line, increase its height, and recalculate the starting position of the current line and the available width range of the current line.

13. The method according to claim 4, characterized in that, Question layout based on the aforementioned structured question rendering model includes: When the test question layout includes table layout, the column width is determined according to the table content; Based on the column widths of the table, the table content is reformatted to determine the row height of each cell in the table; Based on the column width of the table and the row height of each cell, the size of the merged cell and the coordinates of each cell are calculated and determined.

14. The method according to claim 4, characterized in that, Question layout based on the aforementioned structured question rendering model includes: When the test question layout includes flexible box layout of test question content blocks, space is allocated and arranged for the sub-items within the flexible box container according to the main axis direction of the flexible box container, the elasticity coefficient of the sub-items, and the alignment of the sub-items.

15. The method according to any one of claims 1 to 5, characterized in that, The edited structured test question rendering model is rendered to display the test question data, including: Starting from the root node of the structured test question rendering model, the node tree of the structured test question rendering model is traversed according to the depth-first principle, and the rendering results of child nodes are collected. Match the corresponding rendering component and generate view fragments based on the node type of each child node; The view fragments are assembled into a complete view according to the hierarchy, which includes at least a background layer, a main content layer, and an embedded element layer.

16. A test question editing and rendering system, characterized in that, include: Model conversion engine, question editor, question layout engine, and question rendering engine; The model conversion engine is used to construct a structured test question rendering model using unstructured test question data. The structured test question rendering model is a data structure that records test question content and related information of test question content in a structured way through a node tree. The structured test question rendering model defines the node types and node attributes in the node tree according to a unified test question data definition standard and processing logic definition standard. The question editor is used to edit question content and / or format questions based on the structured question rendering model; The test question formatting engine is used to format test questions based on the structured test question rendering model. The test question rendering engine is used to render the edited structured test question rendering model to display the test question data.

17. An electronic device, characterized in that, Including memory and processor; The memory is connected to the processor and is used to store programs; The processor is used to implement the test question rendering processing method as described in any one of claims 1 to 15 by running the program in the memory.

Images