fix(fonts): resolve declared custom and Google fonts in text rendering#100
Open
LeadcodeDev wants to merge 1 commit into
Open
fix(fonts): resolve declared custom and Google fonts in text rendering#100LeadcodeDev wants to merge 1 commit into
LeadcodeDev wants to merge 1 commit into
Conversation
Custom/Google fonts declared in a scenario's `fonts` were downloaded and handed to Skia via `FontMgr::new_from_data`, but that call returns a detached Typeface and never exposes it to `match_family_style` — Skia's default FontMgr only name-resolves installed system fonts. So every `font-family` pointing at a declared font silently rendered in the Helvetica/Arial fallback (e.g. Anton came out as a generic sans-serif). Keep the raw bytes in a global family->bytes registry when loading, and have `typeface_with_fallback` resolve custom families from it first — building and caching the Typeface per render thread (the FontMgr is thread-local, so system-thread registration alone never reached the rayon render workers). One weight per custom family via this path; multi-weight custom families are follow-up. Tests: registry stores first-wins + serves bytes; a registered family resolves to its own typeface over the system fallback (uses the cached Anton TTF when present, skips on a cold cache).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Fonts declared in a scenario's
fontsarray (local orsource: "google") never actually rendered. They were downloaded and passed to Skia viaFontMgr::new_from_data, but that returns a detachedTypefacethatmatch_family_stylecan't find — Skia's default FontMgr only name-resolves installed system fonts. Everyfont-familypointing at a declared font silently fell back to Helvetica/Arial.Concretely: a scenario declaring
{ "family": "Anton", "source": "google" }and usingfont-family: "Anton"rendered in a generic system sans-serif — the download succeeded, the glyphs were wrong.Fix
family -> bytesregistry (first registration wins).typeface_with_fallbackresolves custom families from the registry first, building theTypefacefrom the bytes and caching it per render thread. The FontMgr isthread_local, so registering only on the main thread never reached the rayon render workers — resolving from shared bytes does.Before / after
Same scenario (a yellow block with
font-family: "Anton"):Verification
cargo test -p rustmotion-coregreen; new tests: registry stores-first-wins + serves bytes; a registered family resolves to its own typeface over the system fallback (uses the cached Anton TTF when present, skips on a cold cache — the render is the visual counterpart).cargo fmtclean, clippy 0 warnings.Scope / follow-up
One weight per custom family via this path (sufficient for accent/display faces). Multi-weight custom families (e.g. Inter 400+700 both declared) resolve to the first registered weight — a follow-up if needed.