TrueType Font Data Segmentation for Embedded Memory Optimization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Embedded systems face memory constraints due to the large size of TrueType fonts, which require expensive and limited fast memory for rendering text in multiple languages, making it costly to support various languages with appealing text rendering quality.
Innovation Solution
The method involves separating TrueType font data into two sets, where the 'glyf' table data is loaded into slower memory and the remaining tables are loaded into faster memory, optimizing memory usage by prioritizing frequent access paths and reducing the need for expensive fast memory.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If TrueType font files are loaded entirely into fast memory for rendering multiple languages, then text rendering quality and versatility are improved, but memory cost and memory size requirements increase significantly
Solution Approach 1:
The patent segments the TrueType font file into two distinct parts: a first part containing the font directory, name table, and cmap table (loaded into fast memory), and a second part containing the glyf table (loaded into slow memory). This segmentation allows the system to load only the essential font structure data into expensive fast memory while storing the large glyph outline data in cheaper slow memory, thereby reducing fast memory requirements while maintaining the ability to render multiple languages with high quality.
2Quantity of substance
If TrueType font files are stored in slow memory to reduce fast memory usage, then memory cost is reduced, but access time for font data increases
Solution Approach 1:
The patent extracts the glyf table (glyph outline data) from the main font file structure and stores it separately in slow memory, while keeping the essential font directory, name, and cmap tables in fast memory. This extraction allows the system to quickly access font metadata and character-to-glyph mappings from fast memory, then selectively load only the specific glyph data needed for rendering from slow memory, minimizing the time penalty of using slow memory.
Solution Approach 2:
The patent performs preliminary actions by pre-loading the font directory, name table, and cmap table into fast memory before rendering operations begin. This preliminary loading of essential font structure data ensures that when rendering is needed, the system can immediately access font metadata and character mappings without waiting for slow memory operations, thereby reducing overall access time while still utilizing slow memory for the bulk glyph data.
3Productivity
If all font data is loaded into fast memory at once, then rendering speed is improved, but memory cost and power consumption increase
Solution Approach 1:
The patent implements a dynamic memory loading strategy where glyph data is loaded from slow memory into fast memory on-demand based on rendering requirements. The system dynamically determines which glyphs need to be rendered and loads only those specific glyph data portions from slow memory into fast memory temporarily, rather than statically loading all font data. This dynamic approach maintains rendering speed by ensuring needed data is available in fast memory while reducing power consumption by minimizing the amount of data transferred and kept in energy-intensive fast memory.
Data Source
Figure 1~2
Figure 3~4
AI summary
A computer implemented method (100) for handling TrueType font files (110) in an embedded system (138), a TrueType font file (110) representing a specific font, the TrueType font file (110) consisting of a plurality of concatenated tables containing font data, the plurality of tables at least including a 'glyf' table (114) which defines the appearance of the glyphs, i.e., the outlines of the characters of the font, the plurality of tables without the 'glyf' table (114) being the remaining tables, the embedded system (138) at least comprising a first memory (140) and a second memory (142), whereas the first memory (140) is slower in terms of reading and/or writing performance than the second memory (142), the method (100) comprising the steps: separating (102) the font data into at least a first (134) and a second set of data (136), whereas the first set of data (134) is constructed out of the 'glyf' table (114), and the second set of data (136) constructed at least out of the remaining tables; loading (104) the first set of data (134) into the first memory (140); loading (106) the second set of data (136) into the second memory (142), and; prior to the rendering operation (108) of a specific glyph (152), loading the data corresponding to the specific glyph (152) from the first set of data (134) into the second memory (142), if it is not already loaded into the second memory (142).