Stellaris Graphics Library : Font Glyph Data Format
the rows were connected side-by-side
Consider the following font glyph (for a non-existant character from a 14x8 font):
..............
..............
..............
......xx......
.....xxxx.....
...xxxxxxxx...
...xxxxxxxx...
..............
Store Glyph by Bytes ( 18 bytes )
........ ...... .. 0x00 0x00
........ ...... .. 0x00 0x00
........ ...... .. 0x00 0x00
......xx ...... .. 0x03 0x00
.....xxx x..... .. 0x07 0x80
...xxxxx xxx... .. 0x1F 0xE0
...xxxxx xxx... .. 0x1F 0xE0
........ ...... .. 0x00 0x00
0x12, 0x0e,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x07, 0x80, 0x1F, 0xE0, 0x1F, 0xE0, 0x00, 0x00
Store Glyph by Bits ( 16 bytes ) uncompressed
The graphics library supports three distinct bitmap font formats offering a variety of features depending upon the needs of an application.
All three formats encode individual characters in the same way but use different headers and character glyph lookup methods.
Font data is stored with a scheme that treats the rows of the font glyph as if they were connected side-by-side.
Therefore, pixels from the end of one row can be combined with pixels from the beginning of the next row when storing.
Fonts may be stored in an uncompressed format or may be compressed with a simple pixel-based RLE encoding.
For either format, the format of the data for a font glyph is as follows:
The first byte of the encoding is the number of bytes within the encoding (including the size byte).
The second byte is the width of the character in pixels.
The remaining bytes describe the pixels within the glyph.
For the uncompressed format, each 8-pixel quantity from the font glyph is stored as a byte in the glyph data.
The most significant bit of each bit is the left-most pixel.
|-------------|-------------|-------------|-------------|-------------|-------------|-------------|-------------|
................................................xx...........xxxx........xxxxxxxx......xxxxxxxx.................|
|-------|-------|-------|-------|-------|-------|-------|-------|-------|-------|-------|-------|-------|-------|
This would be stored as follows:
0x10,
0x0e,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xc0, 0x07, 0x80, 0x7f, 0x81, 0xfe, 0x00, 0x00
Compression of the font data is via a per-glyph pixel RLE scheme. The encoded format of the font data is as follows:
A non-zero byte encodes up to 15 consecutive off pixels followed by up to 15 consecutive on pixels. < off-on >
The upper nibble contains the number of off pixels and the lower nibble contains the number of on pixels.
So, for example, 0x12 means that there is a single off pixel followed by two on pixels.
A zero byte indicates repeated pixels. < N * 8 >
The next byte determines the size and type of the repeated pixels.
The lower seven bits specifies the number of bytes in the literal encoding (referred to as N).
If the upper bit is set, then there are N*8 on pixels.
If the upper bit is not set, then there are N*8 off pixels.
The repeated pixel encoding is very useful for the several rows worth of off pixels
that are present in many glyphs.
..............
..............
..............
......xx......
.....xxxx.....
...xxxxxxxx...
...xxxxxxxx...
..............
For the same glyph as above, the the compressed would be as follows,
with an explanation of each byte or byte sequence:
|-------------|-------------|-------------|-------------|-------------|-------------|-------------|-------------|
................................................xx...........xxxx........xxxxxxxx......xxxxxxxx.................|
|-------|-------|-------|-------|-------|-------|-------|-------|-------|-------|-------|-------|-------|-------|
0x0a: There are 10 bytes in the encoding of this glyph, including this byte.
0x0e: This glyph is 14 pixels wide.
0x00 0x06: The glyphs starts with 48 off pixels (6 bytes).
0x02: The fourth row has no addition off pixels before the two on pixels.
0xb4: The fourth row ends with 6 off pixels and the fifth row starts with 5 off pixels, making 11 off pixels. This is followed by 4 on pixels.
0x88: The fifth row ends with 5 off pixels, and the sixth row starts with 3 off pixels, making 8 off pixels. This is followed by 8 on pixels.
0x68: The sixth row ends with 3 off pixels, and the seventh row starts with 3 off pixels, making 6 off pixels. This is followed by 8 on pixels.
0xf0: The seventh row ends with 3 off pixels, and the eighth row has 14 off pixels. Since the maximum that can be encoded is 15, fifteen of the off pixels are here.
0x20: The remaining two off pixels, ending the glyph.
This results in a ten byte compressed font glyph, compared to the sixteen bytes required to describe the glyph without compression.
Store Glyph by Bits ( 10 bytes ) compressed
0x0a, 0x0e,
0x00, 0x06, 0x02, 0xb4, 0x88, 0x68, 0xf0, 0x20
Store Glyph Black Box by Bits ( 10 bytes ) compressed
( x, y ) = ( 3, 3 )
( w, h ) = ( 8, 4 )
+-------+ (3)
| ..............
| ..............
| ..............
+(3) ......xx...... --+ 0x32, 0x54, 0x2F, 0x01
.....xxxx..... |
...xxxxxxxx... 4
...xxxxxxxx... --+
..............
| |
+--8---+
<--box information--->
0x10, 0x0e, 0x03, 0x03, 0x08, 0x04, 0x32, 0x54, 0x2F, 0x01
len width x y w h data------------------
256 * 256 ( w = 0, h = 0 )
the cols were connected side-by-side
Font data is stored with a scheme that treats the cols of the font glyph as if they were connected side-by-side.
Therefore, pixels from the end of one col can be combined with pixels from the beginning of the next col when storing.
Fonts may be stored in an uncompressed format or may be compressed with a simple pixel-based RLE encoding.
Consider the following font glyph (for a non-existant character from a 14x8 font):
..............
..............
..............
......xx......
.....xxxx.....
...xxxxxxxx...
...xxxxxxxx...
..............
0x11, 0x0E, 0x00, 0x00, 0x00, 0x06, 0x06, 0x0E, 0x1E, 0x1E, 0x0E, 0x06, 0x06, 0x00, 0x00, 0x00 -- uncompressed by bytes
0x11, 0x0E, 0x00, 0x00, 0x00, 0x06, 0x06, 0x0E, 0x1E, 0x1E, 0x0E, 0x06, 0x06, 0x00, 0x00, 0x00 -- uncompressed by bits
0x0E, 0x0E, 0x00, 0x03, 0x52, 0x62, 0x44, 0x44, 0x53, 0x62, 0x62, 0x00, 0x03, 0x10 -- compressed by bits
0x0C, 0x0E, 0x03, 0x03, 0x08, 0x04, 0x22, 0x22, 0x1B, 0x13, 0x22, 0x22 -- compressed box by bits
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
2012-05-15 同步复位与异步复位-异步复位和同步复位区别.