Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#5,112 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@user-github-me ci sta già lavorando.

Dal 8/10/2026.

  • #5202 di @user-github-me — aperta
  • #5203 di @user-github-me — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
html, typescript
Ambito
frontend, performance

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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
Lingua principale
TypeScript
Stelle
54.1k
Fork
4.9k
Merge medio
7h 19m
PR unite (30g)
746

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di heygen-com/hyperframes

Tutte le issue di heygen-com/hyperframes

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.