A computer-implemented method for processing a TrueType font file in an embedded system

Abstract

To provide a method for processing a TRUETYPE font file in a built-in system.SOLUTION: A computer-implemented method for processing a TrueType font file (110) in a built-in system (138), where the TrueType font file (110) represents a specific font, the TrueType font file (110) includes a plurality of linked tables containing font data, the plurality of tables include at least a "glyf" table (114) that defines the appearance of glyph, i.e., the outlines of characters of the font, the plurality of tables other than the "glyf" table (114) are other tables, and the built-in system (138) includes at least a first memory (140) and a second memory (142), wherein the first memory (140) has slower reading and / or writing performance than the second memory (142).SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present disclosure relates to a method and system for processing fonts, particularly TrueType fonts, in an embedded system.

Background Art

[0002] Embedded systems are a fundamental part of various technologies and products ranging from digital wristwatches and traffic signal controllers to in-vehicle infotainment systems. These provide dedicated functions within larger mechanical or electronic systems as a combination of a processor, memory, input, and / or output devices. In most cases, embedded systems are designed to include a display device as a graphical user interface.

[0003] Typically, since the cost of an embedded system is optimized, it does not have a large amount of high-speed memory. The characteristics of an embedded system's memory are often low-speed memory (e.g., NAND flash memory) that is not usually memory-mapped and can only be accessed in block units. This memory is generally less expensive and more readily available the larger its size.

[0004] Conversely, high-speed memory is usually memory-mapped and randomly accessible. However, this type of memory is expensive and limited in size (e.g., RAM or NOR flash memory).

[0005] The latest embedded display systems need to provide attractive text rendering quality in multiple languages so as to be as general-purpose as possible. For this purpose, a font engine is usually used. In most cases, this is based on the standardized TrueType (TTF) or OpenType (OTF) outline font standards, while the open-source software development library FreeType is widely adopted as a font engine that renders text into bitmaps. Such a font engine usually requires that the font be in high-speed memory. In the case of FreeType, the font can be processed in a memory-mapped or file-mapped state. However, when multi-language support is required, the memory size of the corresponding TTF font becomes dozens of megabytes (MB), so a large amount of expensive high-speed memory is required.

[0006] Therefore, it is desirable to be able to access methods and systems that do not require a large amount of high-speed memory to process TTF files in an embedded system.

Summary of the Invention

Problems to be Solved by the Invention

[0007] Therefore, an object of the present disclosure is to provide a method and system that overcome the above-mentioned disadvantages of the prior art.

Means for Solving the Problems

[0008] A first aspect of the present disclosure is a computer-implemented method for processing TrueType font (TTF) files in an embedded system. A TrueType font file represents a specific font and includes a plurality of concatenated tables containing font data. These plurality of tables include at least a "glyf" table that defines the appearance of glyphs (font styles), i.e., the outline of the characters of the font. The plurality of tables other than the "glyf" table are other tables. The embedded system includes at least a first memory and a second memory, and the first memory is slower in read and / or write performance than the second memory. The method includes splitting the font data into at least a first data set and a second data set such that the first data set includes the "glyf" table and the second data set includes at least the other tables, loading the first data set into the first memory, loading the second data set into the second memory, and loading from the first data set into the second memory if the data corresponding to a specific glyph has not already been loaded into the second memory before rendering the specific glyph.

[0009] Every TTF file contains a series of concatenated tables where one table is the word order. The first table is a font directory that enables access to other tables within the font. These other tables contain font data and may appear in any order. While a specific table is required for all fonts, other tables are optional depending on the functions expected of a specific font.

[0010] Other tables include, for example, a table called "name" that contains the name of the font. There is also a table called "cmap" that includes the mapping to the glyphs of the characters. A glyph describes the specific form, design, or representation of a character. In other words, the glyphs of a font describe the outline of the font characters, and the corresponding data such as outline points are stored in a table called "glyf".

[0011] The disclosed invention is based on the understanding that while it is necessary to frequently access the memory to render fonts on a display, this is only for a small portion of the content of the TTF file, while other tables are accessed in a significantly different manner.

[0012] Most tables require random access memory to search for specific properties, for example using binary search. However, one notable exception is the "glyf" table, which is typically accessed only when rendering a specific glyph or when a font engine such as FreeType initially loads the font. During rendering, only the data for one glyph at a time is required, and the size of that one glyph is only a few hundred bytes. The "glyf" table also occupies the largest portion of the TTF file, reaching approximately 90% in most cases. The other tables thus only occupy a small portion, about 10% of the TTF file. In other words, the other tables need to be accessed frequently, while the "glyf" table needs to be accessed only rarely.

[0013] Therefore, the present invention proposes to split the TTF file into at least two separate parts and process them in different ways when loading into memory. The small and frequently accessed part is loaded once into high-speed memory. The large but rarely / infrequently accessed part is loaded into low-speed memory. Examples of the first memory include NAND flash memory and embedded multimedia card memory. Examples of the second memory include random access memory (RAM), or a combination of RAM and NOR flash memory.

[0014] However, slow read and write speeds can also be due to cloud-based memory where poor internet connection can be a limiting factor.

[0015] In the most basic approach, the TTF file is split into three parts, namely the part before the "glyf" table, the "glyf" table itself, and the part after the "glyf" table. As a result, the advantage is obtained that the font is divided into three parts and the font data is not changed. Therefore, while loading the "glyf" table as the first data set into the first memory, the other two parts can be loaded into the second memory. However, it is also possible to combine the two parts before and after the "glyf" table into two parts.

[0016] In an advantageous embodiment, the glyphs in the "glyf" table are sorted according to their usage frequency so that the frequently occurring glyphs appear first before being copied into the memory.

[0017] Before loading into the memory, it is also possible to make further modifications to different parts. For example, all the tables necessary for layout and rendering are placed in the front, and / or the tables unnecessary for rendering are completely omitted. For example, when using FreeType for rendering, since FreeType does not require the "post" table for stable operation, the "post" table may be deleted.

[0018] For the purpose of performing special processing, it is also possible to introduce additional tables into the font data. Multiple fonts in the memory can be combined into a single TTF file in any order. Thereby, only the necessary data can be loaded into the high-speed memory, and the memory cost can be significantly reduced.

[0019] In an advantageous embodiment, the second data set contains data from the "glyf" table. In this embodiment, by storing the more frequently used glyphs in the high-speed memory, reloading can be avoided, and thus the access time can be improved. When rendering frequently used glyphs, since they are already available from the second, faster memory, there is no need to load them from the first, slower memory.

[0020] According to a second aspect of the present disclosure, a computer program product includes instructions that, when executed by a computer, cause the computer to perform the steps of the above-described method.

[0021] According to a third aspect of the present disclosure, a computer-readable storage medium includes instructions that, when executed by a computer, cause the computer to perform the steps of the above-described method.

[0022] According to a fourth aspect of the present disclosure, a data carrier signal carries the computer program product according to the second aspect.

[0023] According to a fifth aspect of the present disclosure, an embedded system includes at least one microcontroller. Further, the embedded system includes at least a first memory and a second memory, where the first memory has slower read and / or write performance than the second memory, and the first and second memories are communicatively coupled to at least one microcontroller. Also, the embedded system includes at least one display communicatively coupled to at least one microcontroller. Further, the embedded system is configured to perform the above-described method to render glyphs on at least one display.

[0024] The display may be part of an infotainment system, an instrument cluster, a radio, or a head-up display. The embedded system may further include additional components such as a processor and a graphics processing unit. Different electronic components of the embedded system may be communicatively coupled via a bus such as a CAN bus.

[0025] The different parts of the embedded system may be integrated into a single unit. However, it is also possible to distribute multiple parts of the embedded system across different units. For example, a display and a microcontroller are part of a unit within a vehicle such as a car, motorcycle, truck, train, helicopter, airplane, etc., while the memory can be incorporated into a server.

[0026] In an advantageous embodiment, a TrueType font is rendered using a font engine based on a second data set in a second memory. In other words, the font engine uses the data in the high-speed memory for rendering.

[0027] According to a sixth aspect of the present disclosure, a vehicle implements the above-described embedded system.

[0028] Hereinafter, the present invention will be described by way of a plurality of exemplary embodiments with reference to the accompanying drawings.

Brief Description of the Drawings

[0029]

Figure 1

Figure 2

Figure 3

Figure 4

Modes for Carrying Out the Invention

[0030] FIG. 1 shows a flowchart of a computer-implemented method 100 for processing a TrueType font (TTF) file 110 in an embedded system 138.

[0031] Each TrueType font file 110 represents a specific font and includes a plurality of concatenated tables containing font data. Some tables contain data related to the layout and rendering of the font, some hold information to speed up the rendering process, and other tables store features, settings, copyright notices, font names, style names, and other information related to the font. Some tables are essential to any TTF file 110, while others are optional. One of the essential tables is the "glyf" table 114, which defines the appearance of the glyphs of the font, i.e., the outlines of the characters of the font, encoded in glyph data 152 as an accumulation of specific glyph data 154 for all the glyphs that make up the font.

[0032] In the splitting step 102 of the computer-implemented method 100, the TrueType font file 110 is split into at least a first data set 134 and a second data set 136, where the first data set 134 includes the "glyf" table 114 and the second data set 136 includes at least the other tables, i.e., the plurality of tables of the TTF file 110 other than the "glyf" table 114.

[0033] The embedded system 138 includes at least a first memory 140 and a second memory 142, and the first memory 140 has slower read and / or write performance than the second memory 142.

[0034] Then, in the first loading step 104 of the method 100, the first data set 134 is loaded into the first memory 140. At the same time, in the second loading step 106, the second data set 136 is loaded into the second memory 142. However, it is also possible to execute the first loading step 104 and the second loading step 106 sequentially.

[0035] In the rendering step 108, when rendering specific glyph data 154, the specific glyph data 154 is loaded from the first data set 134 into the second memory 142. However, for example, if the glyph is frequently used and the specific glyph data 154 has already been loaded into the second memory 142 because the second data set 136 contains data from the "glyf" table 114 that is frequently used, this step is skipped to avoid unnecessary workload. The rendering step 108 can be repeated for all glyphs to be rendered, which is visualized by the circular arrow in FIG. 1.

[0036] FIG. 2 shows a schematic diagram that details the steps of the method 100 for processing the TrueType font file 110 in the embedded system 138 of FIG. 1.

[0037] In particular, FIG. 2 details three different approaches regarding the splitting step 102 of FIG. 1. In the example of FIG. 2, the TTF file 110 includes a first portion 112, a "glyf" table 114, and a second portion 116. The first portion 112 holds all data that appears before the "glyf" table 114, while the second portion 116 holds all data that appears after the "glyf" table 114. FIG. 2 details a first approach 118, a second approach 120, and a third approach 126 regarding the method of splitting the TTF file 110 into a first data set 134 and a second data set 136.

[0038] In the first approach 118, the TTF file 110 is split into the "glyf" table 114 that is included in the first data set 134 and loaded into the first memory 140, while the first portion 112 and the second portion 116 are combined without further modification to form the second data set 136 that is loaded into the second memory 142.

[0039] In the second approach 120, the TTF file 110 is split into a first modified "glyf" table 122 and a first modified other table 124. The first modified "glyf" table 122 is a sorted version of the "glyf" table 114, with the most frequently used glyph data 152 appearing at the beginning of the table. The first modified other table 124 includes the first part 112 and the second part 116 of the TTF file 110, while the frequently used tables, such as those related to layout and rendering, are sorted to appear at the beginning of the table. The first modified "glyf" table 122 is included in the first data set 134 and loaded into the first memory 140. The first modified other table 124 is included in the second data set 136 and loaded into the second memory 142.

[0040] In the third approach 126, the TTF file 110 is split into a second modified "glyf" table 128, a frequently used "glyf" table 130, and a second modified other table 132. The second modified "glyf" table 128 is a copy of the "glyf" table 114 with the most frequently used glyph data 152 removed. The second modified "glyf" table 128 is loaded into the first memory 140 as the first data set 134.

[0041] These most frequently used glyph data 152 form the frequently used "glyf" table 130. The second modified other table 132 is a copy of a plurality of tables of the TTF file 110 other than the "glyf" table 114 from which the other tables, i.e., the tables irrelevant to the rendering process, have been removed. The combined frequently used "glyf" table 130 and the second modified other table 132 are stored in the second memory 142 as the second data set 136 for fast access.

[0042] FIG. 3 shows a schematic diagram of an embedded system 138 that executes a method 100 for processing the TrueType font file 110 of FIG. 1.

[0043] The embedded system 138 includes a first memory 140 and a second memory 142. The first memory 140 has lower read and / or write performance than the second memory 142 but has a larger storage capacity. Further, the embedded system 138 includes a microcontroller 144 and a display 146. The first memory 140 and the second memory 142 are communicatively coupled to the microcontroller 144 via a data bus 148. The display 146 is also communicatively coupled to the microcontroller 144, and via a video output 150, the microcontroller 144 can display the rendered glyphs on the display 146.

[0044] A first data set 134 is loaded into the first memory 140. Usually, this is done by flushing the first data set 134 at the end of the generation process. In the example of FIG. 1, the first data set 134 is the unmodified TTF file 110. Thus, the first data set 134 includes a first portion 112, a "glyf" table 114, and a second portion 116. The "glyf" table 114 includes glyph data 152 that defines the appearance of the glyphs in the font and is visualized by a plurality of rectangles in FIG. 3. One rectangle represents the individual glyph data of all the glyphs in the font.

[0045] During startup of the embedded system 138, a copy 112’ of the first portion and a copy 116’ of the second portion are loaded into the second memory 142. However, if, for example, the second memory 142 is a combination of a random access memory (RAM) and a NOR flash memory, it is also possible to flash the copies 112’, 116’ to the second memory 142 at the end of the generation process, similar to the first data set 134. At this stage, the embedded system 138 has all the information regarding how to layout and render the glyphs available in the high-speed memory, except for the glyph data 152. Since this data occupies most of the size of the TTF file 110, it is not desirable to load it into the fast but small second memory 142.

[0046] If the microcontroller is instructed, for example by an infotainment system, to display text on the display 146, the rendering process is started. During rendering, only one specific glyph 154 is needed at a time. Before the rendering process, the specific glyph data 154 is copied into the second memory 142 as a copy 154’ of the specific glyph data. This can then be conveniently loaded from the faster second memory 142. After the rendering process of the copy 154’ of the specific glyph data is completed, the rendering step 108 is repeated for the next glyph to be rendered.

[0047] Figure 4 shows a schematic diagram of a vehicle 156 in which the embedded system 138 of FIG. 3 is implemented.

[0048] Each part of the embedded system 138 may be incorporated into a single device as shown in FIG. 4. However, all or selected parts of the embedded system 138 can also provide the functions of another device, such as an infotainment system.

Description of the Reference Numerals

[0049] 100 Method 102 Splitting Step 104 First loading step 106 Second loading step 108 Rendering step 110 TrueType font file 112 First part 114 "glyf" table 116 Second part 118 First approach 120 Second approach 122 First modified "glyf" table 124 First modified other table 126 Third approach 128 Second modified "glyf" table 130 Frequently used "glyf" table 132 Second modified other table 134 First data set 136 Second data set 138 Embedded system 140 First memory 142 Second memory 144 Microcontroller 146 Display 148 Data bus 150 Video output 152 Glyph data 154 Specific glyph data 156 Vehicle

Claims

1. A computer-implemented method (100) for processing a TrueType font file (110) in an embedded system (138), wherein the TrueType font file (110) represents a specific font, the TrueType font file (110) includes a plurality of concatenated tables including font data, the plurality of concatenated tables includes at least a "glyf" table (114) that defines the appearance of glyphs, i.e., the outline of the characters of the font, and a plurality of tables other than the "glyf" table (114) are other tables, and the embedded system (138) includes at least a first memory (140) and a second memory (142), while the first memory (140) has a lower read and / or write performance than the second memory (142), and the method (100) includes a) dividing (102) the font data into at least a first data set (134) and a second data set (136) such that the first data set (134) includes the "glyf" table (114) and the second data set (136) includes at least other tables; b) loading (104) the first data set (134) into the first memory (140); c) loading (106) the second data set (136) into the second memory (142); d) before a rendering operation (108) of a specific glyph (152), loading from the first data set (134) into the second memory (142) the data corresponding to the specific glyph (152) if the data corresponding to the specific glyph (152) has not already been loaded into the second memory (142); and the glyphs in the "glyf" table (114) are sorted according to usage frequency such that frequently used glyphs appear first before being copied into memory. Method.

2. The method according to claim 1, wherein the second data set (136) includes data from the "glyf" table (114). **Claim 3** A computer program product comprising instructions which, when executed by a computer, cause the computer to perform the steps of the method (100) according to claim 1 or 2. **Claim 4** A computer-readable storage medium comprising instructions which, when executed by a computer, cause the computer to perform the steps of the method (100) according to claim 1 or 2. **Claim 5** An embedded system (138), a) at least one microcontroller (144), b) at least a first memory (140) and a second memory (142), wherein the first memory (140) has slower read and / or write performance than the second memory (142), while the first memory (140) and the second memory (142) are communicatively coupled to the at least one microcontroller (144), the first memory (140) and the second memory (142), c) at least one display (146) communicatively coupled to the at least one microcontroller (144), The embedded system (138) is formed to execute the method (100) according to claim 1 or 2 to render glyphs on the at least one display (146). **Claim 6** The embedded system (138) according to claim 5, wherein a font engine is used to render the TrueType font file (110) based on the second data set (136) stored in the second memory (142). **Claim 7** A vehicle (156) in which the embedded system (138) according to claim 5 is implemented.

Images