Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#5,112 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@jbernard077 ya está trabajando en esto.

Desde el 6/10/2026.

  • #5118 de @jbernard077 — abierto
  • #5202 de @user-github-me — abierto
  • #5203 de @user-github-me — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
html, typescript
Área
frontend, performance

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug triage/needs-design

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
Lenguaje dominante
TypeScript
Estrellas
54.1k
Forks
4.9k
Merge medio
8 h 33 min
PR fusionados (30 d)
665

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de heygen-com/hyperframes

Todos los issues de heygen-com/hyperframes

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.