Skip to content

fix(report): Urdu rendered as tofu on prod whenever the STT mislabelled the language — cherry-pick of #307 - #308

Merged
hyasin270 merged 1 commit into
mainfrom
main-cherry-osmk0-1787164956
Aug 19, 2026
Merged

fix(report): Urdu rendered as tofu on prod whenever the STT mislabelled the language — cherry-pick of #307#308
hyasin270 merged 1 commit into
mainfrom
main-cherry-osmk0-1787164956

Conversation

@hyasin270

Copy link
Copy Markdown
Contributor

Cherry-pick of #307 (already merged to develop and live on NIETE staging as 5a93e8e, all four services SUCCESS).

Prod main carries the identical defect — verified before picking:

134:  const headFam = RTL ? (... ) : `'Fraunces',serif`;
135:  const bodyFam = RTL ? (... ) : `'Lexend',sans-serif`;
206:  .pframe .pcap{... font-family:'Lexend',sans-serif; ...}
 31:  const lang = language || analysis.language || session.transcript_language || 'en';

The Nastaliq @font-face is embedded but referenced by no rule in the Latin branch, so an Urdu-bodied report whose language was mislabelled by the STT had nothing to draw Urdu with. Railway's Chromium has no system fonts — every Urdu glyph painted as an empty box. 44 already-generated reports on prod are in that state, and a coach reported it (HITL R65/R66).

Clean pick, no conflicts. Tests on this main-based tree: 42 passed across the two new suites plus the two neighbours most likely to be disturbed (hero-report-english-chrome, html-to-pdf).

Not fixed here: bd-bfy69 — Soniox writing Urdu as Devanagari. There is no Devanagari font in the repo, so that script will still not render; it is being fixed at source separately.

Closes: bd-osmk0
Closes: bd-gipr1

🤖 Generated with Claude Code

…age — 44 reports rendered as tofu (#307)

Rifat reported a coach debrief that was "only empty boxes with no content"
(R66). The screenshot was in the feedback sheet as a floating image the Sheets
API will not return; pulling it out of an authenticated PDF export showed the
teacher hero report with every Urdu glyph painted as a box while the English
chrome rendered perfectly.

The chain, end to end:

  1. hero-report.service resolved
       lang = language || analysis.language || session.transcript_language || 'en'
     transcript_language is an STT label, and since 2026-08-11 Soniox has been
     returning 'en' / 'hindi' / 'javanese' / 'sindhi' for Urdu classroom audio
     (bd-bfy69, still open). So an Urdu-bodied report went down the Latin arm.
  2. hero-report.template's Latin arm named ONLY 'Fraunces'/'Lexend'. The
     NastaliqUrdu @font-face was embedded but never referenced from any rule in
     that branch.
  3. Railway's Chromium has no system fonts, so those glyphs had nothing to
     fall back to. macOS silently substitutes a system Nastaliq, which is
     exactly why every local render looked correct.

Measured on prod: 44 already-generated reports carry non-Latin script while
sitting in a non-ur/ar branch.

Verified with CSS.getPlatformFontsForNode, before and after, same instrument:
BEFORE the Urdu run resolved to the SYSTEM 'Noto Nastaliq Urdu'
(isCustomFont=false — absent on Railway); AFTER it resolves to the EMBEDDED
face in all three stacks. Latin still resolves to Lexend/Fraunces first; the
fallbacks only catch what those cannot draw.

Also fixed .pframe .pcap, which pinned LLM-generated photo captions to
Latin-only Lexend in EVERY branch — so those tofu'd even on a correctly
labelled Urdu report. That is the bd-2362 class: the small-print element
nobody re-checks after the main stacks are fixed.

Tests: 20 + 12 new, red-first against this tree (9 font assertions failed
before the template change; the language suite could not resolve its module).
Full suite shows zero new failures — the four suites that differed under the
parallel run all pass in isolation both with and without the change.

Closes: bd-osmk0
Closes: bd-gipr1

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
@hyasin270
hyasin270 merged commit d47d6e4 into main Aug 19, 2026
1 of 2 checks passed
@hyasin270
hyasin270 deleted the main-cherry-osmk0-1787164956 branch August 19, 2026 18:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant