reladraw 0.0.1 → 0.1.0

package/dist/constrain.d.ts

@@ -0,0 +1,56 @@
+import type { Placement } from './ast.js';
+/**
+ * The tightest arrangement satisfying a set of relative distances.
+ *
+ * Every placement in the language turns into the same shape of fact: one thing sits
+ * at least so far along an axis from another. Written as `pos[to] >= pos[from]
+ * + weight`, a whole diagram is a system of those, and the arrangement the
+ * author meant is the one where nothing is further apart than it has to be.
+ *
+ * That arrangement is unique and is found by longest paths, so no search
+ * happens and no alternative is ever weighed. Distances come out of the
+ * arithmetic; which side of what a thing sits on came from the author.
+ */
+export interface Constraint {
+    from: number;
+    to: number;
+    weight: number;
+    /** The placement this came from, so a failure can be reported in the author's words. */
+    placement?: Placement;
+}
+/** An exact distance, which is two inequalities pointing opposite ways. */
+export declare function fix(from: number, to: number, distance: number, placement?: Placement): Constraint[];
+export interface Contradiction {
+    /** The placements that cannot all hold. Empty if the loop is entirely implicit. */
+    placements: Placement[];
+}
+/**
+ * Solve, or report the placements that fight.
+ *
+ * Longest path from a virtual source joined to everything at zero, which is
+ * Bellman-Ford with the comparison flipped. A distance that keeps growing after
+ * one pass per node means the constraints run in a circle that demands ever
+ * more room, and that circle is exactly the set of placements to quote back.
+ */
+export declare function tightest(count: number, constraints: Constraint[]): {
+    positions: number[];
+} | {
+    contradiction: Contradiction;
+};
+/**
+ * Which members can be driven apart from which, along one axis.
+ *
+ * A constraint says `pos[to] >= pos[from] + weight`, so it bounds `to` from
+ * below and leaves it free to move further away. Follow those edges and the
+ * question "may this one end up beyond that one?" becomes plain reachability:
+ * if `j` is reachable from `i` and `i` is not reachable from `j`, then the file
+ * lets the distance from `i` to `j` grow without limit and never lets it be
+ * closed from the other side. Pushing `j` past `i` is then the one separation
+ * the file allows, and no choice was made.
+ *
+ * Reachable both ways means the two are pinned at a fixed distance, so they
+ * cannot be separated along this axis at all. Reachable neither way means the
+ * file said nothing that orders them, which is the case the caller must refuse
+ * rather than guess at.
+ */
+export declare function reachability(count: number, constraints: Constraint[]): boolean[][];

package/dist/constrain.js

@@ -0,0 +1,95 @@
+/** An exact distance, which is two inequalities pointing opposite ways. */
+export function fix(from, to, distance, placement) {
+    return [
+        { from, to, weight: distance, ...(placement ? { placement } : {}) },
+        { from: to, to: from, weight: -distance, ...(placement ? { placement } : {}) },
+    ];
+}
+/**
+ * Solve, or report the placements that fight.
+ *
+ * Longest path from a virtual source joined to everything at zero, which is
+ * Bellman-Ford with the comparison flipped. A distance that keeps growing after
+ * one pass per node means the constraints run in a circle that demands ever
+ * more room, and that circle is exactly the set of placements to quote back.
+ */
+export function tightest(count, constraints) {
+    const positions = new Array(count).fill(0);
+    const cameFrom = new Array(count).fill(undefined);
+    for (let pass = 0; pass < count; pass += 1) {
+        let moved = false;
+        for (const constraint of constraints) {
+            const candidate = positions[constraint.from] + constraint.weight;
+            if (candidate > positions[constraint.to] + 1e-9) {
+                positions[constraint.to] = candidate;
+                cameFrom[constraint.to] = constraint;
+                moved = true;
+            }
+        }
+        if (!moved)
+            return { positions };
+    }
+    // Still moving after a full pass per node, so some loop demands more room
+    // every time round it. Walk backwards to find it.
+    for (const constraint of constraints) {
+        if (positions[constraint.from] + constraint.weight > positions[constraint.to] + 1e-9) {
+            return { contradiction: { placements: loopFrom(constraint.to, cameFrom, count) } };
+        }
+    }
+    return { contradiction: { placements: [] } };
+}
+/**
+ * Which members can be driven apart from which, along one axis.
+ *
+ * A constraint says `pos[to] >= pos[from] + weight`, so it bounds `to` from
+ * below and leaves it free to move further away. Follow those edges and the
+ * question "may this one end up beyond that one?" becomes plain reachability:
+ * if `j` is reachable from `i` and `i` is not reachable from `j`, then the file
+ * lets the distance from `i` to `j` grow without limit and never lets it be
+ * closed from the other side. Pushing `j` past `i` is then the one separation
+ * the file allows, and no choice was made.
+ *
+ * Reachable both ways means the two are pinned at a fixed distance, so they
+ * cannot be separated along this axis at all. Reachable neither way means the
+ * file said nothing that orders them, which is the case the caller must refuse
+ * rather than guess at.
+ */
+export function reachability(count, constraints) {
+    const reach = Array.from({ length: count }, () => new Array(count).fill(false));
+    for (const constraint of constraints)
+        reach[constraint.from][constraint.to] = true;
+    for (let via = 0; via < count; via += 1) {
+        for (let from = 0; from < count; from += 1) {
+            if (!reach[from][via])
+                continue;
+            for (let to = 0; to < count; to += 1) {
+                if (reach[via][to])
+                    reach[from][to] = true;
+            }
+        }
+    }
+    return reach;
+}
+/** The placements on the loop reached by following each position back to what set it. */
+function loopFrom(start, cameFrom, count) {
+    let at = start;
+    for (let step = 0; step < count; step += 1) {
+        const previous = cameFrom[at];
+        if (previous === undefined)
+            break;
+        at = previous.from;
+    }
+    const placements = [];
+    const seen = new Set();
+    let cursor = at;
+    while (!seen.has(cursor)) {
+        seen.add(cursor);
+        const previous = cameFrom[cursor];
+        if (previous === undefined)
+            break;
+        if (previous.placement)
+            placements.push(previous.placement);
+        cursor = previous.from;
+    }
+    return placements.reverse();
+}

package/dist/errors.d.ts

@@ -0,0 +1,7 @@
+/** A problem in the source, reported in the vocabulary of the source. */
+export declare class SourceError extends Error {
+    readonly line: number;
+    constructor(message: string, line: number);
+    /** `12: two placements for "server"` — the form the command-line tool prints. */
+    format(file?: string): string;
+}

package/dist/errors.js

@@ -0,0 +1,14 @@
+/** A problem in the source, reported in the vocabulary of the source. */
+export class SourceError extends Error {
+    line;
+    constructor(message, line) {
+        super(message);
+        this.line = line;
+        this.name = 'SourceError';
+    }
+    /** `12: two placements for "server"` — the form the command-line tool prints. */
+    format(file) {
+        const where = file ? `${file}:${this.line}` : `line ${this.line}`;
+        return `${where}: ${this.message}`;
+    }
+}

package/dist/grammar.d.ts

@@ -0,0 +1,103 @@
+/**
+ * The language's *lexical* vocabulary, and a scanner that classifies one line of
+ * source into coloured spans.
+ *
+ * This is deliberately separate from `parser.ts`, and it is not a second parser.
+ * The parser answers "what does this file mean" and refuses anything it cannot
+ * answer for; a highlighter has to colour a half-typed line without complaint,
+ * so it answers only "what kind of word is this" and never fails. Every rule
+ * below is a regex applied to a single line, in priority order, with one bit of
+ * carried state (whether anything has been seen on the line yet, and whether the
+ * previous token was an attribute key).
+ *
+ * **That restriction is the point, and it is what makes this reusable.** An
+ * Emacs `font-lock-keywords` list, a Vim `syntax match` file and a TextMate
+ * grammar are all exactly this: an ordered list of single-line regexes with a
+ * face attached. So the vocabulary here — which is the half that goes stale, and
+ * which is imported from `ast.ts`, `constants.ts` and `icons.ts` rather than
+ * retyped — can be emitted into any of those without this file being ported.
+ * The scanner is the JavaScript consumer of the same spec, and the playground is
+ * its only caller.
+ *
+ * Nothing in the language spans lines: `//` runs to the end of one, a string
+ * closes on one, and there are no blocks. That is the property those editor
+ * formats need and the reason a `.reladraw` grammar is small in all of them.
+ */
+/** What a span of source is, for colouring. */
+export type TokenKind = 
+/** `// to the end of the line` */
+'comment'
+/** A quoted string, quotes included. Unterminated ones count, so typing is quiet. */
+ | 'string'
+/** The word a statement opens with: `box`, `link`, … */
+ | 'keyword'
+/** The name a statement declares, right after its keyword. */
+ | 'name'
+/** `->` and `<->`. */
+ | 'arrow'
+/** Placement and link vocabulary: `right`, `of`, `level`, `with`, `and`, `between`, … */
+ | 'relation'
+/** A `key:` opening an attribute or a bracketed modifier. */
+ | 'attribute'
+/** The single word an attribute takes. */
+ | 'value'
+/** `#14532d`, wherever it appears. */
+ | 'colour'
+/** `(` and `)` around a placement's or a label's modifiers. */
+ | 'bracket'
+/** Everything else: node names being referred to, and whitespace. */
+ | 'plain';
+export interface Span {
+    kind: TokenKind;
+    /** Half-open, in characters, into the line it came from. */
+    start: number;
+    end: number;
+}
+/**
+ * The words a statement may open with. `parseStatement` in `parser.ts` is the
+ * authority — its switch is what actually accepts them — and this list mirrors
+ * it. A word missing here is a word that draws in the plain colour, which is a
+ * dull page rather than a wrong one.
+ */
+export declare const STATEMENT_KEYWORDS: readonly ["box", "note", "link", "deck", "style", "diagram"];
+/**
+ * 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
+ * colours here without anybody remembering to come back.
+ */
+export declare const RELATION_WORDS: string[];
+/**
+ * The patterns, as source strings, so a generator can emit them into another
+ * editor's grammar without reaching into a compiled RegExp. Each is written to
+ * match at the point the scanner has reached; the scanner adds the sticky flag.
+ *
+ * A name may contain dots (containment) and hyphens, which is why the word
+ * pattern is what it is rather than `\w+`.
+ */
+export declare const PATTERNS: {
+    readonly comment: "\\/\\/.*";
+    readonly string: "\"(?:\\\\.|[^\"\\\\])*\"?";
+    readonly keyword: `(?:${string})\\b`;
+    readonly arrow: "<->|->|<-";
+    readonly attribute: "[A-Za-z][A-Za-z0-9_-]*:";
+    readonly colour: "#[0-9A-Fa-f]{3,8}\\b";
+    readonly relation: `(?:${string})\\b`;
+    readonly bracket: "[()]";
+    readonly word: "(?:[^\\s()\"\\/]|\\/(?!\\/))(?:[^\\s\"\\/]|\\/(?!\\/))*";
+    /**
+     * The same, inside an open bracket, where `)` closes the group instead of
+     * being an ordinary character. An editor grammar that cannot count brackets
+     * should use this one throughout: mistaking `rgb(20,20,20)` for three tokens
+     * is a smaller wrong than swallowing the `)` that ends `(gap: tight)`.
+     */
+    readonly wordInGroup: "(?:[^\\s()\"\\/]|\\/(?!\\/))(?:[^\\s)\"\\/]|\\/(?!\\/))*";
+};
+/**
+ * Classify one line. Always returns spans covering it end to end, in order, so a
+ * caller can rebuild the text by concatenation and can trust that nothing was
+ * dropped — which is what a highlighter drawn *behind* a textarea needs, since
+ * a lost character would slide every following one out of register.
+ */
+export declare function highlightLine(line: string): Span[];
+/** Every line of a source file, classified. Line endings are not included. */
+export declare function highlight(source: string): Span[][];

package/dist/grammar.js

@@ -0,0 +1,215 @@
+/**
+ * The language's *lexical* vocabulary, and a scanner that classifies one line of
+ * source into coloured spans.
+ *
+ * This is deliberately separate from `parser.ts`, and it is not a second parser.
+ * The parser answers "what does this file mean" and refuses anything it cannot
+ * answer for; a highlighter has to colour a half-typed line without complaint,
+ * so it answers only "what kind of word is this" and never fails. Every rule
+ * below is a regex applied to a single line, in priority order, with one bit of
+ * carried state (whether anything has been seen on the line yet, and whether the
+ * previous token was an attribute key).
+ *
+ * **That restriction is the point, and it is what makes this reusable.** An
+ * Emacs `font-lock-keywords` list, a Vim `syntax match` file and a TextMate
+ * grammar are all exactly this: an ordered list of single-line regexes with a
+ * face attached. So the vocabulary here — which is the half that goes stale, and
+ * which is imported from `ast.ts`, `constants.ts` and `icons.ts` rather than
+ * retyped — can be emitted into any of those without this file being ported.
+ * The scanner is the JavaScript consumer of the same spec, and the playground is
+ * its only caller.
+ *
+ * Nothing in the language spans lines: `//` runs to the end of one, a string
+ * closes on one, and there are no blocks. That is the property those editor
+ * formats need and the reason a `.reladraw` grammar is small in all of them.
+ */
+import { DIRECTIONS, EDGES, PASSAGE_AXES } from './ast.js';
+/**
+ * The words a statement may open with. `parseStatement` in `parser.ts` is the
+ * authority — its switch is what actually accepts them — and this list mirrors
+ * it. A word missing here is a word that draws in the plain colour, which is a
+ * dull page rather than a wrong one.
+ */
+export const STATEMENT_KEYWORDS = ['box', 'note', 'link', 'deck', 'style', 'diagram'];
+/** Statements whose second word declares a name. `diagram` has none. */
+const DECLARES_NAME = ['box', 'note', 'deck', 'style'];
+/**
+ * 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
+ * colours here without anybody remembering to come back.
+ */
+export const RELATION_WORDS = [
+    ...DIRECTIONS,
+    ...EDGES,
+    ...Object.keys(PASSAGE_AXES),
+    // The connecting words. `of` is optional after a direction, `and` joins
+    // targets, `between` opens a passage, `level with` is the alignment.
+    'of',
+    'and',
+    'level',
+    'with',
+    'between',
+];
+/** Longest first, so `above-left` is not read as `above` followed by `-left`. */
+function alternation(words) {
+    return [...new Set(words)].sort((a, b) => b.length - a.length).join('|');
+}
+/**
+ * The patterns, as source strings, so a generator can emit them into another
+ * editor's grammar without reaching into a compiled RegExp. Each is written to
+ * match at the point the scanner has reached; the scanner adds the sticky flag.
+ *
+ * A name may contain dots (containment) and hyphens, which is why the word
+ * pattern is what it is rather than `\w+`.
+ */
+export const PATTERNS = {
+    comment: '\\/\\/.*',
+    // The closing quote is optional: every string is unterminated for as long as
+    // it is being typed, and a highlighter that waits for the quote repaints the
+    // rest of the file on every keystroke.
+    string: '"(?:\\\\.|[^"\\\\])*"?',
+    keyword: `(?:${alternation(STATEMENT_KEYWORDS)})\\b`,
+    // `<->` first, or `<-` would match its opening half and leave a stray `>`.
+    arrow: '<->|->|<-',
+    attribute: '[A-Za-z][A-Za-z0-9_-]*:',
+    colour: '#[0-9A-Fa-f]{3,8}\\b',
+    relation: `(?:${alternation(RELATION_WORDS)})\\b`,
+    bracket: '[()]',
+    // Matches what `tokenizeLine` treats as one bare token, and the awkwardness is
+    // load-bearing rather than accidental. A `(` counts as punctuation only where
+    // a token starts, so `rgb(20,20,20)` is one word — hence the first character
+    // being spelled differently from the rest. A lone `/` is ordinary and only a
+    // doubled one opens a comment, which is what the lookahead is for.
+    word: '(?:[^\\s()"\\/]|\\/(?!\\/))(?:[^\\s"\\/]|\\/(?!\\/))*',
+    /**
+     * The same, inside an open bracket, where `)` closes the group instead of
+     * being an ordinary character. An editor grammar that cannot count brackets
+     * should use this one throughout: mistaking `rgb(20,20,20)` for three tokens
+     * is a smaller wrong than swallowing the `)` that ends `(gap: tight)`.
+     */
+    wordInGroup: '(?:[^\\s()"\\/]|\\/(?!\\/))(?:[^\\s)"\\/]|\\/(?!\\/))*',
+};
+/**
+ * The rules that are pure regex, in priority order. Three things are missing and
+ * each for a reason: a comment wins over all of them and is tried first, a
+ * bracket is punctuation only at certain depths so the scanner counts them
+ * itself, and the catch-all word rule varies with that same depth and is
+ * appended per call.
+ */
+const RULES = [
+    { kind: 'string', re: sticky(PATTERNS.string) },
+    { kind: 'arrow', re: sticky(PATTERNS.arrow) },
+    // Before `relation`, because the trailing colon is what tells `left: …` from
+    // the `left` of a placement, and after `arrow` so `->` is never a word.
+    { kind: 'attribute', re: sticky(PATTERNS.attribute) },
+    { kind: 'colour', re: sticky(PATTERNS.colour) },
+    { kind: 'relation', re: sticky(PATTERNS.relation) },
+];
+const SPACE = sticky('[ \\t]+');
+const COMMENT = sticky(PATTERNS.comment);
+const KEYWORD = sticky(PATTERNS.keyword);
+const WORD = sticky(PATTERNS.word);
+const WORD_IN_GROUP = sticky(PATTERNS.wordInGroup);
+function sticky(source) {
+    return new RegExp(source, 'y');
+}
+function match(re, line, at) {
+    re.lastIndex = at;
+    const found = re.exec(line);
+    return found ? found[0] : null;
+}
+/**
+ * Classify one line. Always returns spans covering it end to end, in order, so a
+ * caller can rebuild the text by concatenation and can trust that nothing was
+ * dropped — which is what a highlighter drawn *behind* a textarea needs, since
+ * a lost character would slide every following one out of register.
+ */
+export function highlightLine(line) {
+    const spans = [];
+    let at = 0;
+    /** Nothing but whitespace seen yet, so the next word is the statement keyword. */
+    let opening = true;
+    /** The last thing emitted was a `key:`, so the next word is its value. */
+    let expectingValue = false;
+    /** How many brackets are open, which is what makes a `)` punctuation. */
+    let depth = 0;
+    const push = (kind, end) => {
+        spans.push({ kind, start: at, end });
+        at = end;
+    };
+    while (at < line.length) {
+        const gap = match(SPACE, line, at);
+        if (gap !== null) {
+            push('plain', at + gap.length);
+            continue;
+        }
+        // A comment wins everywhere, including in the middle of a statement.
+        const comment = match(COMMENT, line, at);
+        if (comment !== null) {
+            push('comment', at + comment.length);
+            continue;
+        }
+        if (opening) {
+            opening = false;
+            const keyword = match(KEYWORD, line, at);
+            if (keyword !== null) {
+                push('keyword', at + keyword.length);
+                if (DECLARES_NAME.includes(keyword)) {
+                    const space = match(SPACE, line, at);
+                    if (space !== null) {
+                        push('plain', at + space.length);
+                        const name = match(WORD, line, at);
+                        // `style backup  stroke: …` declares a name; `box  fill: red` is a
+                        // half-typed line whose second word is already an attribute, and
+                        // colouring that as a name would be a lie about what it is.
+                        if (name !== null && !name.endsWith(':'))
+                            push('name', at + name.length);
+                    }
+                }
+                continue;
+            }
+        }
+        // Brackets before the rest, and only where they are really punctuation: an
+        // opening one wherever a token starts, a closing one only while a group is
+        // open. That is `tokenizeLine`'s rule, and it is what keeps an unquoted
+        // `rgb(20,20,20)` a single word rather than three.
+        const ch = line[at];
+        if (ch === '(') {
+            depth += 1;
+            expectingValue = false;
+            push('bracket', at + 1);
+            continue;
+        }
+        if (ch === ')' && depth > 0) {
+            depth -= 1;
+            expectingValue = false;
+            push('bracket', at + 1);
+            continue;
+        }
+        let matched = false;
+        for (const rule of [...RULES, { kind: 'plain', re: depth > 0 ? WORD_IN_GROUP : WORD }]) {
+            const text = match(rule.re, line, at);
+            if (text === null)
+                continue;
+            // An attribute's value is whatever single token follows it, whatever it
+            // would otherwise have been called: `to: right` is a value, not a
+            // direction, and `style: wide` is a style name, not a gap.
+            const kind = expectingValue && rule.kind !== 'string' && rule.kind !== 'colour' && rule.kind !== 'bracket'
+                ? 'value'
+                : rule.kind;
+            expectingValue = rule.kind === 'attribute';
+            push(kind, at + text.length);
+            matched = true;
+            break;
+        }
+        // Nothing in `RULES` can fail on a non-space character, but a scanner that
+        // could loop forever is not worth the saved line.
+        if (!matched)
+            push('plain', at + 1);
+    }
+    return spans;
+}
+/** Every line of a source file, classified. Line endings are not included. */
+export function highlight(source) {
+    return source.split(/\r?\n/).map(highlightLine);
+}

package/dist/icons.d.ts

@@ -0,0 +1,86 @@
+/**
+ * The built-in icon set.
+ *
+ * Every glyph is path data written into the SVG, and that is the whole reason
+ * this file exists rather than a dependency. The output contract is a standalone
+ * document: an icon font would render as blank boxes on any machine that does
+ * not have the font, and an `<image href>` would need the file to travel beside
+ * the SVG. Inline paths cost a few hundred bytes each and always arrive.
+ *
+ * A name here says what the thing *is*, never what the picture looks like. The
+ * same discipline as `gap: wide` over `gap: 110` and `muted` over a hex value:
+ * the word is the whole interface, so it has to carry meaning rather than
+ * geometry, and naming the meaning is what lets the drawing be improved later
+ * without every diagram that uses it changing sense.
+ *
+ * The set is deliberately small. In a drawing tool you pick a shape out of a
+ * visual palette and hundreds are browsable; here you type the word from memory,
+ * which caps the useful vocabulary at something that fits in a head. Add a name
+ * when a diagram asks for a distinction it cannot otherwise make.
+ */
+/**
+ * Icons carry three tones rather than colours. `ink` is the drawn line, `shade`
+ * the body it encloses, and `void` is the page showing through — the same
+ * knockout a link label already uses. Naming tones instead of colours is what
+ * lets one glyph sit correctly on a dark theme and a light one.
+ */
+export type IconTone = 'ink' | 'shade' | 'void';
+export interface IconPath {
+    d: string;
+    fill?: IconTone;
+    stroke?: IconTone;
+}
+export interface Icon {
+    /** Side of the square the paths are drawn on. Scaled to the drawn size. */
+    readonly grid: number;
+    readonly paths: readonly IconPath[];
+}
+/** Line width on the 24-unit grid, scaled with everything else. */
+export declare const ICON_STROKE = 1.1;
+export declare const ICONS: Record<string, Icon>;
+export declare const ICON_NAMES: string[];
+/**
+ * The icon a node asks for, or nothing. Called by the resolver, which reserves
+ * the room, and by the renderer, which fills it, so the two cannot disagree
+ * about whether there is an icon at all.
+ *
+ * An unknown name is refused rather than dropped. That is the same rule
+ * `DIAGRAM_KEYS` follows and it is here for the same reason: a misspelt
+ * `icon: laptp` that quietly draws nothing is indistinguishable from the tool
+ * being broken, and an author will stare at the file looking for the mistake in
+ * the wrong place. Since the vocabulary is closed and short, the error can list
+ * the whole of it.
+ */
+/**
+ * The outlines a box can take. `box` is the plain rectangle and needs no word.
+ *
+ * Named for what a node *is*, never for the geometry, which is the same rule the
+ * icon names follow: `document` and not `folded-corner`. A shape carrying a
+ * conventional meaning is a second channel alongside colour, and a stronger one
+ * — a fill is whatever the author assigned and has to be learnt from the
+ * diagram, while a folded corner has meant "an artifact, not a process" in
+ * flowcharts for decades and reads with no legend at all.
+ */
+export declare const BOX_SHAPES: readonly ["document"];
+export type BoxShape = 'box' | (typeof BOX_SHAPES)[number];
+export interface NodeShape {
+    outline: BoxShape;
+    /**
+     * Set when the node is drawn as a glyph rather than as a box. There is then
+     * no outline, no fill and no padding: the node *is* the picture, and its size
+     * is the picture's. `icon:` decorates a box, this replaces it.
+     */
+    body?: Icon;
+}
+/**
+ * What a node is drawn as. Shared by the resolver, which sizes it, and the
+ * renderer, which draws it.
+ *
+ * The value is either a box outline or the name of a glyph. Those are the two
+ * things "what is this drawn as" can answer, and the author has no reason to
+ * care which category their answer fell into. The test that separates them is
+ * whether the node still sizes itself from its label: a `document` does, a
+ * glyph does not.
+ */
+export declare function shapeFor(appearance: Record<string, string>, line: number): NodeShape;
+export declare function iconFor(appearance: Record<string, string>, line: number): Icon | undefined;