Srijika: OpenType Layout - Reusing Font Restyling for Nine Indic Scripts

0. Abstract


Core	A system for generating installable Indic fonts by restyling template glyphs via retrieval-grounded latent diffusion.
Gap	Generative models produce images, not fonts; Indic scripts require complex, professionally-engineered shaping-engine contracts.
Approach	Restyles glyph outlines of shaping-complete templates while retaining original GSUB/GPOS layout machinery and using a defect-tolerant verification pipeline.
Result	Ships 66 TTFs across nine scripts; zero-shot SSIM gates range from 0.686 to 0.786, with cluster accuracy 0.981–1.000.

The Question — How can OpenType fonts for Indic scripts be restyled efficiently without generating them from scratch, while ensuring layout consistency and addressing data scarcity? [1]

Srijika is a system that produces installable OpenType fonts for nine Brahmic scripts. [1]
1. The scripts include Devanagari, Tamil, Bengali, Telugu, Kannada, Malayalam, Gujarati, Gurmukhi, and Odia. [2]
The system restyles glyph outlines of existing template fonts instead of generating fonts from scratch. [2]
1. This approach reuses the template's cmap and GSUB closure, as well as its GPOS data under a documented metric policy. [4]
2. This ensures that every output is a valid font by construction. [5]
Srijika ships 66 TTFs, including 57 curated presets and nine open-vocabulary showcase fonts. [5]
1. All fonts pass the OpenType Sanitizer. [6]
2. HarfBuzz and CoreText reproduce the template's glyph-ID sequences for conjunct-heavy probes on every font. [6]
3. A full-closure audit of 80,915 glyphs and 54,812 anchors quantifies every metric delta. [6]
Style selection uses natural language through Lipika, a retrieval index over approximately 650 open-license families. [7]
1. Lipika grounds a prompt in a concrete donor face. [7]
2. A reference-conditioned latent diffusion model redraws each template glyph in the donor's style. [8]
3. A content gate, harmonization pass, and shaped-cluster verify-and-repair loop revert any failing glyph to its template outline. [8]
Adding a new script requires approximately 20,000 to 48,000 steps with a warm-start graft recipe. [9]
1. Per-script routing avoids cross-script dilution caused by grafting. [9]
Evaluation is performed against no-learning baselines. [10]
1. On SSIM gates for diffusion-training-family-held-out data, unrestyled template copy outperforms generation on 50 of 56 faces. [10]
2. Style movement is only measurable with an internal, same-model embedding whose training corpus includes the held-out families. [11]
  1. The median gap closure is 0.05. [11]
  2. One out-of-distribution (OOD) family, Alkatra, reaches 0.85–0.94 closure, while seven others show minimal movement. [11]
3. A learned baseline, an independent style metric, and a human study are outside the scope of this report. [12]
The contributions include the formulation, the layout-reusing pipeline and its audit, a frozen nine-script ID/OOD benchmark, and a negative-results catalogue. [12]
1. The negative-results catalogue details six unsuccessful conditioning/objective levers. [13]
2. It also includes a forensic study of train-time objective contamination and a data-hull analysis of when reference-guided restyling fails. [13]

1. Introduction [14]

Brahmic scripts are read by over 800 million people, with India's 2011 Census alone recording over a billion mother-tongue speakers of scheduled languages written in them. [14] However, their typographic ecosystems are significantly smaller than Latin's. [15] For example, Google Fonts hosts over 1,800 Latin families but only six families for Odia script. [15]

Structural Gap in Indic Font Design [16]
1. A text-ready Indic font is a shaping-engine contract, not just a drawing exercise. [16]
2. It requires hundreds to thousands of conjuncts, half forms, and matra variants to be present and mutually consistent through OpenType substitution. [17]
3. This complexity multiplies the cost of every new design. [18]
4. Generative models are an obvious solution, but current approaches that generate glyph images fall short because an image of type is not a usable font. [18]
Srijika System Overview [20]
1. Srijika takes a natural-language style description and outputs an installable TTF for any of nine Brahmic scripts. [20]
2. It retains the template's substitution closure and reuses its positioning structure. [20]
3. The core design decision is to never generate a font from scratch. [21]
4. It restyles the complete glyph closure of a professionally-engineered open-license template font, tile by tile, using a reference-conditioned latent diffusion model. [21]
5. Outlines are rebuilt in place, so the template's GSUB machinery is reused unchanged. [22]
6. Its GPOS structure is reused subject to documented metric and anchor-coordinate transformations. [22]
7. Finite HarfBuzz and CoreText probes verify glyph-ID parity with the template. [23]
8. Visual positioning quality and exhaustive GPOS behavior are outside the current audit. [23]
Lipika for Style Control [24]
1. Style comes from Lipika, a retrieval index over approximately 650 open-license families. [24]
2. Lipika's embeddings ground open-vocabulary prompts in concrete reference glyphs. [24]
Defect-Tolerant Serving Pipeline [25]
1. The pipeline includes a content gate with a retry ladder, style harmonization, coherence capping, and shaped-cluster verification with per-glyph repair. [25]
2. This converts a model that is usually correct into a font where every glyph either passes verification or reverts to the template outline. [26]
Contributions of Srijika [26]
1. Template-layout-reusing restyling: The template's cmap and GSUB substitution closure are retained unchanged. [27]
  1. GPOS structure is reused subject to documented metric and anchor-coordinate transformations. [27]
  2. Layout is reused, not learned, which decouples restyling quality from layout logic. [28]
2. Retrieval-grounded styling (Lipika): Per-(family, script) CLIP-style embeddings convert free-text prompts into reference tiles. [29]
  1. This sidesteps the lack of Indic style-attribute datasets. [29]
3. A graft recipe for scaling one backbone to nine scripts: Training resumes from a shipped checkpoint with uniform pack concatenation. [30]
  1. An observation of dilution under sequential grafting showed that previously shipped scripts degrade relative to the donor. [30]
  2. Re-weighted sampling only relocates the loss, rather than removing it. [31]
  3. Per-script routing serves each script from the checkpoint that first passed its gate, avoiding shipped-script regressions. [31]
4. An evaluation protocol for generated Indic fonts: This includes family-held-out zero-shot gates with genre-matched splits, script bars, content probes, and a shaped-cluster critic. [33]
  1. A frozen two-strata (ID/style-OOD) benchmark with a diffusion-training-disjoint controlled checkpoint is used. [34]
  2. Benchmark families remain in Lipika's encoder and retrieval training corpus. [35]
  3. The headline finding is that OOD style transfer is strongly family-specific. [35]
5. A negative-results catalogue: This includes six unsuccessful lever families, a forensic study of train-time objective contamination, and a data-hull boundary. [36]
  1. These characterize failure modes under the architecture, critic, and training regime. [37]
  2. These are expected to recur in similar reference-guided glyph generators. [37]

2. Related Work [38]

Few-shot font generation [38]
1. Component- and style-disentangling generators (FUNIT, MX Font, DG-Font, CF-Font) and diffusion approaches (FontDiffuser) synthesize unseen glyphs from a few references. [38]
2. These methods primarily target Latin and CJK scripts. [39]
3. They emit rasters and do not address font assembly or the more complex shaping problem for Brahmic scripts. [39]
4. Srijika adopts their reference-conditioning insight but changes the deliverable. [40]
  1. The unit of generation is a tile in a template's glyph closure. [40]
  2. The output is an installable font by construction. [41]
Direct vector-font synthesis [41]
1. This parallel approach generates outlines natively in vector space. [41]
2. Examples include VecFontSDF, DualVector, VecFusion, and VecGlypher. [42]
3. These systems generate vectors natively and avoid a tracing stage. [43]
4. They target isolated glyphs, predominantly Latin/CJK. [43]
5. None addresses OpenType layout closure, which can exceed a thousand interdependent glyphs per face for Brahmic scripts. [44]
6. Srijika chose raster diffusion plus tracing because it composes with any template's closure out of the box. [44]
7. Swapping in a native vector generator per tile is compatible with the pipeline and an attractive upgrade path. [45]
Diffusion conditioning [45]
1. Srijika's generator is a latent diffusion model with reference cross-attention, similar to adapter-style conditioning. [45]
2. Forensic analysis contradicts the intuition that stronger decode-side content injection improves content fidelity. [46]
  1. All six unsuccessful levers targeted decode-side fidelity. [47]
  2. Evidence suggests training data coverage and objective hygiene are the binding constraints. [47]
3. A learned few-shot baseline (e.g., FontDiffuser) was not run, so this reading is scoped to Srijika's architecture. [48]
Font retrieval and attributes [49]
1. Attribute-based font selection and CLIP-based font embeddings (FontCLIP) are trained on Latin attribute data. [49]
2. These show reported zero-shot generalization to other scripts. [50]
3. No purpose-built Indic resource existed. [50]
4. Lipika fills this gap with per-(family, script) embeddings over an Indic corpus. [50]
  1. It uses a CLIP-LoRA tower for donor retrieval. [51]
  2. A family-recognizer backbone serves as the generator's style encoder and the critic's style metric. [51]
Indic text shaping [52]
1. Correct rendering of Brahmic scripts is codified in Unicode and implemented by HarfBuzz. [52]
2. Srijika relies on this in two ways: [53]
  1. Templates are chosen from fonts with professionally validated shaping. [53]
  2. The cluster critic reshapes generated fonts through HarfBuzz to check visual plausibility after restyling. [53]

3. Problem Setting: Nine Brahmic Scripts [54]

Brahmic scripts significantly increase the difficulty of font generation across three axes. [54]

Closure Size and Shaping [54]
1. A text-ready font is the layout closure of its script blocks, not just a set of codepoint glyphs. [55]
2. This includes conjunct ligatures, half forms, matra variants, and contextual substitutes reachable through GSUB. [55]
3. Closure sizes vary by an order of magnitude across scripts. [56]
  1. Mukta Mahee's Gurmukhi closure is 210 glyphs. [56]
  2. Baloo Da 2's Bengali closure is 1264 glyphs. [56]
4. Any generated font must maintain this machinery, or clusters will visibly break. [57]
Data Scarcity with Genre Skew [57]
1. The open-license corpus assembled spans approximately 650 families across nine scripts. [57]
2. Per-script family counts range from 250 (Devanagari) down to 7 (Odia). [58]
3. Display and decorative genres are almost absent outside the largest scripts, which are precisely the styles users request. [58]
Visual Regime [59]
1. Matras, stacked conjuncts, and headstrokes (śirorekhā) mean that per-glyph plausibility is insufficient. [59]
2. Errors only become apparent when shaped text is read as clusters. [59]
3. This motivates Srijika's cluster-level verification. [60]
Corpus Sourcing and Licensing [60]
1. The corpus is drawn from Google Fonts (OFL/Apache), SMC, and community foundries. [60]
2. Every training font, template, and donor is open-licensed. [61]
3. Generated fonts carry OFL-compliant renames, crediting their template. [61]

4. The Srijika System [61]

4.1. Template glyph replacement [62]

Key Mechanism — Srijika restyles existing template fonts by replacing individual glyph outlines, ensuring that the complex OpenType layout data is preserved and reused, rather than generated from scratch. [62]

Restyling Process [62]
1. Given a natural-language style description, Srijika does not synthesize a font from scratch. [62]
2. It restyles a curated, shaping-complete template font. [62]
3. For each glyph outline in the template's script closure, a generative model redraws the glyph in the target style. [63]
4. The new outline is traced back into the template's glyf table. [63]
Layout Data Preservation [63]
1. The cmap and GSUB lookup data of the template are retained unchanged. [63]
2. GPOS lookup structure and feature routing are retained. [64]
3. Anchors belonging to a translated outline are moved by the same vector. [64]
4. Pair-positioning values are retained according to a documented metric policy. [64]
Shaping Engine Decisions [65]
1. Because glyph selection is driven by cmap and GSUB, a shaping engine makes the same glyph-selection decisions for the output font as for the template. [65]
2. Visual quality of the restyled outlines is a separate question, handled by verification. [66]
Problem Transformation and Fallback [66]
1. This converts an open-ended font-engineering problem into a per-glyph image translation problem with a structural floor. [66]
2. A rejected glyph reverts to its professionally drawn template outline. [67]
3. Accepted generated outlines remain subject to the limits of the internal critic. [67]
Formal Process and Metric Policy [68]
1. Let T be the template with script glyph closure G(T) = {g1, ..., gn}. [68]
  1. G(T) is computed by subsetting with layout closure over the script's Unicode blocks. [68]
2. Let R = {r1, ..., r6} be six reference tiles rendered from a donor font carrying the target style. [68]
3. A conditional generator fθ(gi, R) produces a restyled raster tile for every gi. [69]
4. This tile is thresholded, vectorized, and re-inserted into the template's glyph slot. [70]
5. Metrics are derived from the template's, with a raster-space baseline alignment before vectorization. [70]
6. The advance widens only when the restyled outline is fatter. [71]
7. Ink falling left of the template's sidebearing floor is shifted right, with the glyph's GPOS anchors translated by the same vector. [71]
8. Pair-positioning values are retained unchanged. [72]
9. This policy keeps positioning data consistent with moved outlines. [72]
  1. It does not guarantee that every attachment remains visually appropriate for a redesigned stroke or terminal. [73]
  2. Anchor-to-ink and collision auditing are future work. [73]
10. Output advances differ from the template's only by these policy-defined widenings. [73]
  1. Measured extrema are not typographic safety bounds. [74]
11. One audited template per script was sufficient to reach fidelity gates. [75]
  1. This bounds layout-scale style transfer. [75]
12. Candidates are audited by glyph closure size and GSUB completeness. [75]
  1. Meera has 1153 glyphs for Malayalam. [76]
  2. Baloo Da 2 has 1264 glyphs for Bengali. [76]
  3. Mukta Mahee has 210 glyphs for Gurmukhi, which are structurally small due to few conjuncts. [76]

4.2. Lipika: grounding language in a donor font [77]

Open-vocabulary style control is handled by retrieval. [78] Lipika consists of two image models trained on the same Indic font corpus. [78]

Lipika's Recognizer Model [78]
1. The first model is a recognizer: a ConvNeXt-V2-tiny trained with a sub-center ArcFace head to identify font families from rendered glyphs. [78]
2. Its frozen penultimate features serve multiple purposes: [79]
  1. As the generator's style encoder. [79]
  2. As the serving critic's style judge. [79]
  3. As the embedding behind the closure metric. [79]
  4. This makes the closure metric a same-model measurement. [80]
Lipika's Language Grounding Model [80]
1. The second model grounds language: a CLIP-L text/image tower pair with a LoRA-adapted image tower. [80]
2. It is fine-tuned on rendered specimens of the corpus. [81]
3. It is indexed with one L2-normalized embedding per (family, script) face. [81]
4. A natural language description, such as "warm rounded friendly," retrieves a ranked list of donor faces. [82]
  1. This list can optionally be filtered by script. [82]
  2. The top face provides the six style-reference tiles. [82]

Srijika serving pipeline diagram

Figure 1: The Srijika serving pipeline. A prompt retrieves donor reference glyphs via Lipika; the diffusion model restyles the template’s glyph closure tile-by-tile; four verification stages gate, harmonize, snap, and shape-verify the result, each able to revert individual glyphs to the template outline (dashed) — so every glyph in an output font either passed verification or is the template outline, and the layout program is inherited. [85]

Training and Properties of the Language Grounding Model [88]
1. The tower is trained with a fused attribute-supervision stack. [88]
  1. Deterministic labels come from foundry metadata. [89]
  2. Measured stroke-contrast uses EDT ridge widths on rendered specimens, clamping VLM claims. [89]
  3. Two VLM annotation passes are performed over a 48-attribute vocabulary. [89]
2. The shipped checkpoint achieves a mean Spearman correlation of 0.50 between attribute-text similarity and gold labels on held-out families. [90]
3. Retrieval grounding offers two advantages over generation from text: [90]
  1. The style is always realizable because it exists as a font. [91]
  2. Licensing is auditable per donor. [91]

4.3. Reference-conditioned glyph diffusion [92]

Generator Architecture [92]
1. The generator is a latent-diffusion UNet with 134 million parameters (132.9 million UNet + 1.2 million style projection). [92]
2. It operates over 128 × 128 glyph tiles. [92]
3. The template glyph raster enters as a content channel at conv_in. [93]
4. Style is injected by cross-attention over pooled embeddings of the six reference tiles. [93]
  1. These embeddings are computed by the frozen Lipika recognizer backbone. [93]
  2. Only the 1.2 million-parameter projection onto cross-attention tokens is trained. [94]
5. Classifier-free guidance is enabled by token dropout at train time. [94]
6. Sampling uses a guidance scale of 3–4.5 and 50 steps. [94]
7. The same backbone, trained once and grafted per script, serves all nine scripts through per-script routing. [95]

4.4. Defect-tolerant serving pipeline [95]

Raw per-glyph generation is not shippable. [96] Srijika wraps it in four verification-and-repair stages, each with a template-fallback exit. [96]

Content Gate + Retry Ladder [97]
1. A retrieval-based content-identity critic checks if each generated tile still reads as its source glyph. [97]
2. Failing glyphs retry down a guidance ladder. [97]
3. Unrecoverable glyphs retain the template outline. [97]
4. The critic is a serve-time filter only; adding it as a train-time loss destroys training. [98]
Weight Harmonization with a Bounded Coherence Cap [99]
1. Per-glyph stroke-weight outliers (log ink-ratio deviations, MAD-scaled) are regenerated with direction-aware guidance ladders. [99]
  1. Thin outliers retry at higher guidance. [99]
  2. Thick outliers retry at lower guidance. [100]
2. A counter-fill guard (border flood-fill hole area) catches blobbed counters that erosion statistics miss. [100]
3. A blended-median coherence cap reverts any glyph to the template if it remains > 1.35× above the fleet median weight. [100]
4. The cap has bounded authority: if more than 25% of styled tiles are flagged, the heaviness is considered the style itself, and the cap stands down. [101]
Baseline Snap [102]
1. Per-glyph vertical jitter is canceled in raster space before vectorization. [102]
2. Row-profile cross-correlation against the content raster measures each glyph's vertical drift. [103]
3. The font-wide median drift is kept as style. [103]
4. The residual jitter adjusts the trace offset. [103]
5. Outlines enter the template's coordinate system already normalized. [104]
  1. No positioned outline is moved vertically afterward. [104]
  2. The template's anchor y-coordinates remain unchanged by baseline normalization. [104]
  3. The audit confirms ∆y ≡ 0 across all 54,812 anchors. [105]
6. Whether unchanged coordinates remain visually appropriate for redesigned ink is a separate question, evaluated only through the shaped-cluster critic so far. [105]
7. Horizontal sidebearing shifts occur in vector space and explicitly translate anchors. [106]
Shaped-Cluster Verify and Repair [107]
1. The assembled font is shaped with HarfBuzz over the script's cluster inventory. [107]
2. Clusters that no longer read correctly (content critic on the shaped raster) have their constituent glyphs greedily reverted to template outlines until the cluster reads again. [108]
3. Fleet-wide, this converges at a cluster accuracy of 0.981–1.000 with 7–110 reverted glyphs per font. [109]
4. A donor precheck measures the donor's bbox-normalized ink density and warns when it exceeds the training hull. [110]
5. OFL-compliant renaming credits the template. [110]

4.5. Parametric post-axes [111]

Shipped fonts expose three outline-space parametric axes applied directly to the TTF. [111]

Available Axes [112]
1. Weight [112]
2. Counter [112]
3. Em-fill [112]
These axes provide users with a small design space around each generated style without re-sampling the model. [112]

5. Training: One Graft Recipe, Nine Scripts [113]

5.1. Pair packs and curated splits [113]

Training Data Generation [113]
1. Training data is generated from the corpus itself. [113]
2. Within each family, (content, style) tile pairs are rendered. [114]
3. The content channel comes from the script's template. [114]
4. The target comes from a corpus font, over per-script shaping-aware unit inventories (aksharas, conjuncts, matra combinations). [114]
5. Packs per script range from approximately 8,000 to 300,000+ pairs across 7–250 families. [115]
6. A glyph-level auxiliary pack (single codepoints rendered per font) hardens coverage. [115]
7. A script-sniffing bug taught the importance of validating per-script Unicode ranges first. [116]
  1. Glyph-OK rates were 62–87% when correct. [116]
  2. Rates were 2–3% when silently falling back to Devanagari codepoints. [117]
Split Curation and the Modak Rule [117]
1. Split curation is more important than volume. [117]
2. The deployment policy, known as the Modak rule, keeps decorative/display families in the training split. [117]
  1. These families were unlearnable zero-shot in runs and depressed fresh-script baselines when placed in test. [118]
3. The Odia expansion provides a two-run demonstration: [118]
  1. With the decorative Alkatra family in test, the script gated at 0.6541 SSIM. [119]
  2. Its reconstruction grids looked structurally correct, and a normal-genre validation family scored 0.720. [119]
  3. Re-splitting Alkatra into train and a serif family into test, then retraining with the same recipe and initialization, yielded a 0.7622 zero-shot gate. [120]
    1. Both runs resumed the same v3.7 checkpoint, differing only in split membership. [121]
  4. The +0.108 delta is a benchmark-composition difference, not a like-for-like model improvement. [121]
    1. Test distribution and training membership both changed. [122]
4. An instrumented re-run of both conditions (Table 1) sharpens the reading. [122]
  1. For the held-out Alkatra family, generated Lipika gap closure is 0.866 (seed-stable at 0.866/0.861/0.867). [123]
  2. This compares to 0.009 for tile-space geometric transform and 0.008 for morphology. [124]
  3. The two-family OOD-condition macro is 0.450. [124]
  4. This closure is comparable to, not exceeding, the largest in-distribution family closure (0.98). [125]
  5. It occurs while SSIM falls below even template copy. [125]
  6. This provides qualitative support that the Alkatra case exhibits visibly larger local restyling and high internal Lipika closure, despite lower SSIM. [126]
  7. The in-distribution SSIM gate penalizes this case rather than rewards it. [127]
5. The epistemic status is noted: this is a post-hoc test-set change, applying a rule established earlier on Devanagari rather than tuned per script. [127]
  1. Both numbers are reported: 0.6541 with the decorative family held out (an out-of-distribution challenge set) and 0.7622 genre-matched. [128]
6. Operationally, the Modak rule is a split policy. [129]
  1. Scientifically, excluding difficult genres from test is not a satisfying evaluation design, as decorative styles are precisely what users request. [129]
7. This post-hoc Odia case motivates a controlled two-strata protocol with genre-matched and style-OOD families reported side by side. [130]
8. Table 1 records the historical Odia study. [131]
9. benchmark_v1 is the controlled nine-script realization. [131]
  1. It includes a versioned benchmark manifest with one decorative/display OOD family per script (Modak for Devanagari, Alkatra for Bengali and Odia, Akaya for Telugu and Kannada, Coiny, Chilanka, Shrikhand, Langar). [132]
  2. It also includes existing genre-matched ID families, templates, reference-selection rules, seeds, metrics, and SHA-256 hashes. [134]
  3. Section 7 reports the single-model two-strata evaluation on it (Table 5). [135]
10. Figure 3 shows the resulting held-out reconstructions. [135]

Condition	Held-out family	Faces	Gen SSIM	Tpl. copy SSIM	Morph SSIM	Geom SSIM	Gen Lipika closure	Geo Lipika closure	Morph Lipika closure
OOD (gen-v3.11)	Alkatra	5	0.6377	0.6997	0.6922	0.7101	0.866	0.009	0.008
	Lohit Oriya	1	0.7364	0.7619	0.7628	0.7325	0.034	0.020	-0.003
condition macro			0.6870	0.7308	0.7275	0.7213	0.450	0.014	0.002
Genre (gen-v3.11b)	Noto Serif Oriya	5	0.7689	0.7917	0.7903	0.7608	0.025	0.006	0.007
	Lohit Oriya	1	0.7290	0.7619	0.7628	0.7325	0.026	0.020	-0.003
condition macro			0.7490	0.7768	0.7766	0.7466	0.026	0.013	0.002

Table 1: Odia split-composition study, by held-out family. Two training runs with the same recipe and initialization (gen-v3.11 / gen-v3.11b, both resumed from v3.7), differing only in which family is held out. All methods under the instrumented protocol of Sec. 7: family-mean SSIM for generation, template copy, target-oracle morphology, and the reference-only tile-space geometric transform, plus family Lipika similarity gap closures for generation, geometry, and morphology. [136]

The OOD row shows qualitative support, not controlled validation. [143] SSIM ranks the visibly style-moving output below template-like structure, while neither tested baseline reproduces the movement. [143]

OOD condition qualitative results

Figure 2: The OOD condition, qualitatively. Top: the held-out Alkatra wght700 face under gen v3.11, rows labeled in-figure: template, target-oracle morphology, reference-only tile-space geometric transform, generated tiles, and the Alkatra ground truth. Morphology and geometry barely move from the template — consistent with their near-zero Lipika closures in Table 1 — while generation visibly adopts the donor’s heavy rounded style at a structural cost that SSIM penalizes. Bottom: a HarfBuzz-shaped specimen of a font assembled from the same held-out checkpoint and conditioning as the raster rows (gen-v3.11, seed 7, guidance 3, template Noto Sans Oriya wght400, the eval protocol’s six Alkatra-wght700 reference tiles): 210 of 562 closure glyphs passed the content gate and are restyled, the remainder revert to template outlines — the visible weight mixing is the pipeline’s honest OOD behavior, not a curated production preset. The artifact passes ots; SHA-256 03560c71c59f9614… in the supplement manifest. [145]

Zero-shot reconstruction of held-out Odia faces

Figure 3: Zero-shot reconstruction of held-out Odia faces (gen-v3.11b; Lohit Oriya and two Noto Serif Oriya weights). Each block shows, top to bottom: the template glyphs (model input content), the target-oracle morphology reference (template dilated/eroded to the target’s ink coverage), generated tiles conditioned on six reference glyphs from the unseen family, and the ground-truth target. Template and morphology are nearly indistinguishable; the generated row moves stroke weight, terminals, and contrast toward the target. [153]

5.2. Warm-start grafting [157]

Grafting Recipe [157]
1. Every script after the first three is added using the same recipe. [157]
2. Training resumes from the latest passing checkpoint (weights, optimizer, EMA). [157]
3. The new script's packs are appended to the mix by uniform concatenation. [158]
4. Training continues for a 20,000–48,000-step window with a cosine LR restart (peak ≈ 2.3×10−5, floor 0.05×). [158]
Performance and Efficiency [159]
1. New script quality tracks the donor checkpoint's competence. [159]
2. Gurmukhi and Odia entered at 0.7861 and 0.7622 zero-shot SSIM, respectively. [159]
  1. These scores were above several first-generation script baselines. [160]
3. Each script required approximately 7 GPU-hours on a single H100. [160]

5.3. Dilution under grafting and per-script routing [161]

Cost of Grafting: Dilution [161]
1. Grafting incurs a cost: when appended data is a large fraction of the mix (e.g., +42% for Malayalam+Gujarati), most previously shipped scripts degrade relative to the donor. [161]
2. This degradation occurs at both window lengths tested (Table 2). [162]
3. The degradation is not monotone in window length. [162]
  1. Tamil and Kannada partially recover between +20,000 and +30,000 steps, with Kannada reaching just above the donor. [163]
  2. A longer window is not a reliable fix. [163]
4. Re-weighted sampling only relocates the dilution (zero-sum) rather than removing it. [163]
5. This regularity is termed dilution, observed under one architecture, capacity, data order, and schedule, not a universal law. [164]
Response: Per-Script Routing [165]
1. The response is per-script routing: each script is served by the checkpoint that first passed its gate. [165]
  1. v3.7 for the first five scripts. [166]
  2. v3.8b for Malayalam/Gujarati. [166]
  3. v3.11b for Gurmukhi/Odia. [166]
2. Routing is an engineering choice, not a finding. [166]
  1. A shipped checkpoint is never updated, so it cannot regress. [167]
3. It costs one resident model per graft generation. [167]
4. The scientific question of a single model that adds scripts without dilution remains open. [167]

Script	v3.7 (donor)	v3.8 (+20k)	v3.8b (+30k)	v3.12 (+30k, wtd.)
Devanagari	0.7476	0.7458	0.7408	0.7408
Tamil	0.7570	0.7493	0.7532	0.7498
Bengali	0.7687	0.7558	0.7534	0.7587
Telugu	0.7691	0.7824	0.7790	0.7828
Kannada	0.6860	0.6714	0.6887	0.6803
Malayalam	—	0.7346	0.7401	0.7298
Gujarati	—	0.7022	0.7019	0.7024

Table 2: Dilution under grafting. Grafting Malayalam+Gujarati (+42% pairs, uniform sampling) onto gen-v3.7 (@120k) degrades most previously shipped scripts relative to the donor at both window lengths, while new scripts improve. [168]

The degradation is not monotone in window length, and re-weighted sampling only shifts mean SSIM by approximately 0 versus v3.8b, relocating damage to down-weighted scripts. [171] In these runs, dilution is zero-sum. [172]

6. Evaluation Protocol [172]

Zero-shot gates [172]
1. Each script holds out complete font families (not individual weights) as a test split, genre-matched per the Modak rule. [173]
2. During evaluation, the model restyles the script's template glyphs using six reference tiles from each held-out family. [173]
3. It scores SSIM between generated and ground-truth tiles over the script's unit inventory at guidance 3. [174]
4. Reference tiles are drawn from a disjoint subset of the unit inventory and are never among the scored targets. [174]
5. Table 3 reports means pooled over all generated tiles of the held-out faces. [175]
6. Tiles within a face and faces of one family are correlated, so pooled statistics overstate the effective sample size. [175]
  1. n is families: 2–4 per script. [176]
  2. Faces are 2–12. [176]
7. Table 3 also reports family counts and family-level macro averages. [176]
8. Appendix B reports every held-out face individually. [177]
  1. The design is balanced at 64 tiles per face, so the pooled mean equals the face-level macro-average. [177]
9. Template-copy and density-matched morphology references, and a reference-only geometric baseline, are scored on the same targets. [178]
10. This gate isolates reference-conditioned reconstruction under oracle donor references. [179]
  1. The donor is a real held-out font, removing prompt retrieval from the loop. [179]
  2. It neither bounds nor measures end-to-end prompt-to-font quality. [180]
  3. The end-to-end critic and designer review provide only partial evidence. [180]
  4. A controlled human evaluation of prompt-to-font output remains future work. [181]
Script bars [181]
1. A script's bar is the gate score of the first model that shipped it. [181]
2. No later model may serve a script below its bar (quality-over-cost rule). [182]
3. This turns every subsequent training run into a regression test across all shipped scripts. [182]
Content probes [183]
1. Two calibrated Latin display donors (Lobster: heavy-but-inside-hull; AlfaSlab: beyond-hull) probe content survival under aggressive styling. [183]
2. Metrics include initial wrong-glyph counts and template-fallback rates under the serving gate's retry ladder. [184]
End-to-end critic [184]
1. Shipped fonts are scored by donor style match (embedding cosine), legibility fraction, and shaped-cluster accuracy after repair. [184]
2. Specimens are additionally proofed visually. [185]

7. Results [185]

Script	Fam.	Faces	SSIM	Fam. macro	Tpl. copy	Morph	Geom	Serving model
Devanagari	3	12	0.7476	0.7371	0.7913	0.7919	0.7787	gen-v3.7
Tamil	2	3	0.7570	0.7674	0.7598	0.7628	0.6918	gen-v3.7
Bengali	2	4	0.7687	0.7694	0.7810	0.7781	0.7653	gen-v3.7
Telugu	4	8	0.7691	0.7542	0.7797	0.7972	0.8356	gen-v3.7
Kannada	2	11	0.6860	0.6980	0.7546	0.7545	0.7481	gen-v3.7
Malayalam	4	7	0.7401	0.7397	0.7816	0.7820	0.7991	gen-v3.8b
Gujarati	2	2	0.7019	0.7019	0.7260	0.7199	0.7245	gen-v3.8b
Gurmukhi	2	3	0.7861	0.7779	0.8041	0.8077	0.7736	gen-v3.11b
Odia	2	6	0.7622	0.7490	0.7867	0.7858	0.7561	gen-v3.11b

Table 3: Shipped zero-shot gate scores: an in-distribution, genre-matched operational gate (SSIM over held-out families, test split, guidance 3), read against three no-learning references — template copy, density-matched morphology, and the coherent reference-only geometric baseline — plus the per-script serving route. [186]

The table shows that the serving model for each script meets or exceeds its inherited bar. [189]

Zero-shot gates [190]
1. Table 3 reports the shipped matrix. [190]
2. Three regularities are observed: [190]
  1. Scores track test split genre composition more than script complexity. [190]
    1. Gurmukhi, added last, posts the highest score because its held-out faces are body-text designs inside the training hull. [191]
    2. Kannada's test split includes a display cut. [192]
  2. Held-out sets are small (2–4 families per script), and tiles within a face are correlated. [192]
    1. Family-level macro-averages are reported alongside pooled means. [193]
    2. Full per-face scores with p25 tails are in Appendix B. [193]
    3. Family macro averages move pooled means by at most ±0.015. [194]
      1. The largest movement occurs where a single family contributes 10 of 11 faces (Kannada). [194]
    4. With n=2–4 independent families per script, these are descriptive statistics, not estimates with useful confidence intervals. [195]
      1. Sampling-seed reruns with two additional diffusion seeds move pooled per-script means by at most 0.006 SSIM (Table 6). [196]
  3. Under these small descriptive test sets, the grafted scripts' (Malayalam through Odia) family-macro gate scores overlap the range of the original five under the identical protocol. [197]
Template-copy baseline and a target-oracle diagnostic [198]
1. The do-nothing baseline scores the unrestyled template glyph against the same held-out targets. [198]
2. It posts higher pooled SSIM than the model on every script (by 0.003–0.069) and on 50 of 56 held-out faces (Appendix B). [199]
3. A second no-learning reference, density-matched morphology, dilates or erodes each template glyph until its ink coverage exactly matches the target tile's. [200]
  1. It then scores the morphed tile. [201]
  2. This isolates how much of the SSIM gap is pure ink-coverage matching. [201]
4. It is a target-oracle diagnostic, not a comparable reference-conditioned baseline. [202]
  1. It reads each scored target's own ink coverage, which the generator never receives. [202]
  2. Its conditioning is six disjoint reference tiles. [203]
  3. Its per-tile morphs are independently tuned, so they need not assemble into a coherent font. [203]
5. It lands within ±0.018 of template copy on every script (Table 3) and above generated SSIM on 53 of 56 faces. [204]
  1. Density matching alone neither improves much on the raw template nor lets generation catch up on in-distribution targets. [205]
6. This is expected and diagnostic: most held-out faces are body-text designs structurally close to the professionally drawn template. [205]
  1. SSIM rewards that proximity more than it rewards style movement. [206]
7. On the Lipika style metric, generated tiles attain 0.14–0.67 pooled normalized similarity to the held-out face's six-reference centroid. [206]
  1. This compares to 0.06–0.17 for the unrestyled template under the same normalization (Appendix B). [207]
8. At the family level, the paired comparison separates the two questions and gives a sober magnitude. [208]
  1. Generated tiles sit closer to the reference centroid than the template on 18 of 23 held-out families. [209]
  2. The median Lipika similarity-gap closure is only 0.047 (IQR 0.016–0.133). [209]
    1. 8 families exceed 0.10. [210]
    2. 3 families exceed 0.25. [210]
    3. 1 family exceeds 0.5. [210]
    4. 5 families are negative (minimum −0.101). [210]
  3. Generation improves the internal Lipika style score on most held-out families. [211]
  4. The median family closes under 5% of the template-to-target similarity gap. [211]
  5. Large closures concentrate in a few families (Karla Tamil Upright 0.40, Meera Inimai 0.98, RIT TN Joy 0.26). [212]
  6. Template copy retains higher SSIM on 20 of 23 (Table 6). [212]
    1. The model moves style at some structural cost, typically by a small amount. [213]
9. These statistics are seed-stable. [213]
  1. Across three sampling seeds, the median closure is 0.047/0.054/0.047. [213]
  2. Counts above 0.10 and 0.25 are unchanged. [214]
  3. Exactly one near-zero family (Lohit Malayalam) flips sign. [214]
10. The morphology reference's style cosine tracks the template's within 0.08 on every family. [214]
  1. This style movement is not reproduced by the tested ink-coverage-matched morphology diagnostic. [215]
Coherent reference-only geometric baseline [215]
1. This third no-learning reference estimates one global parameter set from the six reference tiles alone. [215]
  1. Parameters include ink-bbox x/y scale (clamped to [0.8, 1.25]) plus one fractional morphological weight radius. [216]
  2. This is the same conditioning the generator receives. [217]
2. It applies this parameter set to every template tile. [217]
3. Structurally, it is competitive. [218]
  1. It exceeds generated SSIM on 17 of 23 families. [218]
  2. It exceeds template copy on 10 of 23 (pooled per script 0.69–0.84, Table 3). [218]
4. On style, it is not competitive. [219]
  1. Its median Lipika similarity-gap closure is 0.006 (IQR −0.004–0.027, maximum 0.218, none above 0.25). [219]
  2. Generation has a 0.047 median and 3 families above 0.25. [220]
  3. Generation out-closes it on 17 of 23 families (Table 6). [220]
5. The style movement diffusion delivers is not explained by global scale-and-weight geometry. [221]
  1. Richer parametric families (contrast, slant, per-stroke modulation) remain untested. [221]
6. Where a held-out face departs far from the template, the SSIM ordering flips (Meera Inimai: +0.043 over template copy, +0.039 over morphology, at style ratio 0.98). [222]
7. Table 3 is read through its baselines: the gates are in-distribution regression tests, meaningful for run-over-run comparison (bars, Table 2). [223]
  1. They are not evidence that generation out-reconstructs copying on typical body-text targets. [224]
  2. They are not a measure of open-vocabulary output quality. [224]
Controlled two-strata benchmark [225]
1. To remove the post-hoc confound of the Odia study (Table 1), one model was trained from scratch on the frozen benchmark_v1 manifests (gen-bench-v1). [225]
  1. This involved all nine packs uniformly concatenated, 168,000 steps, no resume, and no auxiliary losses. [226]
  2. Every script's ID, OOD, and validation families were simultaneously excluded from diffusion pair-pack training. [226]
  3. Both strata were evaluated under identical weights, references, seeds, and baselines (Table 5). [227]
2. Scope notes: [228]
  1. The OOD families were retrospectively selected (Alkatra's behavior was known before the manifest was written) and subsequently frozen. [228]
    1. This is controlled reproduction, not a preregistered discovery test. [229]
  2. Seed columns vary inference sampling only, and gen-bench-v1 is one training run (training-seed replication was not run). [229]
  3. The 168,000 step budget and final-checkpoint rule were fixed in the frozen manifest before training. [230]
  4. Test strata were never inspected during diffusion-model fitting or checkpoint selection. [231]
  5. gen-bench-v1 is a controlled research checkpoint for studying generalization to families held out of diffusion training, not the routed production model. [231]
3. Three findings: [232]
  1. The Alkatra case reproduces under control. [232]
    1. The same held-out multilingual Alkatra family produces high closure in both its Bengali (0.935) and Odia (0.853) script renderings. [233]
    2. These are correlated script-level observations of one style family, not independent family replications. [234]
    3. They are seed-stable, with geometry and morphology at ≤0.011, while SSIM stays below template copy. [234]
    4. The pattern of Table 1 is not an artifact of comparing two separately trained runs. [235]
  2. OOD style movement is family-specific, not category-general. [235]
    1. The other seven unique OOD families (Modak, Coiny, two Akayas, Chilanka, Shrikhand, Langar) close a median of 0.040 (range −0.034–0.062). [236]
    2. The decorative stratum is not uniformly transferable from six references. [237]
    3. Alkatra's heavy rounded style is the outlier the model imitates well, cautioning against generalizing any single OOD case. [237]
  3. Freezing both strata did not collapse in-distribution behavior. [238]
    1. The frozen model's 22 ID families post a closure median of 0.118 with SSIM−template deltas (median −0.023) matching the shipped models' band. [238]
    2. Direct ranking against the serving chain is confounded by different training budgets and mixes, so both are reported without ranking. [239]
4. One disjointness caveat applies to all closure numbers. [240]
  1. The exclusions cover diffusion training. [240]
  2. A family-membership audit finds all 30 benchmark families (and both Alkatra script renderings) inside the 595-family corpus that trained both Lipika image models. [240]
    1. This includes the CLIP retrieval tower and index, and the recognizer whose frozen features are the generator's style encoder and the closure metric's embedding. [242]
  3. The judge is a family-identity classifier trained to cluster the very families it scores. [243]
  4. The generator's conditioning pathway carries a learned representation of them. [244]
  5. Representational exposure through Lipika is not excluded, and closure remains an internal metric. [244]
  6. Evaluating with a benchmark-disjoint Lipika retrain and an independent style embedding is future work, as is any human evaluation. [245]
5. All 31 family rows, three seeds each, are in Table 5 and the supplement CSV. [246]
End-to-end generation [246]
1. A nine-prompt showcase run (one open-vocabulary prompt per script, retrieval-selected donors) produced nine installable fonts (Fig. 4). [246]
2. These fonts had shaped-cluster accuracy of 0.998–1.000 on every script and legibility fraction of 0.82–1.00. [247]
3. They restyled 101–681 template glyphs per font (the remainder were shaped-cluster-safe template outlines). [248]
4. This took 12–136 minutes on a single L4. [248]
5. Across the 57 shipped presets, the serving critic reports cluster accuracy of 0.981–1.000. [249]
6. Per-glyph repair reverts a median of approximately 8% of glyphs to the template on the hardest display donors. [249]
7. These reverts are concentrated in rare conjuncts where a fallback is visually preferable to a defect. [250]

[Figure] Generated font per script showcase

Figure 4: One generated font per script from a single showcase run, each rendered from its installable TTF with HarfBuzz shaping. Donors span native-script families (Amita, Ekushey Punarbhaba, Kumar One, Baloo Tamma 2, RIT Thaara) and system templates. The Tamil row (donor Oi, an ultra-black face at the data-hull edge, Sec. 8.3) visibly mixes restyled ultra-black glyphs with lighter template fallbacks — the defect-tolerant pipeline providing critic-mediated functional recovery at the cost of visible style consistency: evidence of fallback functionality, not of a coherent type family on this donor. [251]

Structural validation [256]
1. All 66 shipped TTFs (57 presets, nine showcase fonts) pass the OpenType Sanitizer (ots). [256]
  1. ots is the load-time gate Chromium and Firefox apply to web fonts. [257]
2. Layout inheritance was verified cross-engine. [257]
  1. On conjunct- and matra-heavy probe strings per script, HarfBuzz and Apple CoreText each produce glyph-ID sequences identical to the font's template for all 66 fonts. [258]
  2. There was no system-font fallback. [259]
3. A full-closure audit (every glyph of every font against its template: 80,915 glyphs, 54,812 anchors) quantifies the metric policy's actual footprint, split by provenance. [259]
  1. The 50,066 template-fallback glyphs carry exactly zero metric deltas. [261]
  2. Over the 30,849 accepted generated glyphs: [261]
    1. Advance deltas are p50 0.045 em, p95 0.358 em, maximum 1.93 em. [261]
    2. Per-script p95 ranges from 0.17–1.11 em, heaviest under Gujarati and Devanagari display donors. [262]
    3. There are zero narrowed advances closure-wide. [263]
    4. Accepted-glyph right-sidebearing |∆| reaches p95 0.142 em (max 1.98). [263]
    5. Outline-extrema p95 is 0.193 (max 0.889). [264]
    6. Anchor translations are purely horizontal (∆y identically zero on all 54,812 compared anchors, |∆x| p95 0.089 em, max 0.44) and track their outline's shift. [264]
  3. Defining the tail as a >0.35 em advance or right-sidebearing change, 1,617 accepted glyphs (5.2%) exceed it across 61 fonts. [266]
    1. These are dominated by i-matra width variants under display donors. [267]
    2. The supplement ships the per-glyph tail list and a SHA-256 manifest of artifacts, templates, and validation logs. [267]
  4. These are policy-defined widenings, not typographic safety bounds. [268]
4. A rendered-context audit of the tail addresses the gap directly. [268]
  1. Of the 1,617 tail glyphs, 248 are reachable in the shaped unit inventory. [269]
    1. The rest are feature-context width variants. [269]
  2. Rendering each reachable glyph in flanked shaped context at 12/24/48 ppem against its template as control finds zero clipping and zero line-fit blowups (advance ratio >2.5×). [270]
  3. There were 191 raw adjacent-ink overlaps, of which 187 also occur in the template (legitimate tight fit). [271]
  4. The remaining four generation-introduced overlap cases (in three fonts) were reverted to their template outlines. [272]
    1. The three fonts were rehashed and revalidated (ots 66/66 still passes). [273]
    2. The rendered audit was re-run clean. [273]
  5. Rendered auditing of the 1,369 feature-context only variants (84.7% of the tail) remains open beyond the shaped-cluster critic. [274]
    1. These are reachable only through GSUB lookup contexts outside the unit inventory. [275]
    2. This should precede any artifact freeze for a future human evaluation. [275]
5. FontBakery's universal profile reports the same metadata-policy findings on Srijika fonts as on professional templates. [276]
  1. It found exactly one generation-introduced defect class: the OFL rename step dropped font-specific name records (IDs ≥256) that the STAT table still references in fonts built on variable-font-instanced templates (Bengali, Kannada, Odia). [277]
    1. This yielded dangling-reference warnings. [279]
  2. The rename step now preserves those records, and the shipped files were repaired. [279]
    1. Only name records changed, so the outline/layout audit remains applicable. [280]
  3. The metadata-repaired release was rerun through ots and FontBakery. [280]
    1. ots passes 66/66. [281]
    2. The ttx-roundtrip failure class drops from 22 fonts to zero with no dangling STAT references. [281]
    3. Every remaining FontBakery finding class also occurs on the professional template controls. [282]
  4. This FontBakery comparison was run on the metadata-repaired release and was not repeated after the four outline reverts. [283]
    1. Those three fonts were re-validated with ots and the rendered-context audit only. [284]
    2. FontBakery findings describe their pre-revert outlines. [285]
  5. A SHA-256 manifest of the repaired artifacts, their templates, and the validation logs accompanies the supplement. [285]
6. Scope and versions: [286]
  1. ots 9.2.0. [286]
  2. HarfBuzz via uharfbuzz 0.56.0 and Apple CoreText on macOS 26.5. [286]
  3. Three conjunct- and matra-heavy probe strings per script. [287]
  4. FontBakery 1.1.0. [287]
7. These checks cover sanitizer acceptance, glyph-ID parity, and metric/anchor deltas. [288]
  1. They do not audit anchor-to-ink attachment quality, cross-glyph collision, or rasterized appearance. [288]
  2. The shaped-cluster critic audits rendered clusters, but only through HarfBuzz. [289]
Style axes [290]
1. Parametric post-hoc axes (outline offsetting for weight, signed-area counter scaling, em-fill scaling) apply bounded geometric restyling to finished fonts within calibrated safe ranges. [290]
  1. Weight offset: −40 to +80 font units. [291]
  2. Counter scale: 0.8–1.2. [291]
  3. Em-fill: 0.95–1.06. [291]
2. These axes result in zero shaped cluster breaks on calibration probes. [292]
3. They provide controllable weight and proportion variation that the diffusion model alone does not expose. [292]

8. Negative Results and Forensics [293]

One-third of this project's GPU budget was spent on levers that failed. [293] These are reported because the pattern they form, and the forensic method used to untangle them, is more transferable than any single positive result. [294]

8.1. Six tested-and-unsuccessful lever families [296]

Five levers targeted content fidelity under aggressive styling, especially with ultra-heavy display donors. [296] The sixth targeted the memory cost of per-script routing. [297]

Auxiliary content CE on the denoised latent [297]
1. This was a train-time classifier pressure toward glyph identity. [297]
2. It destroyed global training. [298]
Skeleton conditioning at conv_in [298]
1. A Zhang-Suen skeleton was used as a second content channel. [298]
2. The channel died. [299]
3. Because the skeleton is a deterministic function of the adjacent raster channel, it carries zero marginal information. [299]
4. A zero-initialized channel with redundant signal receives no sustained gradient while weight decay pulls it to equilibrium. [300]
  1. Final per-channel input norms were 4.25 (raster) vs 0.0125 (skeleton), a 340× gap (Fig. 5). [301]

Redundant conditioning dies graph

Figure 5: Redundant conditioning dies. Per-channel conv_in weight norms after 25k graft steps. The zero-initialized skeleton channel (v4.0) settles at weight-decay equilibrium because its signal is computable from the adjacent raster channel. Content-raster dropout (v4.1) makes the skeleton non-redundant and revives the pathway 17× — and heavy-donor probes still got worse, falsifying the structure-deficit hypothesis rather than the mechanism. [295]

5. ControlNet-style grafts work when the control input is not computable from existing inputs. <span class='source-play-button' data-idx='302' aria-label="Script" aria-label="Script">[302]</span> 6. A redundancy-breaking raster-dropout variant revived the pathway (<strong>17× norm recovery</strong>) but still failed gates. <span class='source-play-button' data-idx='303' aria-label="Script" aria-label="Script">[303]</span>

Multi-scale content adapter [304]
1. FontDiffuser-style injection was used at every down-block. [304]
2. The mechanism verifiably works: adapter head norms were alive at all four scales, and structure flowed with the raster channel blanked. [305]
3. However, gates did not improve. [305]
4. Conditioning richness was not the binding constraint. [306]
Weight-domain target augmentation [306]
1. Consistent dilation/erosion of target+refs was used to extend the weight range. [306]
2. Gates remained flat. [307]
Self-supervised contrastive style loss [307]
1. This involved predicting the reference embedding from the noised target, properly hinged per-sample. [307]
2. It taxed fidelity below bars and yielded zero blackness gain. [308]
Per-pack weighted sampling [308]
1. This aimed to unify routing by re-weighting old scripts to their pre-graft share. [308]
2. The first two runs collapsed, a verdict later voided when both proved to carry the contaminating auxiliary loss of (1). [309]
3. A clean isolation (identical recipe minus the auxiliary term) trained healthily and landed 2/7 gates. [310]
  1. Mean SSIM shift versus uniform concatenation over the same window was approximately 0. [311]
  2. Dilution relocated to whichever scripts lost share (Malayalam, squeezed from its 19% natural share to 13%, paid −0.010). [311]
4. Weighted sampling is not toxic; it is zero-sum. [312]
  1. At this model capacity and window length, no share vector clears seven bars simultaneously. [312]
  2. Routing (Sec. 5) remains the architecture by controlled evidence rather than by default. [313]

Lever	Attack surface	Mechanism	Deva SSIM	AlfaSlab fb
v3.6 baseline	—	—	0.7445	54%
Aux content CE	objective	✓	0.553†	—†
Skeleton ch. (v4.0)	input cond.	× (dead)	0.7366	56%
+ raster drop (v4.1)	input cond.	✓	0.7403	67%
Multi-scale (v5.0)	decoder cond.	✓	0.7363	59%
Weight aug (v5.1)	data (synth)	✓	0.7214	64%
Oversample (v5.2)	data (balance)	✓	0.7354	54%
SCR unhinged (v5.3)	objective	✓	0.6713	86%
SCR hinged (v5.4)	objective	✓	0.6882	53%

Table 4: Six tested-and-unsuccessful lever families. Mechanism = did the lever verifiably do its job (channel alive, aug applied, loss learning)? Deva = SSIM on the deva test split under the protocol of record (bar 0.7445). AlfaSlab fb = template-fallback rate on an out-of-hull ultra-black donor (baseline 54%). [314]

Every working mechanism either left the fallback rate unchanged or made it worse, while five of eight broke the in-hull gate. [319] The aux-CE row predates the protocol of record and the AlfaSlab probe; its contemporary deva baseline was 0.729, so 0.553 is a 24% collapse. [320] It was the only lever that cut content errors (Lobster fallbacks 157 → 48) by pulling outputs toward classifier centroids, destroying style. [321] v4.0's mechanism check failed (skeleton channel norm 0.0125, 340× below siblings), which is itself the finding. [322]

The pattern arguing against the conditioning hypothesis is the conjunction of the two right-hand columns in Table 4. [323] In every row, the mechanism check passes, but the extreme-donor fallback rate never improves on the 54% baseline. [324] Five of eight variants pay for the attempt with a broken deva gate. [325]

The convergent lesson is that levers (1)–(5) attacked conditioning and objectives, but the model was never asked to draw glyphs beyond its target distribution. [326] The failure lies in the data hull (Sec. 8.3), and none of the tested conditioning levers extrapolated a weight regime absent from targets. [327]

8.2. The aux-loss contamination study [328]

Contamination Incident [328]
1. A train-time content-identity loss (weight 0.1), previously only a serve-time filter, was carried into four consecutive training launches due to a misreconstructed launch configuration. [328]
2. All four collapsed with a consistent signature: [330]
  1. Uniform cross-script SSIM collapse (0.13–0.19 below bars on all seven scripts at once). [330]
  2. Systematic boldening (generated/target ink ratio 0.963 → 1.036). [331]
  3. Style washing. [331]
  4. Validation panels, reconstruction grids, and the loss curve all looked healthy. [331]
Forensic Investigation [332]
1. Controlled reruns cleared three plausible culprits: [332]
  1. A sampler-free run collapsed identically (not the new sampler). [332]
  2. A byte-exact rerun of a passing recipe collapsed (not the window or schedule). [333]
  3. Re-evaluating unchanged checkpoints reproduced their historical scores to four decimals (not environment drift). [333]
2. The experiment tracker resolved it: diffing the logged config of passing and failing runs isolated a single delta (content_ckpt). [334]
3. The diffusion-term loss at the resume step instantly separated the regimes (Fig. 6). [335]
  1. 0.0010 clean vs 0.0066–0.0090 polluted. [335]
  2. The gap is the auxiliary term. [336]

Objective contamination loss fingerprint

Figure 6: Objective contamination has an instant loss fingerprint. Four runs resume the same gen-v3.7 checkpoint at step 120k with the same LR schedule; the only difference is a train-time content-identity CE term (weight 0.1). Contaminated runs (red/orange) sit 6–8× above the clean diffusion-loss regime from the first logged step and never rejoin it; clean runs (blue/green) overlap almost exactly. Gates would not reveal the failure until ∼7 GPU-hours later. [309]

4. Gates would not reveal the failure until approximately <strong>7 GPU-hours later</strong>. <span class='source-play-button' data-idx='337' aria-label="Script" aria-label="Script">[337]</span> 5. A clean relaunch passed its gates on the first try. <span class='source-play-button' data-idx='337' aria-label="Script" aria-label="Script">[337]</span>

Operational Lessons [338]
1. Never add a train-time loss term absent from the last passing run's logged config; diff configs before launching. [338]
2. Uniform cross-script collapse with healthy panels and systematic boldening indicates objective-function contamination, not data, sampling, or environment. [339]
3. The experiment tracker's per-run config and environment snapshot are the forensic record of truth; a launch reconstructed from memory is not a record. [340]

8.3. The data-hull boundary [341]

Ink Density Measurement [341]
1. Per-font median bbox-normalized ink density was measured over all 278 Devanagari training faces. [341]
  1. Complete families; multi-weight families contribute several faces (Fig. 7). [342]
2. Results: p50 0.366, p90 0.518, p99 0.616, maximum 0.732 (Modak, the blackest real Indic font in the corpus). [342]

Data hull graph

Figure 7: The data hull. Per-font median bbox-normalized ink density of all 278 Devanagari training faces, ranked. The beyond-hull probe donor AlfaSlab (0.757) is blacker than every training target including Modak (0.732); its 54% content-gate fallback rate was immovable under all six unsuccessful levers. Lobster (0.543, ≈p90) sits inside the hull and restyles with 11% fallback. [341]

Beyond-Hull Probes [343]
1. Under the same metric, the ultra-black Latin donor AlfaSlab measures 0.757, which is beyond every training target. [343]
2. AlfaSlab exhibits a structural 54–59% content-gate fallback rate under every lever in this section. [344]
3. Lobster at 0.543 (approximately p90) mostly works (11% fallback). [345]
Serving System Response [345]
1. The serving system ships the boundary rather than pretending to cross it. [345]
2. A donor ink-density precheck bands each request (normal / heavy / hull edge / beyond-hull) with calibrated expected-fallback warnings. [346]
Hypothesis and Limitations [347]
1. Under this reading, and limited to the architecture, critic, and levers tested, crossing the hull points to targets that do not exist in open-license Indic typography. [347]
  1. This suggests commissioned glyph sheets are needed, rather than the modeling levers tried. [349]
2. The hull is framed as the best-supported hypothesis, not a demonstrated cause. [349]
  1. Evidence is a single scalar (ink density) and two Latin probe donors. [350]
  2. AlfaSlab (0.757) exceeds the blackest training face (0.732) only modestly. [350]
  3. Explanations at other levels (backbone capacity, critic calibration, tile resolution, or the Latin-to-Indic donor gap itself) are not excluded. [351]
3. A density-banded multi-donor study would be needed to map the boundary's actual shape. [352]

9. Limitations [353]

Data Hull Inheritance [353]
1. Srijika inherits the data hull: donors whose ink density exceeds the blackest training faces degrade to template-heavy output. [353]
2. Under the best-supported hypothesis, the remedy is data acquisition rather than the modeling levers tested. [354]
3. Modeling-side explanations (capacity, critic calibration, tile resolution, the donor-script gap) are not excluded. [355]
Glyph-Local Style Transfer [355]
1. Style transfer is glyph-local. [355]
2. Donor identities carried by layout-scale features (extreme width, connected-script joins, baseline dance) transfer weakly, even when per-glyph quality is high. [356]
  1. Donor match cosine is 0.24–0.41 on such donors versus 0.61–0.99 on weight/contrast-driven styles. [357]
  2. This is because six reference tiles cannot encode what is not visible at tile scale. [357]
3. A library of structurally diverse audited templates per script (wide, condensed, high-contrast), matched to the donor before restyling, could recover some of this. [358]
  1. This would come at the cost of re-grafting, as the content channel's distribution is tied to the training template. [359]
Per-Script Routing vs. Unified Model [360]
1. Per-script routing trades memory for regression-safety. [360]
2. A unified single model remains an open challenge. [360]
  1. Weighted sampling trains cleanly but reallocates dilution zero-sum. [361]
  2. Larger capacity, continual-learning regularization (e.g., EWC), per-script adapters over a frozen shared backbone, or mixture-of-experts capacity are natural next levers, none yet run through the falsification protocol. [361]
Font Features [363]
1. Generated fonts reuse the template's kerning and mark-attachment data (subject to the anchor-translation policy of Sec. 4). [363]
2. They ship unhinted. [364]
3. Parametric axes operate on outlines rather than variable-font deltas. [364]
Evaluation Gaps [365]
1. Prompt quality: Gates measure fidelity to held-out real fonts under oracle references, isolating the reconstruction component. [365]
  1. They neither bound nor measure open-vocabulary prompt quality, for which designer review rounds are relied upon. [366]
  2. The prompt interface (retrieval) is validated only by an attribute-label Spearman of 0.50 (Sec. 4). [366]
  3. A retrieval evaluation against designer-labeled prompts and a paired human preference study (generated vs. geometric vs. template fonts) are missing evidence and remain future work. [367]
2. Learned baselines: All baselines are no-learning references. [369]
  1. A learned few-shot generator (FontDiffuser, MX-Font, CF-Font, DG-Font) trained on the same pair packs and scored under the same gate protocol is the comparison that would make claims about binding levers falsifiable. [369]
3. Within-font coherence: On heavy display donors, the shipped output is a functional font, not a coherent type family. [371]
  1. Restyled and fallback glyphs visibly mix (Fig. 4, Tamil row). [372]
  2. Fallback rates are reported, but a within-font coherence statistic (e.g., stroke-weight dispersion) per preset is not yet reported. [372]

10. Conclusion [373]

Srijika demonstrates prompt-guided restyling of template-layout-reusing fonts across nine Brahmic scripts, shipped as installable TTFs. [374] This is achieved not by solving font generation generally, but by choosing a formulation where layout-table structure is reused from existing professional engineering. [374]

Key Design Principles [375]
1. Layout-table structure is reused, subject to documented metric and anchor-coordinate transformations. [375]
2. The learned component is confined to local visual restyling under reference conditioning, which diffusion models are demonstrably good at. [376]
Effective Levers [377]
1. System-level levers that mattered were all data and protocol-related. [377]
  1. Genre-matched splits. [378]
  2. Graft-with-routing. [378]
  3. Defect-tolerant serving. [378]
2. Model-level levers mostly did not work, and the reasons are documented. [378]
Future Impact [379]
1. The negative-results catalogue and data-hull analysis are expected to save others GPU cycles. [379]
2. The shipped nine-script system, with its 57 presets and open evaluation protocol, is hoped to become a baseline for typographic generation in underserved scripts. [380]

Ethics and Licensing [381]

Licensing of Resources [381]
1. Every training font, template, retrieval-index entry, and donor is distributed under the SIL Open Font License or Apache 2.0. [381]
2. Generated fonts are derivatives of their template font. [382]
  1. The template's license is retained. [382]
  2. Renaming follows OFL Reserved Font Name requirements. [382]
  3. Attribution to the template family is embedded in the output's name table. [383]
3. No proprietary or scraped fonts were used at any stage. [383]
Ethical Considerations [384]
1. Generated fonts are synthetic derivatives and should not be represented as the work of the original designers. [384]
2. The system is designed to expand, not displace, thin typographic ecosystems. [385]
3. Only open-licensed outputs are released. [385]

Code and Data Availability [386]

Included with this version (arXiv ancillary files) [386]
1. The frozen benchmark_v1 manifest. [386]
2. The per-face, per-seed evaluation CSV for every method (with the six reference-tile indices per face). [386]
3. The per-glyph metric-tail list and its rendered-context audit. [387]
4. The SHA-256 manifest of all 66 shipped fonts, the nine geometric-baseline fonts, their templates, and the validation logs. [387]
5. The human-evaluation protocol sketch. [388]
Publicly Available Now [388]
1. The Lipika recognizer and retrieval code (https://github.com/Loopdesk-AI/lipika). [388]
2. Recognizer weights (https://huggingface.co/loopdesk-ai/lipika). [389]
3. The recognizer evaluation set (https://huggingface.co/datasets/loopdesk-ai/lipika-eval). [389]
Not Included with this Version (Scheduled for Later Release) [390]
1. The Srijika generator, serving pipeline, and evaluation implementation (including the geometric baseline). [390]
2. The generated font files themselves, for which the ancillary manifest carries hashes only. [391]

Just add sources; your living note is ready

Fully trustworthy notes with source links

A variety of notes tailored to your goals

AI chat grounded in your uploaded sources

Deep Search that finds trustworthy sources