尧图网页设计 
桌面应用图形学【免费下载链接】fontforgeFree (libre) font editor for Windows, Mac OS X and GNULinux项目地址https://gitcode.com/gh_mirrors/fo/fontforge点击查看免费下载sfnt 是承载 TrueType 与 OpenType 字体数据的容器格式但纯位图bitmap-only字体如何塞进这个容器Apple、X11Unix/Linux和 Microsoft Windows 各自给出了互不兼容的答案。本篇文章以 FontForge 官方技术文档 bitmaponlysfnt.rst 为骨架结合 tottf.c 的真实表生成逻辑逐一拆解三种格式的表格构成、差异根源与生成细节让读者能够理解 FontForge 在导出 Apple dfont、X11 .otb 与伪造的MS bitmap-only ttf 时分别写了哪些表、为什么这么写以及如何在生成对话框中正确触发这些格式。背景为什么纯位图字体的 sfnt 封装如此混乱sfnt 是存放 TrueType 或 OpenType 字体文件的容器格式即文档开篇所说 the file type which holds a truetype or opentype font。正常情况下sfnt 通过glyflocaTrueType 轮廓或CFFPostScript 轮廓表携带矢量轮廓数据位图只是作为嵌入位图embedded bitmap以EBDT/EBLC等表的形态附加在轮廓之上。但纯位图字体没有轮廓表只有位图数据而各操作系统对如何把位图塞进 sfnt的约定完全不同。正如原文档所言Unfortunately every system has its own way of storing bitmap only fonts into an sfnt wrapper (or the system just doesnt support it)。这导致同一个 FontForge 字体文件针对不同目标平台必须输出结构迥异的 sfnt。FontForge 在 tottf.c 的buildtablestructures函数中集中处理了这套差异化的表组装逻辑后续小节会逐一对照。Apple 的纯位图 sfntbloc/bdat bhedApple 是唯一在官方文档中承认纯位图 sfnt 形态存在的厂商但其文档并不完整。FontForge 文档中描述的结构部分是依据 Apple 文档部分是分析 Apple 少量实际纯位图字体、部分是通过 Apple 工具报错信息反推得到的。Apple 格式的核心特征位图数据位于bloc与bdat表bdat存放位图数据bloc存放指向位图的索引location。原文档特别指出这两张表与 OpenType 中的EBLC/EBDT格式完全一致——差别只在表名大小写不同Apple 用小写 4 字符标签。用bhed表替换head表bhed与head逐字节相同仅标签不同。也就是说它承载了同样的字体全局信息版本、单位、边界框等只是名字告诉解析器这是纯位图字体。没有glyf、loca与CFF表纯位图字体没有轮廓自然不需要这些表。没有hhea与hmtx表水平度量数据直接内嵌在位图 strike位图点阵层中无需独立度量表。垂直方向的vhea/vmtx同理原文档以Presumably这一谨慎措辞推断其同样缺席。maxp表的numGlyphs等于位图字形数量这是必须正确设置的关键字段它告诉解析器一共有多少个位图字形。源码中的实现印证tottf.c 的buildtablestructures函数完整复现了上述规则当at-applebitmaps且不是 MS 模式时位图数据与索引分别以bdatCHR(b,d,a,t)与blocCHR(b,l,o,c)标签写入tottf.c仅当formatff_none at-applebitmaps时输出bhed表注释明确写着 Bitmap only fonts get a bhed table rather than a headtottf.chead、hhea、hmtx表的输出条件均为format!ff_none || !applebitmaps/!applemode即纯 Apple 位图模式下全部跳过tottf.c在度量表写出逻辑中同样有 There is no hmtx table for apple bitmap only fonts 与 No hhea table for apple bitmap-only fonts 的注释tottf.c 与 tottf.c。读取侧同样有对应处理parsettf.c 的表名分发中出现case CHR(b,h,e,d)注释为 Apple uses bhed for fonts with only bitmaps——意味着 FontForge 既能生成也能读取这类字体。有趣的细节表数据复用当同一字体同时满足 Apple 与 MS 位图模式即同时有applebitmaps与msbitmaps时tottf.c 不会重复写数据bdat/bloc条目被设置为dup_of指向先前写入的EBDT/EBLC条目共享同一份位图数据实现一套数据、两张表名的兼容布局。X11Unix/Linux的纯位图 sfntOpenType Bitmap.otbX 协会X Consortium自行设计了名为OpenType Bitmap、扩展名为.otb的格式专门用于 Unix/Linux 平台。与 Apple 方案相比它更贴近标准 OpenType 布局位图数据位于EBLC与EBDT表直接使用 OpenType 的标准表名大写。存在一个零长度的glyf表空表充当占位符表示本字体没有轮廓数据。存在仅含一个条目的loca表loca表按glyf的偏移量组织单条目足以覆盖空表情形。使用标准head表而非bhed与 Apple 不同X11 方案保留head靠空glyf而非表名来传达纯位图语义。maxp.numGlyphs等于位图字形数而非loca表的大小这一点原文档特别强调说明maxp的语义在纯位图场景下必须显式按位图字形数填写不能机械地按轮廓表推导。度量表按需保留原文档补充说明 The fonts I generate also contain the metrics tables as appropriate即 FontForge 生成的 .otb 仍会携带恰当的度量表。对应到源码EBDT与EBLC的输出条件是at-bdat ! NULL (at-msbitmaps || at-otbbitmaps)tottf.c其中otbbitmaps即 X11 .otb 模式而bhed的生成条件排除了非 Apple 情形因此 .otb 必然保留标准head。Microsoft Windows不支持就伪造faked MS bitmap only sfntMicrosoft Windows 原生并不支持纯位图 sfnt。FontForge 为此伪造了一个在多数场景下可用的变体其设计思路是让 Windows 把它当成一个带内嵌位图的普通可缩放字体从而骗过系统的字体加载器。伪造格式的构成位图数据位于EBLC与EBDT表与 X11 一致使用标准 OpenType 表名。为每个字形提供glyf/loca条目条目本身渲染为空白字形space这样系统认为每个字形都有轮廓。这正对应旧版 changelog 中 an ms bitmap only ttf font … is done by creating dummy glyph and loca 的记载。引入EBSC表做像素尺寸映射EBSCembedded bitmap scaling control把常见像素尺寸映射到字体实际提供的尺寸。原文档给出的例子是如果用户请求 20 像素的 strike而字体只提供 18 像素系统可能给出 18 像素的 strike而不是一屏空白字形。EBSC表的输出逻辑见 tottf.c。使用标准head表而非bhed与 X11 相同伪装成普通 sfnt。携带度量表由于这套字体在 MS 眼中看似可缩放因此必须包含hhea/hmtx等度量表否则会被系统拒绝。三种格式对照表特征AppledfontX11.otbMS伪造 bitmap-only ttf位图数据表bloc/bdat与 EBLC/EBDT 同格式EBLC/EBDTEBLC/EBDT头部表bhed与 head 逐字节相同headheadglyf/loca无零长度glyf 单条目loca每字形一个空白条目hhea/hmtx无度量内嵌于 strike按需保留保留伪装可缩放特殊表——EBSC像素尺寸映射maxp.numGlyphs位图字形数位图字形数而非 loca 大小—系统原生支持文档承认但残缺专用 .otb 格式不支持需伪造在 FontForge 中生成这些格式这三种格式均从 FontForge 的Generate Fonts对话框对应文档 generate.rst触发位于位图类型bitmap types列表Apple bitmap only sfnt (dfont)仅当字体不含轮廓时才可选。生成时用位图数据包装出一个 dfont 容器。Apple 官方已暗示该格式进入弃用状态原文档附注 Apple implies that this format is deprecated且 Mac OS X 对它的支持可能并不完整。X11 bitmap only sfnt (otb)即上文所述 OpenType Bitmap 格式。(faked) MS bitmap only sfnt (ttf)即上文所述 Windows 伪造格式原文档以 (faked) 明确标注其伪造属性。生成前的两个前置条件位图尺寸必须存在于字体数据库中所有被选中的像素尺寸都必须已通过Element - Bitmaps Available对应菜单文档 elementmenu.rst生成并入库否则无法导出。抗锯齿位图用深度后缀标注像素尺寸后追加depth表示灰度antialiased/greymap位图例如128表示 12 像素高、8 位深度的抗锯齿位图。另外值得注意生成对话框的Apple / OpenType两个开关也影响位图表形态勾选 Apple 时位图表以bdat命名不勾选时以EBDT命名而数据本身完全一致generate.rst。这与 tottf.c 中bdat/EBDT共用同一份at-bdat数据缓冲的实现互相印证。深入从源码看表级别的差异实现如果想在源码层面验证三种格式到底差在哪最直接的入口是 tottf.c 的buildtablestructures约 L5388 起与 ttf.h 中的struct alltabs。关键的分支条件可归纳为at-applebitmaps控制bdat/bloc/bhed的产生与head/hhea/hmtx的抑制at-msbitmaps、at-otbbitmaps控制EBDT/EBLC的产生at-ebsc ! NULL时追加EBSC表仅 MS 伪造格式需要当 Apple 与 MS 模式同时存在时dup_of机制让bdat/bloc直接复用EBDT/EBLC的字节数据避免重复占用。读取端则在 parsettf.c 通过bhed表标签识别 Apple 纯位图字体。此外TrueOpenTables.rst 的表清单同样记录了 Replaces the head table in Apples bitmap only fonts 以及 FontForge 在生成 Apple 纯位图字体时使用该表的说明可作为交叉验证的文档依据。结语纯位图 sfnt 的封装差异本质上是三大平台对无轮廓字体语义的三种不同回答Apple 用bhed表名宣告身份、X11 用空glyf占位、Windows 则根本没有原生方案而需要 FontForge 伪造EBSC 空白字形来蒙混过关。理解了这三套表级约定再对照 tottf.c 的分支逻辑就能在导出 dfont、.otb 或 bitmap-only ttf 时准确预判产物结构也能在排查为什么某平台打不开我导出的位图字体时快速定位是缺了EBSC、误留了hhea还是maxp.numGlyphs填错。若需要更完整的术语背景可参考 glossary.rst 中关于纯位图字体的条目说明。赞分享桌面应用图形学【免费下载链接】fontforgeFree (libre) font editor for Windows, Mac OS X and GNULinux项目地址https://gitcode.com/gh_mirrors/fo/fontforge点击查看免费下载相关推荐FontForge 技术参考X11 PCF 位图字体文件格式Portable Compiled Format全解析FontForge 技术参考X11 PCF 位图字体文件格式Portable Compiled Format全解析 PCFPortable Compil桌面应用图形学FontForge 与 Macintosh 字体格式资源分叉、dfont、FOND/NFNT 与 sfnt 资源详解FontForge 与 Macintosh 字体格式资源分叉、dfont、FOND/NFNT 与 sfnt 资源详解 Macintosh 平台将字体存放在「资桌面应用图形学Proton GE 中的 UmeFont 日文字体方案以度量兼容实现 MS 日文字体替代Proton GE 中的 UmeFont 日文字体方案以度量兼容实现 MS 日文字体替代 本篇技术指南以 proton ge custom 仓库中 fonts游戏开发上一篇魔兽争霸3终极优化指南5大功能让你的经典游戏在Win10/Win11上完美运行下一篇ncmdumpGUI终极指南3分钟解锁网易云音乐NCM文件重获音乐自由创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 FontForge 中纯位图 sfnt 字体的三种存储格式：Apple bhed、X11 .otb 与 MS 兼容方案的实现解析
桌面应用图形学【免费下载链接】fontforgeFree (libre) font editor for Windows, Mac OS X and GNULinux项目地址https://gitcode.com/gh_mirrors/fo/fontforge点击查看免费下载sfnt 是承载 TrueType 与 OpenType 字体数据的容器格式但纯位图bitmap-only字体如何塞进这个容器Apple、X11Unix/Linux和 Microsoft Windows 各自给出了互不兼容的答案。本篇文章以 FontForge 官方技术文档 bitmaponlysfnt.rst 为骨架结合 tottf.c 的真实表生成逻辑逐一拆解三种格式的表格构成、差异根源与生成细节让读者能够理解 FontForge 在导出 Apple dfont、X11 .otb 与伪造的MS bitmap-only ttf 时分别写了哪些表、为什么这么写以及如何在生成对话框中正确触发这些格式。背景为什么纯位图字体的 sfnt 封装如此混乱sfnt 是存放 TrueType 或 OpenType 字体文件的容器格式即文档开篇所说 the file type which holds a truetype or opentype font。正常情况下sfnt 通过glyflocaTrueType 轮廓或CFFPostScript 轮廓表携带矢量轮廓数据位图只是作为嵌入位图embedded bitmap以EBDT/EBLC等表的形态附加在轮廓之上。但纯位图字体没有轮廓表只有位图数据而各操作系统对如何把位图塞进 sfnt的约定完全不同。正如原文档所言Unfortunately every system has its own way of storing bitmap only fonts into an sfnt wrapper (or the system just doesnt support it)。这导致同一个 FontForge 字体文件针对不同目标平台必须输出结构迥异的 sfnt。FontForge 在 tottf.c 的buildtablestructures函数中集中处理了这套差异化的表组装逻辑后续小节会逐一对照。Apple 的纯位图 sfntbloc/bdat bhedApple 是唯一在官方文档中承认纯位图 sfnt 形态存在的厂商但其文档并不完整。FontForge 文档中描述的结构部分是依据 Apple 文档部分是分析 Apple 少量实际纯位图字体、部分是通过 Apple 工具报错信息反推得到的。Apple 格式的核心特征位图数据位于bloc与bdat表bdat存放位图数据bloc存放指向位图的索引location。原文档特别指出这两张表与 OpenType 中的EBLC/EBDT格式完全一致——差别只在表名大小写不同Apple 用小写 4 字符标签。用bhed表替换head表bhed与head逐字节相同仅标签不同。也就是说它承载了同样的字体全局信息版本、单位、边界框等只是名字告诉解析器这是纯位图字体。没有glyf、loca与CFF表纯位图字体没有轮廓自然不需要这些表。没有hhea与hmtx表水平度量数据直接内嵌在位图 strike位图点阵层中无需独立度量表。垂直方向的vhea/vmtx同理原文档以Presumably这一谨慎措辞推断其同样缺席。maxp表的numGlyphs等于位图字形数量这是必须正确设置的关键字段它告诉解析器一共有多少个位图字形。源码中的实现印证tottf.c 的buildtablestructures函数完整复现了上述规则当at-applebitmaps且不是 MS 模式时位图数据与索引分别以bdatCHR(b,d,a,t)与blocCHR(b,l,o,c)标签写入tottf.c仅当formatff_none at-applebitmaps时输出bhed表注释明确写着 Bitmap only fonts get a bhed table rather than a headtottf.chead、hhea、hmtx表的输出条件均为format!ff_none || !applebitmaps/!applemode即纯 Apple 位图模式下全部跳过tottf.c在度量表写出逻辑中同样有 There is no hmtx table for apple bitmap only fonts 与 No hhea table for apple bitmap-only fonts 的注释tottf.c 与 tottf.c。读取侧同样有对应处理parsettf.c 的表名分发中出现case CHR(b,h,e,d)注释为 Apple uses bhed for fonts with only bitmaps——意味着 FontForge 既能生成也能读取这类字体。有趣的细节表数据复用当同一字体同时满足 Apple 与 MS 位图模式即同时有applebitmaps与msbitmaps时tottf.c 不会重复写数据bdat/bloc条目被设置为dup_of指向先前写入的EBDT/EBLC条目共享同一份位图数据实现一套数据、两张表名的兼容布局。X11Unix/Linux的纯位图 sfntOpenType Bitmap.otbX 协会X Consortium自行设计了名为OpenType Bitmap、扩展名为.otb的格式专门用于 Unix/Linux 平台。与 Apple 方案相比它更贴近标准 OpenType 布局位图数据位于EBLC与EBDT表直接使用 OpenType 的标准表名大写。存在一个零长度的glyf表空表充当占位符表示本字体没有轮廓数据。存在仅含一个条目的loca表loca表按glyf的偏移量组织单条目足以覆盖空表情形。使用标准head表而非bhed与 Apple 不同X11 方案保留head靠空glyf而非表名来传达纯位图语义。maxp.numGlyphs等于位图字形数而非loca表的大小这一点原文档特别强调说明maxp的语义在纯位图场景下必须显式按位图字形数填写不能机械地按轮廓表推导。度量表按需保留原文档补充说明 The fonts I generate also contain the metrics tables as appropriate即 FontForge 生成的 .otb 仍会携带恰当的度量表。对应到源码EBDT与EBLC的输出条件是at-bdat ! NULL (at-msbitmaps || at-otbbitmaps)tottf.c其中otbbitmaps即 X11 .otb 模式而bhed的生成条件排除了非 Apple 情形因此 .otb 必然保留标准head。Microsoft Windows不支持就伪造faked MS bitmap only sfntMicrosoft Windows 原生并不支持纯位图 sfnt。FontForge 为此伪造了一个在多数场景下可用的变体其设计思路是让 Windows 把它当成一个带内嵌位图的普通可缩放字体从而骗过系统的字体加载器。伪造格式的构成位图数据位于EBLC与EBDT表与 X11 一致使用标准 OpenType 表名。为每个字形提供glyf/loca条目条目本身渲染为空白字形space这样系统认为每个字形都有轮廓。这正对应旧版 changelog 中 an ms bitmap only ttf font … is done by creating dummy glyph and loca 的记载。引入EBSC表做像素尺寸映射EBSCembedded bitmap scaling control把常见像素尺寸映射到字体实际提供的尺寸。原文档给出的例子是如果用户请求 20 像素的 strike而字体只提供 18 像素系统可能给出 18 像素的 strike而不是一屏空白字形。EBSC表的输出逻辑见 tottf.c。使用标准head表而非bhed与 X11 相同伪装成普通 sfnt。携带度量表由于这套字体在 MS 眼中看似可缩放因此必须包含hhea/hmtx等度量表否则会被系统拒绝。三种格式对照表特征AppledfontX11.otbMS伪造 bitmap-only ttf位图数据表bloc/bdat与 EBLC/EBDT 同格式EBLC/EBDTEBLC/EBDT头部表bhed与 head 逐字节相同headheadglyf/loca无零长度glyf 单条目loca每字形一个空白条目hhea/hmtx无度量内嵌于 strike按需保留保留伪装可缩放特殊表——EBSC像素尺寸映射maxp.numGlyphs位图字形数位图字形数而非 loca 大小—系统原生支持文档承认但残缺专用 .otb 格式不支持需伪造在 FontForge 中生成这些格式这三种格式均从 FontForge 的Generate Fonts对话框对应文档 generate.rst触发位于位图类型bitmap types列表Apple bitmap only sfnt (dfont)仅当字体不含轮廓时才可选。生成时用位图数据包装出一个 dfont 容器。Apple 官方已暗示该格式进入弃用状态原文档附注 Apple implies that this format is deprecated且 Mac OS X 对它的支持可能并不完整。X11 bitmap only sfnt (otb)即上文所述 OpenType Bitmap 格式。(faked) MS bitmap only sfnt (ttf)即上文所述 Windows 伪造格式原文档以 (faked) 明确标注其伪造属性。生成前的两个前置条件位图尺寸必须存在于字体数据库中所有被选中的像素尺寸都必须已通过Element - Bitmaps Available对应菜单文档 elementmenu.rst生成并入库否则无法导出。抗锯齿位图用深度后缀标注像素尺寸后追加depth表示灰度antialiased/greymap位图例如128表示 12 像素高、8 位深度的抗锯齿位图。另外值得注意生成对话框的Apple / OpenType两个开关也影响位图表形态勾选 Apple 时位图表以bdat命名不勾选时以EBDT命名而数据本身完全一致generate.rst。这与 tottf.c 中bdat/EBDT共用同一份at-bdat数据缓冲的实现互相印证。深入从源码看表级别的差异实现如果想在源码层面验证三种格式到底差在哪最直接的入口是 tottf.c 的buildtablestructures约 L5388 起与 ttf.h 中的struct alltabs。关键的分支条件可归纳为at-applebitmaps控制bdat/bloc/bhed的产生与head/hhea/hmtx的抑制at-msbitmaps、at-otbbitmaps控制EBDT/EBLC的产生at-ebsc ! NULL时追加EBSC表仅 MS 伪造格式需要当 Apple 与 MS 模式同时存在时dup_of机制让bdat/bloc直接复用EBDT/EBLC的字节数据避免重复占用。读取端则在 parsettf.c 通过bhed表标签识别 Apple 纯位图字体。此外TrueOpenTables.rst 的表清单同样记录了 Replaces the head table in Apples bitmap only fonts 以及 FontForge 在生成 Apple 纯位图字体时使用该表的说明可作为交叉验证的文档依据。结语纯位图 sfnt 的封装差异本质上是三大平台对无轮廓字体语义的三种不同回答Apple 用bhed表名宣告身份、X11 用空glyf占位、Windows 则根本没有原生方案而需要 FontForge 伪造EBSC 空白字形来蒙混过关。理解了这三套表级约定再对照 tottf.c 的分支逻辑就能在导出 dfont、.otb 或 bitmap-only ttf 时准确预判产物结构也能在排查为什么某平台打不开我导出的位图字体时快速定位是缺了EBSC、误留了hhea还是maxp.numGlyphs填错。若需要更完整的术语背景可参考 glossary.rst 中关于纯位图字体的条目说明。赞分享桌面应用图形学【免费下载链接】fontforgeFree (libre) font editor for Windows, Mac OS X and GNULinux项目地址https://gitcode.com/gh_mirrors/fo/fontforge点击查看免费下载相关推荐FontForge 技术参考X11 PCF 位图字体文件格式Portable Compiled Format全解析FontForge 技术参考X11 PCF 位图字体文件格式Portable Compiled Format全解析 PCFPortable Compil桌面应用图形学FontForge 与 Macintosh 字体格式资源分叉、dfont、FOND/NFNT 与 sfnt 资源详解FontForge 与 Macintosh 字体格式资源分叉、dfont、FOND/NFNT 与 sfnt 资源详解 Macintosh 平台将字体存放在「资桌面应用图形学Proton GE 中的 UmeFont 日文字体方案以度量兼容实现 MS 日文字体替代Proton GE 中的 UmeFont 日文字体方案以度量兼容实现 MS 日文字体替代 本篇技术指南以 proton ge custom 仓库中 fonts游戏开发上一篇魔兽争霸3终极优化指南5大功能让你的经典游戏在Win10/Win11上完美运行下一篇ncmdumpGUI终极指南3分钟解锁网易云音乐NCM文件重获音乐自由创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考