dj.Diagram theme: make the font configurable, and reconcile the tier palette with DataJoint brand colors

[dimitri-yatsenko]

Two theme gaps surfaced by putting a dj.Diagram figure through a brand review (dj-thought PR #55/#57, where the generated diagram is published in a blog essay). Both are in src/datajoint/diagram.py; both would improve every DataJoint diagram, which is why they belong here rather than in a post-process downstream.

1. fontname is hardcoded

node.set_fontname("Helvetica")                      # ~line 1596
fontname="Helvetica",  # schema label in a sans font  ~line 1696

Two hardcoded sites, so a caller who wants the house typeface has no way to ask for it — the only options are patching or post-processing the SVG. Proposal: add fontname to _DIAGRAM_THEMES (defaulting to "Helvetica", no behavior change) and read it at both sites. Small and mechanical.

Motivation: DataJoint brand typography is Roboto (body) / Roboto Slab (headings), and brand-produced versions of the same figure use them. A theme key lets published figures match without leaving the generator.

2. The tier palette and the brand palette have diverged

Brand-produced art for the same schema uses different values from _DIAGRAM_THEMES["light"]:

Tier	Library today (fill / stroke)	Brand-produced version
Manual	#E7F3EC / #2F7D5B	#DCEFDA / #171C39
Lookup	#F2F4F7 / #A9B1BD	#F1F2F6 / #171C39
Imported	#E2ECFA / #2A5FA5	#D6EDF9 / #171C39
Computed	#FBEAEC / #B23A48	#FFE7DB / #171C39
Part	#FFFFFF / #9AA6B8	#FFFFFF / #171C39

Two real differences, not just drift:

• Computed reads peach in the brand version, red/pink in ours.
• The brand version uses one uniform stroke (#171C39 navy) for every tier and carries tier in the fill alone; the library varies stroke per tier.

The fills are a straightforward "which values win" question for the brand owner. The uniform-stroke choice deserves argument before adoption: per-tier stroke is doing accessibility work. It keeps tiers distinguishable in grayscale and print, and gives a second channel beyond hue for readers with color-vision deficiency, where near-pastel fills alone are weak. I'd keep per-tier strokes unless there's a reason I'm missing, and reconcile only the fills.

Also unused-but-present: the brand palette has an accent cyan #00A0DF with no counterpart in the theme.

Not proposed

Per-table icons appear in the brand-produced version (a person for Subject, a test tube for Sample, and so on). They read well, but nothing in a schema derives them — they would need a hand-maintained table→icon map, which reintroduces exactly the drift that generating the figure exists to prevent. Better left to hand-made cover art.

Suggested split

(1) is uncontroversial and unblocks downstream users now. (2) needs a call from whoever owns the brand palette; happy to open (1) as a PR on its own.

[dimitri-yatsenko]

Revising item 2. I suggested reconciling the tier fills toward the brand palette; on reflection that's the wrong default, and I'd withdraw it. Item 1 (configurable fontname) stands unchanged.

The reasoning, briefly: the two palettes are solving different problems. A brand palette maximizes recognition on marketing surfaces. A notation palette maximizes five-way categorical discrimination under adverse conditions — projector washout, grayscale printing, color-vision deficiency. No single palette is optimal for both, and where they conflict the notation's job should win, because the diagram's purpose is to be read correctly.

Three specifics:

• Brand systems are structurally too small for five categories. One or two primaries plus neutrals is the usual shape; five perceptually distinct hues plus a light/dark pair is a larger demand. Forcing it yields near-neighbours — in the brand-produced version, Computed shifts from red toward peach and lands closer to the Manual/Lookup end of the range. Less discriminable, more on-brand.
• Uniform stroke is a real regression, not a style preference. Carrying tier in fill alone removes the redundant encoding channel that keeps tiers apart in grayscale and for color-vision-deficient readers.
• Most dj.Diagram output isn't ours. It renders in users' notebooks, papers, and theses, describing their pipelines. A brand palette as the library default puts DataJoint's marketing identity into figures that aren't marketing.

The useful generalization: brand should govern what carries no meaning; notation should govern what does.

Carries meaning — notation owns	Carries no meaning — brand-safe
the five tier hues · per-tier stroke · node shape · line weight and dash · the underline	typography · frame · background · corner radius · shadow

Typography lands squarely in the right-hand column, which is why item 1 is uncontroversial: Roboto encodes nothing.

If a fully brand-skinned diagram is ever wanted for marketing surfaces, the mechanism should be an additional named theme — theme="brand" alongside light and dark — rather than a change to the defaults. That gives marketing what it needs on the surfaces it owns, and nothing changes underneath users who generate diagrams about their own schemas.

One honest note in the other direction, since it argues against me: I had assumed changing the palette now would churn an installed base. It wouldn't. datajoint-docs #248 (24 regenerated notebooks) is still open and only one committed figure in the docs tree uses these values, so the modernized theme has barely propagated — this is the cheapest moment a palette change will ever be. That removes "too expensive to change" as a defense. The defense is that the current palette is better suited to the job.