Font generation method and device, electronic equipment and storage medium

Abstract

The invention relates to a font generation method and device, electronic equipment and a storage medium. The method comprises the steps that a target font used by a to-be-processed document is determined; generating a font file of a simulated font based on the target font, wherein the simulated font is used for simulating the target font; and rendering the to-be-processed document based on the font file corresponding to the simulated font. According to the scheme provided by the embodiment of the invention, the technical effect of carrying out high-fidelity and undifferentiated restoration on the original layout of the document in any terminal environment under the condition that an original font file is not needed is realized.

Description

Technical Field

[0001] This application relates to the field of computers, and more particularly to a font generation method, apparatus, electronic device, and storage medium. Background Technology

[0002] In the editing and circulation of digital documents, font loss is a long-standing and widespread problem. When a user opens a document created by someone else that uses a specific font (such as "Source Han Serif"), if the font is not installed on their local computer, the document processing software (such as WPS or Microsoft Word) usually uses a font replacement scheme to ensure that the text content is visible, that is, it automatically selects a local font that is already available for rendering and display.

[0003] However, existing technical solutions have significant drawbacks. Due to the diverse designs of different fonts, their core typographic metrics, such as the precise width and height of each character (the character's bounding rectangle) and the overall line height, vary. Directly replacing the font means these key metrics change, thus disrupting the original precise typography of the document. This manifests as inconsistent characters at the end of text lines, abnormal increases or decreases in the number of text lines, misaligned tables spanning multiple pages, and changes in the total number of pages in the document—all layout misalignment issues that severely impact the accurate presentation of document content and the user's reading experience. Summary of the Invention

[0004] This application provides a font generation method, apparatus, electronic device, and storage medium to solve the technical problem in the prior art that the document layout is disordered and the typesetting effect cannot be maintained in accordance with the original design due to the absence of fonts and direct replacement.

[0005] Firstly, this application provides a font generation method, the method comprising: Determine the target font used in the document to be processed; A font file for a simulated font is generated based on the target font, and the simulated font is used to simulate the target font; The document to be processed is rendered based on the font file corresponding to the simulated font.

[0006] In one possible implementation, generating a font file for a simulated font based on the target font includes: Obtain the basic layout data of the target font, which includes at least the set of commonly used characters of the target font, the width and height parameters of each character in the set of commonly used characters, and the line height parameters of the target font; Based on the typesetting base data, parameter information for constructing a simulated font is generated. The parameter information includes at least graphic combination data and typesetting parameter data. The graphic combination data is used to indicate the combination of basic geometric components to form the character outline of each character in the common character set. The typesetting parameter data is used to control the space size and line spacing when the simulated font is rendered based on the width and height parameters of each character and the line height parameter. Based on the parameter information, a font file corresponding to the simulated font is generated.

[0007] In one possible implementation, determining the target font used by the document to be processed includes: In response to the operation of opening the document to be processed, the system identifies the font specified in the document format information of the document to be processed that is missing in the current system environment, and determines the missing font as the target font.

[0008] In one possible implementation, obtaining the basic typographic data of the target font includes: Parse the text content of the document to be processed to determine the set of commonly used characters; In addition, a query is initiated to the preset font parameter database to obtain the width and height parameters of each character in the commonly used character set and the line height parameter of the target font.

[0009] In one possible implementation, the width and height parameters stored in the font parameter database are obtained in the following way: The characters of the target font are rendered under various resolutions and font rendering engine environments; The bounding rectangle of the rendered bitmap or contour image is measured to obtain the width and height parameters.

[0010] In one possible implementation, based on the typographical base data, graphic combination data for constructing the simulated font is generated, including: The basic typesetting data is input into a pre-trained artificial intelligence model, and the artificial intelligence model outputs the graphic combination data. The graphic combination data specifies a set of basic geometric components to be combined and a combination method for each character in the set of commonly used characters.

[0011] In one possible implementation, generating the font file corresponding to the simulated font based on the parameter information includes: Based on the graphic combination data, basic geometric components are selected and combined from the preset basic geometric component library to form the initial outline of each character in the commonly used character set; Based on the layout parameter data, the initial outline of each character is adjusted so that the width and height of the adjusted character outline conform to the corresponding width and height parameters. Based on the line height parameter, a corresponding font metric parameter is set for the simulated font so that the simulated font can be controlled to reach the line height specified by the line height parameter during rendering. The adjusted character outline data and the font measurement parameters are packaged into a font file that conforms to the standard font format.

[0012] In one possible implementation, the method further includes: Get the font rendering environment parameters of the current system; Based on the font rendering environment parameters and the target pixel size of the text to be rendered, the adjusted character outline is optimized, and corresponding outline fine-tuning instructions are generated. Add the outline fine-tuning instructions to the font file.

[0013] In one possible implementation, the method further includes: In response to a text application style change instruction, a derived font file with the corresponding style is generated based on the parameter information.

[0014] In one possible implementation, the method further includes: In response to the font style switching command, based on the layout parameter data and using a generation strategy corresponding to the target style, a new font file that matches the target style is generated to replace the current font file used for rendering.

[0015] In one possible implementation, generating a font file for a simulated font based on the target font includes: Obtain the access permission information of the document to be processed; Based on the access permission information, determine the set of characters that the font file of the simulated font must contain; Based on the target font and the character set, a font file for the simulated font is generated.

[0016] Secondly, this application provides a font generation apparatus, the apparatus comprising: The target font determination module is used to determine the target font used in the document to be processed; A font simulation module is used to generate a font file for a simulated font based on the target font, wherein the simulated font is used to simulate the target font; The font rendering module is used to render the document to be processed based on the font file corresponding to the simulated font.

[0017] In one possible implementation, the font simulation module includes: The data acquisition unit is used to acquire the basic layout data of the target font. The basic layout data includes at least the set of commonly used characters of the target font, the width and height parameters of each character in the set of commonly used characters, and the line height parameters of the target font. The parameter generation unit is used to generate parameter information for constructing a simulated font based on the typesetting basic data. The parameter information includes at least graphic combination data and typesetting parameter data. The graphic combination data is used to indicate the combination of basic geometric components to form the character outline of each character in the common character set. The typesetting parameter data is used to control the space occupied and line spacing when the simulated font is rendered based on the width and height parameters of each character and the line height parameter. The font file generation unit is used to generate the font file corresponding to the simulated font based on the parameter information.

[0018] In one possible implementation, the target font determination module is specifically used for: In response to the operation of opening the document to be processed, the system identifies the font specified in the document format information of the document to be processed that is missing in the current system environment, and determines the missing font as the target font.

[0019] In one possible implementation, the data acquisition unit includes: The common character determination subunit is used to parse the text content of the document to be processed and determine the set of common characters; The typesetting parameter acquisition subunit is used to initiate a query to a preset font parameter database to obtain the width and height parameters of each character in the commonly used character set and the line height parameter of the target font.

[0020] In one possible implementation, the width and height parameters stored in the font parameter database are obtained in the following way: The characters of the target font are rendered under various resolutions and font rendering engine environments; The bounding rectangle of the rendered bitmap or contour image is measured to obtain the width and height parameters.

[0021] In one possible implementation, the parameter generation unit includes: The first generation subunit is used to input the typesetting basic data into a pre-trained artificial intelligence model, and the artificial intelligence model outputs the graphic combination data. The graphic combination data specifies a set of basic geometric components to be combined and a combination method for each character in the set of commonly used characters.

[0022] In one possible implementation, the font file generation unit includes: The character outline forming subunit is used to select and combine basic geometric components from a preset basic geometric component library according to the graphic combination data to form the initial outline of each character in the commonly used character set; The character outline adjustment subunit is used to adjust the initial outline of each character according to the layout parameter data, so that the width and height of each character outline after adjustment conform to the corresponding width and height parameters. The line height setting subunit is used to set corresponding font measurement parameters for the simulated font according to the line height parameter, so as to control the simulated font to reach the line height specified by the line height parameter during rendering through the font measurement parameters; The file encapsulation subunit is used to encapsulate the adjusted character outline data and the font measurement parameters into a font file that conforms to the standard font format.

[0023] In one possible implementation, the device further includes: The size adjustment module is used to obtain the font rendering environment parameters of the current system; Based on the font rendering environment parameters and the target pixel size of the text to be rendered, the adjusted character outline is optimized, and corresponding outline fine-tuning instructions are generated. Add the outline fine-tuning instructions to the font file.

[0024] In one possible implementation, the device further includes: The style derivation module is used to generate a derived font file with a corresponding style based on the parameter information in response to text application style change instructions.

[0025] In one possible implementation, the device further includes: The style change module is used to respond to the font style switching command, and based on the layout parameter data and adopting a generation strategy corresponding to the target style, regenerate the simulated font file that conforms to the target style, so as to replace the font file currently used for rendering.

[0026] In one possible implementation, the font simulation module includes: The permission acquisition unit is used to acquire the access permission information of the document to be processed; The character set determination unit is used to determine the character set that the font file of the simulated font should contain based on the access permission information. The font file generation unit is used to generate a font file for the simulated font based on the target font and the character set.

[0027] Thirdly, this application provides an electronic device, including: a processor and a memory, wherein the processor is configured to execute a font generation program stored in the memory to implement the font generation method described in any one of the first aspects.

[0028] Fourthly, this application provides a storage medium storing one or more programs that can be executed by one or more processors to implement the font generation method described in any one aspect.

[0029] Compared with the prior art, the technical solution provided in this application has the following advantages: The method provided in this application dynamically identifies missing fonts in a document and triggers a simulated font generation process, thus eliminating the dependence on pre-installed font files; by generating a simulated font based on the original target font, it replicates key parameters that determine the layout, such as character width and height, line height, and character spacing, thereby ensuring high fidelity in document layout structures such as line breaks, pagination, and alignment; by encapsulating the generated result into a complete font file in a standard format, it ensures seamless compatibility and plug-and-play functionality with existing rendering engines and document processing software. In summary, the solution provided in this application achieves the technical effect of high-fidelity, indistinguishable restoration of the original document layout in any terminal environment without requiring the original font file. Attached Figure Description

[0030] 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.

[0031] 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.

[0032] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0033] Figure 1 A flowchart illustrating an embodiment of a font generation method provided in this application; Figure 2 A flowchart illustrating another embodiment of the font generation method provided in this application; Figure 3 A block diagram illustrating an embodiment of a font generation apparatus provided in this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0035] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0036] To address the technical problems in existing technologies where missing fonts and direct replacement result in disordered document layouts and an inability to maintain consistent typography with the original design, this application provides a font generation method, apparatus, electronic device, and storage medium that can achieve high-fidelity, seamless restoration of the original document layout in any terminal environment without requiring the original font file.

[0037] Figure 1 This is a flowchart illustrating an embodiment of a font generation method provided in this application. In one embodiment, the method is applied to a client. Here, "client" broadly refers to software with document display and editing functions, used to provide users with localized services, such as document browsing and editing. Specific implementations of the client include, but are not limited to: applications running as independent processes, sub-applications embedded in a host client (e.g., mini-programs), functional modules running on a web browser (also known as WebApps), or lightweight applications integrated into communication carriers such as email. This application does not limit the specific form of the client. Figure 1 As shown, the method includes the following steps: Step 101: Determine the target font used in the document to be processed.

[0038] The document to be processed refers to the electronic file containing formatted text content that needs to be rendered, displayed, or edited. Its format broadly refers to various text or graphic layout formats, including but not limited to documents in .doc, .docx, .pdf, .otd, and .pptx formats. The core task of step 101 is to determine the "missing font," or target font, that needs to be simulated subsequently based on the document to be processed.

[0039] In one embodiment, when the client loads the document to be processed, it extracts all explicitly defined font usage information by parsing its internal format structure (such as font declaration fields, text style configurations, format metadata, etc.). This font usage information includes, but is not limited to, font name, font style (such as regular, bold, italic, etc.), and the text range in which the font is applied. Subsequently, the client compares the extracted font list with fonts registered in the current operating system font library and / or the built-in font library of the local application. By comparing and filtering, fonts used in the document but not directly called by the rendering engine in the local environment are identified as target fonts.

[0040] For example, if the document to be processed is a .docx file, the client can parse its internal XML structure (such as in word / document.xml). <w:rfonts>The tag is used to extract the declared font name as "Siyuan Songti CN". Next, the client queries the local system font directory (such as C:\Windows\Fonts in Windows, / Library / Fonts in macOS) and the client's own font cache (e.g., the browser uses the system-installed font library by default; if a custom font is loaded, the font file will be temporarily cached in the browser's cache directory (e.g., AppData\Local\Google\Chrome\User Data\Default\Cache in Chrome)). If the font is not found in either directory, "Siyuan Songti CN" is determined to be a missing font and is identified as the target font.

[0041] For another example, if the document to be processed is a .pdf file, the client parses its internal structure to extract font information. A .pdf document might reference an external font through the / BaseFont name in the / Font dictionary, or it might describe the font it uses indirectly through / FontDescriptor and / ToUnicode. More commonly, a .pdf document will directly embed a subset of the fonts it uses within the file. This "font subset" typically only contains the outline data of the characters actually appearing in the document and may use custom naming (e.g., adding a random prefix to "Source Han Serif"). In this case, the client's core task remains determining whether the font (or its subset) is "available" in the local environment. Even if the font data is embedded, if the rendering engine cannot directly and correctly render the text due to format compatibility, permission restrictions, or a lack of a complete Character Map (CMap), the font can still be considered "missing" and thus identified as the target font. Therefore, for .pdf documents, the focus of step 101 is to identify the original font design that the document intends to present (e.g., by parsing the original name of / BaseFont or analyzing the font features of the embedded subset), and to determine whether it is missing from the local environment, thereby triggering the subsequent simulation generation process. This mechanism ensures that the method provided in this application embodiment can be widely applied to various document formats containing text, without being limited by the font embedding or referencing methods of a specific format.

[0042] Accordingly, in one embodiment, determining the target font used by the document to be processed includes: in response to the operation of opening the document to be processed, identifying a font specified in the document format information of the document to be processed that is missing in the current system environment, and determining the missing font as the target font.

[0043] Step 102: Generate a font file for a simulated font based on the target font. The simulated font is used to simulate the target font.

[0044] The simulated font refers to a font generated dynamically through calculation and geometric component synthesis, based on the target font's basic typographic data (including core parameters such as character width and height, line height, etc.) and design style characteristics obtained through analysis. This simulated font can be obtained by processing a preset base font through dynamic calculation and geometric component synthesis. The simulated font is highly consistent with the target font in typographic metrics affecting page layout, such as character width and height, line height, and letter spacing, thus achieving "fidelity in typography." Furthermore, it strives to closely approximate the target font in terms of design style, allowing the simulated font to directly replace the target font for document layout reproduction.

[0045] A simulated font file is a binary file that encapsulates all the data of a simulated font and conforms to a standard font format (such as TrueType or OpenType). This file contains a complete character encoding mapping table, character outline vector data, font metrics, and other necessary control information, and can be directly loaded by the operating system or word processing software for text rendering.

[0046] The core task of step 102 is to dynamically create a font file that can directly replace the target font for document rendering when the target font is missing locally; that is, a simulated font file. This generation process is based on the basic typesetting data obtained from the analysis of the target font, ensuring that the generated simulated font file can maintain the original layout and line breaks of the document to be processed without relying on the original target font, thus achieving "typesetting fidelity".

[0047] The specific implementation process for generating the font file of the simulated font based on the target font will be discussed in the following text. Figure 2 The process shown is explained in detail, but will not be elaborated here.

[0048] Step 103: Render the document to be processed based on the font file corresponding to the simulated font.

[0049] Step 103 aims to use the generated simulated font file to temporarily and seamlessly replace the missing target font to complete document rendering, achieve accurate restoration of the document layout, and solve the problem of layout disorder caused by missing fonts.

[0050] In practice, after generating the simulated font file, the client can temporarily register the simulated font file to the current process's font context or the system's font staging area by manipulating the font management interface provided by the application framework (for example, calling the `addApplicationFont()` function of `QFontDatabase` in the Qt framework, or using a similar dynamic font loading API (Application Program Interface) in other environments). Subsequently, when rendering the document to be processed, the rendering engine will automatically redirect all text drawing instructions that were originally mapped to the missing "target font" to the newly loaded simulated font file, based on all the original formatting attributes of the document (such as font size, color, paragraph style, etc.).

[0051] Because the simulated font matches the original target font in all core typography metrics such as character width, height, line height, and letter spacing, the final rendered document maintains a high degree of consistency with the original design in terms of layout. Specifically, text wrapping, page breaks, table column width and row height, the total number of rows in paragraphs, and even the total number of pages in the document are identical to the preview shown by the document creator using the original target font. This completely avoids typography problems such as increased or decreased line counts, page content overflow, or page offset caused by font substitution.

[0052] As can be seen from the above description, the technical solution provided in this application does not merely draw isolated discrete character graphics, but rather creates a fully functional, faithfully formatted font solution with software adaptability by integrating the layout matching characteristics of simulated fonts with the callable attributes of standard font files. This solution not only accurately replicates the core layout metrics of the target font, such as character width and height, line height, and character spacing, ensuring that the document layout matches the original effect, but also encapsulates complete character outlines, measurement tables, and control information in a standard format, enabling it to be directly called and rendered by word processing software, achieving a fundamental breakthrough from "character graphic replacement" to "full-dimensional layout restoration."

[0053] In addition, in one embodiment, the temporarily loaded simulated font file can be automatically unloaded by the client when the document is closed, or removed after a specific cleanup cycle, thereby ensuring that the font resources of the system or application are not occupied for a long time, and maintaining the efficiency and cleanliness of the operating environment.

[0054] The technical solution provided in this application eliminates the reliance on pre-installed font files by dynamically identifying missing fonts in a document and triggering a simulated font generation process. By generating a simulated font based on the original target font, it replicates key parameters that determine the layout, such as character width and height, line height, and character spacing, thus ensuring high fidelity in document layout structures such as line breaks, pagination, and alignment. By encapsulating the generated result into a complete font file in a standard format, it ensures seamless compatibility and plug-and-play functionality with existing rendering engines and document processing software. In summary, the solution provided in this application achieves the technical effect of high-fidelity, seamless restoration of the original document layout in any terminal environment without requiring the original font file.

[0055] Figure 2 A flowchart illustrating another embodiment of a font file generation method provided in this application. Figure 2 The process shown is in Figure 1 Based on the illustrated process, an exemplary implementation of generating a simulated font file from the target font is described. For example... Figure 2 As shown, it includes the following steps: Step 201: Obtain the basic layout data of the target font. The basic layout data should include at least the set of commonly used characters of the target font, the width and height parameters of each character in the set of commonly used characters, and the line height parameters of the target font.

[0056] Step 201 is the "data acquisition stage" for simulated font generation. The core task is to obtain the core feature data of the target font to provide accurate basis for subsequent simulated font generation.

[0057] The basic typesetting data refers to the core data set that can characterize the typesetting rules of the target font. It is the basic input for generating the simulated font and at least includes core metric data to ensure typesetting consistency. It can also include feature data that reflects the font style. In one embodiment, the basic typesetting data includes at least the set of commonly used characters of the target font, the width and height parameters of each character in the set of commonly used characters, and the line height parameters of the target font.

[0058] The target font's common character set refers to the core character range that must be prioritized for coverage and adaptation when generating the simulated font. For example, this set can be a combination of high-frequency characters actually appearing in the document being processed, or it can be a character set belonging to a specific Unicode block, determined based on the target font's built-in character mapping table (CMap) and general text statistics. This set defines the basic character range that the simulated font needs to generate and include.

[0059] The width and height parameters of each character in the common character set refer to the width value and height value corresponding to the bounding rectangle of the bitmap or vector outline finally presented by each common character in the target font in the rendering environment. This information is an accurate measurement of the occupied size of the character in the layout, and directly determines the horizontal width of the text flow and the vertical space within the line.

[0060] The line height parameter of the target font refers to the vertical distance measurement between the baselines of adjacent lines of text when typesetting the target font. This parameter is jointly determined by the character height, ascender, descender, and leading of the font, and is a key vertical measurement for controlling the number of lines in the document paragraph, the visual density of the line spacing, and the overall page layout.

[0061] In one embodiment, obtaining the typesetting basic data of the target font includes the following steps: First, parse the text content of the document to be processed to determine the common character set. Exemplarily, the client can scan the full text of the document, count the occurrence frequency of each character, filter out the frequently used characters (for example, in a Chinese document, characters such as "的", "是", "在" usually have a high frequency), and combine the character mapping table data inside the target font file to finally determine a common character set to be preferentially adapted. This set ensures that the subsequently generated simulated font can cover the core characters in the document.

[0062] Furthermore, as an optional implementation, generating the font file of the simulated font based on the target font includes: obtaining the access permission information of the document to be processed; determining the character set to be included in the font file of the simulated font according to the access permission information; generating the font file of the simulated font based on the target font and the character set.

[0063] In this implementation, the determined character set is the aforementioned common character set of the target font, but its specific range is dynamically adjusted according to the access permission. The core advantage of this mechanism is that it can achieve the best balance between resource occupancy and functional completeness according to the user's actual operation intention for the document: Among them, when the access permission of the document to be processed is read-only permission (for example, the user only uses it for preview, printing, or reading), the common character set is limited to only include the characters that actually use the target font in this document. This strategy ensures that the document layout can be completely and accurately restored with the smallest generation and loading overhead, achieving the maximization of resource efficiency.

[0064] When the document to be processed has editable access permissions (e.g., the user can modify or add content), the frequently used character set is expanded to include at least one of the following: ① characters actually used in the target font in the document; ② an extended character set. The extended character set aims to anticipate what the user might input during the editing process, and may include, but is not limited to: characters that are highly semantically or syntactically related to the existing text content of the document (such as synonyms, common collocations), common high-frequency words in the language to which the document belongs, or characters predicted based on user input habits. This proactive strategy ensures that when the user inputs new characters related to the original text during subsequent editing, the system does not need to interrupt the process to temporarily generate the character, thus guaranteeing a smooth editing workflow and a seamless user experience.

[0065] Through the aforementioned adaptive strategy based on document access permissions, while meeting the core requirements for layout restoration, the system further achieves intelligent scheduling of resources and meticulous optimization of user experience.

[0066] Secondly, a query is initiated to the pre-built font parameter database to obtain the width and height parameters of each character in the set of commonly used characters and the line height parameters of the target font. The font parameter database is a pre-built cloud or local data service that systematically stores measurement data for various fonts. During the query, a request can be initiated using "target font name" and "set of commonly used characters" as joint conditions to directly and batch obtain the precise width and height information of the corresponding characters and the overall line height parameters of the font. This method avoids the computational overhead of real-time rendering and measurement in the local environment, greatly improving data acquisition efficiency.

[0067] Furthermore, in one embodiment, the width and height parameters stored in the font parameter database are obtained by rendering the characters of the target font under various different resolutions and font rendering engine environments; and by measuring the bounding rectangle of the rendered bitmap or outline image to obtain the width and height parameters.

[0068] This embodiment aims to address the "environment-dependent" problem of font rendering and ensure data universality. The same font file may exhibit slight differences in its final rasterization (i.e., conversion to screen pixels) under different operating systems (such as Windows and macOS), different rendering engines (such as GDI, DirectWrite, and FreeType), and different display resolutions or DPI (Dots Per Inch) scaling ratios. These differences stem from variations in the hinting algorithms, anti-aliasing strategies, and grid alignment rules of each engine. If a simulated font is generated based solely on measurement data from a single environment, the accumulated rendering differences may lead to discrepancies between the final pixel dimensions of characters and expectations when using the simulated font in other environments, resulting in minor layout drift. Therefore, the above embodiment employs a multi-environment verification generation strategy to obtain robust width and height information.

[0069] Multi-environment rendering includes rendering each character of the target font under various environment combinations covering mainstream hardware and software configurations (e.g., resolutions covering typical values ​​such as 72dpi, 96dpi, 144dpi, and 192dpi; rendering engines covering Windows' GDI (Graphics Device Interface) and DirectWrite, macOS's Quartz, and cross-platform FreeType, etc.), generating multiple sets of bitmap or vector contour image samples.

[0070] Then, computer vision tools are used to measure the width and height of each set of rendered samples to obtain their bounding rectangles. Subsequently, the measurement results from all environments are comprehensively analyzed (e.g., calculating the average or taking the mode with the highest frequency) to determine the final, environment-robust width and height information for the character.

[0071] The width and height information obtained in this way is no longer a "snapshot" of a specific environment, but a "robust consensus" that integrates multiple possible rendering results. The simulated font file generated based on this data has stronger cross-platform and cross-environment adaptability. Regardless of the user's device resolution, operating system, or rendering engine, the simulated font can ensure that the character's footprint is as close as possible to the target font's performance in the corresponding environment, thus fundamentally guaranteeing the reliability of typographic consistency and achieving true "what you see is what you get".

[0072] Furthermore, in another embodiment, the basic typesetting data may further include visual feature data of the target font. This visual feature data serves as a supplementary data set characterizing the style attributes of the target font, aiming to make the simulated font more stylistically similar to the target font, thereby further improving the style matching degree of the simulated font. For example, the visual feature data includes the following three types of information: Language attribute information is used to identify the primary language or character set type applicable to the target font. It can be determined by parsing the target font's metadata (such as "CN" in the font name indicating Chinese and "EN" indicating English) or the language settings in the document, to ensure that the glyph structure of the simulated font conforms to the writing habits of the corresponding language (such as horizontal and vertical strokes in Chinese and uppercase and lowercase letter ratios in English).

[0073] The actual weight parameter refers to the stroke weight quantified by visual analysis (such as edge detection and pixel density statistics) of the character image of the target font. This parameter provides a more objective description of weight than the theoretical weight value in the font file, and is different from the qualitative descriptions such as "regular" and "bold" in the font metadata.

[0074] Design style classification refers to the process of using a pre-trained visual recognition model (such as the U-NET model) to analyze font character features (such as whether strokes end with serifs and whether character widths are consistent) and then categorizing them into style categories such as serif, sans-serif, and monospace. This classification provides a basis for subsequently generating character outlines that match the style.

[0075] Step 202: Based on the basic layout data, generate parameter information for constructing the simulated font. The parameter information includes at least graphic combination data and layout parameter data.

[0076] The core task of step 202 is to transform the original typesetting data collected in step 201 into structured parameter information that can be directly used to construct the simulated font. This parameter information is the "blueprint" that guides all subsequent generation operations, ensuring that the final generated simulated font is strictly consistent with the target font in terms of outline structure and typesetting size.

[0077] In one embodiment, the parameter information includes at least graphic combination data and layout parameter data. Specifically: Graphic combination data is used to indicate the combination of basic geometric components to form the character outlines of each character in the set of common characters. That is, the graphic combination data is used to clearly indicate how to select and assemble the vector outlines of each character in the set of common characters from a preset library of basic geometric components. It specifically specifies the types of basic geometric components required for each character (selection), the spatial position relationship between components, the combination order, and connection details such as arc degrees and angles. Among them, the basic geometric components refer to preset basic graphic units that constitute the character outline, which are standardized "building blocks" for all character outlines, such as basic graphic elements including arcs, straight line segments, Bezier curve segments, polygons, etc.

[0078] In one embodiment, according to the typesetting basic data, graphic combination data for constructing a simulated font is generated, including: inputting the typesetting basic data into a pre-trained artificial intelligence model, and the artificial intelligence model outputs the graphic combination data, and the graphic combination data specifies a set of basic geometric components to be combined and a combination method for each character in the set of common characters.

[0079] Among them, the pre-trained artificial intelligence model (such as a neural network based on deep learning) has been trained through a large amount of font data sets, and has learned and internalized the complex mapping relationship from font features (including metric data and style data) to the geometric composition of character outlines.

[0080] The complete typesetting basic data (including the set of common characters, width and height information, line height parameters, visual feature data, etc.) obtained in step 201 is standardized and vectorized, and converted into an input format that the model can receive. The processed data is input into the artificial intelligence model. Based on the knowledge it has learned, the artificial intelligence model reasons for each character in the set of common characters and outputs an optimal set of graphic combination data. The graphic combination data specifies a specific component combination scheme for each character. For example: "The character '中' is composed of two vertical rectangle components as vertical strokes, one horizontal rectangle component as a horizontal stroke, and four arc components as corners, and is assembled according to a specific spatial relationship". This ensures that the generated character outlines are not only accurate in geometric structure, but also faithfully reflect the design features of the original font in terms of visual style.

[0081] This embodiment utilizes the intelligent matching ability of the artificial intelligence model to associate the typesetting basic data with the geometric component combination rules of character outlines, ensuring that the generated graphic combination data not only conforms to the style of the target font, but also can accurately construct character outlines.

[0082] The typesetting parameters are used to control the footprint and line spacing of the simulated font during rendering, based on the width, height, and line height parameters of each character. Generated from the target font's width, height, and line height parameters, the core function of these parameters is to precisely control the layout of the simulated font during rendering. They directly define the footprint (width and height) of each character and the overall line spacing, serving as crucial constraints to ensure that the simulated font produces the exact same typesetting effect (such as line breaks and page breaks) as the target font in the document.

[0083] Step 203: Based on the above parameter information, generate the font file corresponding to the simulated font.

[0084] Step 203 is the final implementation stage of simulated font generation. Its core task is to complete the conversion from parametric description to actual font file based on the graphic combination data and layout parameter data generated in step 202.

[0085] In one embodiment, generating a font file corresponding to the simulated font based on the above parameter information includes: selecting and combining basic geometric components from a preset basic geometric component library according to graphic combination data to form the initial outline of each character in the common character set; adjusting the initial outline of each character according to typesetting parameter data so that the width and height of the adjusted character outlines conform to the corresponding width and height parameters; setting corresponding font measurement parameters for the simulated font according to the line height parameter so as to control the simulated font to reach the line height specified by the line height parameter during rendering; and encapsulating the adjusted character outline data and font measurement parameters into a font file conforming to the standard font format.

[0086] This embodiment, through a series of operations such as contour synthesis, size calibration, measurement configuration and standard encapsulation, ultimately outputs a fully functional standard format font file that can be directly called by text editing software or operating system rendering engines.

[0087] Specifically, in the initial character outline construction stage: based on the graphic combination data, corresponding basic geometric components are selected from a preset basic geometric component library, and then strictly assembled according to the combination order, spatial position, and connection relationship specified in the data, thereby forming the initial outline of each character in the commonly used character set. This outline is the "draft" of the character structure, and its shape has initially reflected the design characteristics of the target font. During this process, the system selects components of the corresponding style from the component library according to the design style classification (such as serif and sans-serif fonts) (for example, selecting components with decorative ends for serif fonts), and adjusts the thickness of the stroke outline of the selected components according to the actual thickness parameters to ensure that the initial outline closely approximates the target font in terms of visual style and stroke weight.

[0088] In the character outline adjustment stage: The precise width and height information specified for each character is obtained from the layout parameter data. Two-dimensional geometric transformations (such as scaling, stretching, or fine-tuning control points) are performed on the initial outline to ensure that the width and height of its bounding rectangle strictly conform to the corresponding target values. This step ensures that the footprint of each character on the page is completely consistent with the target font, forming the geometric basis for achieving faithful typography.

[0089] During the font metric parameter configuration phase: Based on the line height parameter, the corresponding font metric parameters are calculated and set for the simulated font. These parameters will be written into the data table corresponding to the font file as specified. For example, in TrueType / OpenType fonts, by setting values ​​such as Ascender (ascend height), Descender (descend height), and LineGap (line spacing) in the HHea (Horizontal Header Table), the line height of the text during rendering is precisely controlled, thereby ensuring the consistency of the layout at the paragraph level.

[0090] Finally, all calibrated character outline data, configured font metric parameters, necessary character mapping tables (CMap), and OS / 2 tables containing metadata such as weight and style are binary-encapsulated according to industry-standard data structures such as TrueType or OpenType, ultimately generating a complete and portable font file. This file possesses all the functional attributes of standard fonts and can be seamlessly recognized and loaded by mainstream word processing software or services such as WPS and Microsoft Word.

[0091] Through the above process, step 203 generates a simulated font file that is precisely matched in terms of layout size, highly similar in terms of visual style, and completely standard in terms of functional attributes, providing a digital foundation for the final lossless restoration of the document.

[0092] Figure 2 The process described first involves acquiring basic typesetting data, including a set of commonly used characters for the target font, character width and height parameters, and line height parameters. This ensures that the generated target font is always anchored to the core typesetting metrics of the original font, fundamentally guaranteeing that the simulated font maintains strict consistency with the target font in character placement and line height control, laying a reliable data foundation for achieving "typesetting fidelity." Secondly, by transforming the basic typesetting data into structured parameter information containing graphic combination data and typesetting parameter data, a clear and executable "design blueprint" is constructed. The graphic combination data directly guides the geometric construction of character outlines, while the typesetting parameter data precisely constrains the size and spacing during rendering. Their synergy allows for the separation and precise execution of outline synthesis and layout control. Finally, by directly generating a font file conforming to a standard format based on the above parameter information, a complete transformation from parameterized description to a directly callable physical font file is achieved. The generated simulated font file can be seamlessly integrated into the rendering workflow of existing operating systems and word processing software, allowing users to obtain the same typesetting experience as using the original font without any additional adaptation.

[0093] based on Figure 1 and Figure 2 In addition to the process shown, this application also provides the following embodiments: In one embodiment, the method provided in this application further includes: obtaining the font rendering environment parameters of the current system; optimizing the adjusted character outline based on the font rendering environment parameters and the target pixel size of the text to be rendered, and generating a corresponding outline fine-tuning instruction; and adding the outline fine-tuning instruction to the font file of the simulated font.

[0094] Fonts often face challenges when rendered at smaller pixel sizes (e.g., less than 12px): the limited pixel grid struggles to accurately represent delicate vector outlines. This can result in uneven stroke thickness, blurry characters, or overall glyph distortion. Furthermore, different operating systems and rendering engines (such as ClearType for Windows and Quartz for macOS) have their own unique rasterization (converting vectors to pixels) and hinting algorithms. A font that appears clear on Windows may appear blurry on macOS.

[0095] To address this issue, this embodiment adds an adaptive optimization step after generating the basic font file. First, it obtains two key pieces of information: one is the current system's font rendering environment parameters, including the operating system type, screen DPI scaling ratio, and whether subpixel rendering (such as ClearType) is enabled; the other is the target pixel size of the text to be rendered, i.e., the specific height of the text ultimately drawn on the screen, usually in pixels (px), such as "12px". The target pixel size directly determines the pixel grid density that can be used to represent character outlines during rasterization, and is the core basis for triggering and guiding the optimization operation.

[0096] When the system detects that the target pixel size is below a preset threshold (e.g., 12px) and is in a specific rendering environment (such as Windows GDI mode), it triggers an optimization process: calling a pre-defined algorithm model, combining font rendering environment parameters and the target pixel size, to calculate a set of fine-tuning instructions for the outline of each character. These instructions are essentially conditional programs for the rendering engine, with the semantics of: "How to offset the outline control points at the sub-pixel level if and only if, in the current rendering environment, and the drawing size is the specified target pixel size," to achieve the goals of optimizing stroke thickness, aligning pixel grids, and maintaining character clarity. Finally, this set of highly customized instructions is written into a specific data table in the generated simulated font file (e.g., in TrueType format, corresponding to the fpgm, prep tables, and instructions within the glyf data blocks of each glyph).

[0097] By embedding environment-aware contour fine-tuning instructions within the font file, the generated simulated font gains "environment-adaptive" capabilities. Regardless of the device or software on which the document is viewed at a small font size, the font rendering engine can execute these built-in optimization instructions to ensure that character strokes align with the pixel grid and avoid blurring. This maintains excellent readability and visual clarity under various demanding display conditions, achieving display quality equivalent to professional fonts.

[0098] In one embodiment, the method provided in this application further includes: in response to a text application style change instruction, generating a derived font file with a corresponding style based on parameter information.

[0099] In document editing scenarios, users often need to apply styles such as "Bold" or "Italic" to text. If simulated fonts only provide regular styles, the system will be forced to fall back to other available fonts when users apply these formats, resulting in inconsistent styles and secondary layout corruption. Therefore, simulated fonts need to be able to dynamically provide these style variations, just like a complete font family.

[0100] To address this issue, this embodiment employs a "real-time derivation" mechanism. When a user triggers a style change command on text using a simulated font, such as clicking the "bold" button, the system does not replace the font. Instead, it quickly generates a derived font text based on existing regular font simulated font parameters.

[0101] Taking the generation of a bolded font file as an example, an equidistant outward expansion algorithm can be used to calculate the normal direction of each point on the regular font outline. The control points are then moved outward along this direction by a distance calculated based on the target font weight, thus generating a thicker outline. Simultaneously, the width measurement of the characters is intelligently fine-tuned to prevent strokes from becoming too close together and causing them to stick together.

[0102] Taking the generation of a derived font file with a slanted style as another example, a shear transformation matrix is ​​applied to the outline data of the regular font, causing all points to shift in the horizontal direction, thereby producing an overall slanted visual effect.

[0103] Through the above embodiments, users gain a seamless and consistent formatting editing experience. Users can freely apply bolding and italics to simulated font text, and the document layout will not jump or rearrange due to sudden changes in font measurement information. This makes the dynamically generated simulated font functionally equivalent to a complete, pre-installed font family, greatly enhancing the practicality and professionalism in editing scenarios.

[0104] In one embodiment, the method provided in this application further includes: in response to a font style switching instruction, based on typography parameter data and using a generation strategy corresponding to the target style, regenerating a simulated font file that conforms to the target style to replace the currently used font file for rendering.

[0105] Different font styles (such as formal serif fonts, modern sans-serif fonts, and regular monospace fonts) cater to different reading preferences and document types. In scenarios where fonts are missing, users may not only want the layout to remain unchanged, but may also want to adjust the visual style to better suit their current needs (for example, switching a contract from a serif font with a strong print feel to a more readable sans-serif font).

[0106] To address this, this embodiment provides corresponding interactive capabilities. When a user selects to switch the font style of the current simulated font via the interface menu, such as switching to "Bold" or "Serif," the system will initiate a regeneration process. This process follows a core principle: keeping all typographic parameters (width, height, line height) of the original font absolutely unchanged. Under this constraint, the generation strategy corresponding to the target style (e.g., "Bold") is invoked. This means selecting the basic geometric component library for the corresponding style and adjusting the processing algorithm for the stroke ends. Subsequently, based on the unchanged typographic parameters and the new stylized components, a completely new simulated font file conforming to the target style is quickly synthesized and immediately hot-replaces the old file currently in use.

[0107] The technical solution provided in this embodiment achieves the decoupling and unification of layout fidelity and visual style selectability. Users can freely explore and switch between different font styles to meet personalized aesthetic or reading needs in specific scenarios, while ensuring the document structure (page number, line number, chart position) remains absolutely unchanged.

[0108] Figure 3 This is a block diagram illustrating an embodiment of a font generation apparatus provided in this application. Figure 3 As shown, the device includes: The target font determination module 31 is used to determine the target font used in the document to be processed. The font simulation module 32 is used to generate a font file of a simulated font based on the target font, wherein the simulated font is used to simulate the target font; The font rendering module 33 is used to render the document to be processed based on the font file corresponding to the simulated font.

[0109] In one possible implementation, the font simulation module 32 includes: The data acquisition unit is used to acquire the basic layout data of the target font. The basic layout data includes at least the set of commonly used characters of the target font, the width and height parameters of each character in the set of commonly used characters, and the line height parameters of the target font. The parameter generation unit is used to generate parameter information for constructing a simulated font based on the typesetting basic data. The parameter information includes at least graphic combination data and typesetting parameter data. The graphic combination data is used to indicate the combination of basic geometric components to form the character outline of each character in the common character set. The typesetting parameter data is used to control the space occupied and line spacing when the simulated font is rendered based on the width and height parameters of each character and the line height parameter. The font file generation unit is used to generate the font file corresponding to the simulated font based on the parameter information.

[0110] In one possible implementation, the target font determination module 31 is specifically used for: In response to the operation of opening the document to be processed, the system identifies the font specified in the document format information of the document to be processed that is missing in the current system environment, and determines the missing font as the target font.

[0111] In one possible implementation, the data acquisition unit includes: The common character determination subunit is used to parse the text content of the document to be processed and determine the set of common characters; The typesetting parameter acquisition subunit is used to initiate a query to a preset font parameter database to obtain the width and height parameters of each character in the commonly used character set and the line height parameter of the target font.

[0112] In one possible implementation, the width and height parameters stored in the font parameter database are obtained in the following way: The characters of the target font are rendered under various resolutions and font rendering engine environments; The bounding rectangle of the rendered bitmap or contour image is measured to obtain the width and height parameters.

[0113] In one possible implementation, the parameter generation unit includes: The first generation subunit is used to input the typesetting basic data into a pre-trained artificial intelligence model, and the artificial intelligence model outputs the graphic combination data. The graphic combination data specifies a set of basic geometric components to be combined and a combination method for each character in the set of commonly used characters.

[0114] In one possible implementation, the font file generation unit includes: The character outline forming subunit is used to select and combine basic geometric components from a preset basic geometric component library according to the graphic combination data to form the initial outline of each character in the commonly used character set; The character outline adjustment subunit is used to adjust the initial outline of each character according to the layout parameter data, so that the width and height of each character outline after adjustment conform to the corresponding width and height parameters. The line height setting subunit is used to set corresponding font measurement parameters for the simulated font according to the line height parameter, so as to control the simulated font to reach the line height specified by the line height parameter during rendering through the font measurement parameters; The file encapsulation subunit is used to encapsulate the adjusted character outline data and the font measurement parameters into a font file that conforms to the standard font format.

[0115] In one possible implementation, the device further includes: The size adjustment module is used to obtain the font rendering environment parameters of the current system; Based on the font rendering environment parameters and the target pixel size of the text to be rendered, the adjusted character outline is optimized, and corresponding outline fine-tuning instructions are generated. Add the outline fine-tuning instructions to the font file.

[0116] In one possible implementation, the device further includes: The style derivation module is used to generate a derived font file with a corresponding style based on the parameter information in response to text application style change instructions.

[0117] In one possible implementation, the device further includes: The style change module is used to respond to the font style switching command, and based on the layout parameter data and adopting a generation strategy corresponding to the target style, regenerate the simulated font file that conforms to the target style, so as to replace the font file currently used for rendering.

[0118] In one possible implementation, the font simulation module 32 includes: The permission acquisition unit is used to acquire the access permission information of the document to be processed; The character set determination unit is used to determine the character set that the font file of the simulated font should contain based on the access permission information. The font file generation unit is used to generate a font file for the simulated font based on the target font and the character set.

[0119] like Figure 4 As shown in the figure, this application provides an electronic device, including a processor 111, a communication interface 112, a memory 113, and a communication bus 114, wherein the processor 111, the communication interface 112, and the memory 113 communicate with each other through the communication bus 114. Memory 113 is used to store computer programs; In one embodiment of this application, when the processor 111 executes the program stored in the memory 113, it implements the font generation method provided in any of the foregoing method embodiments, including: Determine the target font used in the document to be processed; A font file for a simulated font is generated based on the target font, and the simulated font is used to simulate the target font; The document to be processed is rendered based on the font file corresponding to the simulated font.

[0120] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the font generation method provided in any of the foregoing method embodiments.

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

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

[0123] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms "a," "an," and "described" as used herein may also mean including the plural forms. The terms "comprising," "including," "containing," and "having" are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a specific order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0124] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.< / w:rfonts>

Claims

1. A font generation method, characterized in that, The method includes: Determine the target font used in the document to be processed; A font file for a simulated font is generated based on the target font, and the simulated font is used to simulate the target font; The document to be processed is rendered based on the font file corresponding to the simulated font.

2. The method according to claim 1, characterized in that, The font file for generating a simulated font based on the target font includes: Obtain the basic layout data of the target font, which includes at least the set of commonly used characters of the target font, the width and height parameters of each character in the set of commonly used characters, and the line height parameters of the target font; Based on the typesetting base data, parameter information for constructing a simulated font is generated. The parameter information includes at least graphic combination data and typesetting parameter data. The graphic combination data is used to indicate the combination of basic geometric components to form the character outline of each character in the common character set. The typesetting parameter data is used to control the space size and line spacing when the simulated font is rendered based on the width and height parameters of each character and the line height parameter. Based on the parameter information, a font file corresponding to the simulated font is generated.

3. The method according to claim 1, characterized in that, Determining the target font used in the document to be processed includes: In response to the operation of opening the document to be processed, the system identifies the font specified in the document format information of the document to be processed that is missing in the current system environment, and determines the missing font as the target font.

4. The method according to claim 2, characterized in that, The step of obtaining the basic layout data of the target font includes: Parse the text content of the document to be processed to determine the set of commonly used characters; In addition, a query is initiated to the preset font parameter database to obtain the width and height parameters of each character in the commonly used character set and the line height parameter of the target font.

5. The method according to claim 4, characterized in that, The width and height parameters stored in the font parameter database are obtained through the following method: The characters of the target font are rendered under various resolutions and font rendering engine environments; The bounding rectangle of the rendered bitmap or contour image is measured to obtain the width and height parameters.

6. The method according to claim 2, characterized in that, Based on the aforementioned typesetting data, graphic combination data for constructing the simulated font is generated, including: The basic typesetting data is input into a pre-trained artificial intelligence model, and the artificial intelligence model outputs the graphic combination data. The graphic combination data specifies a set of basic geometric components to be combined and a combination method for each character in the set of commonly used characters.

7. The method according to claim 2, characterized in that, The step of generating the font file corresponding to the simulated font based on the parameter information includes: Based on the graphic combination data, basic geometric components are selected and combined from the preset basic geometric component library to form the initial outline of each character in the commonly used character set; Based on the layout parameter data, the initial outline of each character is adjusted so that the width and height of the adjusted character outline conform to the corresponding width and height parameters. Based on the line height parameter, a corresponding font metric parameter is set for the simulated font so that the simulated font can be controlled to reach the line height specified by the line height parameter during rendering. The adjusted character outline data and the font measurement parameters are packaged into a font file that conforms to the standard font format.

8. The method according to claim 7, characterized in that, The method further includes: Get the font rendering environment parameters of the current system; Based on the font rendering environment parameters and the target pixel size of the text to be rendered, the adjusted character outline is optimized, and corresponding outline fine-tuning instructions are generated. Add the outline fine-tuning instructions to the font file.

9. The method according to claim 1, characterized in that, The method further includes: In response to a text application style change instruction, a derived font file with the corresponding style is generated based on the parameter information.

10. The method according to claim 1, characterized in that, The method further includes: In response to the font style switching command, based on the layout parameter data and using a generation strategy corresponding to the target style, a new font file that matches the target style is generated to replace the current font file used for rendering.

11. The method according to claim 1, characterized in that, The font file for generating a simulated font based on the target font includes: Obtain the access permission information of the document to be processed; Based on the access permission information, determine the set of characters that the font file of the simulated font must contain; Based on the target font and the character set, a font file for the simulated font is generated.

12. A font generation device, characterized in that, The device includes: The target font determination module is used to determine the target font used in the document to be processed; A font simulation module is used to generate a font file for a simulated font based on the target font, wherein the simulated font is used to simulate the target font; The font rendering module is used to render the document to be processed based on the font file corresponding to the simulated font.

13. An electronic device, characterized in that, include: A processor and a memory, the processor being configured to execute a font generation program stored in the memory to implement the font generation method according to any one of claims 1-11.

14. A storage medium, characterized in that, The storage medium stores one or more programs, which can be executed by one or more processors to implement the font generation method according to any one of claims 1-11.

Images