Archive Rendering Printer Config

Rendering / printer config — naming, linking, environments

Carried over from the earlier enumeratio, and never fully built even there. Written for a pg-backed table/Properties UI that no longer exists, but the core idea — presenting a property is printer config (naming, linking, target environment), not one fixed rendering — is still open. It partly overlaps current Rendering Environments (the environment-capability record); per-column printer config and link/history-as-config are not built.

Design note settling the printer-config model behind a property's presentation. Thesis: how a property is named and whether it links in a table/Properties cell is not a fixed rendering — it is config for the printer that renders that property, alongside the visual axes. Ties the render axes (representation × format × medium × alphabet, see Render Assets) to a broader "printer config" that also covers naming, linking, and the target environment. Unblocks the per-column context menu (#62).

The shift: presenting a property IS printer config

A cell in the elements table or the Properties inspector shows some property of a resource — a stat, a map image, the element itself, later any collection/carrier/element reference. There is no single "right" way to show it: a permutation can print as a word, a cycle notation, a one-line title, or a link to its own explorer page. Every one of those is the same property data run through a printer with different config. The render axes already say this for the visual form (which space, which medium, which alphabet); this note extends the same framing to two more knobs — naming and linking — and to the environment the printer targets.

So the full config for presenting one property is three groups:

group	what it configures
visual	the existing render axes — representation (line / page / scene), format, medium (ascii · unicode · latex), alphabet (radix, balanced, symbol set). One category among several, not the whole story.
name	how the property identifies itself — by id, title, notation, or a derived form.
link	whether the value is a link, where it points, and the browsing semantics of following it.

All three resolve against the target environment's capabilities (below).

Naming a property — id / title / notation / derived

A property needs a label (its column header, its inspector row) and, for reference-valued properties (a map image, a sibling collection), the value itself needs a name too. Four naming modes, in rising specificity:

• id — the raw handle (major_index, permutations). Always available, never ambiguous, ugly.
• title — a human title. title / description are polymorphic helpers: already present on meta-collection elements; for math elements, concocted from notation ⊕ fiber-notation; an explicit per-element property where set. This is the default display name where one exists.
• notation — the rendered mathematical notation (the visual axes applied to a textual medium). The natural name for an element value.
• derived — a computed label (title ⊕ notation, a stat's value formatted, a codomain-qualified name). The escape hatch for "name it like this specific thing."

The header label and the value name are the same choice at two scopes; a column config picks a naming mode for each.

Linking a property — whether, where, how

A referenced concept (a map's codomain collection, a sibling, later any element address) can render as plain text or as a link. When it links, three further knobs — and this is where "printer config" reaches past pure visuals:

• whether — link or plain. Default: link when the value has a resolvable target (a map codomain, a findstat id, an element address); plain otherwise. Already the showLink flag on a property row.
• target — in-place vs new session. In-place: navigate this explorer to the referenced resource (today mapHref → /explorer/<codomain>, sibling → ?c=&n=). New session: fork a fresh explorer (new tab) so the current view is preserved — the right default for cross-collection jumps a user wants to keep alongside.
• history — push vs replace. A real browsing step is pushState (back returns to where you were); an in-place mutation of the current view is replaceState (no new history entry). This is the same push/replace discipline the Query-Model already uses for view state: a settled view funnels into the URL via replaceState; a genuine navigation to another resource is a pushState step. Following a reference is navigation → push; retargeting the same view (changing n, toggling a column) is mutation → replace.
• relation + anchor state — link rel, external-vs-internal (findstat/OEIS open target="_blank", internal stay), and any other state that renders into the anchor.

Links are why this is printer config in the broad sense, not just visual config: the same property, in a link-incapable environment, degrades to spelled-out text (below).

Config per ENVIRONMENT — the structural insight

The visual/name/link groups are one category of config. The other axis is the rendering environment, and each has different capabilities — so the printer config is resolved per environment, enabling progressive enhancement: author the richest form, degrade to what the target can do.

environment	capabilities	degradation / notes
web	full — live links, SVG/scene, hover/selection, push/replace history	the reference target; everything else degrades from here
print	tiered. PDF: live links + vector figures. Paper: no links → spell the href out (footnote/appendix), figures rasterize, color may drop	the clearest case that "link" is config, not a fixed thing
terminal	color + OSC-8 hyperlinks; two modes — plain stream vs a full curses TUI that can host its own explorer with its own browsing history	plain stream ≈ print-paper (spell links); TUI ≈ web (in-place nav, push/replace)
mobile	links + touch, but a different notification / share model, constrained width, new-session semantics differ	take stock; not solved now

The insight: general visual options are just one config category; "per environment" is the other, and the two compose. A property's presentation = (visual ⊕ name ⊕ link) config, resolved against an environment's capability set, with progressive enhancement filling the gap. Don't build all four environments now — but the config schema must let a single property definition target any of them without a rewrite.

Near-term deliverable — the per-column context menu (#62)

This model exists to unblock #62: a context menu on a table column header to configure that column's printer config. Most of the plumbing is already there — a property row (PropRow) already carries format, name (header override), width, and showLink, and the Properties pane already has a per-row config popover (format · header · width · link). #62 is that same config set, surfaced on the column header (right-click / caret) instead of only in the Properties list, so a column is configurable in place.

What a column context menu should expose, scoped to what exists today (web environment only for now):

• name — header label: id | title | notation | derived (default: the def's label).
• visual / format — the property's formats (e.g. plain | grouped); later the medium (ascii · unicode · latex) and alphabet where the property is notation-valued.
• link — on/off (showLink); when on and the target supports it: in-place vs new session, and (follow = push) history semantics. Only shown when the value has a resolvable target (map codomain / findstat / address).
• width / visibility / order — min-width, the eye toggle (drop from SELECT), position — already row config, mirrored onto the header menu.

Because a column IS a projection in the Query-Model SELECT list, the context menu is an editor for that projection's printer config — the same object the Properties pane edits, reached from the header. One config source, two surfaces.

Deferred (design fits, don't build yet)

• The non-web environments (print/terminal-TUI/mobile) — schema must accommodate them; renderers come later.
• Element-address references as first-class link targets (needs the address/unrank link scheme).
• The environment-capability resolution layer (progressive-enhancement engine) — a printer picks the richest form its environment supports.

Related: Render Assets (figures as data, the render axes + styling hooks), Query-Model (the column IS a SELECT projection; push/replace URL state), Sort-and-Filter.