cmap 表里的子表长度数据 小于实际值

[0tkl]

使用 ttx 导出 文楷 GB Regular v1.330，在运行到 cmap 表时会报错：

ERROR: An exception occurred during the decompilation of the 'cmap' table
Traceback (most recent call last):
  File "fontTools\ttLib\ttFont.py", line 467, in _readTable
    table.decompile(data, self)
  File "fontTools\ttLib\tables\_c_m_a_p.py", line 179, in decompile
    table.cmap = tables[seenOffsets[offset]].cmap
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "fontTools\ttLib\tables\_c_m_a_p.py", line 289, in __getattr__
    self.ensureDecompiled()
  File "fontTools\ttLib\tables\_c_m_a_p.py", line 278, in ensureDecompiled
    self.decompile(None, None)  # use saved data.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "fontTools\ttLib\tables\_c_m_a_p.py", line 905, in decompile
    delta = idDelta[i]
            ~~~~~~~^^^
IndexError: array index out of range

在十六进制编辑器中，查看报错处（cmap 表里的一张子表）的表头：

0004 1A26 0000 0EFA 0800 000A

根据 OpenType 规范文件 可知，表头说明子表 length 为 6694 (0x1A26) 个字节、segCount 为 3834(0x0EFA) / 2 = 1917。然而由文件结构的定义易知，若 segCount 无误，则 length 不应小于 segCount × 4 + 14 = 7682 个字节。

至于是 segCount 太大还是 length 太小：作为参考，字体丢进 FontCreator，不作任何手动修改，立即导出为 ttf。表头变成了

0004 3CFA 0000 0F22 0800 000A

segCount 跟原来的差不多，但 length 是原来的 2.3 倍有余。故怀疑目前的 length 偏小。

目前已测试 GB 版的三种字重均存在这一 bug。未测文楷的其余版本（无后缀版、屏显版、TC 版、Lite 版）。

这一 bug 会影响所有基于 ttx 的字体处理程序，比如一些字体子集化程序。

[lxgw]

请问大佬有什么解决方法吗？

[0tkl]

请问大佬有什么解决方法吗？

我在 Windows 上原封不动地运行 build.bat 出来的结果没问题（ttx 能正确地导出，无报错），没复现出 bug…… 要不您更新 / 重装一下本地的工具？我本地的工具是这两天新装的

> pip list
Package      Version
------------ ----------
fontmake     3.9.0
fonttools    4.51.0
ufo2ft       3.2.1
ufoLib2      0.16.0

[0tkl]

算了我搓个 CI 吧，PR #11

[NightFurySL2001]

目前猜测原因是 FontForge 导出的二进制有问题。FontForge 本身已经略有历史了，导出的字体文件（TTF/UFO）都有一些奇奇怪怪的问题，比如源文件导出的UFO是没有纵向度量的。我们在尽量解决这个问题。

[0tkl]

目前猜测原因是 FontForge 导出的二进制有问题。FontForge 本身已经略有历史了，导出的字体文件（TTF/UFO）都有一些奇奇怪怪的问题，比如源文件导出的UFO是没有纵向度量的。我们在尽量解决这个问题。

也就是说，现在的 fonts/TTF 文件夹下、还有 release 页面里放的字体文件，并不是直接运行 sources 文件夹里的 build.bat/.sh 来构建的吗

[lxgw]

目前猜测原因是 FontForge 导出的二进制有问题。FontForge 本身已经略有历史了，导出的字体文件（TTF/UFO）都有一些奇奇怪怪的问题，比如源文件导出的UFO是没有纵向度量的。我们在尽量解决这个问题。

也就是说，现在的 fonts/TTF 文件夹下、还有 release 页面里放的字体文件，并不是直接运行 sources 文件夹里的 build.bat/.sh 来构建的吗

是这样的，Sources 文件夹里的 ufoz 源文件是从 TTF 文件中生成的，也就是说，并不是先有源文件再有 TTF，而是反过来。

[moi15moi]

请问大佬有什么解决方法吗？

I would use freetype. fontTools is to restrictive when it parse cmap.

[0tkl]

Reopen this issue until lxgw/LxgwWenkaiTC#16 got merged and applied to this ~GB repo.