reladraw 0.4.0 → 0.6.0

package/NOTICE

@@ -12,3 +12,40 @@ any other trade names, trademarks, service marks, or product names of the
 project, except as required for reasonable and customary use in describing the
 origin of the work (see section 6 of the License). Forks and derived works are
 welcome and must be distributed under a different name.
+
+---
+
+Color palettes
+
+Several of reladraw's themes (src/themes.ts) are adapted from the color
+palettes below. Each is distributed under the MIT License, whose text follows
+the list of copyright notices and applies to each of them.
+
+Solarized       Copyright (c) 2011 Ethan Schoonover
+                https://github.com/altercation/solarized
+Gruvbox         Copyright (c) 2018 Pavel Pertsev
+                https://github.com/morhetz/gruvbox
+Catppuccin      Copyright (c) 2021 Catppuccin
+                https://github.com/catppuccin/catppuccin
+Nord            Copyright (c) 2016-present Sven Greb
+                https://github.com/nordtheme/nord
+Dracula         Copyright (c) 2023 Dracula Theme
+                https://github.com/dracula/dracula-theme
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.

package/README.md

@@ -68,7 +68,7 @@ It is [plain Markdown](.claude/skills/reladraw/SKILL.md) with the syntax referen
 
 ## Status
 
-Version 0.4.0. Early, but it runs: a parser, resolver and SVG renderer in TypeScript with no runtime dependencies, and a command-line tool that takes a text file and writes a standalone SVG. The comparison at the top of this page is that pipeline run on [`examples/arch.reladraw`](examples/arch.reladraw). What is still visibly off there is typography, not placement.
+Version 0.6.0. Early, but it runs: a parser, resolver and SVG renderer in TypeScript with no runtime dependencies, and a command-line tool that takes a text file and writes a standalone SVG. The comparison at the top of this page is that pipeline run on [`examples/arch.reladraw`](examples/arch.reladraw). What is still visibly off there is typography, not placement.
 
 ```
 npm install -g reladraw
@@ -143,4 +143,4 @@ The license covers the code, not the name: it grants no rights to use "reladraw"
 
 ## Contributing
 
-Issues are wanted — especially a diagram you tried to write and could not. Pull requests are read but not merged yet, for a reason explained in [CONTRIBUTING.md](CONTRIBUTING.md).
+Issues are wanted — especially a diagram you tried to write and could not. While the language is changing quickly, an issue is more useful than a pull request; [CONTRIBUTING.md](CONTRIBUTING.md) says why.

package/SYNTAX.md

@@ -1,4 +1,4 @@
-# Syntax reference — 0.4.0
+# Syntax reference — 0.6.0
 
 What the language accepts. The parser, resolver and SVG renderer implement all of it; the sections at the end record what is defective, unchecked or undecided.
 
@@ -422,6 +422,23 @@ You name a side and never a point on it. Alone on a side, an edge lands at its c
 
 The space it leaves is deliberately small, and shrinks further if the side is too short to hold the whole group. On a side short enough, it shrinks to nothing and the attachments coincide. Their texts still come apart, because the lines bow in the middle to make up what the side could not give them, but the arrowheads themselves land on one point and nothing warns you — so a small node with several edges arriving on one side is worth a look.
 
+#### Ends that face away from each other
+
+```
+node parser "Parser"
+node resolver "Resolver"  right of parser
+node renderer "Renderer"  right of resolver
+edge parser -> renderer  "test edge"  from: left  to: right
+```
+
+That line leaves Parser heading left and has to arrive at Renderer from the right, so it must turn back on itself somewhere. It turns back in the gap between its two nodes when there is one wide enough to hold the line and its text, and otherwise it goes over the top: out of its side, along the top of the row clear of the tallest node between its ends, and down into the far side. The text rides on that top stretch, so it never sits on a node. The same goes for `from: top  to: bottom` in a column, which goes round the right, and for an edge from a node back to itself.
+
+Several such lines over the same row take a lane each, the shorter inside the longer, so they nest instead of drawing on top of one another.
+
+Sides at right angles can face away too. `from: left  to: top` with the far node to the right leaves heading away from it, so the line steps out of the left, goes up past both nodes, runs along above them and comes straight down into the top. The side named at the far end says which way round: `to: bottom` takes it underneath instead.
+
+Over the top is the rule, not a guess the tool makes each time — it does not look for the shorter way round. To send the line underneath or round the left, say which side of a node it passes: `below resolver`. See "Passing on one side of a node".
+
 #### Several edges between the same two sides
 
 Edges that run between the *same* pair of sides are a case of their own, because "where the far ends sit" cannot order them: every one of them goes to the same node.
@@ -487,6 +504,78 @@ Several edges may share one channel, and they take a lane each. As with attachme
 
 A named channel does not widen. It is measured off the layout you described, so if you name a gap too narrow for the lines you put through it they crowd together rather than pushing the two nodes apart. That is the difference between this and a text making room for itself, above: there, the corridor is the gap between the edge's own two ends, and opening it moves them apart exactly as anything else put between them would. Here the pair is named by an edge merely passing through, and nothing yet lets an edge bid into a gap it is only a visitor in. It is the remaining half and it is not built.
 
+### Passing on one side of a node
+
+`above`, `below`, `left of` and `right of`, written on an edge, say which side of a node the line passes.
+
+```
+node parser "Parser"
+node resolver "Resolver"  right of parser
+node renderer "Renderer"  right of resolver
+edge parser -> renderer  "underneath"  from: left  to: right  below resolver
+```
+
+They are the placement words, and they mean what `between` means: only where the line passes that node. `below resolver` says the line is below Resolver where it goes by Resolver, not that the whole line is. That edge would go over the top of the row on its own; with the clause it leaves Parser, drops under the row and comes up into Renderer.
+
+Write as many as you need, one for each node you have something to say about. The line meets them in the order they sit along its way, so no clause says an order:
+
+```
+node a "A"
+node b "B"  below a
+edge a -> b  from: top  to: bottom  left of a  right of b
+```
+
+That line leaves the top of A, goes round A's left, crosses over in the gap between the two, passes B on the right, and turns up into B's bottom. The line is drawn as straight stretches joined by rounded corners, each stretch as close to the two ends as its clauses allow, and pushed further out, the way its clause already points, by any node sitting on it.
+
+One clause may name several nodes, and it is not shorthand for several clauses. `below a and b` is below the box bounding both, so it covers the stretch between them too:
+
+```
+node t1 "T1"
+node t2 "T2"  right of t1  (gap: wide)
+node peak "Peak"  right of t1  left of t2  above t1
+edge t1 -> t2  from: bottom  to: bottom  below t1  above peak  below t2
+```
+
+Those three clauses let the line rise over Peak in the gap. Write `below t1 and t2  above peak` instead and it is refused, because Peak sits over the stretch `below t1 and t2` covers, and the line cannot be below the one and above the other at the same point.
+
+One edge may pass some nodes above or below and others left or right. Passing above or below is done travelling across the page, and passing left or right travelling up or down it, so the line turns between the two, as few times as it can:
+
+```
+node a "A"
+node m "M"  right of a
+node n "N"  below m  right of m
+node b "B"  below n  right of n
+edge a -> b  below m  left of n
+```
+
+That line leaves the bottom of A, runs across just under M, turns down on N's left, and runs across into B. The clauses read as before: `left of n` binds only where the line is level with N, so the last stretch passing under N is not held to it.
+
+A side named at an end says which way the line goes first: `from: right` starts it across, `from: bottom` starts it down. With no side named at either end it goes across first, then down.
+
+Clauses of one kind may sit on different legs. Here the line goes over P on the way out, down past N, and under M on the way in, turning twice:
+
+```
+node a "A"
+node p "P"  right of a
+node n "N"  below p  right of p
+node m "M"  below n  right of n
+node b "B"  right of m
+edge a -> b  from: right  to: bottom  above p  right of n  below m
+```
+
+Each clause binds whichever legs pass its node, so a node wide enough to sit under two legs holds both of them to its side.
+
+Refused, each by name:
+
+- **Clauses that cannot all hold** at one point, as above.
+- **A crossing with no room.** Two clauses on opposite sides need a gap between their nodes to cross over in. Placed flush — `gap: 0` — there is none, and the error says to give the placement a gap or drop a clause. The gap is never opened for the line: you wrote how far apart those two are.
+- **A node the line never passes.** `below z` on a line that never goes by Z says nothing.
+- **Both kinds where no way of turning keeps them all.** The error names the clauses, or the one reason if every way fails for the same one.
+- **`between` with a side.** An edge passing between two things already has a side of each.
+- **A part of a node, or a gap.** A line passes a whole box, and passes it as close as reads clearly.
+
+An end with no side named leaves from the side facing where the line is going.
+
 ## Against a part of a node
 
 ```
@@ -630,7 +719,7 @@ Every attribute, and what takes one. The kinds here are what a node's **body** i
 | `line` | | | | ✓ | color |
 | `url` | ✓ | ✓ | ✓ | ✓ | a destination to open when the thing is clicked |
 
-The `diagram` statement has a vocabulary of its own — `background`, and so far nothing else — which is checked the same way. Writing `background:` on a node is an error that points at `fill:`.
+The `diagram` statement has a vocabulary of its own — `theme`, `background` and `text` — which is checked the same way. Writing `background:` on a node is an error that points at `fill:`, and `theme:` on one points at `diagram theme:`. A `default` takes a narrower list for each kind; see "Defaults".
 
 **A word this table does not give the kind is an error.** The two ways of being wrong get different answers, because they have different remedies. A word that is an attribute nowhere is a misspelling, and the error lists what the kind does take. A word that is an attribute *somewhere else* is usually a real statement written on the wrong half of the diagram, so the error says where it belongs:
 
@@ -762,12 +851,66 @@ diagram <attributes>
 Settings that belong to the drawing as a whole rather than to anything in it. There is no name, because a file holds one diagram, and a second `diagram` statement is an error rather than a second opinion.
 
 ```
-diagram  background: #111111
+diagram  theme: nord  background: #1e2229  text: (color: #e0e0e0)
 ```
 
-One attribute so far. `background` takes a color the same way `fill` does, and it colors the page behind everything, including the strip an edge text knocks out of whatever it crosses. Say nothing and the theme's own background stands.
+Three attributes:
+
+- `theme` names the theme that supplies every color the file does not state. See "Themes" below.
+- `background` takes a color the same way `fill` does, and it colors the page behind everything, including the strip an edge text knocks out of whatever it crosses. Say nothing and the theme's own background stands.
+- `text: (color: …)` sets the color of every text, on nodes and edges alike. It takes a color and nothing else; a text size is about one kind of text and belongs on a `default`.
+
+An unknown key is refused by name — `diagram has no "backround" — it takes theme, background, text` — rather than quietly ignored, the same as every other attribute. See "Attributes".
+
+### Themes
+
+```
+diagram  theme: solarized-dark
+```
+
+| theme | |
+|---|---|
+| `dark` | the default: the palette of the benchmark drawing |
+| `light` | the same roles on a white page |
+| `solarized-dark`, `solarized-light` | [Solarized](https://ethanschoonover.com/solarized/) |
+| `gruvbox-dark`, `gruvbox-light` | [Gruvbox](https://github.com/morhetz/gruvbox) |
+| `catppuccin-mocha`, `catppuccin-latte` | [Catppuccin](https://catppuccin.com) |
+| `nord` | [Nord](https://www.nordtheme.com) |
+| `dracula` | [Dracula](https://draculatheme.com) |
+| `high-contrast-dark`, `high-contrast-light` | no fills to lean on, every line at full strength |
+| `print` | a white page, black lines and no fills, for paper |
+
+The borrowed palettes were made for code, where a color marks a keyword or a string. A diagram needs a page, a box, a border, text and a line, so each theme is its scheme read as a diagram rather than a copy of it. Their licenses are in `NOTICE`.
 
-An unknown key is refused by name — `diagram has no "backround" — it takes background` — rather than quietly ignored, the same as every other attribute. See "Attributes".
+A theme only ever supplies a color, so changing it never moves anything. A color you write yourself — `fill: #14532d`, or a style's — stays that color under every theme, which means a hand-picked color can clash with a theme it was not chosen against. `muted` is the one word that follows the theme.
+
+An unknown name is an error that lists the themes.
+
+The command line can render a file in another theme without editing it — `reladraw arch.reladraw --theme light` — and the flag wins over the file's `theme:`. That is how one source becomes a light and a dark image for a README that shows whichever matches the reader's settings. The file's own `background:` and `text:` still win over the flag's theme, as a hand-written color wins over any theme.
+
+### Defaults
+
+```
+default node       border: #4a8a5c
+default leaf       fill: #2e5d3a
+default container  fill: #1a2620  border: #2a3a30
+default edge       line: #7a8a99  text: (color: #9aa5b1, size: small)
+```
+
+A default is a style that every thing of one kind wears without naming it. `node` covers every node; `leaf` a node with no children, and `container` a node with some — the same "has children" the theme's quieter backdrop colors follow, so setting a leaf's fill leaves containers looking like containers. `edge` covers every edge.
+
+The more specific word wins, all the way down:
+
+1. the theme
+2. `diagram`
+3. `default node`
+4. `default leaf` or `default container`, or `default edge`
+5. the thing's styles, a later one winning where two set the same key
+6. what the thing's own line says
+
+A default takes the words a style does, and may name a style of its own with `style:`, which it lays beneath its own words. Unlike a style, it is strict about kind: it names the kind it is for, so a word that kind has no use for can only be a mistake. `default edge  fill: red` is refused and points at `line:`. `badge:` is refused on `default leaf` and `default node`, since a badge is a child and would make every leaf a container, and `icon:` is a leaf's alone, since a picture cannot hold children. A `url:` belongs to one thing, never to a kind.
+
+Each kind is written at most once. `default leaf` twice is an error naming both lines, and `default leaf node` is refused with `default leaf` — a leaf is already a node.
 
 ## What the language refuses
 
@@ -777,7 +920,7 @@ Deliberate omissions. What they protect is that the renderer never *chooses* an
 - **Guessing an axis nobody constrained.** When two placements bind one axis and nothing binds the other, the tool refuses rather than picking a target to center on. Choosing there would decide which row a node shares, not how far it sits from something.
 - **Placements that run in a circle.** A loop where each placement demands more room than the last cannot be satisfied and is an error naming the placements involved. A target does *not* have to be positioned before the node naming it — the whole system is solved at once — so ordinary mutual references are fine.
 - **Edge waypoints.** A point a line must pass through is a coordinate wearing a hat. Saying a line goes between two named things is not one — it names things the diagram already contains, and it survives those things moving.
-- **Choosing a route.** The tool will not find its own way around an obstacle. A line that crosses something it should not is a line you have not yet said enough about, and `between` is how you say it.
+- **Choosing a route.** The tool will not find its own way around an obstacle. A line that crosses something it should not is a line you have not yet said enough about, and `between` and `below <node>` are how you say it.
 - **Set-level placement.** Four siblings around a hub are four statements today. Whether a durable group that reflows when a member is added is worth the same-axis conflict it introduces is undecided.
 
 Note what is *not* on this list: saying more about where something goes. A statement that lets you be more precise is not a step toward auto-layout, and the first version was short enough of them to render the benchmark wrong.
@@ -786,7 +929,7 @@ Note what is *not* on this list: saying more about where something goes. A state
 
 Designed, decided, and absent from the code. Written down so the next version has somewhere to start.
 
-**Nothing keeps an edge clear of a node on its own.** Non-overlap applies to nodes only. A line may still cut across a node it has nothing to do with, and an edge text may still land on top of one. `between` is how you say where a line goes when that matters, and nothing checks the ones where you have not said. A check belongs on the diagnostics list, but finding a route by itself does not — see "What the language refuses".
+**Nothing keeps an edge clear of a node on its own.** Non-overlap applies to nodes only. A line may still cut across a node it has nothing to do with, and an edge text may still land on top of one. `between` and `below <node>` are how you say where a line goes when that matters, and nothing checks the ones where you have not said. A check belongs on the diagnostics list, but finding a route by itself does not — see "What the language refuses".
 
 **An icon outside the built-in seven.** The set is closed, and a diagram wanting a picture that is not in it has nowhere to go. The two shapes this could take are a declaration in the file, `icon <name> "<path data>"` beside `style`, and `icon: ./thing.svg` inlined by the tool at render time. Either keeps the output standalone, which is the constraint any answer has to meet.
 
@@ -828,10 +971,23 @@ That one was found by testing the lexer, not by rendering — and it could not h
 
 ~~An edge text ignored the line break.~~ Fixed. ` / ` split a node's text and was never applied to an edge's, so the marker came out as a literal slash on an arrow and the benchmark's two-line captions had to be flattened to one. The measurer had always returned the split lines; the renderer was handing it the raw string and drawing that instead. The block now centers on the point the text already occupied, so a one-line text sits exactly where it did.
 
+~~An edge whose ends faced away from each other was drawn through its own nodes.~~ Fixed. `from: left  to: right` with the far node further right was one curve bending out at both ends, and with the two nodes in a row it flattened into a straight line through both of them and anything between, its text landing on whatever was in the middle. It was not a matter of exact alignment: a node stepped down a little drew a tilted version of the same line. Such an edge now turns back in the gap between its nodes if there is room, and goes over the top of the row if not. See "Ends that face away from each other".
+
 ## Changelog
 
 Pre-1.0, so the minor number is where a breaking change goes. Every removal below is refused by name with the replacement quoted, rather than dropped in silence — an older file stops with an error saying what to write instead.
 
+**0.6.0**
+
+- An edge whose ends face away from each other, such as `from: left  to: right` with the far node to the right, goes around instead of through its own nodes: through the gap between them if there is room, over the top of the row if not. Several over one row take a lane each. Sides at right angles, such as `from: left  to: top`, go around the same way when one faces away.
+- `above`, `below`, `left of` and `right of` on an edge say which side of a node the line passes: `edge a -> b  below c`. Any number, one per node; one naming several nodes covers the stretch between them too. One edge may mix the two kinds, `below m  left of n`, and the line turns between them as often as they need. Clauses that cannot all be drawn are refused with the reason.
+
+**0.5.0**
+
+- Named themes: `diagram theme: nord`, one of thirteen, and `--theme` on the command line to render a file in another without editing it. The playground has a theme picker, which writes the `theme:` line into the source.
+- `diagram text: (color: …)` sets every text's color at once.
+- `default node | leaf | container | edge` sets what every thing of that kind looks like unless it says otherwise.
+
 **0.4.0**
 
 - A node with any children takes the theme's container colors, however the children are placed. A node with a `badge:` or a single child in a corner now draws as a container too; in 0.3.0 only a node with a title band did. Its text still sits where it did. Say `fill:` and `border:` to keep one looking like a leaf.
@@ -860,6 +1016,7 @@ Pre-1.0, so the minor number is where a breaking change goes. Every removal belo
 
 Open questions the benchmark raised, recorded so a later session does not rediscover them.
 
+- One edge passing some nodes above or below and others left or right — an L-shaped line, across under one node and then down past another — is refused today. Often the picture leaves only one order for the two legs; where two orders both fit, the tool must not pick one, and whether it asks for another clause or follows a standing rule is not decided.
 - Named gaps are the first step toward numbers, but making them minimums took most of the pressure off: they now set how much a diagram breathes, never whether something fits. Whether four names is the right number is still open.
 - Four machines each holding a `files` child with the same text means writing the same line four times. This is the strongest case for a set-level declaration, for terseness rather than for placement.
 - The 2×2 arrangement around a hub is four independent statements, so a fifth machine has no slot to reflow into. There are only eight directions.

package/dist/ast.d.ts

@@ -269,6 +269,13 @@ export interface EdgeStmt {
     textAttrs: Attrs;
     /** `between desktop1 and laptop1` — the gap the line passes through. */
     between?: Passage;
+    /**
+     * `below resolver`, `left of a and b` — which side of a node the line is on
+     * where it passes that node. The placement words, because it is the same
+     * statement about the picture; on an edge it binds only the stretch where the
+     * line is passing, as `between` does. Always `kind: 'offset'` with no gap.
+     */
+    passes?: OffsetPlacement[];
     attrs: Attrs;
     line: number;
 }
@@ -282,8 +289,38 @@ export interface DiagramStmt {
     attrs: Attrs;
     line: number;
 }
-/** The attributes a `diagram` statement understands. */
-export declare const DIAGRAM_KEYS: readonly ["background"];
+/**
+ * The attributes a `diagram` statement understands. `text` takes a bracket,
+ * `text: (color: …)`, and sets the text color of everything at once — the
+ * theme has one text color, shared by nodes and edges, and this is that.
+ */
+export declare const DIAGRAM_KEYS: readonly ["theme", "background", "text"];
+/**
+ * `default leaf  fill: #2e5d3a` — a style that applies to every thing of one
+ * kind without being named. The more specific wins: `node` covers every node,
+ * `leaf` and `container` beat it for the nodes they cover, and a thing's own
+ * styles and words beat any default.
+ */
+export interface DefaultStmt {
+    kind: 'default';
+    target: DefaultTarget;
+    attrs: Attrs;
+    line: number;
+}
+export declare const DEFAULT_TARGETS: readonly ["node", "leaf", "container", "edge"];
+export type DefaultTarget = (typeof DEFAULT_TARGETS)[number];
+/**
+ * What each default may say. A default carries a style's vocabulary, less the
+ * words that would contradict the kind it is written for:
+ *
+ * - A default names its kind, so it is strict where a style is permissive —
+ *   `default edge  fill:` can only be a mistake.
+ * - `badge:` gives a box a child, which makes it a container, so every leaf
+ *   given one by `default leaf` or `default node` would stop being a leaf.
+ * - `icon:` draws a picture, and a picture cannot hold children, so it is a
+ *   leaf's word and not a container's or every node's.
+ */
+export declare const DEFAULT_KEYS: Record<DefaultTarget, readonly string[]>;
 /**
  * The attributes whose value is a color rather than text. A color is written
  * as the viewer will receive it and the renderer keeps no list of color words
@@ -365,7 +402,7 @@ export interface StyleStmt {
     attrs: Attrs;
     line: number;
 }
-export type Stmt = NodeStmt | EdgeStmt | StyleStmt | DiagramStmt;
+export type Stmt = NodeStmt | EdgeStmt | StyleStmt | DiagramStmt | DefaultStmt;
 export interface Document {
     statements: Stmt[];
 }

package/dist/ast.js

@@ -222,8 +222,30 @@ export function describeAxis(axis) {
  * `align` is how its lines range against each other once it is there.
  */
 export const TEXT_KEYS = ['color', 'size', 'wrap', 'align', 'at'];
-/** The attributes a `diagram` statement understands. */
-export const DIAGRAM_KEYS = ['background'];
+/**
+ * The attributes a `diagram` statement understands. `text` takes a bracket,
+ * `text: (color: …)`, and sets the text color of everything at once — the
+ * theme has one text color, shared by nodes and edges, and this is that.
+ */
+export const DIAGRAM_KEYS = ['theme', 'background', 'text'];
+export const DEFAULT_TARGETS = ['node', 'leaf', 'container', 'edge'];
+/**
+ * What each default may say. A default carries a style's vocabulary, less the
+ * words that would contradict the kind it is written for:
+ *
+ * - A default names its kind, so it is strict where a style is permissive —
+ *   `default edge  fill:` can only be a mistake.
+ * - `badge:` gives a box a child, which makes it a container, so every leaf
+ *   given one by `default leaf` or `default node` would stop being a leaf.
+ * - `icon:` draws a picture, and a picture cannot hold children, so it is a
+ *   leaf's word and not a container's or every node's.
+ */
+export const DEFAULT_KEYS = {
+    node: ['style', 'shape', 'fill', 'border', 'text'],
+    leaf: ['style', 'shape', 'icon', 'fill', 'border', 'text'],
+    container: ['style', 'shape', 'badge', 'fill', 'border', 'text'],
+    edge: ['style', 'line', 'text'],
+};
 /**
  * The attributes whose value is a color rather than text. A color is written
  * as the viewer will receive it and the renderer keeps no list of color words

package/dist/cli.js

@@ -3,12 +3,15 @@ import { mkdir, readFile, writeFile } from 'node:fs/promises';
 import { dirname, resolve as resolvePath } from 'node:path';
 import { SourceError } from './errors.js';
 import { compile } from './index.js';
+import { THEME_NAMES, THEMES } from './themes.js';
 const USAGE = `reladraw — render a diagram from stated placement
 
-  reladraw <input.reladraw> [-o <output.svg>]
+  reladraw <input.reladraw> [-o <output.svg>] [--theme <name>]
 
   -o, --out   where to write the SVG. Defaults to the input path with
               its extension replaced by .svg. Use - for standard output.
+  --theme     render in this theme, whatever the file's \`diagram theme:\`
+              says. One of ${THEME_NAMES.join(', ')}.
   -h, --help  print this.
 `;
 async function main(argv) {
@@ -18,6 +21,7 @@ async function main(argv) {
     }
     let input;
     let out;
+    let theme;
     for (let i = 0; i < argv.length; i += 1) {
         const arg = argv[i];
         if (arg === '-o' || arg === '--out') {
@@ -28,6 +32,18 @@ async function main(argv) {
             }
             i += 1;
         }
+        else if (arg === '--theme') {
+            theme = argv[i + 1];
+            if (theme === undefined) {
+                process.stderr.write(`reladraw: --theme needs a name: ${THEME_NAMES.join(', ')}\n`);
+                return 1;
+            }
+            if (THEMES[theme] === undefined) {
+                process.stderr.write(`reladraw: there is no theme called "${theme}" — the themes are ${THEME_NAMES.join(', ')}\n`);
+                return 1;
+            }
+            i += 1;
+        }
         else if (arg.startsWith('-') && arg !== '-') {
             process.stderr.write(`reladraw: unknown option ${arg}\n`);
             return 1;
@@ -47,7 +63,7 @@ async function main(argv) {
     const source = await readFile(input, 'utf8');
     let svg;
     try {
-        svg = compile(source);
+        svg = compile(source, theme === undefined ? {} : { theme: THEMES[theme] });
     }
     catch (error) {
         if (error instanceof SourceError) {

package/dist/grammar.d.ts

@@ -61,7 +61,7 @@ export interface Span {
  * it. A word missing here is a word that draws in the plain color, which is a
  * dull page rather than a wrong one.
  */
-export declare const STATEMENT_KEYWORDS: readonly ["node", "edge", "style", "diagram"];
+export declare const STATEMENT_KEYWORDS: readonly ["node", "edge", "style", "diagram", "default"];
 /**
  * Every word that says something about where a thing goes. Assembled from the
  * lists the parser itself reads, so a direction or a passage axis added there

package/dist/grammar.js

@@ -30,7 +30,7 @@ import { DIRECTIONS, POSITIONS, SIDES, PASSAGE_AXES } from './ast.js';
  * it. A word missing here is a word that draws in the plain color, which is a
  * dull page rather than a wrong one.
  */
-export const STATEMENT_KEYWORDS = ['node', 'edge', 'style', 'diagram'];
+export const STATEMENT_KEYWORDS = ['node', 'edge', 'style', 'diagram', 'default'];
 /** Statements whose second word declares a name. `diagram` has none. */
 const DECLARES_NAME = ['node', 'style'];
 /**

package/dist/index.d.ts

@@ -6,7 +6,8 @@ export * from './measure.js';
 export * from './model.js';
 export { parse } from './parser.js';
 export { resolve, type ResolveOptions } from './resolve.js';
-export { render, DARK_THEME, type RenderOptions, type Theme } from './render.js';
+export { render, type RenderOptions } from './render.js';
+export { DARK_THEME, DEFAULT_THEME, THEMES, THEME_NAMES, type Theme } from './themes.js';
 import { type RenderOptions } from './render.js';
 import { type ResolveOptions } from './resolve.js';
 /** Source text in, SVG out. The whole pipeline in one call. */

package/dist/index.js

@@ -6,7 +6,8 @@ export * from './measure.js';
 export * from './model.js';
 export { parse } from './parser.js';
 export { resolve } from './resolve.js';
-export { render, DARK_THEME } from './render.js';
+export { render } from './render.js';
+export { DARK_THEME, DEFAULT_THEME, THEMES, THEME_NAMES } from './themes.js';
 import { parse } from './parser.js';
 import { render } from './render.js';
 import { resolve } from './resolve.js';

package/dist/model.d.ts

@@ -1,4 +1,4 @@
-import type { Attrs, Axis, Kind, Placement } from './ast.js';
+import type { Attrs, Axis, Direction, Kind, Placement } from './ast.js';
 import type { Line } from './text.js';
 import type { Body } from './icons.js';
 /** A `between` clause with its targets resolved. Mirrors `Passage` in `ast.ts`. */
@@ -7,6 +7,17 @@ export interface LayoutPassage {
     /** Which gap, where the pair has two. Absent when the pair leaves no doubt. */
     axis?: Axis;
 }
+/**
+ * `below resolver` on an edge with its targets resolved: the line is on that
+ * side of the box bounding `nodes`, where it passes them. Mirrors the edge's
+ * `passes` in `ast.ts`.
+ */
+export interface LayoutPass {
+    direction: Direction;
+    nodes: LayoutNode[];
+    /** As the author wrote it, for error messages. */
+    written: string;
+}
 /** A node with its geometry solved. Coordinates are absolute, origin top-left. */
 /** A distance past each side of a box. */
 export interface Reach {
@@ -116,6 +127,8 @@ export interface LayoutEdge {
      * rather than solved for, so edges stay out of the constraint system entirely.
      */
     between?: LayoutPassage;
+    /** Which side of which nodes the line passes. Measured in the renderer, like `between`. */
+    passes?: LayoutPass[];
     attrs: Attrs;
     appearance: Attrs;
     line: number;