Use live endpoint constructors when geometry must follow sampled values
or other Visuals. Use the static annotation constructors for fixed points.
An edge or corner supplied with anchor-of requires renderer-measured
layout; a center reference is a semantic position. These marks express an
author’s diagram, not a geometric proof.
58.12.1 Dynamic Endpoint Geometry🔗ℹ
Live endpoint constructors provide deterministic geometry relationships
without mutable updaters. Each endpoint accepted by the procedures below may be a literal
vec2, a point-valued scene-parameter? handle, a top-level
Visual/symbol/nested visual-path?, or a value made with
anchor-of. A plain Visual reference selects its semantic reference
position. Parameter values must be vec2 at every sampled time.
Creates one endpoint description for target. A centre anchor is the
ordinary semantic point. An edge or corner selects the target’s live
renderer-measured box at render time; offset is a world-space offset
from that selected point. This result is intended as an endpoint argument to
the live endpoint constructors.
Creates a finite line segment with independently sampled endpoints.
Even a literal-endpoint connection is represented by a relation.
Example:
Creates an arrow with a shaft and optional tips that follow independently
sampled endpoints.
Creates a finite visible ray that begins at start and points through
through. Its rendered length is fixed by length, avoiding an
ill-defined infinite renderer object.
Every endpoint constructor returns a relation-visual?. Literal points,
parameters, and centre references create a 'semantic relation; a
non-centre anchor-of creates a 'layout relation, measured
against the current renderer-visible box after normal scene sampling. The
relations retain their identity, support their ordinary outer movement and
opacity animation, and can be inspected before rendering. Endpoint geometry
must still resolve to distinct points at the sampled time.
58.12.2 Mathematical Annotations🔗ℹ
Mathematical annotations are small semantic, path-backed marks for explanatory
diagrams. Selected marks support the same live endpoint protocol as
line-between: a literal vec2, point-valued
scene-parameter, Visual ID/path (its semantic centre), or
anchor-of description. Literal points return the immediate
path-visual? or group-visual? values. Parameter and
centre-reference inputs create semantic relations; an edge/corner anchor creates
a layout relation. Both are deterministic from the sampled state. The layout
phase is restricted to top-level relations, and it uses complete renderer bounds
rather than exact visible outlines.
Creates an open circular arc. Positive sweeps travel counter-clockwise; the
absolute sweep must be no greater than one full turn. The implementation splits
the arc into quarter-turn cubic Bézier pieces, retaining exact cardinal
endpoints rather than using a polyline approximation.
Selects dash intervals by the geometry’s total arc length. Curves remain cubic
path fragments; they are not flattened into renderer-specific segments.
Creates a finite dashed line. start and end must differ.
Creates an arc mark from the ray
vertex–
first to the ray
vertex–
second. By default it selects the signed minor angle;
reflex? selects its complementary reflex sweep. Collinear rays are
rejected instead of producing a deceptive zero-angle mark. Its name avoids
shadowing
racket/base’s numeric
angle procedure.
Creates the conventional square-corner mark from two supplied rays. It does not
try to prove that those rays are perpendicular.
Creates
angle-marker from three live endpoint descriptions. Literal
vec2 values return the same static path as
angle-marker. Otherwise,
all three endpoints are sampled together before the angle arc is built. It
still does not infer a mathematical relationship between the rays.
Creates
right-angle from three live endpoint descriptions. A right
angle remains an author assertion: the implementation follows the two rays but
does not verify they are perpendicular.
Creates a symmetric cubic curly brace. Positive
offset places it to
the left of start-to-end travel; negative values place it on the other side.
With literal points it is an ordinary path; otherwise its two live endpoints
are sampled together.
brace is a short spelling with the same
arguments.
Short spelling for
brace-between. It creates the same symmetric cubic
brace with the same placement and styling rules.
Creates a brace and centered plain-text label. The child identities are
deterministically derived as id plus -brace and -label.
With live endpoints the brace and label are rebuilt together from the same two
sampled points.
Creates
curved-arrow from two live endpoint descriptions. Each
sample rebuilds both the circular shaft and its final-tangent tip, so the arrow
head follows the changing arc. It does not select routes around obstacles or
support arbitrary Bézier/elliptical routes.
Creates a layout relation around the sampled rendered bounding box of
target. Padding is in world coordinates. The relation follows motion,
scale, rotation, and nested/derived target layout, retains its ordinary outer
style and opacity animation, and records its target as a semantic selection
dependency. Its current implementation is square-cornered; #f selects
its default transparent fill. Like other layout relations, it must currently
remain top-level and its box includes renderer padding rather than only visible
ink.