古语有云：没有最好，只有更好。

如要制定一个好的点阵字库格式，需考虑如下几点因素：

1、语言支持

2、检索效率

3、空间占比

4、维护与扩展

一、语言支持

网络上可以搜索到各种各样的点阵字库软件，归类一下主要分3种格式：等高等宽，等高不等宽，不等高不等宽。前2种颇为常见，基本近80%，如果只是处理一些常规语言（如英文，中文，韩文等），基本满足了。若遇到一些特殊语种（如阿拉伯语，泰文，印地语等），需要做字符叠加，内嵌等动作，则会相当困难，甚至很难实现。

1、Hight Fixed

等高等宽，等高不等宽都属于等高模式，会强制补白边。如下图示：

2、Not Fixed

不等高不等宽，也就是宽高不固定，只记录有效像素区域信息。如：记录字符有效像素宽、高，定位信息（x，y偏移），以及走纸宽度（Device Width）。如下图示：

说明： 字符"j"模拟演示。

说明：泰文叠加处理效果

建议：若要支持更多的语言，甚至包含一些特殊语种，推荐使用 Not Fixed 格式，也便于将来语言扩展。由于只针对有效像素，故其绘画效率也更高。

二、检索效率

检索效率高低，由检索方式决定，不同的检索方式，效率不一。另外不同的编码方式，会间接影响其检索方式。

1、内码

例如：gb2312，big5，cp1252等，默认都是指内码，由于编码规范、连续，特别遇到等宽字库的时候，可以通过编码，字库宽高，直接计算定位到点阵信息。如：Dos字库。

优点：可以省去检索表空间。

缺点：每一种编码需对应一个字库文件。支持的代码页越多，字库文件也就越多，间接导致文件繁多，管理麻烦，并且还会出现一些空白点阵（对应空字符），重复字符（不同代码页）。

2、Unicode

将不同语言（或代码页）的字符统一编码到unicode字符集，但由于需求不同用到的字符数也会不同，间接导致编码无法连续。

优点：将多语言统一到一个字库文件，便于管理与维护。

缺点：由于编码不连续，必须建立检索表配合检索。

注意：检索方式，值得深究。

三、空间占比

说到空间，自然就会想到硬件成本，特别在这个薄利多销的年代，控制好成本，也是竞争优势的体现。针对字库而言，空间占比最多的主要有2部分：检索表，点阵信息。

1、检索表

针对不连续编码，可以通过编码分段或编码映射的方式，来优化检索表空间，具体视情况而定。

1.1、编码分段

将有效编码分成多段处理，尽量减少检索信息中的空字符。当然也得考虑分段数量，若分段过多，也可能适得其反，甚至不能缩减空间，还会降低检索效率。

例如：使用编码 0x20，0x21，0x22，0x32，0x101，0x102，0x105，0x107。可以分成2段，第一段：0x20-0x32，第二段：0x101-0x107，检索表大小由分段字符之间的总字符数决定。

1.2、编码映射

记录有效使用编码，然后通过搜索编码，定位检索信息位置。

例如：使用编码 0x20，0x21，0x22，0x32，0x101，0x102，0x105，0x107。首先将这8个编码按升序都记录下来，然后为这8个编码建立一个检索表，检索表大小由有效字符数决定。

2、点阵信息

存储方式不同，空间大小也会存差异。字体设计基本都会考虑（横向，纵向）字间距，若采用Height Fixed模式，小点阵（< 18 pixel）稍有优势，否则 Not Fixed 更占优，特别灰度字库，更是优势明显。更有甚者，有人对点阵信息进行压缩，效率如何得视实际情况而论。

四、维护与扩展

这些年找了很多字库软件，为了分析其特点，当然也包括字库文件格式。有些字库文件，直接纯点阵，宽高信息体现在文件名中；有的弄了文件头，但相对简陋，只有宽高，字符数等信息；有的把检索表弄成数组，点阵信息弄成bin文件；有的用png（所有字符存成一张图），配合检索表（数组、列表）定位等等；各有利弊，适合自己就是最好的。

1、维护

维护，简单理解就是万一遇到问题，能快速定位并解决它。既然涉及到维护，那么环节当然是越少越好。

2、扩展

扩展，能根据新的需求，补充属性，尽量能向前兼容（老版本）。单就点阵字库而言，当需求越来越明确，后期增加属性的概率也会越来越低，但要一步到位亦是很难。

很多时候，我们的字库数据都是以文件方式烧写到Flash，而Bin文件（二进制格式）又是最省的方式。如果定义bin文件，建议加个文件头，便于快速了解字库的基本信息。例如：标识头，版本信息，文件大小、字符数，扫描方式、位深度、宽高等信息。标识头能快速判断文件是否有效；版本信息利于版本扩展；文件大小，有助于分析文件是否完整等等，这些看似不经意的信息，对于我们将来的维护与扩展，将会获益良多。若想了解更多，推荐研究下位图文件格式。