PaperlayerView exact revision on arXiv

Source-linked AI summary

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

Anil Pai

arXiv:2609.05661v1cs.CVcs.GRcs.LG

TL;DR

Brahmic font generation must preserve large, interdependent OpenType shaping closures, not just produce glyph images. Srijika restyles template glyphs using retrieved references while reusing template layout structures. On held-out faces, template copying outscored generation on pooled SSIM and on most faces.

  • Problem

    Brahmic fonts require large, mutually consistent GSUB closures, while generative glyph images alone do not provide an assembled, text-ready font.

    Source: §1 · p. 1, §3 · p. 3

  • Method

    Srijika redraws glyphs in a shaping-complete template closure, reuses its layout structures, and uses Lipika retrieval to supply style references for diffusion.

    Source: §1 · p. 2, §4.1 · p. 4

  • Results

    Template copying scored higher pooled SSIM than the model on every script by 0.003–0.069 and on 50 of 56 held-out faces.

    Source: §7 · p. 12

  • Takeaways & Limitations

    Srijika demonstrates prompt-guided restyling as installable TTFs across nine Brahmic scripts by reusing existing layout-table structure and confining learned generation to local visual restyling.

    Source: §10 · p. 20

    The fidelity gates use oracle references and do not measure open-vocabulary prompt quality; a learned baseline, independent style metric, and human study are outside the report’s scope.

    Source: §9 · p. 20

Abstract

from arXiv · show

We present Srijika, a system for producing installable OpenType fonts for nine Brahmic scripts: Devanagari, Tamil, Bengali, Telugu, Kannada, Malayalam, Gujarati, Gurmukhi, and Odia. Rather than generating fonts from scratch, Srijika restyles glyph outlines from shaping-complete template fonts. It preserves the template's cmap and GSUB closure and its GPOS data under a documented metric policy, making every output a complete font by construction. This addresses a central challenge of Indic font generation: hundreds to thousands of conjuncts, half forms, and matra variants must remain mutually consistent under OpenType shaping. Srijika produces 66 TTFs: 57 curated presets and nine open-vocabulary showcase fonts. All pass the OpenType Sanitizer, while HarfBuzz and CoreText reproduce the template glyph-ID sequences on conjunct-heavy probes. A full-closure audit covering 80,915 glyphs and 54,812 anchors quantifies metric changes. Natural-language style selection uses Lipika, a retrieval index over approximately 650 open-license font families. A reference-conditioned latent diffusion model redraws template glyphs in the selected style, followed by content gating, harmonization, and shaped-cluster verification with fallback to template outlines. We evaluate against no-learning baselines. On diffusion-training-family-held-out SSIM gates, template copying outperforms generation on 50 of 56 faces. Style movement is measurable only with an internal same-model embedding whose training corpus includes the held-out families, so these results require caution. A learned baseline, independent style metric, and human study are outside this report's scope. Our contributions are the layout-reusing formulation and pipeline, its nine-script audit and benchmark, and a negative-results catalogue covering failed conditioning, objective choices, and data-hull limits of reference-guided restyling.

1 Introduction

Indic font generation must preserve large, interdependent OpenType shaping closures, not just produce appealing glyph images. Srijika reuses template layout structures and combines retrieval-grounded restyling with an evaluation protocol and a catalogue of negative results.

1 Introduction

  • Hundreds to thousands of conjuncts, half forms, and matra variants must remain mutually consistent under OpenType shaping, making text-ready font generation a structural challenge.An image of type alone is not a usable font.Source: §1 · pp. 1–2
  • Srijika restyles complete template glyph closures while retaining cmap and GSUB unchanged and reusing GPOS subject to documented transformations.Finite HarfBuzz and CoreText probes check glyph-ID parity; visual positioning quality and exhaustive GPOS behavior remain outside the audit.Source: §1 · p. 2
  • Lipika uses per-family, per-script embeddings to turn free-text prompts into reference tiles, addressing the lack of Indic style-attribute datasets.Source: §1 · p. 2
  • Under sequential grafting, previously shipped scripts degrade relative to the donor, while re-weighted sampling relocates rather than removes dilution in the reported runs.Per-script routing avoids shipped-script regressions because shipped checkpoints are not updated.Source: §1 · p. 2
  • The evaluation protocol uses family-held-out gates and a diffusion-training-disjoint controlled checkpoint, and reports that OOD style transfer is strongly family-specific.Benchmark families remain present in Lipika’s encoder and retrieval training corpus.Source: §1 · p. 2
  • The paper catalogues six unsuccessful lever families, train-time objective contamination, and a data-hull boundary under its architecture, critic, and training regime.Recurrence in similar generators is expected, but not shown.Source: §1 · p. 2

2 Related Work

Prior font-generation approaches often synthesize rasters or isolated vectors without assembling a font or preserving Brahmic OpenType layout closure. Srijika adopts reference conditioning but changes the deliverable to a template-closure font, while its comparisons remain scoped to the tested architecture and setting.

Few-shot font generation

  • Few-shot generators synthesize unseen glyphs from a few references, but typically emit rasters and leave font assembly—and Brahmic shaping—out of scope.The paper adopts reference conditioning while generating tiles within a template’s glyph closure.Source: §2 · p. 3

Direct vector-font synthesis

  • Native vector generators avoid tracing but target isolated glyphs, predominantly Latin or CJK, and do not address OpenType layout closure for Brahmic scripts.The paper says raster diffusion plus tracing composes with template closure, while a native vector generator per tile remains a compatible upgrade path.Source: §2 · p. 3

Diffusion conditioning

  • The tested conditioning forensics found all six unsuccessful levers attacked decode-side fidelity, with evidence pointing to training-data coverage and objective hygiene as constraints in this setting.No learned few-shot baseline was run on the pair packs, so this is not yet a comparative claim.Source: §2 · p. 3

Font retrieval and attributes

  • Lipika fills the stated lack of a purpose-built Indic resource with per-family, per-script embeddings over an Indic corpus for donor retrieval and style encoding.Prior attribute-based and CLIP-based font embeddings described here were trained on Latin attribute data.Source: §2 · p. 3

Indic text shaping

  • Srijika relies on HarfBuzz for Indic text shaping and uses a cluster critic to check whether shaped clusters remain visually plausible after restyling.Templates are selected from fonts whose shaping is professionally validated.Source: §2 · p. 3

3 Problem Setting: Nine Brahmic Scripts

Brahmic font generation is difficult because large shaping closures, uneven data availability, and script-specific visual structures all matter. Errors that seem acceptable glyph by glyph can become apparent when shaped text is read as clusters.

Closure size and shaping

  • A font’s GSUB-reachable closure includes conjunct ligatures, half forms, matra variants, and contextual substitutes; closure sizes range from 210 to 1264 glyphs in the examples given.Mukta Mahee’s Gurmukhi closure has 210 glyphs, while Baloo Da 2’s Bengali closure has 1264.Source: §3 · p. 3

Data scarcity with genre skew

  • The assembled open-license corpus spans about 650 families across nine scripts, but per-script counts range from 250 for Devanagari to 7 for Odia.Display and decorative genres are nearly absent outside the largest scripts.Source: §3 · p. 3

Visual regime

  • Matras, stacked conjuncts, and headstrokes make per-glyph plausibility insufficient; errors may surface only when shaped text is read as clusters.This motivates cluster-level verification.Source: §3 · p. 3

Corpus and licensing

  • The corpus is drawn from Google Fonts, SMC, and community foundries, and the stated fonts, templates, and donors are open-licensed.Generated fonts carry OFL-compliant renames crediting their template.Source: §3 · pp. 3–4

4 The Srijika System

Srijika restyles a shaping-complete template rather than generating a font from scratch, retaining its layout machinery while changing glyph outlines. Retrieval supplies style references, diffusion generates tiles, and verification and repair protect the output.

4.1 Template glyph replacement

  • Template replacement redraws each glyph in the script closure and retains cmap and GSUB lookup data, while reusing GPOS structure under a documented metric policy.Rejected glyphs revert to the template outline; shaping-engine glyph-selection decisions therefore match the template’s by construction, with verification treating visual quality separately.Source: §4.1 · p. 4

4.2 Lipika: grounding language in a donor font

  • Lipika retrieves donor faces from natural-language descriptions using per-family, per-script embeddings, and the top face supplies six reference tiles.Its recognizer also supplies the generator’s style encoder and the serving critic’s style judge; the caption depicts retrieval feeding the restyling and verification pipeline.Source: §4.2 · pp. 4–5, Figure 1 · p. 5

4.3 Reference-conditioned glyph diffusion

  • A latent-diffusion UNet takes the template glyph raster as content and injects style through cross-attention over embeddings of six reference tiles.The described model has 134M parameters, with only the 1.2M-parameter style projection trained.Source: §4.3 · p. 5

4.4 Defect-tolerant serving pipeline

  • Serving uses content checks with retries, weight harmonization, baseline snapping, and shaped-cluster repair, with template-outline fallback available for glyphs.Cluster accuracy reaches 0.981–1.000 with 7–110 reverted glyphs per font; the weight cap stands down when more than 25% of tiles are flagged.Source: §4.4 · pp. 5–6

4.5 Parametric post-axes

  • Shipped fonts expose weight, counter, and em-fill axes applied directly to the TTF, without re-sampling the model.Source: §4.5 · p. 6

5 Training: One Graft Recipe, Nine Scripts

Srijika’s training recipe builds script-specific data packs, curates family splits, and warm-starts new scripts from passing checkpoints. The experiments report strong zero-shot entry results alongside a dilution trade-off when grafting additional scripts.

5.1 Pair packs and curated splits

  • Decorative/display families remained in training after they proved unlearnable zero-shot and depressed fresh-script test baselines; the Odia study reports both OOD and genre-matched conditions.The +0.108 SSIM difference compares different training and test family membership, not a like-for-like model improvement.Source: §5.1 · pp. 6–7
  • For held-out Alkatra, generated Lipika closure was 0.866 versus 0.009 for geometry and 0.008 for morphology; the two-family OOD macro was 0.450.This OOD case is qualitative support, not controlled validation: SSIM penalizes visible style movement that the tested baselines do not reproduce.Source: Table 1 · p. 7, §5.1 · p. 7

5.2 Warm-start grafting

  • Gurmukhi and Odia entered at 0.7861 and 0.7622 zero-shot SSIM, above several first-generation script baselines, for ∼7 GPU-hours each on one H100.Held-out Odia examples show generated tiles moving stroke weight, terminals, and contrast toward targets, while template and morphology rows are nearly indistinguishable.Source: §5.2 · p. 9, Figure 3 · p. 9

5.3 Dilution under grafting and per-script routing

  • Adding Malayalam+Gujarati (+42% pairs) degraded most previously shipped scripts at both window lengths; reweighted sampling relocated rather than removed the loss.Tamil and Kannada partly recover from +20k to +30k, so longer training is not a reliable fix; per-script routing costs one resident model per graft generation.Source: Table 2 · p. 10, §5.3 · p. 10

6 Evaluation Protocol

The evaluation tests reference-conditioned reconstruction on held-out font families and separately probes shipped fonts with an end-to-end critic. Its gates provide regression comparisons, but do not establish prompt-to-font quality or that generation beats copying on typical body-text targets.

6 Evaluation Protocol

  • Each zero-shot gate holds out complete font families, conditions on six reference tiles, and scores SSIM over the script’s unit inventory against ground-truth tiles.Reference tiles come from a disjoint inventory subset; pooled tile statistics can overstate effective sample size, so the protocol also reports family counts and family-level macro-averages.Source: §6 · p. 10
  • The gates use real held-out donor fonts and therefore neither measure nor bound end-to-end prompt-to-font quality; controlled human evaluation remains future work.Designer review and the end-to-end critic provide only partial evidence for that setting.Source: §6 · p. 11
  • The end-to-end critic scores shipped fonts on donor style match, legibility, and shaped-cluster accuracy after repair, with specimens also visually proofed.Two calibrated Latin display donors probe content survival under aggressive styling.Source: §6 · p. 11

7 Results

Across shipped gate tests, template copying generally retains higher SSIM than generation, while controlled out-of-distribution style transfer is family-specific. Showcase fonts are installable and pass shaped-cluster checks, with visible fallback trade-offs and audited metric changes.

7 Results

  • Template copy scores higher pooled SSIM than generation on every script by 0.003–0.069 and on 50 of 56 held-out faces.Table 3 presents shipped zero-shot gate scores against no-learning references.Source: Table 3 · p. 11, §7 · p. 12
  • Gurmukhi's highest gate score tracks body-text held-outs inside the training hull, while Kannada's split includes a display cut; family macro-averages shift pooled means by at most ±0.015.With 2–4 independent families per script, these are descriptive statistics; grafted scripts' family-macro scores overlap the original five's range.Source: §7 · pp. 11–12
  • Generated tiles sit closer to the reference centroid than template copy on 18 of 23 held-out families, but median Lipika similarity-gap closure is 0.047.Template copy retains higher SSIM on 20 of 23 families; Geom's median closure is 0.006 versus generation's 0.047.Source: §7 · p. 12
  • Among seven unique OOD families beyond Alkatra, median style-gap closure is 0.040 (range −0.034–0.062), while Alkatra reaches 0.935 for Bengali and 0.853 for Odia.All benchmark families occur in the corpus used to train Lipika and the style embedding, so closure remains an internal metric.Source: §7 · p. 13
  • Nine showcase fonts reached 0.998–1.000 shaped-cluster accuracy and 0.82–1.00 legibility, though Tamil's Oi output visibly mixes ultra-black glyphs with lighter fallbacks.The showcase restyled 101–681 template glyphs per font in 12–136 minutes on one L4.Source: §7 · p. 13, Figure 4 · p. 14
  • All 66 shipped TTFs pass OTS, and HarfBuzz and CoreText reproduce template glyph-ID sequences on the probes; accepted generated glyphs have p95 advance deltas of 0.358 em.Of 1,617 glyphs with advance or sidebearing changes over 0.35 em, 248 were reachable in the shaped unit inventory; four generation-introduced overlap cases were reverted, while 1,369 context-only variants remain unaudited.Source: §7 · pp. 14–15
  • Bounded post-hoc outline axes provide weight and proportion variation with zero shaped-cluster breaks on calibration probes.The calibrated ranges are weight offset −40 to +80 font units, counter scale 0.8–1.2, and em-fill 0.95–1.06.Source: §7 · p. 15

8 Negative Results and Forensics

The section catalogs unsuccessful conditioning and objective changes, traces a train-time loss failure, and characterizes a data-hull boundary. The authors report that a third of the project’s GPU budget went to failed levers.

8.1 Six tested-and-unsuccessful lever families

  • Raster and skeleton input norms were 4.25 and 0.0125, respectively (340× apart); raster dropout revived the skeleton pathway 17×, but heavy-donor gates still failed.The skeleton signal was computable from the adjacent raster channel, leaving it redundant; the result weighs against a structure-deficit explanation.Source: §8.1 · p. 16, Figure 5 · p. 16
  • Multi-scale adapters worked at all four scales, yet gates did not improve, indicating that richer conditioning was not the binding constraint.Weight-domain target augmentation also left gates flat, while contrastive style loss reduced fidelity without improving blackness.Source: §8.1 · p. 16
  • Every working mechanism left AlfaSlab fallback unchanged or worsened it, while five of eight variants broke the in-hull Devanagari gate.The table summarizes six tested lever families; the auxiliary-CE row predates the protocol-of-record baseline and AlfaSlab probe.Source: Table 4 · p. 17, §8.1 · p. 17
  • Clean weighted sampling trained healthily and passed 2/7 gates, but dilution shifted across scripts; Malayalam’s share fell from 19% to 13% with a −0.010 shift.Mean SSIM shift versus uniform concatenation was approximately zero, and the authors report no tested share vector clearing all seven bars simultaneously.Source: §8.1 · p. 17

8.2 The aux-loss contamination study

  • The train-time content-identity loss caused uniform cross-script SSIM collapse of 0.13–0.19 below bars, systematic boldening, and style washing despite healthy-looking validation panels.At resume, diffusion-term loss was 0.0010 for clean runs versus 0.0066–0.0090 for polluted runs; a clean relaunch passed its gates.Source: §8.2 · pp. 17–18
  • The loss fingerprint appeared immediately: contaminated runs stayed 6–8× above the clean diffusion-loss regime, while clean runs overlapped and gates would reveal failure about seven GPU-hours later.The four runs resumed the same checkpoint and schedule, differing only by the train-time content-identity CE term.Source: Figure 6 · p. 18

8.3 The data-hull boundary

  • AlfaSlab’s ink density was 0.757, beyond the training maximum of 0.732, and its content-gate fallback remained 54–59%; in-hull Lobster at 0.543 had 11% fallback.The density measurements cover 278 Devanagari training faces; the donor precheck warns when a request exceeds the training hull.Source: §8.3 · p. 18, Figure 7 · p. 19
  • The data-hull explanation is a best-supported hypothesis, not a demonstrated cause: it rests on one scalar and two Latin probe donors, with other modeling explanations unexcluded.A density-banded multi-donor study is needed to map the boundary’s actual shape.Source: §8.3 · p. 19

9 Limitations

Srijika’s evaluation and style transfer have defined boundaries: heavy or structurally distinctive donors, oracle-reference gates, and per-script routing all constrain what the reported results establish.

9 Limitations

  • Donors beyond the training ink-density range degrade to template-heavy output; the proposed data-acquisition remedy is a best-supported hypothesis, with modeling-side explanations not excluded.The boundary analysis is limited to the tested architecture, critic, and levers.Source: §9 · p. 19
  • Glyph-local transfer weakly captures layout-scale traits such as extreme width, connected-script joins, and baseline variation, even when per-glyph quality is high.Six reference tiles cannot encode features not visible at tile scale; diverse audited templates matched to donors could recover some traits, at the cost of re-grafting.Source: §9 · p. 19
  • Oracle-reference gates measure held-out-font fidelity, not open-vocabulary prompt quality; retrieval evaluation against designer-labeled prompts and a paired human study remain future work.The prompt interface has only an attribute-label Spearman of 0.50; baselines are no-learning references, and heavy-donor outputs lack a within-font coherence statistic.Source: §9 · p. 20

10 Conclusion

Srijika demonstrates prompt-guided restyling of installable fonts across nine Brahmic scripts by reusing existing layout structure and limiting learning to local, reference-conditioned visual restyling.

10 Conclusion

  • Srijika ships installable fonts for nine Brahmic scripts by reusing professionally engineered layout-table structure, subject to documented metric and anchor-coordinate transformations.The learned component is confined to local visual restyling under reference conditioning.Source: §10 · p. 20

Ethics and Licensing

The released fonts are open-licensed derivatives of their templates, with attribution and naming requirements preserved.

Ethics and Licensing

  • Generated fonts retain the template’s license, follow OFL Reserved Font Name renaming requirements where applicable, and credit the template family in the output name table.The work reports using only SIL Open Font License or Apache 2.0 materials and no proprietary or scraped fonts.Source: Ethics and Licensing · p. 20

Code and Data Availability

The release distinguishes currently available Lipika resources from Srijika artifacts scheduled for a later revision. Its evaluation uses family-held-out gates and reports per-face scores, with family-level independence and internal style metrics requiring careful interpretation.

Code and Data Availability

  • Lipika retrieval code, recognizer weights, and evaluation set are public; the Srijika generator, serving and evaluation implementations, and generated fonts are not included in this version.The ancillary files include benchmark and evaluation manifests, font hashes, geometric-baseline fonts and validation logs, and a human-evaluation protocol sketch.Source: Code and Data Availability · pp. 20–21

A Gate protocol details

  • Each script’s frozen test split holds out complete font families; evaluation scores generated tiles against ground-truth tiles using SSIM.Models use guidance 3.0 and six reference tiles from the held-out family; shipping requires clearing both the gate and the script’s inherited bar.Source: A Gate protocol details · p. 22

B Per-face gate scores and template baseline

  • Family is the independent unit: tiles within a face and weights from one design are correlated, so per-face rows—not pooled tile-level percentiles—are the honest display.Each face contributes 64 tiles; pooled means equal per-face macro-averages, but per-face p25 cannot be recovered from pooled numbers.Source: B Per-face gate scores and template… · p. 22
  • Style ratio is generated-tile similarity to the six-reference centroid divided by real-tile similarity, not a measure of displacement from the template.It is an internal score from the generator’s frozen style encoder, whose training corpus includes held-out families; an earlier ink-density description was corrected.Source: B Per-face gate scores and template… · pp. 22–23
  • The geometric baseline estimates one scale-and-weight transform per held-out face from its six references, then applies it unchanged to that face’s scored tiles.It is a tile-space transform, not a font assembled for gate comparison; separately assembled geometric fonts passed OTS, while the evaluation implementation is scheduled for later release.Source: B Per-face gate scores and template… · p. 23

C Preset catalogue

The serving deployment provides 57 curated, assembled TTF presets across nine scripts. Family-level results show small typical style-closure effects and strong variation across held-out families.

C Preset catalogue

  • The serving deployment exposes 57 curated presets across nine scripts, each a fully assembled TTF generated from a named donor.Every preset ships with a critic report, and fleet-wide shaped-cluster accuracy is 0.981–1.000; per-face gate-score tables cover the five originally shipped and four grafted scripts.Source: C Preset catalogue · p. 23, Table 7 · p. 26, Table 8 · p. 27
  • In the controlled benchmark, the other seven unique style-OOD families have median closure 0.040, while Alkatra has high closure in both script renderings.The two Alkatra observations are correlated measurements of one held-out family; the benchmark excludes these families from diffusion pair-pack training but not Lipika encoder or retrieval-index training.Source: Table 5
  • Generated style exceeds the template’s on 18 of 23 families, but median closure is 0.047 and the largest closures concentrate in a few families.Eight families exceed 0.10 closure, three exceed 0.25, and five are negative.Source: Table 6 · p. 25
  • The geometric baseline has higher SSIM than generation on 17 of 23 families, but its median closure is 0.006, with none above 0.25.The family-level results average faces within each family; there are two to four families per script, so the statistics are descriptive.Source: Table 6 · p. 25
Loading 2609.05661v1…