字体信息 GetFontData

���¼���ԭʼ��ҳ ��ӡ

TrueType字体文件解析 | 学步园

在使用一些老外写的报表工具或控件时，总是会遇到中文乱码的问题；呵呵，这不我最终也遇上了，在我们的产品中使用了一个叫做eDocEngineer的报表输出控件；然后在中文平台上输出PDF等文档时，中文无法输出。经调试发现原来是TrueType字体文件解析时出了问题。老外对于TrueType字体的解析基本上只考虑了扩展名为ttf的情况，也即一个字体文件里只有一个字体，没有考虑到True Type Collection的情况，也即扩展名为ttc。

在使用win API函数GetFontData提取字体文件的数据时，一般都会写着GetFontData(DC, 0, 0, nil, 0)来获取字体数据的长度，然后再调用GetFontData(DC, 0, 0, Buff, FontLen)来获取这个字体的数据。对于ttf文件时，这样写是没有问题，但在处理True Type Collection时这里就会遇到Offset问题，最根本的原因就是ttc与ttf的区别。

ttc的格式与ttf的格式基本相同,offset也都是从文件头开始的；为什么使用处理ttf的方式来处理ttc会遇到问题呢？原因就在于虽然两者格式基本相同，但ttc文件里还是多了些东西。我们来比较下两种文件的格式：

首先是ttf的文件格式，ttf首先是从一个Table Directory开始的，一个ttf只有一个Directory,Directory的结构如下

FIXED version

USHORT numOfTables

USHORT searchRange

USHORT entrySelector

USHORT rangeShift

接下来就是Table Entries结构，之后就是存在的实际数据。

我们再来看ttc的文件格式，ttc文件的文件头如下：

TAG         TTCTag —’ttcf’

FIXED32  Version

ULONG    numOfDirectories

接下来就是Directory结构

我们可以看到ttf跟ttc的区别了。然后里面所有的offset都是从文件头开始计算的，因此如果在处理ttc文件时也用GetFontData(DC, 0,0, nil,0)的方式来提取字体数据，就会遇到offset问题。要解决这个问题，就需要把ttc的所有数据都提取出来，也即应该修改下GetFontData的第二个参数dwMetricsTable, 相对于ttc的参数值为0×66637474,也即为GetFontData(DC, 0×66637474, 0, nil, 0)或GetFontData(DC, 0×66637474, 0, buff, fontLen)来获得整个ttc文件的数据。然后再按照文件结构来解析即可。

更多关于字体文件结构的信息，可以参阅一个朋友的博文<关于TrueType字体结构的文章>.

重新加载原始网页 打印

关于TrueType字体结构的文章 - Arcan的波酪戈 - Arcan

TrueType字体通常包含在单个TrueType字体文件中，其文件后缀为.TTF。OpenType字体是以类似   于TrueType字体的格式编码的POSTSCRIPT字体。OPENTYPE字体使用.OTF文件后缀。OPENTYPE还允许把多个OPENTYPE字体组合在一个文件中以利于数据共享。这些字体被称为TrueType字体集（TrueType   collection），其文件后缀为.TTC。
TrueType字体用machintosh的轮廓字体资源的格式编码，有一个唯一的标记名"sfnt"。windows没有macintosh的位图字体资源格式，字体目录   包含了字体格式的版本号和几个表，每个表都有一个tableentry结构项，tableentry结构包含了资源标记、校验和、偏移量和每个表的大小。下面是TrueType字体目录的c语言定义：
typedef   sturct
{
char   tag[4];
ULONG   checkSum;
ULONG   offset;
ULONG   length;
}TableEntry;

typedef   struct
{
Fixed   sfntversion;   //0x10000   for   version   1.0
USHORT   numTables;
USHORT   searchRange;
USHORT   entrySelector;
USHORT   rangeShift;
TableEntry   entries[1];//variable   number   of   TableEntry
}TableDirectory;

        TrueType   字体中的所有数据都使用big-endian编码，最高位字节在最前面（因为TrueType字体最初是由apple公司定义的，而apple公司的os运行在motorola的cpu上）。如果一人TrueType字体以00   01   00   00   ,00   17开头，我们就可以知道它的格式是轮廓字体资源（"sfnt"）版本1.0的格式，有23个表。

        TableDirectory结构的最后一个字段是可变长度的tableentry结构的数组，安体中的每个表对应其中一项。TrueType字体中的每个表都保存了不同的逻辑信息-----如图元中数据、字符到图元的映射、字距调整信息等等。有表是必须的，有些是可选的。下表列出了TrueType字体中常见的表。
head           字体头                                           字体的全局信息
cmap           字符代码到图元的映射               把字符代码映射为图元索引
glyf           图元数据                                       图元轮廓定义以及网格调整指令
maxp           最大需求表                                   字体中所需内存分配情况的汇总数据
mmtx           水平规格                                       图元水平规格
loca           位置表索引                                   把元索引转换为图元的位置
name           命名表                                           版权说明、字体名、字体族名、风格名等等
hmtx           水平布局                                       字体水平布局星系：上高、下高、行间距、最大前进宽度、最小左支撑、最小右支撑
kerm           字距调整表                                   字距调整对的数组
post           PostScript信息                           所有图元的PostScript   FontInfo目录项和PostScript名
PCLT           PCL   5数据                                     HP   PCL   5Printer   Language   的字体信息：字体数、宽度、x高度、风格、记号集等等
OS/2           OS/2和Windows特有的规格         TrueType字体所需的规格集
在TableDirectory结构中，所有的TableEntry结构都必须根据它们的标记名排序。比如，cmap必须出现在head前，而head必须在glyf前。但是实际的表可以出现在TrueType字体文件中的任意位置。
Win32API   提供了一个应用程序可用于查询原始TrueType字体信息的函数：
DWORD   GetFontData(HDC   hDC,DWORD   dwTable   ,DWORD   dwOffset,   LPVOID   lpbBuffer   ,DWORD   cbData);
GetFontData函数可以用于查询设备上下文中当前逻辑字体所对