Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

fonts gate before composition scripts only covers faces that static markup already uses

未关闭
  • 哪里不对？
#5,112 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@user-github-me 已经在做这个了。

开始于 2026年10月8日。

  • #5202 来自 @user-github-me —— 未关闭
  • #5203 来自 @user-github-me —— 未关闭

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
html, typescript
领域
frontend, performance

调研方向

Start by inspecting the composition-script font-readiness gate changed in #4980 and reproduce with the attached index.html, local font, and render --workers 1; compare script-time measurements with document.fonts.load() results. The issue outlines two possible approaches but does not choose between them, so the fix needs investigation and a decision. Done when script-built text measures with its intended font before composition scripts proceed, without breaking the existing timeout behavior.

由索引模型根据 Issue 内容生成。

描述

Since 0.8.122 (#4980) composition scripts start only after web fonts are ready, which fixed measure-after-build layouts for fonts that static markup uses. The gate does not cover a face that only script-built text uses: it forces one layout, then awaits document.fonts.ready, and a face starts loading only when some text already in the DOM requests it. Text created by the composition script requests its face afterwards, so a getBoundingClientRect() taken at script time still sees the fallback font for that face. Which faces are loaded when a script runs therefore depends on what other scenes in the assembled page happen to show statically.

Repro (two files, attached): a local @font-face ("LocalFace", font-display: block, embedded by the compiler as a data URI) that no static text uses. The script sets a title in that face, measures it, centres it from the measurement, registers the timeline, then measures again inside document.fonts.load() and writes both numbers into the frame.

  • v0.8.135, render --workers 1: script-time width 1378.1 status unloaded / after fonts.load width 1056.5 status loaded. The title is centred from the first number, so it sits 161 px off centre in the final frame.
  • Control: uncomment the one static <span> in the face and both widths are 1056.5 with status loaded at script time.

Same mechanism with the compiler-fetched Google face: in a nine-scene project, a script-built block measured correctly only because an unrelated scene's static label happened to use the same weight; a second script-built block whose rows use a different weight measured 4 px short and was centred 2 px off. A handwritten title whose underline is drawn to the measured width rendered the underline 253 px too long and the title 114 px off centre in every render.

Two fixes look possible from the outside:

  1. Before releasing the scripts, call load() on every declared FontFace (Array.from(document.fonts).map((f) => f.load())) under the existing 5 s cap, so the stated guarantee holds for script-built text too.
  2. A lint finding when a composition script calls getBoundingClientRect / offsetWidth / offsetHeight outside a document.fonts.load() / document.fonts.ready callback, with the fix hint to measure inside it and register the timeline at the end (the documented async-build path).

Repro project (index.html, assets/fonts/local-face-700.woff2, package.json, hyperframes.json) and the rendered frame attached. Render log lines come from the page console as surfaced by the CLI.

Attachments: repro-bundle.zip (the four repro files)

rendered frame: script-time width 1378.1 px vs 1056.5 px after fonts.load
主要语言
TypeScript
星标
54.1k
派生
4.9k
平均合并
7 小时 19 分钟
30 天内合并 PR
746

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

heygen-com/hyperframes 的其他 Issue

查看 heygen-com/hyperframes 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。