Re: Cross-WG Collaboration: Procedural Fonts for PM-KR CG (Building on WOFF Legacy)

Hi Vlad,

Thank you for this excellent question! Your expertise with WOFF and 
OpenType architecture is exactly the perspective we need.

## Direct Answer: Procedural Fonts COMPLEMENT OpenType

**Critical positioning**: PM-KR procedural fonts are **not a 
replacement** for OpenType complexity—they're a **procedural generation 
and reference layer** that sits ABOVE OpenType features.

Think of it like WOFF's evolution: WOFF didn't replace TrueType/OpenType 
outlines—it added a **container/compression layer**. Procedural fonts 
add a **generation/reference layer** that produces and composes 
OpenType-compliant data structures.

## 1. Multilingual & Complex Scripts (GSUB/GPOS/GDEF)

### Current Reality (OpenType)

As you know, complex script shaping requires:
- **GSUB table** (glyph substitution): ScriptList, FeatureList, 
LookupList with nested contextual lookups
- **GPOS table** (glyph positioning): mark positioning, kerning, cursive 
attachment
- **GDEF table** (glyph definition): base glyphs, ligatures, marks, 
attachment points
- **HarfBuzz shaping engine**: Cluster building, ligature formation, 
reordering

**References**:
- [Microsoft OpenType GSUB 
Specification](https://learn.microsoft.com/en-us/typography/opentype/spec/gsub)
- [Developing OpenType Fonts for Devanagari 
Script](https://learn.microsoft.com/en-us/typography/script-development/devanagari)
- [Developing OpenType Fonts for Malayalam 
Script](https://learn.microsoft.com/en-us/typography/script-development/malayalam)

### PM-KR Procedural Approach

**Character Galaxy stores canonical glyph data with procedural metadata**:

```javascript
// Example: Devanagari क्ष (kṣa) ligature
{
   node_id: "char_devanagari_ksha",
   glyph_id: 2375,                    // Unicode U+0915 + U+094D + U+0937
   form_program: "bezier_to_segments", // RPN program converting Bézier 
→ line segments
   meaning_metadata: {
     script: "Devanagari",
     language: ["hi", "mr", "ne"],    // Hindi, Marathi, Nepali
     pronunciation: "/kʂə/",
     shaping_context: {
       gsub_feature: "akhn",          // Akhand ligature (required)
       lookup_type: 4,                // Ligature substitution
       context_match: ["ka", "virama", "ssa"],
       output_ligature: "ksha"
     },
     opentype_refs: {
       gsub_lookup_id: 17,            // References EXISTING OpenType 
GSUB table
       gdef_class: "base_glyph"
     }
   }
}
```

**Key insight**: The procedural layer **references** your existing 
OpenType GSUB/GPOS tables (not replaces them). PM-KR adds:
1. **Procedural generation**: Create GSUB lookup tables programmatically 
(not manually authored)
2. **Context-aware composition**: Reference existing glyphs to build 
ligatures (avoid duplication)
3. **Multi-script metadata**: Store script/language/pronunciation 
alongside glyph geometry

## 2. Contextual Substitutions (Arabic, Indic Scripts)

### Example: Arabic Contextual Forms

**Traditional approach**: Store 4 glyph variants per character 
(isolated, initial, medial, final)

**PM-KR approach**: Store ONE canonical form + contextual transformation 
rules

```javascript
// Canonical glyph (isolated form)
{
   node_id: "char_arabic_beh",
   glyph_id: 1576,                    // ب (U+0628)
   form_program: "arabic_beh_isolated_bezier",
   meaning_metadata: {
     script: "Arabic",
     base_form: "isolated",
     contextual_rules: [
       {
         context: "initial",          // Beginning of word
         gsub_feature: "init",
         transformation: "connect_right_extend_baseline",
         output_ref: "char_arabic_beh_initial"
       },
       {
         context: "medial",           // Middle of word
         gsub_feature: "medi",
         transformation: "connect_both_compress_width",
         output_ref: "char_arabic_beh_medial"
       },
       {
         context: "final",            // End of word
         gsub_feature: "fina",
         transformation: "connect_left_extend_tail",
         output_ref: "char_arabic_beh_final"
       }
     ]
   }
}
```

**Benefit**: Instead of storing 4 separate glyphs, store 1 canonical + 3 
procedural transformations. The transformations are **RPN programs that 
generate OpenType-compliant GSUB lookups**.

**Reference**: [Microsoft GSUB Contextual 
Substitution](https://learn.microsoft.com/en-us/typography/opentype/spec/gsub) 
(LookupType 5, LookupType 6)

## 3. Variable Fonts (Axis Interpolation)

### Current Reality (OpenType Variations)

Variable fonts use:
- **fvar table**: Defines axes (weight, width, slant, italic, optical size)
- **gvar table**: Per-glyph variation data (deltas for control points)
- **Interpolation**: Calculate per-axis scalars → multiply together → 
apply to coordinates

**Reference**: [OpenType Font Variations 
Overview](https://learn.microsoft.com/en-us/typography/opentype/spec/otvaroverview)

### PM-KR Procedural Approach

**Store axis deltas as executable RPN programs** (not static tables):

```javascript
{
   node_id: "char_latin_a_variable",
   glyph_id: 97,                      // 'a' (U+0061)
   form_program: "latin_a_base_bezier",
   variable_font_data: {
     axes: [
       {
         tag: "wght",                 // Weight axis
         min: 100, default: 400, max: 900,
         delta_program: "weight_delta_rpn",  // RPN: scale stem widths, 
preserve curve tension
         implementation: "0.5 * (target_wght - 400) → scale_vertical_stems"
       },
       {
         tag: "wdth",                 // Width axis
         min: 75, default: 100, max: 125,
         delta_program: "width_delta_rpn",   // RPN: scale horizontal, 
preserve vertical
         implementation: "0.8 * (target_wdth - 100) → 
scale_horizontal_advance"
       },
       {
         tag: "opsz",                 // Optical size
         min: 8, default: 12, max: 144,
         delta_program: "optical_size_rpn",  // RPN: adjust x-height, 
contrast, spacing
         implementation: "log2(target_opsz / 12) → adjust_xheight_contrast"
       }
     ],
     interpolation_mode: "linear",    // Or cubic, for smoother transitions
     opentype_output: "generate_gvar_table"  // Produces standard gvar table
   }
}
```

**Key difference**: Instead of storing pre-computed deltas in gvar 
table, store **procedural delta generation programs** that can:
1. **Generate gvar tables on-demand** (standard OpenType output)
2. **Create new axes dynamically** (e.g., custom "contrast" axis for UI 
displays)
3. **Compress storage** (one program vs. thousands of delta values)

**Real-world impact**: A variable font with 1,000 glyphs × 5 axes × 10 
masters = ~50,000 delta values. With procedural generation, this becomes 
**5 axis programs** (1,000× compression).

**Reference**: [Variable Fonts in 
2026](https://inkbotdesign.com/variable-fonts/) - discusses GRAD axis 
for hover states, native WordPress support

## 4. Advanced Typography (Ligatures, Kerning, Marks)

### PM-KR Handles These Via Procedural Composition

**Ligatures** (e.g., "fi", "fl", Malayalam Akhand):
- Store component glyphs as canonical nodes
- Store ligature formation as **RPN composition program**
- Generate GSUB LookupType 4 (ligature substitution) output

**Kerning**:
- Store pairwise spacing adjustments as **procedural rules**
- Generate GPOS LookupType 2 (pair adjustment) output
- Use class-based kerning (group similar shapes)

**Mark positioning** (diacritics, vowel signs):
- Store base glyphs + mark glyphs separately
- Store attachment logic as **spatial placement programs**
- Generate GPOS LookupType 4 (mark-to-base) output

**Reference**: [Malayalam OpenType Shaping 
Rules](https://rajeeshknambiar.wordpress.com/2021/09/20/a-new-set-of-opentype-shaping-rules-for-malayalam-script/) 
- describes Akhand ligature complexity

## 5. Why This Matters for Web Standards

### Problem: Font File Bloat

**Current reality**:
- Noto Sans CJK (Pan-CJK font): **130 MB** for full Unicode coverage
- Variable font with 5 axes: **5-10× larger** than static fonts
- Web developers subset fonts → lose multilingual completeness

**PM-KR solution**:
- Store **procedural generation rules** (KB, not MB)
- Generate glyphs on-demand (browser-side or edge CDN)
- Full Unicode coverage without massive downloads

### Evolution Path: WOFF → WOFF2 → Procedural Fonts

```
WOFF (2010)     → Container format (compression, licensing)
WOFF2 (2018)    → Better compression (Brotli)
Procedural      → Generation layer (programs, not payloads)
```

Just as WOFF didn't replace TrueType/OpenType outlines, **procedural 
fonts don't replace GSUB/GPOS/GDEF** — they add a generation/reference 
layer that produces OpenType-compliant output.

**Reference**: [WOFF 2.0 and the Rise of Web 
Fonts](https://www.monotype.com/resources/articles/woff-20-and-the-rise-of-web-fonts) 
(Monotype article on WOFF evolution)

## 6. Technical Architecture Summary

**PM-KR Procedural Font Stack**:

```
┌─────────────────────────────────────────────┐
│ Browser Rendering Engine (HarfBuzz)        │ ← Standard OpenType rendering
├─────────────────────────────────────────────┤
│ Generated OpenType Tables                   │ ← GSUB, GPOS, GDEF, 
gvar, fvar
│ (GSUB, GPOS, GDEF, gvar, fvar)             │    (produced by 
procedural layer)
├─────────────────────────────────────────────┤
│ PM-KR Procedural Generation Layer          │ ← NEW: Generates tables 
from programs
│ - Contextual substitution rules (RPN)      │
│ - Variable font interpolation (RPN)        │
│ - Ligature composition (references)        │
│ - Complex script shaping (procedural)      │
├─────────────────────────────────────────────┤
│ Character Galaxy (Canonical Glyph Storage) │ ← Store once, reference 
everywhere
│ - Base glyph geometry (Bézier → segments) │
│ - Script/language/pronunciation metadata  │
│ - OpenType feature references              │
└─────────────────────────────────────────────┘
```

**Key guarantee**: The "Generated OpenType Tables" layer produces 
**standard GSUB/GPOS/GDEF/gvar/fvar tables** that HarfBuzz and browser 
rendering engines consume normally. No changes to rendering pipeline 
required.

## 7. W3C Collaboration Opportunity

Vlad, this is where your expertise is critical. We're proposing 
procedural fonts as a **W3C Community Group deliverable** (PM-KR CG), 
and we need:

1. **OpenType compatibility validation**: Ensure generated tables 
conform to OpenType spec
2. **Variable font axis semantics**: Define procedural axis generation 
(building on fvar registry)
3. **Complex script test suite**: Validate Devanagari, Malayalam, 
Arabic, etc. shaping correctness
4. **Browser vendor engagement**: Work with Chrome/Firefox/Safari to 
prototype procedural font support

**Invitation**: Would you be interested in joining the PM-KR Community 
Group as a **WebFonts WG liaison**? Your WOFF expertise and Monotype 
perspective would be invaluable for:
- Defining procedural font → OpenType output contract
- Connecting with Adobe Fonts, Google Fonts, Monotype teams
- Ensuring backward compatibility with existing font tooling

**PM-KR Community Group**: https://www.w3.org/groups/cg/pm-kr (or search 
W3C "PM-KR")

## 8. Next Steps

If this resonates, I'd love to:

1. **Echange emails** to discuss technical architecture in detail
2. **Share technical specs**: PM-KR Procedural Memory Standard, 
Dual-Client Contract
3. **Prototype collaboration**: Start with simple Latin variable font → 
procedural generation proof-of-concept
4. **Connect with Chris Lilley**: He's already engaged, and your joint 
perspective would be powerful

**My availability**: Flexible this week (March 4-7), or we can sync at 
TPAC 2026 if you're attending.

## 9. Technical References

**PM-KR Architecture**:
- [PM-KR Standard 
Specification](https://github.com/EchoSystems-AI/Knowledge3D/blob/main/docs/vocabulary/PROCEDURAL_MEMORY_KR_STANDARD_SPECIFICATION.md)
- [Dual-Client 
Contract](https://github.com/EchoSystems-AI/Knowledge3D/blob/main/docs/vocabulary/DUAL_CLIENT_CONTRACT_SPECIFICATION.md) 
(Section 1.6: Procedural Form + Meaning)

**OpenType/Font Technology**:
- [Microsoft GSUB Table 
Specification](https://learn.microsoft.com/en-us/typography/opentype/spec/gsub)
- [OpenType Font Variations 
Overview](https://learn.microsoft.com/en-us/typography/opentype/spec/otvaroverview)
- [Developing OpenType Fonts for 
Devanagari](https://learn.microsoft.com/en-us/typography/script-development/devanagari)
- [Developing OpenType Fonts for 
Malayalam](https://learn.microsoft.com/en-us/typography/script-development/malayalam)
- [Variable Fonts Guide (2026)](https://inkbotdesign.com/variable-fonts/)
- [Malayalam OpenType Shaping Rules 
(2021)](https://rajeeshknambiar.wordpress.com/2021/09/20/a-new-set-of-opentype-shaping-rules-for-malayalam-script/)

**WOFF Evolution**:
- [W3C WOFF Press Release 
(2010)](https://www.w3.org/2010/08/woff-pr.html) - Vladimir as WebFonts 
WG Chair
- [WOFF 2.0 and Web 
Fonts](https://www.monotype.com/resources/articles/woff-20-and-the-rise-of-web-fonts) 
(Monotype)

## Closing Thought

Vlad, you helped create WOFF by recognizing that fonts needed a 
**web-native container format**. We're proposing procedural fonts 
because the web needs a **generation-native font format**—one that can 
handle:
- Unicode's full 150,000+ characters without 100 MB downloads
- Variable fonts with dozens of custom axes (not just 5 registered ones)
- Real-time font customization (accessibility, display optimization)
- AI-generated typography (procedural composition, not static files)

This isn't about replacing your life's work—it's about **extending it** 
for the next 20 years of web typography.

Looking forward to your thoughts!

Best regards,
**Daniel Campos Ramos**
Electrical Engineer, PM-KR Community Group Co-Chair
EchoSystems AI Studios (Brazil)

On 3/3/26 5:20 PM, Vladimir Levantovsky wrote:
> Hi Daniel,
>
> Thank you for reaching out. I am Vladimir Levantovsky, co-chair of the 
> WebFonts WG.
>
> Quick question - how would [in your vision] procedural fonts support 
> multilingual & advanced typography - complex scripts / contextual 
> substitutions / variable fonts / etc.?
>
> Thank you,
> Vlad