开发者 Jim Paris 上周把一个奇怪的东西放上了 GitHub：一款叫 qr-font 的 TrueType/OpenType 字体。输入 abc[hello]ghi，方括号里的 hello 会被自动渲染成一个完整的二维码符号，方括号外的文字照常显示。项目附带在线演示页面，可以直接在浏览器里输入文本试运行。
项目地址是 jimparis/qr-font，目前约 161 星、5 次 fork，最新版本 v1.0.0 标注发布于 2026 年 6 月 28 日。这不是把一张二维码图片塞进字体文件那么简单，真正的技术动作发生在排版引擎的 shaping 阶段，而不是应用层代码里。
计算逻辑搬进了字体，不是搬进图片
传统做法里，二维码是应用层的产物。不管是 qrcode 库还是 ZXing，都是先算好模块矩阵，再画成图片或 SVG。字体和排版引擎完全不参与这个过程。
qr-font 反过来，把生成逻辑整个编译进了字体的 GSUB（Glyph Substitution）表。分隔符解析、字节展开、Reed-Solomon 校验位计算、模块布局、固定掩码渲染，全部由排版引擎在“整形”（shaping）阶段现场跑一遍。
这才是这个项目真正有意思的地方。它证明排版引擎能扛住这一整套计算，不是说它比传统方式更好用。
容量和限制，卡在字体环境上
项目提供三个版本，容量差距不小：
| 版本 | 模块规格 | 最多字符数 |
|---|---|---|
| 1-L | 21×21 | 17 |
| 2-L | 25×25 | 32 |
| 3-L | 29×29 | 53 |
数字越大不是免费的。字体文件里预编译的 GSUB 规则会随之膨胀，构建时间明显变长，项目专门留了一个“占位纠错”的快速构建模式来省时间。
限制也很明确：只支持可打印 ASCII，方括号做分隔符，mask pattern 固定用 0。不能选纠错等级，不支持中文或任意二进制数据，字符数一超上限就没法用。
作者自己也说这是个 proof-of-concept，依赖环境要能正确执行 OpenType 的 GSUB 特性。浏览器、排版引擎、办公软件之间的实现差异是否都能稳定触发这套逻辑，项目没有给出验证。这些限制不是二维码规范本身的问题，是这套实现方式的取舍——牺牲纠错灵活性和字符集，换来不用调用应用层库生成图片的实验价值。
对字体工程师和文档用户分别意味着什么
字体工程、排版引擎和前端渲染开发者，可以拿这个项目研究 GSUB 的能力边界，测试 shaping 性能上限。但先别指望现成的跨环境兼容性，想真正用它，得自己在目标渲染环境里跑一遍验证，再判断能不能接进产品。
需要在文档或设计系统里嵌入小型二维码的技术用户，只有内容是短小的可打印 ASCII（不超过 53 字符），并且能接受“不保证跨环境可扫”这个风险，才值得先试一下。涉及正式产品的用户扫码路径，还是该用 qrcode、ZXing 这类经过大规模验证的应用层库，不要为了省一次调用换来扫不出来的风险。
接下来最该盯的变量，是有没有人在 Chrome、Safari、Word、InDesign 这类不同 shaping 引擎里做过实测扫码验证。如果这块兼容性一直没人补，qr-font 大概就会停在 GitHub star 数上，走不出 demo 阶段。