Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#5,112 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@user-github-me is already working on this.

Since Oct 8, 2026.

  • #5202 by @user-github-me — open
  • #5203 by @user-github-me — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
html, typescript
Domain
frontend, performance

Research direction

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.

Written by the indexing model from the issue text.

Description

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
Dominant language
TypeScript
Stars
54.1k
Forks
4.9k
Avg merge
7h 19m
Merged PRs (30d)
746

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from heygen-com/hyperframes

All issues in heygen-com/hyperframes

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.