Archive Render Assets

Render assets — figures as data, from pg to the page

Archived. From the Postgres-era project, also called enumeratio; in this page that name means that project. The pg-backed three-layer split is superseded; the idea of a structured render tree lives on in boxes. Kept for its reasoning; the current page is Rendering Environments and Boxes.

Status: living design doc for the "figures as data" spike (spikes.md). The thesis: a representation of an element — text, SVG, image, an interactive scene — is another cast of the element data into a space (see visual-representations.md), and casts are DATA. If the raw generation lives in the db, representations become augmentable on the fly — new/custom figures as catalog rows, no recompile — and can be authored by anyone and packaged as an MR. This doc records the layering and gets built out as the spike resolves each piece.

The three layers (who does what)

Layer	Responsibility	Examples
pg SQL (@enumeratio/data)	Raw generation, as data. Given an element (its carrier value), emit the render payload: textual notation, an SVG string, a structured render-tree, coordinates for a scene. Declared in the catalog (base_repr, base_glyph, base_polytope) and computed by SQL functions — so a new representation is a row + a function, live-augmentable.	render_fn(<carrier>) → text (line space); a glyph_svg(<carrier>) → text (page space); polytope point/dim/contains fns (scene space).
client (@enumeratio/client)	Asset resolution. Ask pg for the representation of a given resource (collection / fiber / element) in whatever FORM the caller needs, and hand it back: text notation (latex / unicode / asciimath, with printer config), an SVG string, an image, a structured spec. Knows the catalog, the medium/printer options, and the shared styling-hook names (so the SVG it resolves is theme-aware).	evaluateExpression, render(element, opts), a future figure(element, { kind, format }) → svg|spec.
web components	Web-specific heavy lifting. Render the resolved asset in the browser, apply the shared styling hooks, and own interactivity + statefulness (hover, selection, subcomponent/fragment picking that reports back). Generic where possible: point at a resolved asset/spec + config, render it, hook its state.	@enumeratio/components — pure figures (*-glyph, svg-figure, polytope-figure, polytope-overlay) + client-backed enumeratio-* (notation, figure, expression).

Rule of thumb: pg computes the math + the raw payload; the client resolves + shapes the asset; the web component does the DOM/GL/interaction. Nothing web-specific in pg; nothing math-specific in the component.

Asset forms

One resource, many forms — the client resolves whichever the caller asks for:

• Textual notation — latex / unicode / asciimath (the medium axis), with printer config (radix, alphabet, balanced/negabase, …). Already the base_repr + rendering-axes model.
• SVG — a page-space glyph as an SVG string (theme-aware via the styling hooks below). Today the glyphs compute SVG in TS; the spike moves that generation into pg (glyph_svg(<carrier>) → text) so it's data.
• Images / other — rasterized or externally-produced assets where SVG isn't enough.
• Structured render-tree — a portable spec (not a raw string) a generic renderer walks; potentially other UI-serialization targets (framework-serialized component JSON) for non-Lit consumers.

Figures as data (the augmentable core)

base_glyph / base_repr / base_polytope already declare, IN THE CATALOG, how an element casts into a space. The spike extends that from "which TS renderer" to "the render SPEC itself, emitted by pg." Then:

• a generic renderer web component takes a resolved spec + config/properties and renders it — the built-in *-glyph elements become the defaults, with a generic fallback for db-authored representations;
• a new representation is a catalog row + a SQL function — no recompile, experiment freely;
• authors package a representation as an MR (or as data we turn into an MR) — the same fold-back path as a new collection.

Shared styling hooks (keep the set tight)

Every figure + component honors ONE small, documented set of CSS custom properties, so the whole surface reads as one system in light/dark and a db-emitted SVG themes correctly:

hook	role
--enumeratio-accent	primary accent — marks, fills, strokes
--enumeratio-border	borders · gridlines · axes
--enumeratio-muted	muted / secondary text
--enumeratio-text	body text

Each has a sensible standalone fallback; the explorer maps its PrimeVue theme onto them (--enumeratio-accent: var(--p-primary-color), …), and elements currently also read --p-* directly with the --enumeratio-* as fallback. The client can know these hook names so the SVG it resolves references var(--enumeratio-accent) rather than a literal colour. Keep the set small and documented — this table is the source of truth; adding a hook is a deliberate change, not an ad-hoc var().

Where it stands

• Built: base_repr / base_glyph / base_polytope catalog casts; the Lit figures (@enumeratio/components — *-glyph, polytope-figure, polytope-overlay) rendering from element data; the client-backed enumeratio-* elements (<enumeratio-expression>, <enumeratio-notation>) over the client core; the render corpus as a reference oracle. The first SVG-from-db round-trip: glyph_svg(<carrier>) (dyck / motzkin, sharing one lattice_path_svg) emits a self-contained SVG; carrier_renders_svg derives support from the overloads; handle.glyphSvg(rank) resolves it; the generic <svg-figure> injects it and <enumeratio-figure> wires the round-trip.
• Spike (open): the remaining figures-as-data pieces — the render-SPEC schema (a structured render-tree, not just a string), more glyph_svg overloads + config, the statefulness/selection protocol, styling-hook consolidation (dropping the direct --p-* reads), and the extensibility / MR-as-data path — tracked as issue 83 of the Postgres-era repository.

Related: visual-representations.md (the casts-into-spaces model), the type-model + routing spike, and the maps/dimensions-measures threads in roadmap.md.