这个书源在稳定版可以用，但是测试版不行

[skybbk1001]

http://sy.legado1.top/sy.php/3a5f0cbb2e8a3bdecb8d71bb56cfd18b.json

这是书源地址

测试版报错

[821938089]

字体解析有问题
@Antecer

[Antecer]

是loca成员长度为uint16的时候把值识别错了，已经修复了：
https://github.com/gedoor/legado/actions/runs/9562220794

[Antecer]

你查询Unicode有没有字形应该用 font.getGlyfIdByUnicode() 函数，返回0就是没有字形的。
getGlyfByUnicode() 是根据字体文件的定义返回的内容，字体文件把 Unicode 指向哪个轮廓就会返回哪个轮廓，这里明显是字体文件把 19980 指向了缺省的轮廓 0

[skybbk1001]

你查询Unicode有没有字形应该用 font.getGlyfIdByUnicode() 函数，返回0就是没有字形的。 getGlyfByUnicode() 是根据字体文件的定义返回的内容，字体文件把 Unicode 指向哪个轮廓就会返回哪个轮廓，这里明显是字体文件把 19980 指向了缺省的轮廓 0

但是这个unicode本身就不存在字体内，怎么会有指向

[Antecer]

TTF字体格式是这样的，你以为这个Unicode没在字体内，其实它在字体内，只是字体文件给它分配的轮廓索引就是0.
这里从截图可以看到，字体数据里面有一段Unicode范围是19978-19981，所以它是包含19980的。
当然，在解析字体的时候也可以直接把指向索引0的Unicode给排除掉，但是我这里遵循了TTF的规范，没有排除掉。

[skybbk1001]

TTF字体格式是这样的，你以为这个Unicode没在字体内，其实它在字体内，只是字体文件给它分配的轮廓索引就是0. 这里从截图可以看到，字体数据里面有一段Unicode范围是19978-19981，所以它是包含19980的。 当然，在解析字体的时候也可以直接把指向索引0的Unicode给排除掉，但是我这里遵循了TTF的规范，没有排除掉。

好的，感谢大佬。我一直给书源作者和你们当传话筒，现在总算是解决了。辛苦了

[Antecer]

考虑到这个字体查询功能并不会使用它的轮廓数据作为字体渲染，新版本已经把轮廓索引为0的Unicode排除。