• 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


  • 相关阅读:
    hbase 简介
    Hadoop本地库介绍
    MapReduce:详解Shuffle过程
    eucalyptus,openstack
    openstack installing...
    今年2011
    wget代理设置(转载)
    openstack running
    python 升级到2.6(转载)
    高德地图Windowphone API学习地图定位与地图模式的切换
  • 原文地址:https://www.cnblogs.com/shangdawei/p/3080035.html
Copyright © 2020-2023  润新知