6f0e3d8e6b
name.js write 函数改用 view.setUint16 后未同步 writer.offset， 导致 name 字符串覆盖 header，name 表损坏。浏览器依赖 name 表 识别字体所以无法渲染，而 Node 端渲染不依赖 name 表所以基准 测试未检测到。 同时修复 cmap sizeof 动态计算记录头大小的问题。 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1.7 KiB
/loop 持续优化字体子集化性能，可以大胆放开手脚的去做，但是优化完一定要通过pnpx tsx ./基准测试.test.ts。中途不要切换到其他模式，比如计划模式也不要询问我，你直接做就行了，请你持续的去优化，不要去询问我，不要去中断，好吧
把基准测试结果文档保存在本地 benchmark_results/ ，这样我方便查看。你的文档中应该在每个重大节点更新基准测试结果（benchmark_results/OPTIMIZATION_LOG.md），这样我能方便看到你使用了哪些优化方法，得到了什么样的优化效果。
=== 字体裁剪基准测试 ===
8个汉字: avg=23.6ms min=18.4ms max=37.2ms 输出=16,508 bytes ssim=1.0000 拉丁+数字: avg=16.4ms min=13.7ms max=18.2ms 输出=1,272 bytes ssim=1.0000 千字文前段: avg=59.4ms min=47.3ms max=76.5ms 输出=161,344 bytes ssim=1.0000
=== 一晚上优化后的 字体裁剪基准测试 ===
8个汉字: avg=7.7ms min=3.8ms max=20.7ms 输出=16,572 bytes ssim=1.0000 拉丁+数字: avg=3.2ms min=1.6ms max=6.6ms 输出=1,272 bytes ssim=1.0000 千字文前段: avg=11.7ms min=6.8ms max=21.7ms 输出=161,816 bytes ssim=1.0000
其他方向
woff2 格式是不是更优越，可以新增这种格式吗，然后ttf的也还支持，但是默认使用这个
就是有一个纯前端的优化，咱们提供的js SDK好像是通过定时器扫描的吧，这当然是一种方式，也是最省心的一种方式，但是咱们是不是还可以考虑另外一种方式，就是通过配置来启用定时扫描还是由用户自己的事件来触发，甚至由用户直接传递文本，这样的话对于首页上的demo来说，可能会有更高的及时性响应