Font cache-free display method

Abstract

The invention relates to the technical field of font display, and particularly discloses a non-cache font display method. The method comprises the following steps of: compiling a character set into a font dot matrix file and storing the font dot matrix file on a disk, wherein the font dot matrix file comprises font header information, a UNICODE coding-to-font ID mapping table, a font ID-to-font data index table, a font dot matrix data table and a GBK coding-to-font data index table; only the font row height, the font size, the character baseline and the underline position recorded by the font header information are loaded to a memory, and the font dot matrix data table is not cached; querying whether the character has a corresponding GBK code or not, if so, obtaining character dot matrix data offset and dot matrix byte number from a font data index table by using the GBK code, otherwise, traversing by using UNICODE code to obtain font ID of the character, and further obtaining the character dot matrix data offset and dot matrix byte number; and reading the character dot matrix data into a memory, and drawing a character image. The font memory occupation and the disk IO number are effectively reduced, and the graphic interface display fluency is improved.

Description

Technical Field

[0001] This invention relates to the field of font display technology, and in particular to a display method that does not require caching font dot matrix data in memory. Background Technology

[0002] Currently, with the rapid popularization of the Internet of Things (IoT) and smart meters, UI interaction in small embedded devices is becoming increasingly common, and users have higher and higher requirements for the UI interaction of electronic products. Text display plays a more important role in UI interface display. In order to improve UI rendering and make switching smoother, most data equipment manufacturers adopt a space-for-time trade-off solution and use higher-performance hardware to improve the UI interaction experience, directly caching character dot matrix data in memory. However, the memory of small embedded devices is quite limited (e.g., serial port touch screens), and increasing memory and using higher-performance hardware will lead to higher equipment costs. Taking serial port touch screens as an example, these types of touch screens are usually configured with corresponding configuration software to display various UI interaction interfaces for PLC, instrument and other parameters, and many interfaces use font display. As the demand for small embedded devices increases, the requirements for equipment cost and performance control become more and more stringent, and the solution of trading space for time and using higher-performance hardware to improve the UI interaction experience is becoming increasingly difficult to meet the needs.

[0003] Another existing technology is the low-caching solution to reduce device memory consumption. Low-caching solutions typically use vector fonts, calculating character bitmap data using formulas, caching it, and then rendering it. For example, this can be done using open-source software like libfreetype. However, this solution requires high CPU computing power, which in turn increases device cost. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to overcome the shortcomings of the prior art and provide a font cache-free display technology. This cache-free solution stores the dot matrix data of the characters on the disk, without caching the character dot matrix data in memory. It quickly retrieves the dot matrix data corresponding to the characters through a special font file indexing mechanism and then draws them.

[0005] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is: a method for displaying fonts without buffering, the method comprising:

[0006] The character set is compiled into a font bitmap file and stored on disk. The font bitmap file consists of five parts: font header information, a UNICODE encoding to glyph ID mapping table, a glyph ID to glyph data index table, a glyph bitmap data table, and a GBK encoding to glyph data index table. The character set contains all characters used by the application, arranged in ascending order of UNICODE encoding. The glyph ID is the sequence number of the UNICODE encoding in the character set. The glyph bitmap data table stores the bitmap data corresponding to each character in the character set obtained through the PC system API, ordered by glyph ID. The UNICODE encoding to glyph ID mapping table stores the mapping relationship between the UNICODE encoding of the character set and the glyph ID. The glyph ID to glyph data index table stores the bitmap data offset corresponding to each glyph ID. The GBK encoding to glyph data index table stores the bitmap data offset of characters in the character set that have GBK encoding.

[0007] During font initialization, only the font line height, font size, character baseline, and underline position recorded in the font header information are loaded into memory; the glyph dot matrix data table is not cached.

[0008] The system checks if the character to be drawn exists in the GBK encoding table. If it does, it uses the GBK encoding to obtain the dot matrix data offset and the number of dot matrix bytes of the character to be drawn from the GBK encoding to glyph data index table. Otherwise, it queries the UNICODE encoding table to obtain the UNICODE encoding corresponding to the character to be drawn. Using the UNICODE encoding, it iterates through the UNICODE encoding to glyph ID mapping table to obtain the glyph ID corresponding to the character to be drawn. Then, based on the glyph ID, it obtains the dot matrix data offset and the number of dot matrix bytes of the character to be drawn from the glyph ID to glyph data index table.

[0009] The dot matrix data of the character to be drawn is read from the character dot matrix data table into memory based on the dot matrix data offset and the number of dot matrix bytes. The image of the character is drawn using the dot matrix data of the character to be drawn, as well as the font line height, font size, character baseline, and underline position that have been loaded into memory.

[0010] Preferably, generating a UNICODE encoding to glyph ID mapping table includes:

[0011] The character set is divided into four table types to generate a UNICODE encoding to glyph ID mapping table. Sub-tables with consecutive UNICODE encodings and consecutive glyph IDs only need to record the sub-table index. Sub-tables with consecutive UNICODE encodings but non-consecutive glyph IDs need to record the sub-table index and a list of glyph IDs. Sub-tables with non-consecutive UNICODE encodings but consecutive glyph IDs need to record the sub-table index and a list of UNICODEs. Sub-tables with neither consecutive UNICODE encodings nor consecutive glyph IDs need to record the sub-table index, a list of UNICODEs, and a list of glyph IDs. The sub-table index contains the starting UNICODE value, the number of UNICODEs, the starting glyph ID value, the number of glyph IDs, the sub-table type, and the index offset. The index offset is used to indicate the corresponding glyph ID list and UNICODE list for that sub-table.

[0012] Preferably, the generated glyph dot matrix data includes:

[0013] The dot matrix data corresponding to each character in the character set is obtained through the PC system API and set in the character dot matrix data table according to the character ID.

[0014] Preferably, the first 8 bytes of the character dot matrix data table are used to set the number of bytes occupied by the character dot matrix data table and the function identifier.

[0015] Preferably, generating the glyph ID to the glyph data index table includes:

[0016] Calculate the dot matrix data offset for each glyph ID in the character set and set it in the glyph ID to glyph data index table in ascending order of glyph ID; where when glyph ID is 1, the dot matrix data offset is 8; when glyph ID is 2, the dot matrix data offset is the number of bytes occupied by the dot matrix data of glyph ID 1 plus 8; when glyph ID is n, n>2, the dot matrix data offset is the number of bytes occupied by the dot matrix data of glyph ID n-1 plus 8. The dot matrix data offset and the number of bytes occupied are the dot matrix data offset position and the number of bytes occupied by the dot matrix data of the character corresponding to the glyph ID in the glyph dot matrix data table.

[0017] Preferably, generating a GBK encoding to glyph data index table includes:

[0018] For all encodings from 0x8140 to 0xFEFE in the GBK encoding table, generate corresponding dot matrix data offsets and dot matrix byte counts, and set them in the GBK encoding to character data index table according to the GBK encoding table order; Specifically, convert the GBK encodings with high bytes of 0x81 to 0xFE and low bytes of 0x40 to 0xFE one by one to UNICODE encoding, and check whether the character set contains the UNICODE encoding corresponding to the GBK encoding. If it does not contain it, the dot matrix data offset and dot matrix byte count corresponding to the GBK encoding are recorded as 0; if it does contain it, the dot matrix data offset and dot matrix byte count corresponding to the GBK encoding are recorded as the dot matrix data offset position and the number of bytes occupied by the dot matrix data for the corresponding character in the character dot matrix data table, respectively.

[0019] Preferably, the first 8 bytes of the GBK encoding to glyph data index table are used to set the number of bytes occupied by the GBK encoding to glyph data index table and the function identifier;

[0020] The GBK encoding to glyph data index table sets the same fixed number of bytes for each GBK encoding to store the dot matrix data offset and the number of dot matrix bytes.

[0021] Preferably, when the character to be drawn by the application has a corresponding GBK encoding, the position of the GBK encoding in the character data index table is calculated as: ((GBK encoding high byte - 0x81) * (0xFF - 0x40) + GBK encoding low byte - 0x40) * number of single index bytes + 8. The offset of the corresponding position is used to obtain the dot matrix data offset and the number of dot matrix bytes of the character to be drawn, where the number of single index bytes is the number of bytes of the fixed number of bytes.

[0022] Preferably, during continuous queries, the offset of the dot matrix data and the number of dot matrix bytes corresponding to the character to be drawn are recorded after each query. Subsequent queries first check whether the character is the same as the character queried in the previous query. If they are the same, the offset of the dot matrix data and the number of dot matrix bytes corresponding to the character to be drawn can be obtained directly.

[0023] Preferably, the five parts of the font bitmap file are stored sequentially, with a fixed number of bytes at the beginning of each part used to record the number of bytes occupied by each part; during font initialization, the starting offset of the UNICODE encoding to glyph ID mapping table, the starting offset of the glyph ID to glyph data index table, the starting offset of the glyph bitmap data table, and the starting offset of the GBK encoding glyph data index table are calculated based on the starting position of the font header information and the number of bytes occupied by each part, and then loaded into memory.

[0024] The beneficial effects of this invention are that it effectively reduces memory usage and disk I / O count when displaying fonts, improves character drawing performance of embedded devices with small memory, and enhances the smoothness of graphical interface display. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the method flow of the present invention.

[0026] Figure 2 This is a schematic diagram of the font bitmap file compilation process according to an embodiment of the present invention.

[0027] Figure 3 This is a schematic diagram of the font header information format according to an embodiment of the present invention.

[0028] Figure 4 This is a schematic diagram of a UNICODE encoding to character ID mapping table format according to an embodiment of the present invention.

[0029] Figure 5 This is a schematic diagram of the character ID to character data index table format according to an embodiment of the present invention.

[0030] Figure 6 This is a schematic diagram of a character dot matrix data table format according to an embodiment of the present invention.

[0031] Figure 7 This is a schematic diagram of a GBK encoding to character data index table format according to an embodiment of the present invention. Detailed Implementation

[0032] The detailed description and technical content of the present invention are explained below with reference to the accompanying drawings. However, the drawings are provided for reference and illustration only and are not intended to limit the present invention.

[0033] Character encoding is used to assign a unique numerical code to each character to be displayed in a computer application according to set rules; a character encoding table is a mapping table between characters and their corresponding numerical codes. Existing publicly available and commonly used character encoding tables include the GBK encoding table and the Unicode encoding table; GBK is a double-byte encoding scheme used for the extension specification of Chinese character internal codes, with an encoding range from 0x8140 to 0xFEFE; Unicode is an international standard for character encoding.

[0034] When displaying characters in the UI of a small embedded device, it is necessary to provide the character dot matrix data corresponding to each character. Multiple characters form a character set. Each character needs to be identified using character encoding.

[0035] The character set contains all the characters that an application might use. The size of the character set varies depending on the application. Embedded devices typically only require a few hundred to a few thousand characters, so the embedded device only needs to store the dot matrix data of these potentially used characters.

[0036] like Figure 1 As shown, the present invention provides a method for displaying fonts without caching, comprising:

[0037] The character set is compiled into a font bitmap file and stored on disk. The font bitmap file consists of five parts: font header information, a UNICODE encoding to glyph ID mapping table, a glyph ID to glyph data index table, a glyph bitmap data table, and a GBK encoding to glyph data index table. The character set contains all characters used by the application, arranged in ascending order of UNICODE encoding, and each character is assigned a glyph ID. The glyph ID is the sequence number of the UNICODE encoding in the character set (the sequence number can start from 1), ensuring that each character in the character set has a corresponding glyph ID and UNICODE encoding. The glyph bitmap data table stores the bitmap data corresponding to each character in the character set obtained through the PC system API, ordered by glyph ID. The UNICODE encoding to glyph ID mapping table stores the mapping relationship between the UNICODE encoding of the character set and the glyph ID. The glyph ID to glyph data index table stores the bitmap data offset corresponding to each glyph ID. The GBK encoding to glyph data index table stores the bitmap data offset of characters in the character set that have GBK encoding.

[0038] During font initialization, only the font line height, font size, character baseline, and underline position recorded in the font header information are loaded into memory; the glyph dot matrix data table is not cached.

[0039] The system checks if the character to be drawn exists in the GBK encoding table. If it does, it uses the GBK encoding to obtain the dot matrix data offset and the number of dot matrix bytes of the character to be drawn from the GBK encoding to glyph data index table. Otherwise, it queries the UNICODE encoding table to obtain the UNICODE encoding corresponding to the character to be drawn. Using the UNICODE encoding, it iterates through the UNICODE encoding to glyph ID mapping table to obtain the glyph ID corresponding to the character to be drawn. Then, based on the glyph ID, it obtains the dot matrix data offset and the number of dot matrix bytes of the character to be drawn from the glyph ID to glyph data index table.

[0040] The dot matrix data of the character to be drawn is read from the character dot matrix data table into memory based on the dot matrix data offset and the number of dot matrix bytes. The image of the character is drawn using the dot matrix data of the character to be drawn, as well as the font line height, font size, character baseline, and underline position that have been loaded into memory.

[0041] The generated font header information includes:

[0042] The system records the current font's line height, font size, character baseline, and underline position. Further, it can record the font version, number of mapping tables, font pixel size, pixel compression algorithm, glyph ID data format, underline position, underline thickness, glyph line height, number of bits used for pixel drawing offset data, number of bits used for horizontal / vertical pixel data, and glyph pixel BPP, and then serializes this information to generate font header information.

[0043] Generating a UNICODE encoding to glyph ID mapping table includes:

[0044] The continuity of Unicode encodings in the character set is analyzed, dividing the set into sets with continuous and discontinuous Unicode encodings. The continuity criterion is that the next Unicode encoding is equal to the previous Unicode encoding plus 1, and the number of consecutive encodings is greater than a set threshold. Then, the continuity of glyph IDs is analyzed separately for sets with continuous and discontinuous Unicode encodings. The continuity criterion is that the previous glyph ID is plus 1, and the number of consecutive IDs is greater than a set threshold. The final set is divided into four table types to generate a UNICODE-to-glyph ID mapping table. Subtables with consecutive UNICODE codes and consecutive glyph IDs only need to record the subtable index. Subtables with consecutive UNICODE codes but non-consecutive glyph IDs need to additionally record the glyph ID list (i.e., the subtable index and glyph ID list are required). Subtables with non-consecutive UNICODE codes but consecutive glyph IDs need to additionally record the UNICODE list (i.e., the subtable index and UNICODE list are required). Subtables with neither consecutive UNICODE codes nor consecutive glyph IDs need to additionally record both the UNICODE list and the glyph ID list (i.e., the subtable index, UNICODE list, and glyph ID list are required). The subtable index contains the starting UNICODE value, the number of UNICODE codes, the starting glyph ID value, the number of glyph IDs, the subtable type, and the index offset. The index offset indicates the corresponding glyph ID list and UNICODE list for that subtable.

[0045] The advantage of setting up four types of sub-tables for the UNICODE encoding to glyph ID mapping table is that the corresponding glyph ID can be quickly found based on the UNICODE encoding.

[0046] If a UNICODE encoding belongs to a sub-table with consecutive UNICODE encodings and consecutive glyph IDs, calculate the difference between the UNICODE encoding and the starting value of the UNICODE encoding in the sub-table index record. Add the difference to the starting value of the glyph ID in the sub-table index record to obtain the glyph ID corresponding to the UNICODE encoding.

[0047] If a UNICODE encoding belongs to a sub-table with continuous UNICODE encodings and discontinuous glyph IDs, calculate the difference between the UNICODE encoding and the starting value of the UNICODE encoding in the sub-table index record. Add 1 to the difference to get the position value. Then, obtain the glyph ID in the glyph ID list indicated by the index offset in the sub-table index record according to the position value. This glyph ID is the glyph ID corresponding to the UNICODE encoding.

[0048] If a UNICODE encoding belongs to a sub-table of non-contiguous UNICODE encodings and contiguous glyph IDs, the UNICODE encoding is searched in the UNICODE encoding list indicated by the index offset of the sub-table index record. The position value of the UNICODE encoding in the UNICODE encoding list is obtained. This position value is added by 1 and then the glyph ID starting value of the sub-table index record is added to obtain the glyph ID corresponding to the UNICODE encoding.

[0049] If a UNICODE encoding belongs to a sub-table where both UNICODE encodings and glyph IDs are discontinuous, the UNICODE encoding is searched in the UNICODE encoding list indicated by the index offset in the sub-table's index record. The position value of the UNICODE encoding in the UNICODE encoding list is obtained. The glyph ID is then obtained from the glyph ID list indicated by the index offset in the sub-table's index record based on the position value. This glyph ID is the glyph ID corresponding to the UNICODE encoding.

[0050] The generated glyph dot matrix data table includes:

[0051] The dot matrix data corresponding to each character in the character set is obtained through the PC system API and set in the character dot matrix data table according to the character ID. The dot matrix data includes parameters such as dot matrix width, dot matrix height, horizontal offset, and vertical offset, and the data is serialized to generate binary.

[0052] In a specific embodiment of the method of the present invention, the first 8 bytes of the character dot matrix data table are used to set the number of bytes occupied by the character dot matrix data table and the function identifier.

[0053] In a specific embodiment of method one of the present invention, the first 8 bytes from the glyph ID to the glyph data index table are used to set the number of bytes occupied by the glyph dot matrix data table and the function identifier.

[0054] Generating the glyph ID to glyph data index table includes: calculating the dot matrix data offset of each glyph ID in the character set and setting it in the glyph ID to glyph data index table in ascending order of glyph ID. Specifically, when glyph ID is 1, the dot matrix data offset is 8; when glyph ID is 2, the dot matrix data offset is the number of dot matrix bytes for glyph ID 1 plus 8; when glyph ID is n (>2), the dot matrix data offset is the number of dot matrix bytes for glyph ID n-1 plus 8. Here, the dot matrix data offset and the number of dot matrix bytes represent the dot matrix data offset position and the number of bytes occupied by the dot matrix data for the character corresponding to the glyph ID in the glyph dot matrix data table.

[0055] The number of dot matrix bytes corresponding to each glyph ID can be calculated by combining the glyph ID to the glyph data index table with the glyph dot matrix data table. The number of dot matrix bytes for glyph ID 1 is the dot matrix data offset of glyph ID 2 minus the dot matrix data offset of glyph ID 1. The number of dot matrix bytes for glyph ID n-1 is the dot matrix data offset of glyph ID n minus the dot matrix data offset of glyph ID n-1. The number of dot matrix bytes for glyph ID n is the number of bytes occupied by the glyph dot matrix data table minus the dot matrix data offset of glyph ID n.

[0056] Generating a GBK encoding to glyph data index table includes:

[0057] For all encodings from 0x8140 to 0xFEFE in the GBK encoding table, generate corresponding dot matrix data offsets and dot matrix byte counts, and set them in the GBK encoding to character data index table according to the GBK encoding table order. Specifically, convert the GBK encodings with high bytes of 0x81 to 0xFE and low bytes of 0x40 to 0xFE one by one to UNICODE encoding. Check whether the character set contains the corresponding UNICODE encoding for the GBK encoding. If it does not contain it, the dot matrix data offset and dot matrix byte count for the corresponding GBK encoding are recorded as 0. If it does contain it, it means that the character corresponding to the GBK encoding has dot matrix data in the character dot matrix data table. The dot matrix data offset and dot matrix byte count for the corresponding GBK encoding are recorded as the dot matrix data offset position and the number of bytes occupied by the dot matrix data for the corresponding GBK encoding character in the character dot matrix data table, respectively.

[0058] In one specific implementation, the first 8 bytes of the GBK encoding to glyph data index table are used to set the number of bytes occupied by the GBK encoding to glyph data index table and the function identifier.

[0059] When the application displays a character to be drawn, it first checks whether the character to be drawn by the application has a corresponding GBK encoding in the GBK encoding table;

[0060] When the application needs to draw a character with a corresponding GBK encoding, the position of that GBK encoding in the character data index table is calculated as: ((GBK encoding high byte - 0x81) * (0xFF - 0x40) + GBK encoding low byte - 0x40) * number of single index bytes + 8. Offsetting the corresponding position yields the dot matrix data offset and the number of dot matrix bytes for the character to be drawn. After successful acquisition, the dot matrix data offset and the number of dot matrix bytes corresponding to the character to be drawn are recorded. Based on the obtained dot matrix data offset and the number of dot matrix bytes, the dot matrix data corresponding to the character to be drawn can be read from the character dot matrix data table. Here, the number of single index bytes is the number of bytes used in the character data index table to store the dot matrix data offset and the number of dot matrix bytes corresponding to each GBK encoding. In one specific implementation, four bytes are used to store the dot matrix data offset and four bytes to store the number of dot matrix bytes for each GBK encoding, and the number of single index bytes is fixed at 8.

[0061] When the application needs to draw a character but there is no corresponding GBK encoding, it iterates through the UNICODE encoding to obtain the glyph ID of the character to be drawn from the glyph ID mapping table. Then, it uses the glyph ID to obtain the dot matrix data offset and dot matrix byte count of the character to be drawn from the glyph data index table. After successful acquisition, it records the dot matrix data offset and dot matrix byte count of the character to be drawn. Based on the obtained dot matrix data offset and dot matrix byte count, it can read the dot matrix data corresponding to the character to be drawn from the glyph dot matrix data table.

[0062] In the method of this invention, when querying continuously, the offset of the dot matrix data and the number of dot matrix bytes corresponding to the character to be drawn are recorded after each query. Subsequent queries first check whether the character is the same as the character queried last time. If they are the same, the offset of the dot matrix data and the number of dot matrix bytes corresponding to the character to be drawn can be obtained directly.

[0063] In a specific embodiment of the method of the present invention, the five parts of the font bitmap file are stored sequentially. The first few bytes (e.g., the first four bytes) of each part are used to record the number of bytes occupied by each part. During font initialization, the starting offset of the UNICODE encoding to the glyph ID mapping table, the starting offset of the glyph ID to the glyph data index table, the starting offset of the glyph bitmap data table, and the starting offset of the GBK encoding glyph data index table can be calculated based on the starting position of the font header information and the number of bytes occupied by each part, and loaded into memory, so that the starting position of each table can be quickly located when subsequent steps use each table.

[0064] like Figure 2As shown, the specific process and method for compiling a font file containing the character "I want to invent a font drawing method without caching". First, sort the characters using the UNICODE encoding of the characters and assign glyph IDs. Then, divide the table according to the degree of dispersion of the UNICODE encoding and the glyph ID. Finally, compile and generate the font file.

[0065] Figure 3 It is a schematic diagram of the font header information format for an embodiment, specifically including information such as the font size (pixels), BPP (gray level of pixels), and font file number in the font file. In the data block of the font header information, the first 4 bytes (bytes 0 - 3) are used to record the number of bytes occupied by the entire data block, and bytes 4 - 7 record the function of this data block, with the function identifier being "HEAD".

[0066] Figure 4 It is a schematic diagram of the UNICODE encoding to glyph ID mapping table format for an embodiment, used to traverse and lock the glyph ID mapping table where the glyph ID corresponding to the UNICODE encoding of the character is located, and then obtain the glyph ID corresponding to the character by traversing the mapping table. In the data block of the UNICODE encoding to glyph ID mapping table, the first 4 bytes (bytes 0 - 3) are used to record the number of bytes occupied by the entire data block, and bytes 4 - 7 record the function of this data block, with the function identifier being "UNIC".

[0067] Figure 5 It is a schematic diagram of the glyph ID to glyph data index table format for an embodiment, used to obtain the offset position of the dot matrix data corresponding to the glyph ID in the glyph dot matrix data table. In the data block of the glyph ID to glyph data index table, the first 4 bytes (bytes 0 - 3) are used to record the number of bytes occupied by the entire data block, and bytes 4 - 7 record the function of this data block, with the function identifier being "LOCA", and bytes 8 - 11 record the number of glyphs. In this embodiment, the number of glyphs is 24.

[0068] Figure 6 It is a schematic diagram of the glyph dot matrix data table format for an embodiment, used to save the glyph dot matrix data. In the data block of the glyph dot matrix data table, the first 4 bytes (bytes 0 - 3) are used to record the number of bytes occupied by the entire data block, and bytes 4 - 7 record the function of this data block, with the function identifier being "GLYF". In this embodiment, the number of glyphs is 24, and this data block starts from byte 8 and records the dot matrix data of these 24 glyphs in the order of glyph IDs.

[0069] Figure 7This is a schematic diagram of a GBK encoding to glyph data index table format. This format is mainly used for searching character glyph dot matrix data based on GBK encoding. The performance complexity of the search algorithm is controlled to O(1), and character dot matrix data can be quickly located and loaded for drawing without caching. In the data block of the GBK encoding to glyph data index table, the first 4 bytes (bytes 0-3) are used to record the total number of bytes occupied by the entire data block. Bytes 4-7 record the function of the data block, and the function is identified as "GBK". Starting from byte 8, the data block records the dot matrix data offset and dot matrix byte number corresponding to each GBK encoding in GBK encoding order. Each dot matrix data offset and dot matrix byte number is allocated four bytes.

[0070] The embodiments described above are merely preferred embodiments for fully illustrating the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

Claims

1. A font non-cache display method, characterized in that: The method includes: The character set is compiled into a font dot matrix file and stored on the disk. The font dot matrix file includes five parts: font header information, UNICODE code to glyph ID mapping table, glyph ID to glyph data index table, glyph dot matrix data table and GBK code to glyph data index table; wherein the character set is all characters used by the application arranged in ascending order according to the UNICODE code, and the glyph ID is the sequence number of the UNICODE code arranged in the character set; the glyph dot matrix data table stores the dot matrix data corresponding to each character in the character set obtained through the PC system API in the order of glyph ID; the UNICODE code to glyph ID mapping table stores the mapping relationship between the UNICODE code of the character set and the glyph ID; the glyph ID to glyph data index table stores the dot matrix data offset corresponding to each glyph ID; the GBK code to glyph data index table stores the dot matrix data offset of the GBK-encoded character in the character set; Font initialization, only load the font line height, font size, character baseline, and underline position recorded in the font header information into the memory, and the glyph dot matrix data table is not cached; Query whether there is a corresponding GBK code in the GBK code table for the character to be drawn by the application. If yes, use the GBK code to obtain the dot matrix data offset and dot matrix byte number of the character to be drawn in the GBK code to glyph data index table; otherwise, query the UNICODE code table to obtain the UNICODE code corresponding to the character to be drawn, use the UNICODE code to traverse the UNICODE code to glyph ID mapping table to obtain the glyph ID corresponding to the character to be drawn, and then obtain the dot matrix data offset and dot matrix byte number of the character to be drawn from the glyph ID to glyph data index table according to the glyph ID; The dot matrix data of the character to be drawn is read from the glyph dot matrix data table into the memory according to the dot matrix data offset and the number of dot matrix bytes of the character to be drawn, and the image of the character is drawn using the dot matrix data of the character to be drawn and the font line height, font size, character baseline, and underline position that have been loaded into the memory.

2. A font non-cache display method according to claim 1, characterized in that: Generating a UNICODE encoding to glyph ID mapping table includes: The character set is divided into four table types to generate a UNICODE encoding to glyph ID mapping table, wherein the subtable for continuous UNICODE encoding and continuous glyph ID only needs to record the subtable index, the subtable for continuous UNICODE encoding but discontinuous glyph ID needs to record the subtable index and glyph ID list, the subtable for discontinuous UNICODE encoding but continuous glyph ID needs to record the subtable index and UNICODE list, and the subtable for both UNICODE encoding and glyph ID needs to record the subtable index, UNICODE list and glyph ID list; the subtable index includes the UNICODE starting value, the number of UNICODE, the glyph ID starting value, the number of glyph IDs, the subtable type, and the index offset, and the index offset is used to indicate the glyph ID list and UNICODE list corresponding to the subtable.

3. The method for displaying fonts without cache according to claim 1, characterized in that: Generating font dot matrix data includes: The dot matrix data corresponding to each character in the character set is obtained through the PC system API and is set in the font dot matrix data table in the order of font ID.

4. The method for displaying fonts without cache according to claim 1, characterized in that: The first 8 bytes of the font dot matrix data table are used to set the number of bytes occupied by the font dot matrix data table and the function identifier.

5. A font non-cache display method according to claim 4, characterized in that: Generating a glyph ID to a glyph data index table includes: Calculate the dot data offset of each glyph ID of the character set and set it in the glyph ID to glyph data index table in ascending order of the glyph ID; when the glyph ID is 1, the dot data offset is 8; when the glyph ID is 2, the dot data offset is the number of bytes occupied by the dot data of the glyph ID 1 plus 8; when the glyph ID is n, n>2, the dot data offset is the number of bytes occupied by the dot data of the glyph ID n-1 plus 8, and the dot data offset and the number of dot bytes are the dot data offset position and the number of bytes occupied by the dot data of the character corresponding to the glyph ID in the glyph dot data table.

6. A font non-cache display method according to claim 4, characterized in that: Generating GBK encoding to glyph data index table includes: Generate corresponding dot data offsets and dot byte numbers for all codes 0x8140 to 0xFEFE in the GBK coding table and set them in the GBK coding to font data index table in the order of the GBK coding table; wherein, convert the GBK codes with high bytes of 0x81 to 0xFE and low bytes of 0x40 to 0xFE into UNICODE codes one by one, query whether the character set contains the UNICODE code corresponding to the GBK code, if not, the dot data offset corresponding to the GBK code is recorded as 0 and the dot byte number is recorded as 0; if contained, the dot data offset and dot byte number corresponding to the GBK code are recorded as the dot data offset position and the number of bytes occupied by the dot data of the character corresponding to the GBK code in the font dot data table.

7. A font non-cache display method according to claim 6, characterized in that: The first 8 bytes of the GBK encoding to the font data index table are used to set the number of bytes occupied by the GBK encoding to the font data index table and the function identifier; The GBK encoding to font data index table sets the same fixed number of bytes for each GBK encoding to store the dot matrix data offset and the number of dot matrix bytes.

8. The method for displaying fonts without cache according to claim 7, characterized in that: When the application wants to draw a character with a corresponding GBK code, the position of the GBK code in the GBK code to glyph data index table is calculated as: ((GBK code high byte - 0x81)*(0xFF-0x40)+GBK code low byte - 0x40)*number of single index bytes + 8, and the corresponding offset position is used to obtain the dot data offset and dot byte number of the character to be drawn, where the number of single index bytes is the number of bytes of the fixed number of bytes.

9. The method for displaying fonts without cache according to claim 1, characterized in that: When querying continuously, the dot matrix data offset and dot matrix byte number corresponding to the character to be drawn are recorded after each query. Subsequent queries first check whether they are the same as the last queried character. If they are the same, the dot matrix data offset and dot matrix byte number corresponding to the character to be drawn can be directly obtained.

10. The method for displaying fonts without cache according to claim 6, characterized in that: The five parts of the font dot matrix file are stored sequentially and successively, and the fixed number of bytes before each part is used to record the number of bytes occupied by each part; When the font is initialized, the starting offset of the UNICODE encoding to glyph ID mapping table, the starting offset of the glyph ID to glyph data index table, the starting offset of the glyph dot matrix data table, and the starting offset of the GBK encoding glyph data index table are calculated according to the starting position of the font header information and the number of bytes occupied by each part, and loaded into the memory.

Images