[Suggestion] Font generator enhancements.

[lelandg]

Discord Report by Leland Green — Sysop (378271581971021826)

Reporter: lelandgreen
Category: Suggestion
Server: Chameleon Labs

Details

Reported by: Leland Green — Sysop (lelandgreen)

Add kerning and other advanced options. Use AI to detect proper kerning betwen characters and other settings in auto mode. Send a batch of images using LLM contract, e.g., to get kerning settings for all glyphs.

---

Auto-created via ChatMaster /report command

[lelandg]

🤖 Investigation by CL Issue Investigator (Claude Opus) — proposed changes below, not yet applied.

I now have a complete picture. This is a feature suggestion rather than a defect, so my report frames the "diagnosis" as a grounded gap analysis against the current implementation.

Diagnosis

This is a feature suggestion, not a bug. The request has three distinct parts, which I map to the current code:

1. "Add kerning … and other advanced options." Kerning already exists but is rudimentary and not user-editable. It is computed entirely by hand-rolled heuristics in core/font_generator/metrics.py:

   • A fixed, hard-coded pair list KERNING_PAIRS (metrics.py:43-65) — only ~50 classic pairs (A/v, T/o, L/T, f/i, etc.). Any pair not in this list is never kerned.
   • _calculate_kerning (metrics.py:443-471) iterates only those pairs, keeping a value only if abs(kern) >= self.kerning_threshold (metrics.py:467; threshold = 0.15 * units_per_em, metrics.py:141).
   • _calculate_kern_value (metrics.py:473-516) derives the value from a crude _analyze_edge shape classifier (metrics.py:518-563) that buckets a glyph edge into straight/round/diagonal/open by x-coordinate variation, plus a few if-special cases. There is no spacing/sidebearing analysis of the actual glyph pair, just a per-glyph edge label.
   • Side bearings are a flat constant: default_side_bearing = 3% of em applied symmetrically to every glyph (metrics.py:128,140; advance width = glyph width + 2×bearing at metrics.py:194). There is no per-glyph optical spacing.

2. "Use AI to detect proper kerning … in auto mode." No AI is involved in kerning today. The AI vision subsystem (core/font_generator/glyph_identifier.py, AIGlyphIdentifier) is used only for character identification (which glyph is this?), never for spacing/kerning measurement.

3. "Send a batch of images using LLM contract … to get kerning settings for all glyphs." The "batch + LLM contract" pattern the reporter describes already exists for identification and is the natural template to reuse:

   • batch_identify (glyph_identifier.py:745) → _identify_batch (:794) builds a numbered grid composite (_create_numbered_composite, :835), sends one structured prompt (_build_batch_prompt, :874), and parses a line-per-glyph response (_parse_batch_response, :901). That request/response shape is exactly the "LLM contract" concept.
   • Caveat: the batch path is Gemini-only — _identify_batch calls self._client.models.generate_content (:812); the Anthropic path (_identify_glyph_anthropic, :309) has no batch equivalent, even though Anthropic/Claude is the documented "recommended" provider (:81).

Two structural gaps make this enhancement non-trivial:

• Kerning is never tunable from the wizard. The GUI always constructs FontBuilder(info=font_info) with no metrics= argument (gui/font_generator/font_wizard.py:1923 for preview, :2273 for export). That forces build() to instantiate a default FontMetricsCalculator() internally (core/font_generator/font_builder.py:133-141) with default threshold/side-bearing. There is no UI to view or edit kerning pairs, advance widths, side bearings, or units_per_em (confirmed: no spacing/side-bearing/kerning controls in font_wizard.py; the only spacing references are Qt layout and bitmap-preview spacing).

• Kerning is emitted only as a legacy kern table (format 0) in _add_kerning (font_builder.py:543-575) — no GPOS pair adjustment. Many modern shapers/browsers ignore the old kern table for OpenType, so AI-derived kerning may not even render in some targets.

• Kerning is inherently pairwise. The existing per-glyph numbered composite cannot measure kerning, because a single glyph image carries no information about its neighbor's spacing. An AI auto-kern mode must render pairs (or the full sample sheet with real adjacency) and ask the model for per-pair adjustments in normalized units, then map back to font units.

Affected files

• core/font_generator/metrics.py — kerning pair list, kern-value heuristics, side bearings, threshold (the core of part 1).
• core/font_generator/glyph_identifier.py — AI vision + batch "LLM contract" to extend for kerning, and to add Anthropic batch support.
• core/font_generator/font_builder.py — _add_kerning (legacy kern only); accept/honor externally supplied kerning & GPOS.
• gui/font_generator/font_wizard.py — no UI to trigger AI auto-kern, edit pairs/spacing, or pass tuned metrics into FontBuilder (:1923, :2273).
• core/font_generator/__init__.py — public exports if new classes/methods are added.
• Reference/design context: Plans/VectorizedFontGeneration.md, Plans/2026-01-27-font-segmentation-row-column.md, Notes/Discord_FontGenerator_Options.md.

Proposed changes

A reviewable, incremental path (each step independently shippable):

1. Make kerning/spacing tunable & editable (prerequisite, no AI).
Pass a configured FontMetrics/FontMetricsCalculator into FontBuilder from the wizard instead of relying on the internal default:

# font_wizard.py (both preview ~1923 and export ~2273)
from core.font_generator import FontMetricsCalculator
calc = FontMetricsCalculator(
    default_side_bearing=page4.side_bearing_pct,    # new UI control
    kerning_threshold=page4.kern_threshold_pct,     # new UI control
)
metrics = calc.calculate(self.glyphs)
self.glyphs = calc.get_normalized_glyphs()
builder = FontBuilder(info=font_info, metrics=metrics)

Add a "Spacing & Kerning" page/section exposing global side-bearing, kern threshold, and an editable table of kerning pairs (left, right, value) seeded from metrics.kerning.

2. Add an AI auto-kern "contract" reusing the batch pattern.
New method on AIGlyphIdentifier (mirroring _build_batch_prompt/_parse_batch_response), e.g. suggest_kerning(pairs, render_fn):

• Render each candidate pair (use existing normalized glyph outlines / preview bitmaps) into a labeled composite, with the current default spacing applied so the model judges the real gap.
• Structured prompt: for each numbered pair, return a recommended spacing adjustment as a fraction of em (e.g. -0.04) plus confidence.
• Parse into {(left, right): kern_units} (multiply fraction × units_per_em), merge into metrics.kerning, and surface in the editable table from step 1 for human review before build. Log full request/response per the project's LLM-logging rules (CLAUDE.md → "show everything sent to the LLM").

3. Emit GPOS in addition to (or instead of) the legacy kern table in font_builder.py:_add_kerning so AI-tuned kerning renders in modern shapers (fontTools buildGPOS/feature-file kern feature).

4. Add Anthropic batch support so auto-kern works with the recommended Claude provider, not just Gemini (_identify_batch is currently self._client-only, :812).

Suggested scope for a first PR: steps 1 + a single-image-sheet AI pass that returns per-pair suggestions (smaller blast radius than full pair rendering), gated behind an explicit "Auto-detect kerning (AI)" button, defaulting off.

Risks / side effects

• Cost / latency / privacy: AI auto-kern sends rendered glyphs to an external LLM. Must be opt-in, key-gated, and obey the project's "log everything sent to the LLM" rule. Note global CLAUDE.md guidance: do not let untrusted text drive actions — keep this a user-triggered button.
• Pairwise explosion: N glyphs → N² candidate pairs. Batching must cap per-request count (the existing max_per_request=20 at :749 is a model) and the UI should let users scope which pairs to evaluate.
• Regression in spacing: Passing a tuned metrics into FontBuilder changes the current "always default calculator" behavior (font_builder.py:133-141); verify the normalized-glyph handoff (get_normalized_glyphs) is consistent between preview (:1923) and export (:2273), or descenders/baseline could shift between preview and exported file.
• GPOS migration: Adding GPOS while keeping the kern table can double-apply kerning in some renderers; pick one source of truth.
• Parsing fragility: The batch response parser is line-position based (_parse_batch_response, :901) and brittle; a kerning variant needs robust JSON-style parsing with fallbacks (per the project's "robust JSON parsing / fallback" LLM guidance).
• Provider asymmetry: Until Anthropic batch exists, "auto mode" silently requires Gemini despite Claude being the recommended identifier (:81) — could confuse users.

Confidence

High that the current kerning is heuristic, fixed-pair, non-AI, non-editable, and emitted only via the legacy kern table, and that the AI batch "contract" infrastructure already exists to extend (all cited with line numbers).

Medium/low on points I could not verify by execution: I did not run the wizard, so I confirmed the absence of kerning/spacing UI by code search (font_wizard.py has no side-bearing/threshold/kern-edit controls) rather than by interaction. I also did not verify how well any specific LLM actually estimates kerning from rendered pairs — that is an empirical/quality question outside static analysis. Whether the maintainers prefer GPOS vs. legacy kern, and which provider should back auto-mode, are product decisions, not facts derivable from the code.