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

 

 

posted @   IAmAProgrammer  阅读(500)  评论(0编辑  收藏  举报
(评论功能已被禁用)
编辑推荐:
· 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 同步复位与异步复位-异步复位和同步复位区别.
点击右上角即可分享
微信分享提示