@fundar/data-chart-telling 0.0.25 → 0.0.27

package/dist/plots/scatter/buildScatterMarkers.d.ts

@@ -0,0 +1,11 @@
+import type { Series, Accessor } from '../../types/plots/data/common';
+import type { ScatterSegmentStyle } from '../../types/plots/segments/common';
+import type { VisualGroup } from '../../types/plots/segments/config';
+import type { DotStyle } from '../../types/plots/styling';
+import type { DotMarkerConfig } from '../../types/markers/common';
+/** Every `'dot'` marker for one ScatterPlot render: one per visual segment. */
+export declare function buildScatterMarkers<TData extends Record<string, unknown>>(args: {
+    groupedSeries: VisualGroup<Series<TData>, ScatterSegmentStyle>[];
+    r?: Accessor<TData, number> | number;
+    disabledDotsFor: (seriesName: string) => DotStyle | undefined;
+}): DotMarkerConfig[];

package/dist/plots/scatter/buildScatterMarkers.js

@@ -0,0 +1,37 @@
+import { resolveAccessor } from '../utils/accessors';
+import { paletteColor } from '../../utils/color';
+import { getConfiguration } from '../../configuration/config.svelte';
+/** Every `'dot'` marker for one ScatterPlot render: one per visual segment. */
+export function buildScatterMarkers(args) {
+    const { groupedSeries, r, disabledDotsFor } = args;
+    const cfg = getConfiguration();
+    const rFn = r === undefined || typeof r === 'number' ? r : resolveAccessor(r);
+    const markers = [];
+    groupedSeries.forEach((group, seriesIndex) => {
+        const defaultColor = paletteColor(seriesIndex, cfg.palette);
+        const disabledDots = disabledDotsFor(group.series.name);
+        const xFn = resolveAccessor(group.series.x);
+        const yFn = resolveAccessor(group.series.y);
+        for (const seg of group.visualSegments) {
+            const dotStyle = seg.style;
+            markers.push({
+                type: 'dot',
+                data: seg.data,
+                x: xFn,
+                y: yFn,
+                r: rFn,
+                style: {
+                    dotRadius: disabledDots?.dotRadius ?? dotStyle.dotRadius ?? cfg.scatter.dotRadius,
+                    dotFill: disabledDots?.dotFill ?? dotStyle.dotFill ?? defaultColor,
+                    dotSymbol: disabledDots?.dotSymbol ?? dotStyle.dotSymbol,
+                    dotStroke: disabledDots?.dotStroke ?? dotStyle.dotStroke,
+                    dotStrokeWidth: disabledDots?.dotStrokeWidth ?? dotStyle.dotStrokeWidth,
+                    dotFillOpacity: disabledDots?.dotFillOpacity ?? dotStyle.dotFillOpacity,
+                    dotStrokeOpacity: disabledDots?.dotStrokeOpacity ?? dotStyle.dotStrokeOpacity,
+                    dotStrokeDasharray: disabledDots?.dotStrokeDasharray ?? dotStyle.dotStrokeDasharray,
+                },
+            });
+        }
+    });
+    return markers;
+}

package/dist/plots/scatter/resolveRadiusPaddedDomain.d.ts

@@ -0,0 +1,10 @@
+/**
+ * Extends a `[min, max]` data domain so the largest rendered dot radius
+ * doesn't get clipped by the plot's own frame — svelteplot's own `'auto'`
+ * margin only measures axis chrome (tick labels), never mark geometry, so a
+ * point sitting at the domain edge with a non-trivial radius otherwise
+ * overflows past the frame. `innerSizePx` is an estimate (the real pixel
+ * range isn't known until the scale itself is built from this domain), so
+ * this errs generous rather than exact.
+ */
+export declare function resolveRadiusPaddedDomain(values: number[], maxRadiusPx: number, innerSizePx: number): [number, number] | undefined;

package/dist/plots/scatter/resolveRadiusPaddedDomain.js

@@ -0,0 +1,23 @@
+/**
+ * Extends a `[min, max]` data domain so the largest rendered dot radius
+ * doesn't get clipped by the plot's own frame — svelteplot's own `'auto'`
+ * margin only measures axis chrome (tick labels), never mark geometry, so a
+ * point sitting at the domain edge with a non-trivial radius otherwise
+ * overflows past the frame. `innerSizePx` is an estimate (the real pixel
+ * range isn't known until the scale itself is built from this domain), so
+ * this errs generous rather than exact.
+ */
+export function resolveRadiusPaddedDomain(values, maxRadiusPx, innerSizePx) {
+    const finite = values.filter((v) => Number.isFinite(v));
+    if (finite.length === 0 || innerSizePx <= 0 || maxRadiusPx <= 0)
+        return undefined;
+    const min = Math.min(...finite);
+    const max = Math.max(...finite);
+    if (min === max) {
+        // A degenerate single-value domain has no data-per-pixel ratio to pad by — fall back to a fixed unit either side.
+        return [min - 1, max + 1];
+    }
+    const dataPerPixel = (max - min) / innerSizePx;
+    const pad = maxRadiusPx * dataPerPixel;
+    return [min - pad, max + pad];
+}

package/dist/plots/utils/declutter.d.ts

@@ -45,55 +45,73 @@ export type Declutter1DResult<T> = {
  * that side, so a plain 50/50 blend would still ask the up-pass and
  * down-pass to pull the block symmetrically toward *both* edges before
  * `fitRunsWithinBounds` shifts/shrinks it back — the up-pass reaching for
- * room that was never really there. That round trip is exactly what makes
- * individual members travel far past their neighbours' original positions
- * (`laneAssignment`'s doc comment calls this out as the thing that forces an
- * unsafe, overlapping travel span), so a run near an edge leans toward
- * whichever pass already grows away from it instead — the block still
- * expands to clear `minGap` everywhere, just mostly in the one direction
- * that was actually available, the way a person sliding books apart on a
- * shelf pinned against one wall would.
+ * room that was never really there, needlessly widening how far members end
+ * up travelling from their original positions (`laneAssignment`'s own lane
+ * count grows with exactly that travel distance — see its doc comment) — so
+ * a run near an edge leans toward whichever pass already grows away from it
+ * instead — the block still expands to clear `minGap` everywhere, just
+ * mostly in the one direction that was actually available, the way a person
+ * sliding books apart on a shelf pinned against one wall would.
  */
 export declare function declutter1D<T extends {
     pos: number;
 }>(items: T[], minGap: number, bounds?: readonly [number, number]): Declutter1DResult<T>;
 /**
  * Groups `declutter1D`'s own `connected` flags into runs (maximal stretches
- * of consecutive connected pairs), then assigns each run member a lane by
- * *mirrored* position — the run's top and bottom member share lane 0, the
- * next-in-from-top and next-in-from-bottom share lane 1, and so on toward
- * the run's centre (an odd-sized run's exact middle member gets the
- * innermost lane alone) — but only after checking that a proposed pair's
- * *travel spans* (`[min(original, final), max(original, final)]`, the pixel
- * range a leader line's vertical segment actually sweeps through) don't
- * overlap. A pair that would collide is split into two lanes of its own
- * instead of one shared one, so correctness never depends on the pairing
- * being right — only on this check.
+ * of consecutive connected pairs), then gives every run member its own,
+ * unique lane — no two members ever share one, deliberately (see below) —
+ * ordered so that a leader line drawn through lane `rank` never crosses, or
+ * even draws visually flush against, one drawn through any other lane of
+ * the same run.
  *
- * Mirrored position is still the *first* thing tried, not span-overlap
- * colouring picking lanes on its own, because minimizing lane count isn't
- * actually the goal here — a run of `n` safely-non-overlapping members could
- * often be greedily packed into far fewer than `ceil(n / 2)` lanes, but
- * doing that defeats the point: it's what visually fans a pileup's leader
- * lines apart in the first place. Mirrored pairing keeps that fan-out
- * exactly where it's safe (the common case for `declutter1D`'s own output),
- * and only degrades — never breaks — where it isn't.
+ * Every member's leader line is the same three-segment elbow: a horizontal
+ * stub from the data point out to its lane, a vertical run up/down that
+ * lane to the label's height, then a final horizontal run in to the shared
+ * label column. Two such elbows, `i` (in the tighter of the two lanes) and
+ * `j` (further out), are safe from crossing *specifically* when neither of
+ * these can happen:
+ * - `j`'s own stub (at `j`'s original height) reaches out past `i`'s lane
+ *   while `i`'s vertical run passes through that height — `j`'s stub would
+ *   cut across `i`'s vertical segment.
+ * - `i`'s final run (at `i`'s label height) reaches past `i`'s own lane out
+ *   to the shared column, and in doing so crosses `j`'s lane while `j`'s
+ *   vertical run passes through *that* height — `i`'s own final segment
+ *   would cut across `j`'s vertical segment.
  *
- * A run whose members still end up with genuinely overlapping travel spans
- * (heavy, edge-adjacent compression) has no lane assignment that's both
- * crossing-free *and* touch-free under this shared-`px`/shared-`labelX`
- * elbow geometry — sharing draws two segments on top of each other, splitting
- * draws an actual crossing. `declutter1D`'s bounds-aware margin bias (see its
- * own doc comment) exists specifically to keep that from happening in the
- * first place, by keeping a run's displacement mostly one-directional when
- * it sits close to an edge, rather than papering over it here.
+ * Whether `i` can safely take the tighter lane depends on both members'
+ * *actual* pixel geometry — not simply on which one moved further — so each
+ * pair is checked directly per {@link saferNearer} rather than inferred from
+ * a single sort key. A pair with a clean, provable answer either way (the
+ * overwhelmingly common case for `declutter1D`'s own output) is ordered by
+ * that answer; a pair with no clean answer (both directions equally
+ * "unsafe," or, symmetrically, both fine) falls back to the same *travel
+ * distance* heuristic used before this per-pair check existed — furthest
+ * `|final - original|` first — which is what decides ties and keeps the
+ * "furthest traveller gets the tightest lane, so it starts bending
+ * immediately rather than reaching across everyone else's leader lines
+ * first" intent for every pair the geometry itself doesn't already settle.
+ *
+ * No sharing, ever, is the other half of this: two members can only have
+ * non-overlapping travel spans (and so pass the old, now-removed,
+ * share-a-lane check) by sitting far apart along the axis — but "far apart"
+ * is exactly the case with the most room to spare, so it never needed the
+ * lane it would save by sharing, while any pair close enough to actually be
+ * short on room has spans close enough together that sharing draws their
+ * two leader lines only a couple pixels apart — visually indistinguishable
+ * from one continuous line touching the next label down. A run of `n`
+ * members uses exactly `n` lanes; letting the lane count grow is the price
+ * of a fan that never has two leader lines touching *or* crossing, and
+ * `ValueLabels`' own auto-margin measurement (see its doc comment) already
+ * grows `margins.right` to fit however many lanes that turns out to be, so
+ * nothing has to be guessed up front.
  *
  * `rank` is the lane index (0-indexed) to drive a leader line's routing:
  * `rank` 0 bends right off the data point (a short first stub); higher
  * ranks travel further before bending (right up to the shared label
- * column). `lanesUsed` is the run's own total lane count (shared by every
- * member); `runSize` is the run's member count, for callers that just need
- * to know whether a given member belongs to a real run at all.
+ * column). `lanesUsed` is the run's own total lane count — always equal to
+ * `runSize` — shared by every member; `runSize` is the run's member count,
+ * for callers that just need to know whether a given member belongs to a
+ * real run at all.
  */
 export declare function laneAssignment(originals: number[], finals: number[], connected: boolean[]): {
     rank: number;

package/dist/plots/utils/declutter.js

@@ -34,14 +34,13 @@
  * that side, so a plain 50/50 blend would still ask the up-pass and
  * down-pass to pull the block symmetrically toward *both* edges before
  * `fitRunsWithinBounds` shifts/shrinks it back — the up-pass reaching for
- * room that was never really there. That round trip is exactly what makes
- * individual members travel far past their neighbours' original positions
- * (`laneAssignment`'s doc comment calls this out as the thing that forces an
- * unsafe, overlapping travel span), so a run near an edge leans toward
- * whichever pass already grows away from it instead — the block still
- * expands to clear `minGap` everywhere, just mostly in the one direction
- * that was actually available, the way a person sliding books apart on a
- * shelf pinned against one wall would.
+ * room that was never really there, needlessly widening how far members end
+ * up travelling from their original positions (`laneAssignment`'s own lane
+ * count grows with exactly that travel distance — see its doc comment) — so
+ * a run near an edge leans toward whichever pass already grows away from it
+ * instead — the block still expands to clear `minGap` everywhere, just
+ * mostly in the one direction that was actually available, the way a person
+ * sliding books apart on a shelf pinned against one wall would.
  */
 export function declutter1D(items, minGap, bounds) {
     const sorted = [...items].sort((a, b) => a.pos - b.pos);
@@ -137,41 +136,60 @@ function fitRunsWithinBounds(positions, connected, [lo, hi]) {
 }
 /**
  * Groups `declutter1D`'s own `connected` flags into runs (maximal stretches
- * of consecutive connected pairs), then assigns each run member a lane by
- * *mirrored* position — the run's top and bottom member share lane 0, the
- * next-in-from-top and next-in-from-bottom share lane 1, and so on toward
- * the run's centre (an odd-sized run's exact middle member gets the
- * innermost lane alone) — but only after checking that a proposed pair's
- * *travel spans* (`[min(original, final), max(original, final)]`, the pixel
- * range a leader line's vertical segment actually sweeps through) don't
- * overlap. A pair that would collide is split into two lanes of its own
- * instead of one shared one, so correctness never depends on the pairing
- * being right — only on this check.
+ * of consecutive connected pairs), then gives every run member its own,
+ * unique lane — no two members ever share one, deliberately (see below) —
+ * ordered so that a leader line drawn through lane `rank` never crosses, or
+ * even draws visually flush against, one drawn through any other lane of
+ * the same run.
  *
- * Mirrored position is still the *first* thing tried, not span-overlap
- * colouring picking lanes on its own, because minimizing lane count isn't
- * actually the goal here — a run of `n` safely-non-overlapping members could
- * often be greedily packed into far fewer than `ceil(n / 2)` lanes, but
- * doing that defeats the point: it's what visually fans a pileup's leader
- * lines apart in the first place. Mirrored pairing keeps that fan-out
- * exactly where it's safe (the common case for `declutter1D`'s own output),
- * and only degrades — never breaks — where it isn't.
+ * Every member's leader line is the same three-segment elbow: a horizontal
+ * stub from the data point out to its lane, a vertical run up/down that
+ * lane to the label's height, then a final horizontal run in to the shared
+ * label column. Two such elbows, `i` (in the tighter of the two lanes) and
+ * `j` (further out), are safe from crossing *specifically* when neither of
+ * these can happen:
+ * - `j`'s own stub (at `j`'s original height) reaches out past `i`'s lane
+ *   while `i`'s vertical run passes through that height — `j`'s stub would
+ *   cut across `i`'s vertical segment.
+ * - `i`'s final run (at `i`'s label height) reaches past `i`'s own lane out
+ *   to the shared column, and in doing so crosses `j`'s lane while `j`'s
+ *   vertical run passes through *that* height — `i`'s own final segment
+ *   would cut across `j`'s vertical segment.
  *
- * A run whose members still end up with genuinely overlapping travel spans
- * (heavy, edge-adjacent compression) has no lane assignment that's both
- * crossing-free *and* touch-free under this shared-`px`/shared-`labelX`
- * elbow geometry — sharing draws two segments on top of each other, splitting
- * draws an actual crossing. `declutter1D`'s bounds-aware margin bias (see its
- * own doc comment) exists specifically to keep that from happening in the
- * first place, by keeping a run's displacement mostly one-directional when
- * it sits close to an edge, rather than papering over it here.
+ * Whether `i` can safely take the tighter lane depends on both members'
+ * *actual* pixel geometry — not simply on which one moved further — so each
+ * pair is checked directly per {@link saferNearer} rather than inferred from
+ * a single sort key. A pair with a clean, provable answer either way (the
+ * overwhelmingly common case for `declutter1D`'s own output) is ordered by
+ * that answer; a pair with no clean answer (both directions equally
+ * "unsafe," or, symmetrically, both fine) falls back to the same *travel
+ * distance* heuristic used before this per-pair check existed — furthest
+ * `|final - original|` first — which is what decides ties and keeps the
+ * "furthest traveller gets the tightest lane, so it starts bending
+ * immediately rather than reaching across everyone else's leader lines
+ * first" intent for every pair the geometry itself doesn't already settle.
+ *
+ * No sharing, ever, is the other half of this: two members can only have
+ * non-overlapping travel spans (and so pass the old, now-removed,
+ * share-a-lane check) by sitting far apart along the axis — but "far apart"
+ * is exactly the case with the most room to spare, so it never needed the
+ * lane it would save by sharing, while any pair close enough to actually be
+ * short on room has spans close enough together that sharing draws their
+ * two leader lines only a couple pixels apart — visually indistinguishable
+ * from one continuous line touching the next label down. A run of `n`
+ * members uses exactly `n` lanes; letting the lane count grow is the price
+ * of a fan that never has two leader lines touching *or* crossing, and
+ * `ValueLabels`' own auto-margin measurement (see its doc comment) already
+ * grows `margins.right` to fit however many lanes that turns out to be, so
+ * nothing has to be guessed up front.
  *
  * `rank` is the lane index (0-indexed) to drive a leader line's routing:
  * `rank` 0 bends right off the data point (a short first stub); higher
  * ranks travel further before bending (right up to the shared label
- * column). `lanesUsed` is the run's own total lane count (shared by every
- * member); `runSize` is the run's member count, for callers that just need
- * to know whether a given member belongs to a real run at all.
+ * column). `lanesUsed` is the run's own total lane count — always equal to
+ * `runSize` — shared by every member; `runSize` is the run's member count,
+ * for callers that just need to know whether a given member belongs to a
+ * real run at all.
  */
 export function laneAssignment(originals, finals, connected) {
     const n = connected.length + 1;
@@ -181,7 +199,15 @@ export function laneAssignment(originals, finals, connected) {
         const b = finals[k];
         return a < b ? [a, b] : [b, a];
     };
-    const overlaps = (a, b) => a[0] < b[1] && b[0] < a[1];
+    const distance = (k) => Math.abs(finals[k] - originals[k]);
+    /** Whether lane-`i`-nearer-than-`j` is provably crossing-free — see this function's doc comment. */
+    function saferNearer(i, j) {
+        const [loI, hiI] = span(i);
+        const [loJ, hiJ] = span(j);
+        const jStubCutsI = originals[j] >= loI && originals[j] <= hiI;
+        const iFinalCutsJ = finals[i] >= loJ && finals[i] <= hiJ;
+        return !jStubCutsI && !iFinalCutsJ;
+    }
     let i = 0;
     while (i < n) {
         let j = i;
@@ -189,32 +215,21 @@ export function laneAssignment(originals, finals, connected) {
             j++;
         const runSize = j - i + 1;
         if (runSize > 1) {
-            const rankOf = new Array(runSize);
-            let lo = 0;
-            let hi = runSize - 1;
-            let nextLane = 0;
-            while (lo <= hi) {
-                if (lo === hi) {
-                    rankOf[lo] = nextLane;
-                    nextLane += 1;
-                }
-                else if (!overlaps(span(i + lo), span(i + hi))) {
-                    rankOf[lo] = nextLane;
-                    rankOf[hi] = nextLane;
-                    nextLane += 1;
-                }
-                else {
-                    rankOf[lo] = nextLane;
-                    rankOf[hi] = nextLane + 1;
-                    nextLane += 2;
-                }
-                lo += 1;
-                hi -= 1;
-            }
-            const lanesUsed = nextLane;
-            for (let k = 0; k < runSize; k++) {
-                out[i + k] = { rank: rankOf[k], lanesUsed, runSize };
-            }
+            // Members of this run, ordered so each is provably safe to place
+            // nearer than the next whenever that's decidable, furthest-travelled
+            // first otherwise (ties keep their original — i.e. top-to-bottom —
+            // order, since `sort` is stable). Position in this order *is* the
+            // rank: no sharing.
+            const order = Array.from({ length: runSize }, (_, k) => i + k).sort((a, b) => {
+                const aNearer = saferNearer(a, b);
+                const bNearer = saferNearer(b, a);
+                if (aNearer !== bNearer)
+                    return aNearer ? -1 : 1;
+                return distance(b) - distance(a);
+            });
+            order.forEach((k, rank) => {
+                out[k] = { rank, lanesUsed: runSize, runSize };
+            });
         }
         i = j + 1;
     }

package/dist/plots/utils/geoAccessors.d.ts

@@ -36,7 +36,7 @@ export declare function geometryPartCentroids(geometry: GeoJSON.Geometry): [numb
  * based on a per-part predicate, reassembling a geometry of the same type
  * from whatever survives — `null` if nothing does. Used to let a single
  * feature's geometry be split between the main map and an `inset` marker
- * (see `GeoDataProps.excludeParts`/`GeoInsetMarker.featurePartsFilter`)
+ * (see `GeoDataProps.excludeParts`/`GeoInsetMarkerConfig.featurePartsFilter`)
  * without preprocessing the source data: e.g. a province whose `MultiPolygon`
  * spans both a mainland part and a far-flung part can have the main map
  * exclude the latter while an inset shows only it.

package/dist/plots/utils/geoAccessors.js

@@ -102,7 +102,7 @@ export function geometryPartCentroids(geometry) {
  * based on a per-part predicate, reassembling a geometry of the same type
  * from whatever survives — `null` if nothing does. Used to let a single
  * feature's geometry be split between the main map and an `inset` marker
- * (see `GeoDataProps.excludeParts`/`GeoInsetMarker.featurePartsFilter`)
+ * (see `GeoDataProps.excludeParts`/`GeoInsetMarkerConfig.featurePartsFilter`)
  * without preprocessing the source data: e.g. a province whose `MultiPolygon`
  * spans both a mainland part and a far-flung part can have the main map
  * exclude the latter while an inset shows only it.

package/dist/plots/utils/labelOverflow.svelte.d.ts

@@ -0,0 +1,51 @@
+import type { MarginConfig } from '../../types/plots/props';
+/** How far a value label's rendered box extends past the plot's own content box, in pixels, on each side (0 = no overflow). */
+export type MarginOverflow = {
+    left: number;
+    right: number;
+    top: number;
+    bottom: number;
+};
+/**
+ * Watches an SVG group's rendered bounding box against the plot's own
+ * content box (`bounds`) and reports how far it overflows on each side.
+ * Polled across successive paints until two consecutive readings agree,
+ * rather than trusted after a single frame: the group's own resolved
+ * geometry (driven by svelteplot's separate reactive graph) and svelteplot's
+ * own axis auto-margins can take a variable number of frames to settle —
+ * more on a page with many other components competing for layout (e.g. a
+ * docs page) than in an isolated story. Measuring too early can catch
+ * content still at its pre-layout default position; capped so a layout that
+ * genuinely never stabilizes still reports its last reading instead of
+ * polling forever. Also waits for web fonts to finish loading, since glyph
+ * metrics (and therefore `getBBox()`) can still reflect a fallback font's
+ * narrower widths until the real font swaps in.
+ */
+export declare function watchLabelOverflow(args: {
+    el: () => SVGGElement | undefined;
+    bounds: () => {
+        left: number;
+        right: number;
+        top: number;
+        bottom: number;
+    } | undefined;
+    onOverflow: (overflow: MarginOverflow) => void;
+}): void;
+/**
+ * Tracks value-label overflow reported by (possibly several, e.g. one per
+ * series) {@link watchLabelOverflow} calls and grows a local margin override
+ * to fit it — monotonically, since shrinking it back would re-expose the
+ * overflow that caused the growth in the first place, oscillating between
+ * "shrink margin → overflow reappears → grow margin → …". Each side is only
+ * ever set when the caller's own `margins` prop hasn't already pinned it, so
+ * an explicit caller override always wins over this auto-grown one.
+ */
+export declare function createLabelMarginTracker(margins: () => MarginConfig | undefined): {
+    report: (overflow: MarginOverflow) => void;
+    readonly resolvedMargins: Partial<{
+        top: number | "auto";
+        right: number | "auto";
+        bottom: number | "auto";
+        left: number | "auto";
+    }> | undefined;
+};

package/dist/plots/utils/labelOverflow.svelte.js

@@ -0,0 +1,116 @@
+const NO_OVERFLOW = { left: 0, right: 0, top: 0, bottom: 0 };
+/**
+ * Watches an SVG group's rendered bounding box against the plot's own
+ * content box (`bounds`) and reports how far it overflows on each side.
+ * Polled across successive paints until two consecutive readings agree,
+ * rather than trusted after a single frame: the group's own resolved
+ * geometry (driven by svelteplot's separate reactive graph) and svelteplot's
+ * own axis auto-margins can take a variable number of frames to settle —
+ * more on a page with many other components competing for layout (e.g. a
+ * docs page) than in an isolated story. Measuring too early can catch
+ * content still at its pre-layout default position; capped so a layout that
+ * genuinely never stabilizes still reports its last reading instead of
+ * polling forever. Also waits for web fonts to finish loading, since glyph
+ * metrics (and therefore `getBBox()`) can still reflect a fallback font's
+ * narrower widths until the real font swaps in.
+ */
+export function watchLabelOverflow(args) {
+    $effect(() => {
+        const el = args.el();
+        const bounds = args.bounds();
+        const reportOverflow = args.onOverflow;
+        if (!el || !bounds)
+            return;
+        const MAX_ATTEMPTS = 30;
+        let cancelled = false;
+        let frame;
+        let attempt = 0;
+        let lastReading;
+        function measure() {
+            if (cancelled)
+                return;
+            let box;
+            try {
+                box = el.getBBox();
+            }
+            catch {
+                return;
+            }
+            const overflow = {
+                left: Math.ceil(Math.max(0, bounds.left - box.x)),
+                right: Math.ceil(Math.max(0, box.x + box.width - bounds.right)),
+                top: Math.ceil(Math.max(0, bounds.top - box.y)),
+                bottom: Math.ceil(Math.max(0, box.y + box.height - bounds.bottom)),
+            };
+            attempt += 1;
+            const stable = lastReading != null &&
+                lastReading.left === overflow.left &&
+                lastReading.right === overflow.right &&
+                lastReading.top === overflow.top &&
+                lastReading.bottom === overflow.bottom;
+            lastReading = overflow;
+            if (stable || attempt >= MAX_ATTEMPTS) {
+                reportOverflow(overflow);
+            }
+            else {
+                frame = requestAnimationFrame(measure);
+            }
+        }
+        const fontsReady = document.fonts?.ready ?? Promise.resolve();
+        fontsReady.then(() => {
+            if (cancelled)
+                return;
+            frame = requestAnimationFrame(measure);
+        });
+        return () => {
+            cancelled = true;
+            if (frame !== undefined)
+                cancelAnimationFrame(frame);
+        };
+    });
+}
+/**
+ * Tracks value-label overflow reported by (possibly several, e.g. one per
+ * series) {@link watchLabelOverflow} calls and grows a local margin override
+ * to fit it — monotonically, since shrinking it back would re-expose the
+ * overflow that caused the growth in the first place, oscillating between
+ * "shrink margin → overflow reappears → grow margin → …". Each side is only
+ * ever set when the caller's own `margins` prop hasn't already pinned it, so
+ * an explicit caller override always wins over this auto-grown one.
+ */
+export function createLabelMarginTracker(margins) {
+    let measured = $state(NO_OVERFLOW);
+    function report(overflow) {
+        const next = {
+            left: Math.max(measured.left, overflow.left),
+            right: Math.max(measured.right, overflow.right),
+            top: Math.max(measured.top, overflow.top),
+            bottom: Math.max(measured.bottom, overflow.bottom),
+        };
+        if (next.left !== measured.left ||
+            next.right !== measured.right ||
+            next.top !== measured.top ||
+            next.bottom !== measured.bottom) {
+            measured = next;
+        }
+    }
+    const resolvedMargins = $derived.by(() => {
+        const base = margins();
+        if (measured.left <= 0 && measured.right <= 0 && measured.top <= 0 && measured.bottom <= 0)
+            return base;
+        const out = { ...base };
+        if (measured.right > 0 && base?.right === undefined)
+            out.right = measured.right;
+        if (measured.left > 0 && base?.left === undefined)
+            out.left = measured.left;
+        if (measured.top > 0 && base?.top === undefined)
+            out.top = measured.top;
+        if (measured.bottom > 0 && base?.bottom === undefined)
+            out.bottom = measured.bottom;
+        return out;
+    });
+    return {
+        report,
+        get resolvedMargins() { return resolvedMargins; },
+    };
+}

package/dist/plots/utils/legendDisabled.d.ts

@@ -1,4 +1,4 @@
-import type { LegendDisabledStyle } from '../../types/charts/legend';
+import type { LegendDisabledStyle } from '../../types/layout/legend';
 import type { StrokeStyle, DotStyle } from '../../types/plots/styling';
 /**
  * The three per-mark override layers a legend "disabled" state can apply,

package/dist/plots/utils/segments.d.ts

@@ -1,8 +1,9 @@
-import type { AxisValue } from '../../types/plots/axis';
+import type { AxisValue } from '../../types/layout/scales';
 import type { Series } from '../../types/plots/data/common';
 import type { LineSegmentStyle } from '../../types/plots/segments/common';
 import type { Segment, VisualGroup } from '../../types/plots/segments/config';
 import type { SegmentsConfig } from '../../types/plots/props';
+import type { ScopedMarkerGroup } from '../../types/layout/geometry';
 /**
  * Returns the flat {@link Segment} list for one series.
  * Series-specific segments are added before `'default'` segments so that
@@ -11,15 +12,6 @@ import type { SegmentsConfig } from '../../types/plots/props';
 export declare function resolveSegmentsForSeries<TStyle>(segments: SegmentsConfig<TStyle>, seriesName: string): Segment<TStyle>[];
 /** Returns true when `xVal` falls inside any of a segment's x ranges. */
 export declare function matchesSegmentX<TStyle>(xVal: AxisValue, seg: Segment<TStyle>): boolean;
-/**
- * For each segment in `segs`, returns the subset of `data` rows whose x value
- * (from `xAccessor`) falls inside any of the segment's x ranges. Rows are
- * not deduplicated across segments — a row that matches multiple segments
- * appears in each resulting array.
- *
- * Used by component and hover markers with the `'segment'` strategy.
- */
-export declare function getDataForSegments<TData, TStyle>(data: TData[], xAccessor: (d: TData) => AxisValue, segs: Segment<TStyle>[]): TData[][];
 /**
  * Warns about obvious configuration mistakes: multiple catch-all segments
  * (no `areas`) in the same series list. Since catch-alls are evaluated last
@@ -38,3 +30,18 @@ export declare function validateSegments<TStyle>(segments: SegmentsConfig<TStyle
  * aren't duplicated as an extra, separately-styled mark.
  */
 export declare function buildGroupedSeries<S extends Series<any>, TStyle = LineSegmentStyle>(seriesList: S[], segments: SegmentsConfig<TStyle>, connect?: boolean): VisualGroup<S, TStyle>[];
+/**
+ * Builds the `ScopedMarkerGroup[]` a `Plot.svelte` hands to `GeometryLayout`
+ * for rendering `series`-scoped `hover`/`component` markers — one group per
+ * series, carrying its resolved segments' match predicates and colors.
+ * `colorFor` resolves a series' own default color; `segmentColorFor` reads
+ * whichever field counts as "color" out of that plot kind's segment style
+ * shape (e.g. `fill` vs `stroke.stroke`), since that's the only part of this
+ * that isn't shared across plot kinds.
+ */
+export declare function buildScopedMarkerGroups<TData extends Record<string, unknown>, S extends Series<any>, TStyle>(args: {
+    groupedSeries: VisualGroup<S, TStyle>[];
+    segments: SegmentsConfig<TStyle>;
+    colorFor: (series: S, seriesIndex: number) => string;
+    segmentColorFor: (style: TStyle | undefined, defaultColor: string) => string;
+}): ScopedMarkerGroup<TData>[];