Web end OFD file rendering method and device and storage medium

Abstract

The invention discloses a rendering method and device for an OFD file at a Web end and a storage medium, and relates to the technical field of webpage rendering, and the method comprises the steps that the OFD file is segmented, and JSON data fragments are stored in an index database; calculating a corresponding pre-rendered page and a pre-rendered page number according to the target browsing page number and a preset rendering interval, and reading a target JSON data fragment to which the pre-rendered page belongs according to the pre-rendered page number; creating placeholder containers of which the number is the same as the total number of pages on a Web end page, and marking corresponding page numbers for the placeholder containers; the method comprises the following steps: extracting pre-rendered page JSON data from a target JSON data fragment, performing real content rendering on a first placeholder of which the page number is a pre-rendered page number according to the pre-rendered page JSON data, and rendering skeleton screen placeholder elements on a second placeholder of which the page number is not a pre-rendered page number, thereby solving the problem of rendering delay caused by full rendering of an OFD file at a Web end, and improving the rendering efficiency of the OFD file. And efficient and stable browsing of the OFD file at the Web end is realized.

Description

Technical Field

[0001] This application relates to the field of web page rendering technology, and in particular to a method, device and storage medium for rendering OFD files on the web. Background Technology

[0002] In the current social context, reading Open Fixed-layout Document (OFD) format files can be divided into desktop applications and web applications. Desktop applications are gradually being replaced by web applications due to their weak cross-platform capabilities, high device dependence, and cumbersome software upgrades. OFD documents contain vector graphics and Extensible Markup Language (XML) data. As my country's independently developed document format, complex OFD files still exist in government application scenarios where a single file exceeds 500MB. Traditional web-based OFD file parsing solutions require loading the entire file into memory and simultaneously rendering all page DOM elements, resulting in large OFD file parsing times exceeding 20 seconds. Furthermore, large OFD format files are prone to lag when loading on the web, and rendering delays occur on the web.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a rendering method, device and storage medium for OFD files on the Web, aiming to solve the technical problem of rendering delay caused by full rendering of OFD files on the Web in the prior art.

[0005] To achieve the above objectives, this application proposes a method for rendering OFD files on a web platform, the method comprising: The JavaScript Object Notation (JSON) structure data corresponding to the OFD file is divided based on a preset page number range to obtain multiple JSON data fragments, and each of the JSON data fragments is stored in the index database on the Web side. The JSON structure data is obtained by performing structured parsing on the OFD file. Based on the target browsing page number and the preset rendering range, calculate the pre-rendered page number of the corresponding pre-rendered page, and read the target JSON data fragment to which the pre-rendered page belongs from the index database according to the pre-rendered page number; Based on the total number of pages of the OFD file fragments corresponding to the target JSON data fragment, create placeholder containers with the same total number of pages on the web page, and mark the corresponding page number for each placeholder container; Extract pre-rendered page JSON data with page number matching the pre-rendered page number from the target JSON data fragment, and render real content for the first placeholder container with page number matching the pre-rendered page number based on the pre-rendered page JSON data, and render skeleton screen placeholder elements for the second placeholder container with page number not matching the pre-rendered page number.

[0006] In one embodiment, before the step of segmenting the JSON structure data corresponding to the Open Format Document (OFD) file based on a preset page number range, the method further includes: Obtain the OFD file, decompress the OFD file using the JSZip library, and obtain the corresponding XML file object; The OFD-XML-PARSER parser is used to parse the XML file object and convert it into JSON structured data; Calculate the serialized byte length of the JSON structure data, and count the number of elements in the array composed of all text type objects in the JSON structure data; If the serialized byte length is greater than or equal to a first preset threshold, or the number of elements is greater than or equal to a second preset threshold, the step of segmenting the JSON structure data corresponding to the Open Format Document (OFD) file based on a preset page number range is executed.

[0007] In one embodiment, the step of storing each of the JSON data fragments in an index database on the web side includes: Construct corresponding shard key-value pairs for each of the JSON data shards, wherein the shard key is the page number range contained in the corresponding JSON data shard, and the shard value is the corresponding JSON data shard; Write the shard key-value pairs corresponding to each of the JSON data shards into the index database; After the step of writing the shard key-value pairs corresponding to each of the JSON data shards into the index database, the method further includes: The variable storing the JSON structure data corresponding to the OFD file is assigned the value null, so as to trigger the garbage collection mechanism on the web side to reclaim the memory space occupied by the JSON structure data.

[0008] In one embodiment, the step of creating a placeholder container on the web page with the same number of pages as the total number of pages includes: The pages contained in the OFD file fragments are used as placeholder pages. The OFD file is parsed by the OFD-XML-PARSER parser to obtain the physical width and height attribute values ​​of the placeholder pages. The unit of the physical width and height attribute values ​​is millimeters. Create a reference element with a preset width in the web page, obtain the actual pixel width of the reference element, and determine the millimeter to pixel conversion ratio through the physical width and height attribute values ​​and the actual pixel width; Based on the conversion ratio, the physical width and height attribute values ​​of the page to be occupied are converted into the corresponding pixel size; The document.createElement() method is called to create the placeholder container with the same number of pages as the total number of pages on the web page, and the pixel size of each placeholder container is set to the width and height of the corresponding Cascading Style Sheets (CSS). When performing a page scaling operation on the page to be placed, a scaling ratio is applied to the display size of the placeholder container; When performing an export or print operation on the page to be placed, the export or print operation is performed based on the physical width and height attribute values ​​of the page to be placed.

[0009] In one embodiment, the step of reading the target JSON data fragment to which the pre-rendered page belongs from the index database based on the pre-rendered page number includes: The pre-rendered page number is formatted as the first shard key corresponding to the target browsing page number. The first shard key is queried in each of the JSON data shards in the index database to obtain the JSON data shard corresponding to the first shard key. The JSON data fragment corresponding to the first sharding key is determined as the target JSON data fragment.

[0010] In one embodiment, the step of rendering real content in a first placeholder container with the page number of the pre-rendered page number based on the pre-rendered page JSON data includes: The JSON data of the pre-rendered page is parsed to extract the basic page attributes, signature object data, image object data, drawing object data, and text object data of the pre-rendered page; The placeholder container with the page number of the pre-rendered page number is identified as the first placeholder container, and the first placeholder container is positioned. Clear the content within the first placeholder container and create a parent container tag element based on the page's basic attributes, including the width and height of the pre-rendered page. Based on the signature object data, the image object data, the drawing object data, and the text object data, fill the interior of the parent container tag element; The parent container tag element, after being filled, is inserted into the first placeholder container, and the pre-rendered page is rendered and displayed using the Document Object Model (DOM) rendering mechanism.

[0011] In one embodiment, the step of filling the interior of the parent container tag element based on the signature object data, the image object data, the drawing object data, and the text object data includes: Generate a signature label element based on the signature object data, and insert the signature label element into the parent container label element; Image tag elements are generated based on the image object data, and the image tag elements are inserted into the parent container tag elements; The drawing object data is parsed, and special drawing elements are generated using Scalable Vector Graphics (SVG) tags and / or SVG path tags, and the special drawing elements are inserted into the parent container tag element; Determine whether the text object data contains special symbols or artistic fonts; If so, parse the text object data, generate the corresponding text special drawing element using the SVG tag and / or the SVG path tag, and insert the text special drawing element into the parent container tag element; If not, generate a text tag element based on the text object data and insert the text tag element into the parent container tag element.

[0012] In one embodiment, after the step of rendering the actual content of the first placeholder container with the page number of the pre-rendered page number based on the pre-rendered page JSON data, the method further includes: When a user's page-turning operation is detected, causing a change in the target browsing page number, the updated second pre-rendered page is determined based on the updated target browsing page number and the preset rendering range. Determine whether the rendered page that has been rendered is the second pre-rendered page; If not, the rendered page is identified as the first page to be cleaned, and a cleanup operation is performed on the first page to be cleaned; The step of performing a cleanup operation on the first page to be cleaned includes: Locate the outermost parent container element corresponding to the first page to be cleaned, clear all child elements inside the outermost parent container element, and remove the tag node of the first page to be cleaned; Remove all event listeners bound to the parent container element and its child elements on the first page to be cleaned; Insert the skeleton screen placeholder element into the cleared outermost parent container element; The page JSON data used to render the first page to be cleaned is used as the data to be cleaned, and the data to be cleaned stored in memory is set to null so that the garbage collection mechanism of the web client can reclaim the memory occupied by the data to be cleaned.

[0013] In one embodiment, when an anomaly is detected during the parsing or rendering process of the OFD file, the current memory usage status is obtained through the performance.memory API on the web client, and the current memory usage status is used to determine whether the anomaly is caused by a memory leak. If the anomaly is determined to be caused by a memory leak, the preset rendering range is reduced. Based on the narrowed preset rendering range and the target browsing page number, determine the updated third pre-rendered page; Determine whether the rendered page that has been rendered is the third pre-rendered page. If it is determined that the rendered page is not the third pre-rendered page, the rendered page is identified as the second page to be cleaned. Perform a cleanup operation on the second page to be cleaned to release memory, and generate the skeleton screen placeholder element and reload button at the abnormal page location; If it is determined that the exception is not caused by the memory leak, the exception information is captured and stored in the local cache; When the main thread on the web client is idle, the abnormal information is reported to the server through a background thread, and the skeleton screen placeholder element and the reload button are generated at the abnormal page location. Record the number of reloads; If the number of reloads exceeds a preset threshold, an error placeholder image is rendered at the location of the abnormal page to alert the user that the page parsing is abnormal.

[0014] Furthermore, to achieve the above objectives, this application also proposes a rendering apparatus for web-based OFD files, the rendering apparatus for web-based OFD files comprising: The file splitting module is used to split the JSON structure data corresponding to the OFD file based on a preset page number range, obtain multiple JSON data fragments, and store each of the JSON data fragments in the index database on the Web side; The data sharding module is used to calculate the corresponding pre-rendered page and the pre-rendered page number of the pre-rendered page based on the target browsing page number and the preset rendering range, and to read the target JSON data shard to which the pre-rendered page belongs from the index database based on the pre-rendered page number. The blank placeholder module is used to create placeholder containers on the web page with the same total number of pages as the target JSON data fragment corresponding to the OFD file fragment, and to mark the corresponding page number for each placeholder container; The rendering module is used to extract pre-rendered page JSON data with page number as the pre-rendered page number from the target JSON data fragment, and to render real content for the first placeholder container with page number as the pre-rendered page number according to the pre-rendered page JSON data, and to render skeleton screen placeholder elements for the second placeholder container with page number not as the pre-rendered page number.

[0015] In addition, to achieve the above objectives, this application also proposes a rendering device for web-based OFD files, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the rendering method for web-based OFD files as described above.

[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the Web-based OFD file rendering method described above.

[0017] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the Web-based OFD file rendering method described above.

[0018] The one or more technical solutions proposed in this application have at least the following technical effects: The JSON structure data corresponding to the OFD file is segmented based on a preset page number range to obtain multiple JSON data fragments, and each JSON data fragment is stored in the index database on the web side, avoiding the memory consumption of loading all data at once. Based on the target browsing page number and the preset rendering range, the corresponding pre-rendered page and its pre-rendered page number are calculated, and the target JSON data fragment to which the pre-rendered page belongs is read from the index database according to the pre-rendered page number, reducing data transmission and parsing overhead. Based on the total number of pages of the OFD file fragments corresponding to the target JSON data fragments, placeholder containers with the same number of pages are created on the web side page to construct a complete document skeleton structure, and each placeholder container is marked with its corresponding page number, ensuring page layout stability and providing a layout foundation for virtual scrolling. This method extracts pre-rendered page JSON data with pre-rendered page numbers from the target JSON data fragments. Based on this data, it renders the actual content of the first placeholder container with the pre-rendered page number, ensuring that actual elements are generated only in the visible or adjacent areas. It also renders skeleton screen placeholder elements for the second placeholder container with a non-pre-rendered page number, reducing unnecessary rendering overhead and balancing rendering efficiency with user experience. This solves the rendering latency problem caused by full rendering of OFD files on the web, enabling efficient and stable browsing of OFD files on the web. The web-based OFD file rendering method provided in this application divides the complete JSON structure data after parsing the OFD file into multiple lightweight JSON data fragments according to a preset page number range and persists them to an index database, avoiding long-term resident memory of large amounts of JSON structure data. It dynamically calculates the required pre-rendered pages and pre-rendered page numbers based on the target browsing page number and a preset rendering range (e.g., ±3 pages) and accurately reads the target JSON data fragment to which the pre-rendered page belongs from the index database. Next, during page initialization, placeholder containers with the same number of pages as the document are created. This avoids page jitter during scrolling through a fixed layout, and the lightweight nature of the containers minimizes resource consumption. Finally, only the first placeholder container, which belongs to the pre-rendered page number, is rendered with actual content. For the other second placeholder containers, only the skeleton screen is rendered. This reduces the total number of DOM elements and the amount of rendering computation, thus avoiding the memory pressure caused by full rendering. This allows the web client to stably and smoothly process (parse and render) OFD files with limited resources. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] 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, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating the first embodiment of the method for rendering OFD files on the Web side in this application. Figure 2 A flowchart illustrating another method for rendering OFD files on the Web side provided in this application; Figure 3 A flowchart illustrating another method for rendering OFD files on a web platform provided in this application; Figure 4 A flowchart illustrating another method for rendering OFD files on a web platform provided in this application; Figure 5 A flowchart illustrating a dynamic resource cleanup mechanism provided in this application; Figure 6 This application provides a schematic diagram of an abnormal rendering and crash reloading process; Figure 7 This is a schematic diagram of the module structure of the rendering device for OFD files on the Web side according to an embodiment of this application; Figure 8 This is a schematic diagram of the device structure of the hardware operating environment involved in the rendering method of the OFD file on the Web side in the embodiments of this application.

[0022] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0024] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0025] The main solution of this application embodiment is as follows: The JSON structure data corresponding to the OFD file is segmented based on a preset page number range to obtain multiple JSON data fragments, and each JSON data fragment is stored in the index database on the Web side. The JSON structure data is obtained by structured parsing of the OFD file. Based on the target browsing page number and the preset rendering range, the pre-rendered page number of the corresponding pre-rendered page is calculated, and the target JSON data fragment to which the pre-rendered page belongs is read from the index database based on the pre-rendered page number. Based on the total number of pages in the OFD file fragments corresponding to the target JSON data fragments, placeholder containers with the same number of pages are created on the Web side page, and each placeholder container is marked with the corresponding page number. Pre-rendered page JSON data with the pre-rendered page number is extracted from the target JSON data fragments, and based on the pre-rendered page JSON data, the first placeholder container with the pre-rendered page number is rendered with real content, and the second placeholder container with a page number other than the pre-rendered page number is rendered with skeleton screen placeholder elements.

[0026] In this embodiment, for ease of description, the following description will focus on the rendering system that identifies OFD files on the Web client.

[0027] In the current social context, OFD format file reading can be divided into desktop applications and web applications. Desktop applications are gradually being replaced by web applications due to their weak cross-platform capabilities, high device dependence, and cumbersome software upgrades. OFD documents contain vector graphics and structured XML data. As my country's independently developed document format, complex OFD documents still exist in government application scenarios where a single file exceeds 500MB. Traditional web-based OFD file parsing solutions require loading the entire file into memory and simultaneously rendering all page DOM elements, resulting in OFD file parsing times exceeding 20 seconds. Furthermore, large OFD format files are prone to lag when loading on the web, and rendering delays can occur on the web.

[0028] This application provides a solution that divides the complete JSON structure data after parsing an OFD file into multiple lightweight JSON data fragments according to a preset page number range, and persists them to an index database, avoiding the long-term resident memory of large amounts of JSON structure data. It dynamically calculates the required pre-rendered pages and page numbers based on the target browsing page number and a preset rendering range (e.g., ±3 pages), and accurately reads the target JSON data fragment to which the pre-rendered page belongs from the index database. Next, during page initialization, placeholder containers with the same number of pages as the document are created. This fixed layout avoids page jitter during scrolling, and the lightweight containers do not consume excessive additional resources. Finally, only the first placeholder container belonging to the pre-rendered page number is rendered with actual content, while only the skeleton screen is rendered for the other second placeholder containers. This reduces the total number of DOM elements and rendering computation, thereby avoiding the memory pressure caused by full rendering and enabling the web client to stably and smoothly process (parse and render) OFD files with limited resources.

[0029] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a web-based OFD file rendering device capable of performing the above functions. The following description uses a web-based OFD file rendering system as an example to illustrate this embodiment and the subsequent embodiments.

[0030] Based on this, this application provides a method for rendering OFD files on a web platform, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the method for rendering OFD files on the Web side in this application.

[0031] In this embodiment, the rendering method for OFD files on the Web side includes steps 101-104: Step 101: The JSON structure data corresponding to the OFD file is divided based on the preset page number range to obtain multiple JSON data fragments, and each JSON data fragment is stored in the index database on the Web side. The JSON structure data is obtained by performing structured parsing on the OFD file.

[0032] Specifically, the preset page range is a pre-defined page segmentation unit, such as 50 or 100 pages per range. The granularity of the segmentation is adjustable. For example, if the preset page range is 50, then pages 1-50 are one range, and 51-100 are the next range. Large OFD files or files with many pages are prone to triggering the browser's memory limit during full loading, leading to crashes. The JSON structure data corresponding to the OFD file is structured JSON data generated after parsing the OFD file (usually referring to files with more than 100 pages, or files containing a large number of images, seals, and vector graphics). It contains all the information required for rendering, such as the layout, text, image paths, and seal coordinates of each page. Due to the complexity of OFD format files, the JSON structure data corresponding to OFD files is usually large. JSON data chunks are small blocks of JSON data divided according to the preset page range. Each chunk corresponds to several consecutive pages (such as pages 1-50, 51-100), containing only the rendering data of all pages within the corresponding range. The size of a single chunk is usually controlled within 50MB for fast loading and parsing. The index database is IndexedDB (a NoSQL database) natively supported by the browser. It features local storage, transaction support, the ability to store large amounts of data, and asynchronous operations that do not block the main thread. It is suitable for storing large JSON shards and supports fast queries through the index (such as querying the corresponding shard by page number range).

[0033] In some embodiments, an OFD parsing tool can be used to parse the OFD file into a complete JSON structure containing the total number of pages and detailed data for each page. Then, according to a preset page range (e.g., every 50 pages), the page array of the JSON structure is divided into multiple consecutive page number segments of JSON data. Each segment contains rendering information (such as layout, text, image coordinates, etc.) for the pages within the corresponding range, and the start and end page numbers of the segment are marked. Finally, the web-side IndexedDB database is initialized, an object repository containing start and end page indexes is created, and each JSON data segment is asynchronously stored in this repository through transactions, achieving local persistent storage and efficient query support for each JSON data segment. After storage, the memory references to the original JSON structure are released, allowing the JSON structure data to be garbage collected, thereby significantly reducing memory usage and laying the foundation for subsequent on-demand loading.

[0034] Optionally, the steps of storing each JSON data fragment in an index database on the web include: Construct corresponding shard key-value pairs for each JSON data shard, where the shard key is the page number range contained in the corresponding JSON data shard, and the shard value is the corresponding JSON data shard. Write the shard key-value pairs corresponding to each JSON data shard into the index database; After writing the shard key-value pairs corresponding to each JSON data shard to the index database, the following steps are also included: Assign the variable storing the JSON structure data corresponding to the OFD file to null so that the garbage collection mechanism on the web side can reclaim the memory space occupied by the JSON structure data.

[0035] Specifically, shard key-value pairs are the basic data units used for indexing database storage, containing a shard key and a shard key value. The shard key is an index that uniquely identifies a JSON data shard (the page number range contained in the JSON data shard, such as 1-50, 51-100), and the shard value is the corresponding JSON data shard, containing structured data (such as text, images, coordinates, etc.) from all pages within that range. The garbage collection mechanism is a built-in memory management mechanism in the web client (browser). When an object referenced by a variable is no longer used (e.g., the variable is assigned the value null), the web client (browser) automatically reclaims the memory space occupied by that object.

[0036] For example, after an OFD file is parsed by OFD-XML-PARSER, a complete JSON structure containing all page data is generated, which consumes a significant amount of memory. To reduce memory pressure, the system divides the JSON structure into multiple JSON data shards based on a preset page range (e.g., 50 pages per unit). Then, a key-value pair is constructed for each JSON data shard, where the shard key can be a string representing the page range contained in the corresponding JSON data shard (e.g., "pages_1_50"), and the shard value is the JSON data shard itself corresponding to that range. Next, using the IndexedDB API provided by the browser, a preset object repository in the web-based index database (e.g., IndexedDB) is opened, a read / write transaction is initiated, all shard key-value pairs are traversed, and each shard key-value pair is written to the repository through the database interface, ensuring that each JSON data shard is stored with its page range (shard key) as a unique identifier, supporting subsequent fast queries by page range. After confirming the successful write operation of all JSON data shards, the system explicitly assigns null to the JavaScript variable (e.g., fullJsonData) used to store the complete JSON structure data. This breaks the JavaScript engine's reference chain to the complete JSON structure data, allowing the web client (browser)'s garbage collection mechanism to identify and release the memory space occupied by the JSON structure data in subsequent runtime cycles. By achieving efficient indexing of sharded data through structured key-value pairs and proactively releasing redundant memory containing the complete data, the system ensures efficient on-demand reading of shards while avoiding resource waste caused by large JSON structure data residing in memory for extended periods, significantly reducing the risk of memory overflow.

[0037] Step 102: Calculate the pre-rendered page number of the corresponding pre-rendered page based on the target browsing page number and the preset rendering range, and read the target JSON data fragment to which the pre-rendered page belongs from the index database based on the pre-rendered page number.

[0038] Specifically, the target page number is the page number the user is currently viewing or about to navigate to (e.g., page 30), which can be triggered by scrolling, page navigation input, or navigation operations. The preset rendering interval is a pre-configured range of offsets used to define the number of pages to be preloaded before and after the target page number. The preset rendering interval can be a symmetrical interval [...]. [N, +N] (e.g., N=3 means 3 pages before and after the target page), the preset rendering interval can also be an asymmetric interval [ [N,+M]. The preset rendering range size can be dynamically adjusted based on page complexity or device performance. The pre-rendered pages are the set of all pages that need to be pre-loaded and rendered, calculated based on the target page number and the preset rendering range. The pre-rendered page numbers are the list of page numbers corresponding to the set of all pages that need to be pre-loaded and rendered, calculated based on the target page number and the preset rendering range. For example: target page number = 30, preset rendering range = [ [2,+2], corresponding to pre-rendered page numbers = {28,29,30,31,32}. The target JSON data fragment is a JSON data fragment containing all pre-rendered page numbers. For example, if pre-rendered page numbers 28-32 belong to the "26-50" JSON data fragment, then that fragment is the target JSON data fragment.

[0039] In some embodiments, when a user navigates to a target page number (e.g., page 30), the rendering is performed according to a preset rendering interval (e.g., […]). The pre-rendered pages and the set of pre-rendered page numbers {28,29,30,31,32} to be preloaded are calculated. Then, based on the sharding granularity (e.g., one shard per 25 pages), the pre-rendered page numbers are mapped to the corresponding shard keys (e.g., "pages_26_50"), and duplicate shard keys are removed. Next, the target JSON data shards corresponding to the shard keys can be read in batches from the index database using IndexedDB transactions. By accurately calculating the set of pre-rendered page numbers to be rendered, only data shards containing the pre-rendered page number set are loaded from the index database, reducing the amount of data loaded to improve response speed. This loads the data required for the current and adjacent pages, avoiding full reads, significantly reducing memory usage and I / O overhead, and providing data support for the subsequent accurate and efficient rendering of the visible area content.

[0040] Optionally, the step of reading the target JSON data fragment to which the pre-rendered page belongs from the index database based on the pre-rendered page number includes: The pre-rendered page number is formatted as the first shard key corresponding to the target browsing page number. The first shard key is queried in each JSON data shard in the index database to obtain the JSON data shard corresponding to the first shard key. The JSON data shard corresponding to the first shard key is determined as the target JSON data shard.

[0041] Step 103: Based on the total number of pages of the OFD file fragments corresponding to the target JSON data fragments, create placeholder containers on the web page with the same number of pages as the total number of pages, and mark the corresponding page number for each placeholder container.

[0042] Specifically, the total number of pages in the OFD file shard corresponding to the target JSON data shard is the total number of pages contained in the currently loaded target JSON data shard (e.g., pages_1_100) (e.g., 100 pages). The placeholder container can be a Lightweight HyperText Markup Language (HTML) element (e.g., ...). Placeholders are used to reserve space for each page in a web browser document. The width and height of the placeholder container are dynamically converted to pixels based on the physical size of the page (millimeters), but no actual content is rendered inside.

[0043] In some embodiments, the total number of pages (e.g., 100 pages) of the OFD file shard is parsed from the target JSON data shard (e.g., Key="pages_1-100" in IndexedDB). Then, within the document container of the web page, a number of placeholder containers equal to the total number of pages are created in a loop (e.g., ...). Each placeholder container corresponds to one page. During creation, a unique page number identifier attribute (e.g., data-page="50") is set for each placeholder container, and the CSS width and height of the placeholder container are precisely set according to the physical width and height (in millimeters) defined for that page in the OFD file. By creating full placeholder containers to fix the page layout, the document skeleton structure is built, ensuring accurate scroll height, reliable page jump positioning, and providing a layout foundation for rendering only the visible area content later, while avoiding page jitter or performance degradation caused by dynamically adding or deleting containers.

[0044] Step 104: Extract the pre-rendered page JSON data with the pre-rendered page number from the target JSON data fragment, and render the real content of the first placeholder container with the pre-rendered page number according to the pre-rendered page JSON data, and render the skeleton screen placeholder elements of the second placeholder container with the page number not pre-rendered page number.

[0045] Specifically, the pre-rendered page number is based on the user's target page number (e.g., 30) and a preset rendering range (e.g., [...]). The set of page numbers to be actually rendered is calculated using [2,+2], for example, [28,29,30,31,32]. The pre-rendered page JSON data is the specific page object whose page number belongs to the pre-rendered page number, selected from the target JSON data fragments. The first placeholder container is the placeholder container for page numbers belonging to the pre-rendered page number; the first placeholder container will be replaced with a complete DOM structure containing real text, images, SVG, and other elements. The second placeholder container is the placeholder container for page numbers not within the range of the pre-rendered page numbers; it will only be retained or replaced with a minimalist skeleton screen. The skeleton screen placeholder elements are lightweight UI placeholders (such as...). (), used to fill a second placeholder container, and can also be used visually to indicate "content is here but not yet loaded".

[0046] In some embodiments, pre-rendered page JSON data whose page numbers belong to pre-rendered page numbers is filtered from the loaded target JSON data fragments. Then, all placeholder containers on the page are traversed: for the first placeholder container whose page number is a pre-rendered page number, the content of the first placeholder container is cleared and a real DOM structure containing text, images, SVG, and other elements is generated and filled according to the corresponding page's pre-rendered page JSON data; for the second placeholder container whose page number is not a pre-rendered page number, it is ensured that only lightweight skeleton screen placeholder elements (such as an empty div with a background color) are retained inside, and no actual document content is drawn. Through differentiated rendering, high-overhead rendering is performed only on the visible and adjacent areas, while the remaining areas maintain extremely low memory usage, thereby significantly reducing overall resource consumption while ensuring browsing smoothness.

[0047] Based on the OFD file rendering method provided in this application, the JSON structure data corresponding to the OFD file is segmented according to a preset page range to obtain multiple JSON data fragments. Each JSON data fragment is stored in the web-based index database, avoiding the memory overhead of loading all data at once. According to the target browsing page number and the preset rendering range, the corresponding pre-rendered page and its pre-rendered page number are calculated. The target JSON data fragment to which the pre-rendered page belongs is read from the index database based on the pre-rendered page number, reducing data transmission and parsing overhead. Based on the total number of pages in the OFD file fragments corresponding to the target JSON data fragments, placeholder containers with the same number of pages are created on the web-based page to construct a complete document skeleton structure. Each placeholder container is marked with its corresponding page number to ensure page layout stability and provide a layout foundation for virtual scrolling. This method extracts pre-rendered page JSON data with pre-rendered page numbers from the target JSON data fragments. Based on this data, it renders the actual content of the first placeholder container with the pre-rendered page number, ensuring that actual elements are generated only in the visible or adjacent areas. It also renders skeleton screen placeholder elements for the second placeholder container with a non-pre-rendered page number, reducing unnecessary rendering overhead and balancing rendering efficiency with user experience. This solves the rendering latency problem caused by full rendering of OFD files on the web, enabling efficient and stable browsing of OFD files on the web. The web-based OFD file rendering method provided in this application divides the complete JSON structure data after parsing the OFD file into multiple lightweight JSON data fragments according to a preset page number range and persists them to an index database, avoiding long-term resident memory of large amounts of JSON structure data. It dynamically calculates the required pre-rendered pages and pre-rendered page numbers based on the target browsing page number and a preset rendering range (e.g., ±3 pages) and accurately reads the target JSON data fragment to which the pre-rendered page belongs from the index database. Next, during page initialization, placeholder containers with the same number of pages as the document are created. This avoids page jitter during scrolling through a fixed layout, and the lightweight nature of the containers minimizes resource consumption. Finally, only the first placeholder container, which belongs to the pre-rendered page number, is rendered with actual content. For the other second placeholder containers, only the skeleton screen is rendered. This reduces the total number of DOM elements and the amount of rendering computation, thus avoiding the memory pressure caused by full rendering. This allows the web client to stably and smoothly process (parse and render) OFD files with limited resources.

[0048] In some embodiments, before the step of segmenting the JSON structure data corresponding to the OFD file based on a preset page number range, the method further includes: Obtain the OFD file, decompress it using the JSZip library, and obtain the corresponding XML file object; The OFD-XML-PARSER parser is used to parse XML file objects and convert them into JSON structured data. Calculate the serialized byte length of JSON structured data, and count the number of elements in the array composed of all text type objects in the JSON structured data; If the serialized byte length is greater than or equal to the first preset threshold, or the number of elements is greater than or equal to the second preset threshold, the OFD file is determined to be a large OFD file.

[0049] Specifically, the JSZip library is a widely used JavaScript library for decompressing ZIP format files. OFD files are user-uploaded or loaded files with the ".ofd" extension; their MIME type can be application / octet-stream or a custom type, and their content is ZIP format binary data. The XML file object is the main description file OFD.xml (or Doc_0 / Document.xml, etc.) within the OFD file, containing core information such as document structure, page definitions, text blocks, and graphic coordinates, in standard XML format. The OFD-XML-PARSER parser is an XML parsing tool used to convert the OFD XML structure into JavaScript objects (i.e., JSON structure data) that are easy for front-end operations. Serialization byte length is the number of bytes in the JSON structure data after converting it to a string using JSON.stringify(), calculated using TextEncoder, reflecting the size of the JSON structure data in memory or during transmission. The number of elements in the text type object array is the total number of all text-type elements (such as text blocks and characters) in the JSON structure data (reflecting content complexity).

[0050] As an example, see reference Figure 2 The system decompresses user-uploaded OFD files using the JSZip library, extracting the main description file (e.g., "OFD.xml" or "Doc_0 / Document.xml") to obtain an XML file object. Then, the self-developed OFD-XML-PARSER parser is used to perform structured parsing of this XML file object, converting it into JSON structured data suitable for front-end processing. This JSON structured data contains nested arrays of all pages and their text, images, vector graphics, and other objects. Next, the system performs a dual load assessment: firstly, it serializes the JSON structured data into a string using JSON.stringify() and calculates the byte length of the JSON structured data using TextEncoder to measure the overall data volume; secondly, it iterates through all text object arrays (e.g., textObjs) across all pages, counting the total number of all text elements to obtain the number of elements in the arrays of all text type objects, reflecting the potential DOM node complexity. If the serialized byte length reaches a first preset threshold (e.g., 50 MB), or the number of elements reaches a second preset threshold (e.g., 10,000), the OFD file is determined to be a large OFD file, and the step of splitting the JSON structure data corresponding to the open-format document OFD file based on a preset page number range is executed. If the OFD file is a large OFD file, it is split and saved. If the OFD file is not a large OFD file, based on the second total page number of the OFD file corresponding to the JSON structure data, placeholder containers with the same number of pages as the second total page number are created on the web page, and each placeholder container is marked with the corresponding page number; the JSON structure data is parsed, and the placeholder containers are rendered with full real content according to the JSON structure data.

[0051] In some embodiments, the step of creating a placeholder container with the same number of pages as the total number of pages on the web page includes: The pages contained in the OFD file fragments are used as placeholder pages. The OFD file is parsed by the OFD-XML-PARSER parser to obtain the physical width and height attribute values ​​of the placeholder pages. The unit of the physical width and height attribute values ​​is millimeters. Create a reference element with a preset width in the web page, obtain the actual pixel width of the reference element, and determine the millimeter to pixel conversion ratio by using the physical width and height attribute values ​​and the actual pixel width; Based on the conversion ratio, the physical width and height attribute values ​​of the page to be placed are converted into the corresponding pixel size; Call the document.createElement() method to create a placeholder container with the same number of pages as the total number of pages on the web page, and set the size of each pixel to the CSS width and height of the corresponding placeholder container; When performing page scaling operations on a placeholder page, apply a scaling ratio to the display size of the placeholder container; When performing export or print operations on a placeholder page, the export or print operation is performed based on the physical width and height attribute values ​​of the placeholder page.

[0052] Specifically, the placeholder pages are all pages in the OFD file that require space to be reserved in the web page, with each placeholder page corresponding to a placeholder container. The physical width and height attributes are the actual page dimensions defined in the OFD file (in millimeters, such as 210mm × 297mm for A4 paper), uniformly specified by the OFD format standard to ensure accurate physical dimensions when printing / exporting the document. The reference element is a hidden DOM element with a fixed width (such as 1mm) created in the web page, used to calibrate the conversion relationship between millimeters and pixels (due to differences in pixel density across different devices / browsers, the pixel value corresponding to 1mm may vary).

[0053] As an example, the pages contained in the OFD file fragments are designated as placeholder pages. The OFD-XML-PARSER parser is used to parse the OFD file, extracting the physical width and height attributes (in millimeters, such as 210mm × 297mm for A4 paper) of the placeholder pages from the parsing results. These physical width and height attributes are the original physical dimensions defined in the OFD file, serving as the benchmark for subsequent size conversion. A hidden reference element with a preset width of 1mm is dynamically created on the web page. The actual pixel width of this reference element can be obtained using JavaScript, and the millimeter-to-pixel conversion ratio is calculated as "actual pixel width of the reference element ÷ 1mm" to eliminate size deviations caused by differences in pixel density across different devices and browsers. Next, based on the conversion ratio, the physical width and height attributes of the placeholder pages are converted to pixel dimensions, ensuring that the screen display size of the placeholder container matches the proportions of the original page. Subsequently, by calling the `document.createElement('div')` method, placeholder containers with the same number of pages are created in a loop. Each placeholder container has its CSS width and height set to the converted pixel dimensions, and its corresponding page number is marked using the `data-page` property. All containers are then inserted into the main page container using `DocumentFragment` to reduce DOM manipulation overhead. When the user zooms in or out, the placeholder containers' `transform:scale` property is adjusted to update their display size in real time, ensuring the page content proportions remain unchanged after zooming. When exporting or printing, pixel dimensions are discarded, and the original physical width and height values ​​(in millimeters) are used directly as output parameters, ensuring the physical dimensions of the exported file or printed result are consistent with the original OFD page. By dynamically calibrating size conversion and adapting to display and output scenarios, the problem of page display proportion distortion on different web devices is solved, while ensuring the accuracy of physical dimensions during export / printing. Batch creation of containers ensures layout stability and provides a precise size benchmark for subsequent rendering.

[0054] In some embodiments, reference Figure 3 The steps for rendering the actual content in the first placeholder container with the pre-rendered page number, based on the pre-rendered page JSON data, include: Step 301: Parse the JSON data of the pre-rendered page and extract the basic page attributes, signature object data, image object data, drawing object data and text object data of the pre-rendered page; Step 302: Determine the placeholder container with the page number being the pre-rendered page number as the first placeholder container, and position the first placeholder container; Step 303: Clear the content inside the first placeholder container and create a parent container tag element based on the page's basic attributes, including the width and height of the pre-rendered page. Step 304: Based on the signature object data, image object data, drawing object data, and text object data, fill the interior of the parent container tag element; Step 305: Insert the filled parent container tag element into the first placeholder container, and render and display the pre-rendered page through the DOM rendering mechanism.

[0055] Specifically, the basic page attributes are the basic metadata of the corresponding pre-rendered page, which may include width and height, used to set the size reference of the rendering container. The signature object data is the description information of the electronic signature or seal in OFD, which may include signature type, coordinates, rotation angle, image resource references, etc. The image object data is the image information embedded in the corresponding pre-rendered page, such as base64 encoding, resource path, position (x, y), width and height, cropping area, etc. The drawing object data may contain a set of instructions for vector graphics (such as lines, rectangles, Bézier curves), which needs to be converted to SVG elements for high-fidelity rendering. The text object data is the text content and its layout information in the pre-rendered page, including text content, font, font size, color, coordinates, alignment, etc.; special characters (such as rare characters) in the text object data need to be converted to SVG paths. The parent container tag element is the newly created... or <svg>The element, as the root node of the pre-rendered page content, has its width and height determined by the basic page properties. The parent container element is used to wrap all child elements and uniformly control their scaling, positioning, and other styles.

[0056] As an example, when it is determined that a pre-rendered page corresponding to a certain pre-rendered page number needs to be rendered with real content, the JSON data of the pre-rendered page corresponding to that page is parsed in a structured manner to extract the basic page attributes, signature object data, image object data, drawing object data, and text object data. Then, based on the pre-rendered page number, the corresponding placeholder container in the web page is located, and the placeholder container of the pre-rendered page number is determined as the first placeholder container. The original skeleton screen or other temporary content within the first placeholder container is cleared, and a new parent container tag element (such as...) is created based on the basic page attributes. The Cascading Style Sheets (CSS) dynamically calculate the width and height using a global millimeter-to-pixel conversion ratio to ensure precise dimensions. Next, following the layer order of the OFD specification, objects such as signatures, images, vector graphics, and text are sequentially converted into corresponding HTML or SVG elements and populated into the parent container. The completed parent container is then inserted into the first placeholder container, and the web-side (browser) DOM rendering mechanism automatically completes the layout and drawing, achieving a realistic, high-fidelity display of the pre-rendered page. Through structured parsing and layered rendering, the layout and styles of OFD page elements are accurately reproduced, efficiently achieving a realistic presentation of the pre-rendered page and meeting user viewing needs.

[0057] In some embodiments, reference Figure 4 The steps for populating the interior of the parent container tag element based on signature object data, image object data, drawing object data, and text object data include: Step 401: Generate a signature tag element based on the signature object data, and insert the signature tag element into the parent container tag element; Step 402: Generate image tag elements based on image object data and insert the image tag elements into the parent container tag elements; Step 403: Parse the drawing object data, generate special drawing elements using SVG tags and / or SVG path tags, and insert the special drawing elements into the parent container tag element; Step 404: Determine whether the text object data contains special symbols or artistic fonts; Step 405: If yes, parse the text object data, generate the corresponding text special drawing element using SVG tags and / or SVG path tags, and insert the text special drawing element into the parent container tag element; Step 406: If not, generate a text tag element based on the text object data and insert the text tag element into the parent container tag element.

[0058] Specifically, the signature tag element is created based on signature object data (path, coordinates, etc.). Labels are used to display electronic signatures and support positioning and rotation styles. Image label elements are generated from image object data. The `<image>` tag is used to render image content within a document. Special drawing elements are accessed via... <svg>Vector graphics (such as lines, curves, complex graphics) implemented by the <label> tag or <SVG path> tag are generated based on the coordinates and style parameters of the drawing object data. The special drawing element for text is used when the text contains special symbols or artistic fonts. <svg>The text graphics drawn by the label or <SVG path> label ensure the accurate rendering of special text styles. The text label element corresponds to ordinary text or Tags are created based on the content, font, color, and other attributes of text object data.

[0059] As an example, to achieve high-fidelity rendering of OFD page content on the web, the system employs a typed and differentiated DOM construction strategy when populating the parent container element. First, it creates a DOM based on the signature object data. or The electronic signature label element is set with absolute positioning and size, and inserted into a parent container to ensure the legal validity and accurate positioning of the electronic signature. Secondly, it is generated according to the image object data standard. For elements, the corresponding image resources are loaded and laid out according to the original coordinates and scaling parameters. For drawing object data (such as lines, rectangles, Bézier curves, etc.), the system parses the path instructions of the drawing object data, which can be done through... <svg>The container combines multiple <SVG path> elements to generate vector graphics. For text object data, further intelligent judgment is made: if the text object data contains rare characters, ethnic minority characters, mathematical symbols or artistic fonts (i.e., characters that the system cannot reliably render), the preset font outline data is called to convert the text content into <svg>The special text drawing element composed of or Tag elements are inserted after setting their font, size, color, and absolute positioning. All elements are inserted into the parent container in the layer order defined by the OFD specification, ensuring the correct overlay relationship between signatures, images, vectors, and text. By categorizing and processing various elements, and using adaptive tags to accurately reproduce the content, the rendering challenges of special symbols and artistic fonts are solved, ensuring that the layout of page elements is consistent with the original OFD, and achieving a complete and accurate presentation of the content.

[0060] Optionally, the step of rendering skeleton screen placeholder elements for the second placeholder container of non-pre-rendered page numbers includes: The placeholder container for non-pre-rendered page numbers is identified as the second placeholder container, and the first placeholder container is located. Clear the contents of the second placeholder container and create a second parent container tag element; A blank placeholder element is generated by filling the interior of the second parent container element with a skeleton screen placeholder element. Insert blank placeholder elements into the placeholder container, and render and display them through the DOM rendering mechanism.

[0061] In some embodiments, reference Figure 5 After rendering the actual content to the first placeholder container with the pre-rendered page number based on the pre-rendered page JSON data, the process also includes: Step 501: When a user's page-turning operation is detected, causing a change in the target browsing page number, the updated second pre-rendered page is determined based on the updated target browsing page number and the preset rendering range. Step 502: Determine whether the rendered page that has been rendered is the second pre-rendered page; Step 503: If not, identify the rendered page as the first page to be cleaned; Step 504: Perform a cleanup operation on the first page to be cleaned; Step 504, which involves performing a cleanup operation on the first page to be cleaned, includes: Step 5041: Locate the outermost parent container element corresponding to the first page to be cleaned, clear all child elements inside the outermost parent container element, and remove the tag node of the first page to be cleaned. Step 5042: Unbind all event listeners from the parent container element and its child elements of the first page to be cleaned. Step 5043: Insert a skeleton screen placeholder element into the outermost parent container element that has been cleared; Step 5044: Use the page JSON data used to render the first page to be cleaned as the data to be cleaned, and set the data to be cleaned stored in memory to null so that the garbage collection mechanism on the web side can reclaim the memory occupied by the data to be cleaned.

[0062] Specifically, the updated second pre-rendered page is the rendered page recalculated based on the new target page number and preset range after the user flips through the page (e.g., if the original pre-rendered pages are 28-32, and the target page number after flipping through is 40, then the second pre-rendered page is 38-42). The already rendered pages are those where the actual content rendering was completed previously (e.g., pages 28-32 before flipping through the page). The first page to be cleaned up is the already rendered page that does not belong to the second pre-rendered page (e.g., pages 28-37 outside of pages 38-42 after flipping through the page), and the resources they occupy need to be released. The outermost parent container element is the root element created for a page during the actual rendering phase. or <svg>The container encloses all content elements on the page and serves as the entry point for performing cleanup operations.

[0063] After rendering the actual content of the first placeholder container corresponding to the current pre-rendered page number, the system further introduces a dynamic resource cleanup mechanism. As an example, when a user performs a page-turning operation (such as scrolling or jumping) causing a change in the target browsing page number, the updated second pre-rendered page is recalculated based on the updated target browsing page number and the preset rendering interval. Then, all rendered pages that have completed actual rendering are traversed to determine if the rendered page is the second pre-rendered page; if not, it is marked as the first page to be cleaned up. For each first page to be cleaned up, the corresponding placeholder container is first located by the corresponding page number, and the outermost parent container element (i.e., the previously inserted actual content container) that serves as the root node of the content is obtained. All child DOM nodes within this outermost parent container element are recursively cleared, and the entire container is removed. Simultaneously, the system unbinds event listeners (such as signature clicks, text selection, and other interaction callbacks) from the parent container and all its child elements. Next, a lightweight skeleton screen placeholder element (such as an empty screen with a background color) is inserted into the placeholder container. To maintain page layout height and visual continuity, the system then marks the JSON data cached in memory used for rendering the page as data to be cleaned up and explicitly sets its variable to null. This breaks the JavaScript engine's reference chain to the data object, allowing the web's garbage collection mechanism to automatically reclaim the memory space it occupies in subsequent runtime cycles. By dynamically cleaning up page resources outside the current pre-rendering scope, the system avoids DOM elements, event listeners, and redundant data from occupying memory for extended periods, effectively preventing memory overflow and page lag. Simultaneously, the skeleton screen maintains layout stability, ensuring smooth page turning for users and balancing resource release with browsing experience.

[0064] In some embodiments, reference Figure 6 When an anomaly is detected during the parsing or rendering of an OFD file, the current memory usage status is obtained through the performance.memory API on the web client, and the current memory usage status is used to determine whether the anomaly is caused by a memory leak. If the anomaly is determined to be caused by a memory leak, reduce the preset rendering range; Based on the narrowed preset rendering range and the target browsing page number, determine the updated third pre-rendered page; Determine whether the rendered page is the third pre-rendered page. If the rendered page is not the third pre-rendered page, determine the rendered page as the second page to be cleaned up. Perform a cleanup operation on the second page to be cleaned to free up memory, and generate a skeleton screen placeholder element and a reload button at the location of the abnormal page; If it is determined that the exception is not caused by a memory leak, the exception information is captured and stored in the local cache; When the main thread on the web is idle, the exception information is reported to the server through a background thread, and a skeleton screen placeholder element and a reload button are generated at the location of the exception page. Record the number of reloads; If the number of reloads exceeds the preset threshold, an error placeholder image will be rendered at the location of the abnormal page to alert the user that the page parsing is abnormal.

[0065] Specifically, a memory leak refers to the phenomenon where unused memory in a program is not released, leading to a continuous increase in memory usage and potentially causing parsing / rendering errors. The third pre-rendered page is the pre-rendering range redefined based on the target page number after narrowing the preset rendering interval (e.g., the original interval ±5 pages becomes ±2 pages after narrowing). The second page to be cleaned up is a rendered page that does not belong to the third pre-rendered page and needs to be cleaned up to release memory. Error information refers to the error log (such as error type and stack trace) when parsing or rendering errors occur, used for troubleshooting.

[0066] As an example, when an exception is detected during parsing or rendering, the browser's `performance.memory` API is called to obtain the current JavaScript heap memory usage (including the used heap size `usedJSHeapSize` and the heap limit `jsHeapSizeLimit`). If the used memory percentage exceeds a preset threshold (e.g., 90%), the exception is determined to be caused by memory pressure or a potential memory leak. At this point, the preset rendering range (e.g., originally ±5 pages) is automatically and dynamically reduced (e.g., adjusted to ±3 pages), and the third pre-rendered page is recalculated based on the updated preset rendering range and the current target page number. Subsequently, all rendered pages that have been rendered are traversed, and rendered pages that do not belong to the third pre-rendered page are marked as the second page to be cleaned up. A complete cleanup operation is performed, including: locating its outermost parent container, removing all child DOM nodes, unbinding event listeners, releasing cached JSON data (setting it to null), and inserting skeleton screen placeholder elements and a "reload" button into the original placeholder container to maintain interface usability. If the exception is determined not to be caused by a memory leak (e.g., incorrect data format, missing resources), the exception stack trace, page number, timestamp, and other information are captured and stored in a local cache such as localStorage. A background task is then started via requestIdleCallback to asynchronously report the exception log to the server when the main thread is idle. Simultaneously, a skeleton screen and a retry button are displayed on the exception page. The system synchronously records the number of reloads for this page. If the cumulative number of retries exceeds a preset threshold (e.g., 3 times), retries are stopped, and a fixed error placeholder image is rendered at the corresponding location, clearly indicating to the user that the page has an unrecoverable parsing exception. By dynamically monitoring memory and handling exceptions in a tiered manner, problems caused by memory leaks can be mitigated, and non-memory errors can be traced through exception reporting. Combined with the reload mechanism and error messages, system stability is ensured while improving user experience.

[0067] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the rendering method of the OFD file on the Web side of this application. Any simple transformations based on this technical concept are within the protection scope of this application.

[0068] This application also provides a rendering device for OFD files on a web platform; please refer to [reference needed]. Figure 7 The rendering devices for OFD files on the web include: The file segmentation module 701 is used to segment the JSON structure data corresponding to the OFD file based on a preset page number range, obtain multiple JSON data fragments, and store each JSON data fragment in the index database on the Web side. The sharded data reading module 702 is used to calculate the corresponding pre-rendered page and the pre-rendered page number of the pre-rendered page based on the target browsing page number and the preset rendering range, and read the target JSON data shard to which the pre-rendered page belongs from the index database based on the pre-rendered page number. Blank placeholder module 703 is used to create placeholder containers on the web page with the same number of pages as the total number of pages in the OFD file fragments corresponding to the target JSON data fragments, and to mark the corresponding page number for each placeholder container; Rendering module 704 is used to extract pre-rendered page JSON data with page numbers of pre-rendered page numbers from the target JSON data fragment, and to render the real content of the first placeholder container with page numbers of pre-rendered page numbers according to the pre-rendered page JSON data, and to render skeleton screen placeholder elements of the second placeholder container with page numbers of non-pre-rendered page numbers.

[0069] The rendering apparatus for web-based OFD files provided in this application, employing the web-based OFD file rendering method described in the above embodiments, can solve the technical problem of rendering delay caused by full rendering of web-based OFD files in the prior art. Compared with the prior art, the beneficial effects of the web-based OFD file rendering apparatus provided in this application are the same as those of the web-based OFD file rendering method provided in the above embodiments, and other technical features in the web-based OFD file rendering apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0070] This application provides a rendering device for web-based OFD files. The rendering device for web-based OFD files includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the rendering method for web-based OFD files in the first embodiment described above.

[0071] The following is for reference. Figure 8 The diagram illustrates a structural schematic of a rendering device suitable for implementing web-based OFD files in the embodiments of this application. The rendering device for web-based OFD files in the embodiments of this application may include, but is not limited to, mobile terminals such as laptops, tablets (Portable Application Description, PADs), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 8 The rendering device for the web-based OFD file shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0072] like Figure 8 As shown, the rendering device for web-based OFD files may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the web-based OFD file rendering device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the rendering device for web-based OFD files to communicate wirelessly or wiredly with other devices to exchange data. Although a rendering device for web-based OFD files with various systems is shown in the figure, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems may be implemented alternatively.

[0073] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0074] The rendering device for web-based OFD files provided in this application, employing the web-based OFD file rendering method described in the above embodiments, can solve the technical problem of rendering delay caused by full rendering of web-based OFD files in the prior art. Compared with the prior art, the beneficial effects of the web-based OFD file rendering device provided in this application are the same as those of the web-based OFD file rendering method provided in the above embodiments, and other technical features in this web-based OFD file rendering device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0075] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0076] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0077] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the web-based OFD file rendering method in the above embodiments.

[0078] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0079] The aforementioned computer-readable storage medium may be included in the rendering device of the web-based OFD file; or it may exist independently and not be mounted in the rendering device of the web-based OFD file.

[0080] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a rendering device for an OFD file on the web, the rendering device performs the following actions: It divides the JSON structure data corresponding to the OFD file based on a preset page number range to obtain multiple JSON data fragments, and stores each JSON data fragment in the web's index database. The JSON structure data is obtained by structured parsing of the OFD file. Based on the target browsing page number and the preset rendering range, it calculates the pre-rendered page number of the corresponding pre-rendered page and reads the target JSON data fragment to which the pre-rendered page belongs from the index database based on the pre-rendered page number. Based on the total number of pages in the OFD file fragments corresponding to the target JSON data fragments, it creates placeholder containers on the web page with the same number of pages as the total number of pages and marks each placeholder container with the corresponding page number. It extracts the pre-rendered page JSON data with the pre-rendered page number from the target JSON data fragments, and renders the actual content of the first placeholder container with the pre-rendered page number and the skeleton screen placeholder elements of the second placeholder container with a page number other than the pre-rendered page number, based on the pre-rendered page JSON data.

[0081] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0082] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0083] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0084] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described rendering method for web-based OFD files, thereby solving the technical problem of rendering delay caused by full rendering of web-based OFD files in the prior art. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the rendering method for web-based OFD files provided in the above embodiments, and will not be repeated here.

[0085] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method for rendering OFD files on a web platform.

[0086] The computer program product provided in this application can solve the technical problem of rendering delay caused by full rendering of OFD files on the Web side in the prior art. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the rendering method of OFD files on the Web side provided in the above embodiments, and will not be repeated here.

[0087] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application. < / svg> < / svg> < / svg> < / svg> < / svg> < / svg>

Claims

1. A rendering method of a Web-side OFD file, characterized by, The rendering method of the Web-side OFD file comprises: segmenting JSON structure data corresponding to an open format document (OFD) file based on a preset page number interval to obtain a plurality of JSON data segments, and storing each of the JSON data segments in an index database of a Web side, wherein the JSON structure data is obtained by structurally analyzing the OFD file; calculating a pre-rendering page number of a corresponding pre-rendering page according to a target browsing page number and a preset rendering interval, and reading a target JSON data segment to which the pre-rendering page belongs from the index database according to the pre-rendering page number; based on a total number of OFD file segments corresponding to the target JSON data segment, creating the same number of placeholder containers as the total number of pages on the Web side, and marking each of the placeholder containers with a corresponding page number; extracting pre-rendering page JSON data with a page number being the pre-rendering page number from the target JSON data segment, and performing real content rendering on a first placeholder container with the page number being the pre-rendering page number and rendering a skeleton screen placeholder element on a second placeholder container with the page number not being the pre-rendering page number according to the pre-rendering page JSON data.

2. The Web OFD file rendering method of claim 1, wherein, Before the step of segmenting the JSON structure data corresponding to the OFD file based on the preset page number interval, the method further comprises: obtaining the OFD file, decompressing the OFD file through a JSZip library to obtain an extensible markup language (XML) file object; using an OFD-XML-PARSER parser to parse and convert the XML file object into JSON structure data; calculating a serialized byte length of the JSON structure data, and counting the number of elements of an array formed by all text type objects in the JSON structure data; if the serialized byte length is greater than or equal to a first preset threshold or the number of elements is greater than or equal to a second preset threshold, performing the step of segmenting the JSON structure data corresponding to the OFD file based on the preset page number interval.

3. The rendering method of the Web-side OFD file according to claim 1, wherein, The step of storing each of the JSON data segments in the index database of the Web side comprises: constructing a corresponding key-value pair for each of the JSON data segments, wherein the key is a page number interval range contained in the corresponding JSON data segment, and the value is the corresponding JSON data segment; writing the key-value pair corresponding to each of the JSON data segments into the index database; After the step of writing the key-value pair corresponding to each of the JSON data segments into the index database, the method further comprises: assigning a variable storing the JSON structure data corresponding to the OFD file to null, so as to trigger a garbage collection mechanism of the Web side to recycle memory space occupied by the JSON structure data.

4. The rendering method of the Web-side OFD file according to claim 1, wherein, The step of creating the same number of placeholder containers as the total number of pages on the Web side comprises: The OFD file is parsed by an OFD-XML-PARSER parser to obtain physical width and height attribute values of the placeholder page, and the physical width and height attribute values are in millimeters; A reference element with a preset width is created in the Web page, and an actual pixel width of the reference element is obtained, and a conversion ratio of millimeters to pixels is determined based on the physical width and height attribute values and the actual pixel width; The physical width and height attribute values of the placeholder page are converted into corresponding pixel sizes based on the conversion ratio; A document.createElement() method is called to create the same number of placeholder containers as the total number of pages in the Web page, and each pixel size is set as a Cascading Style Sheets (CSS) width and height of the corresponding placeholder container; When a page scaling operation is performed on the placeholder page, a scaling ratio is applied to the display size of the placeholder container; When an export or printing operation is performed on the placeholder page, the export or printing operation is performed based on the physical width and height attribute values of the placeholder page.

5. The rendering method of the Web-side OFD file according to claim 1, wherein, The step of performing real content rendering on the first placeholder container with the pre-rendered page number based on the pre-rendered page JSON data includes: The pre-rendered page JSON data is parsed to extract page basic attributes, signature object data, image object data, drawing object data, and text object data of the pre-rendered page; The placeholder container with the pre-rendered page number is determined as the first placeholder container, and the first placeholder container is located; The content in the first placeholder container is emptied, and a parent container tag element is created based on the page basic attributes, including the width of the pre-rendered page and the height of the pre-rendered page; The parent container tag element is filled based on the signature object data, the image object data, the drawing object data, and the text object data; The filled parent container tag element is inserted into the first placeholder container, and the pre-rendered page is rendered and displayed through a Document Object Model (DOM) rendering mechanism.

6. The Web-end OFD file rendering method of claim 5, wherein, The step of filling the inside of the parent container tag element based on the signature object data, the image object data, the drawing object data, and the text object data includes: A signature tag element is generated based on the signature object data, and the signature tag element is inserted into the parent container tag element; An image tag element is generated based on the image object data, and the image tag element is inserted into the parent container tag element; The drawing object data is parsed, a special drawing element is generated using Scalable Vector Graphics (SVG) tags and / or SVG path tags, and the special drawing element is inserted into the parent container tag element; It is determined whether the text object data contains special symbols or artistic fonts; If yes, parse the text object data, generate corresponding text special drawing elements using the SVG tag and / or the SVG path tag, and insert the text special drawing elements into the parent container tag element; If no, generate a text tag element according to the text object data, and insert the text tag element into the parent container tag element.

7. The Web OFD file rendering method of claim 1, wherein, After the step of performing real content rendering on the first placeholder container corresponding to the pre-rendered page code according to the pre-rendered page JSON data, the method further comprises: When detecting that a user page turning operation causes a target browsing page code to change, determining an updated second pre-rendered page according to the updated target browsing page code and the preset rendering interval; determining whether the rendered page is the second pre-rendered page; If no, determining the rendered page as a first to-be-cleaned page, and performing a cleaning operation on the first to-be-cleaned page; The step of performing a cleaning operation on the first to-be-cleaned page comprises: locating a most outer parent container element corresponding to the first to-be-cleaned page, emptying all child elements inside the most outer parent container element, and removing a tag node of the first to-be-cleaned page; unbinding all event listeners on the parent container element and child elements of the first to-be-cleaned page; inserting the skeleton screen placeholder element into the emptied most outer parent container element; setting page JSON data used for rendering the first to-be-cleaned page as to-be-cleaned data, and setting the to-be-cleaned data stored in the memory as null, so that a garbage collection mechanism of the Web end recycles memory occupied by the to-be-cleaned data.

8. The Web OFD file rendering method of claim 1, wherein, Further comprising: When detecting that an exception occurs in the parsing process or the rendering process of the OFD file, obtaining a current memory usage state through the performance.memory API of the Web end, and determining whether the exception is caused by memory leakage through the current memory usage state; If it is determined that the exception is caused by memory leakage, narrowing the preset rendering interval; determining an updated third pre-rendered page according to the narrowed preset rendering interval and the target browsing page code; determining whether the rendered page is the third pre-rendered page, and if it is determined that the rendered page is not the third pre-rendered page, determining the rendered page as a second to-be-cleaned page; performing a cleaning operation on the second to-be-cleaned page to release memory, and generating the skeleton screen placeholder element and the reload button at an exception page position; If it is determined that the exception is not caused by the memory leakage, capturing exception information and storing the exception information in a local cache; when the main thread of the Web end is idle, reporting the exception information to a server through a background thread, and generating the skeleton screen placeholder element and the reload button at the exception page position; recording a reload count; If the reload count exceeds a preset load count threshold, rendering an error placeholder image at the exception page position to prompt a user that an exception page parsing exception occurs.

9. A rendering device of a Web-side OFD file, characterized by, The device comprises a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the rendering method of the Web-side OFD file according to any one of claims 1 to 8.

10. A storage medium, characterized by The storage medium is a computer readable storage medium, and the storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the rendering method of the Web-side OFD file according to any one of claims 1 to 8.

Images