epiphany/crates/epiphany-layout-ir
Levi Neuwirth 24b6a34db9 Slurs: side from the stems, endpoints on the notes, apex clear of both
The rendered slurs were wrong in three independent ways, all visible in the
two-staff and three-staff goldens.

  1. Side. SlurDirection::Auto always arced above. The single-voice rule is
     OPPOSITE the stems -- all stems up puts the slur under the noteheads, all
     down puts it over them, and a mixed-stem span (which has no notehead side)
     goes above. Every Auto slur over a stem-up passage was drawn through its own
     stems. This is why stem direction had to land first: with every stem pointing
     up, "opposite the stems" means nothing.

  2. Endpoints. They sat at staff_top + gap -- a constant offset from the STAFF,
     not from the notes -- so a slur between two C6s hung below its own noteheads
     and crossed their ledger lines. They now sit a gap outside the endpoint
     column's ink, at the notehead's centre. Where the stem points the same way as
     the slur, that ink includes the stem, so the endpoint clears the stem tip.

  3. Clearance. The apex was span-proportional and blind, so a note between the
     endpoints poked straight through the arc. ColumnInk -- per staff, per column:
     top, bottom, stem direction, notehead centre -- is the obstacle field. The
     control points sit on the chord at thirds, so x is exactly linear in t and
     the arc's departure from the chord is 3*lift*t*(1-t); a column at t needing d
     more clearance forces an apex of at least d/(4*t*(1-t)).

An authored height is a floor, not a ceiling: clearance may raise it, so obeying
an author cannot draw a slur through a note. An authored direction still wins.

Obstacles are measured at the notehead CENTRE, the same x the endpoints use. The
first cut used the raw column x, which skews t and silently over-lifts: the
two-staff slur cleared its C6 by 4.05 spaces where 3.5 was needed. The clearance
test now asserts an upper bound as well as a lower one.

SLUR_INSET is gone. Endpoints at the notehead centres are what its 0.6-space
"tuck" approximated for the start point -- and got wrong for the end, where it
tucked a full notehead width to the LEFT of the final note.

Four mutations verified: always-above, staff-relative endpoints, no clearance
pass, and obstacles at the column x. The staff-relative-endpoint mutation PASSED
at first -- the tests asserted only "above the staff" / "below the staff", which a
staff-relative endpoint satisfies by construction. The exact-endpoint assertion
exists because that mutation survived.

Projection change, so no version moves; goldens churn.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-09 13:58:56 -04:00
..
src Slurs: side from the stems, endpoints on the notes, apex clear of both 2026-07-09 13:58:56 -04:00
Cargo.toml Land epiphany-layout-ir (Agent E): layout IR + solver interface 2026-06-19 19:58:01 -04:00
DECISIONS.md Slurs: side from the stems, endpoints on the notes, apex clear of both 2026-07-09 13:58:56 -04:00
README.md Land epiphany-layout-ir (Agent E): layout IR + solver interface 2026-06-19 19:58:01 -04:00

README.md

epiphany-layout-ir

The Epiphany layout intermediate representation and constraint-solver interface, implementing the normative requirements of Chapter 7 ("Layout Intermediate Representation") and the interface of Chapter 9 ("Constraint-Solver Interface") of the core specification (spec/core_spec.pdf). This is Agent E's crate per spec/QUICKSTART.md — it lands last among the implementation crates, building on Agent A's epiphany-determinism and Agent B's epiphany-core (and on Agent C's OperationKindTag for the edit-barrier types — see DECISIONS.md).

The IR sits between the score graph and two downstream consumers: the constraint solver, which resolves spacing and positioning, and the renderer, which produces final visual output. — Chapter 7

The score graph is the canonical truth about the music; this crate is a downstream projection of it. The transformation is a pipeline of four stages, each with its own type and a deterministic, provenance-preserving contract for the next.

What's here

Area Items Spec
Stage 1 — logical LogicalLayoutIR, LayoutRegion, composite LayoutObject, overrides/cross-region objects, to_logical Ch. 7 §"LogicalLayoutIR"
Stage 2 — constrained ConstrainedLayoutIR, SpringSlot, LayoutConstraint, GlyphObject, to_constrained Ch. 7 §"ConstrainedLayoutIR"
Stage 3 — resolved ResolvedLayoutIR, pages/systems/staves/measures, ResolvedGlyph Ch. 7 §"ResolvedLayoutIR"
Stage 4 — render (interface only) RenderIR, RenderPrimitive, RenderIRProducer, to_render Ch. 7 §"RenderIR"
Time axis canonical TimeAxisModel plus dynamic TimeAxis, including registered payload preservation Ch. 7 §"Layout Regions"
Provenance Provenance, LayoutObjectId, SynthesisKind, stable_layout_id (a pure function of the source — stable across relayouts) Ch. 7 §"Provenance"
Engraving decisions EngravingDecision/EngravingDecisionId/EngravingDecisionKind, DecisionSource Ch. 7 §"Engraving Decisions"
Vertical bands VerticalBand/VerticalBandId/VerticalBandKind Ch. 7 §"Vertical Bands"
Incremental cache LayoutCache, DependencyIndex, granular stage caches and invalidation Ch. 7 §"Incremental Layout and Caching"
Glyph catalog GlyphCatalog (metric-lookup interface) + in-tree BravuraCatalog, GlyphCatalogIdentity, SmuflVersion, FontId, GlyphMetric/GlyphAnchor, BRAVURA_METRICS/BRAVURA_VERSION, metrics_hash_for (MUSCFNTM-tagged) Ch. 7 §"Glyph Catalog Interface" / §7.3.2
Edit barriers EditBarrier, BarrierScope, BarrierCondition, ObjectKind, EditContext (precise scope evaluation), keyed on Agent C's OperationKindTag Ch. 8 §"Edit Barriers"
Solver interface ConstraintSolver (solve/solve_incremental, Send + Sync), SolverConfig/SolverBudget, SolverState, InvalidationSet, SolveReport, SolveStatus, SolverTier/SolverVersion, the v0 StubSolver Ch. 9
Round-trip round_trip, RoundTripReport, laid_out_object_ids Ch. 7 (v0 acceptance criterion 6)

The stub solver

Per the QUICKSTART, the v0 constraint solver is a stub: StubSolver returns SolveStatus::Solved with the input geometry verbatim (each glyph's resolved position is exactly its constrained baseline), preserves provenance, and reports all hard constraints satisfied. The real solver — Cassowary or otherwise — comes later (Chapter 9 specifies the interface, not the algorithm); v0 only needs to round-trip IR through the solver interface to prove the contracts hold. The one stub validates the full Chapter 7 §7.3.2 catalog identity and all slot, band, and geometry cross-references before reporting Solved. Explicit constraints are rejected because this interface-only solver cannot honestly evaluate them.

The round-trip (v0 acceptance criterion 6)

round_trip runs graph → LogicalLayoutIRConstrainedLayoutIR → stub-solved ResolvedLayoutIRRenderIR and asserts the contract every stage must satisfy:

  • the stub solver reports Solved with all hard constraints satisfied;
  • the complete Provenance of every object — source, synthesis, dependencies, and stable_id — survives every stage unchanged;
  • no two objects ever share a stable_id, so manifestation multiplicity is preserved (a source manifested in two regions stays two layout objects);
  • the stub solver returns the input geometry verbatim;
  • the set of score-graph sources recovered from the RenderIR is exactly the set laid out — a surjection onto graph identity (one source may back several manifestations, each with its own stable id).

Agent F's testkit drives this same entry point (layout_stub::round_trip) on the 10-measure single-staff hand-off fixture and the rich multi-region generator.

Algorithmic scope

Per the QUICKSTART ("a prototype baseline, not the product"), this crate implements the Chapter 7 IR contracts and interface types, not a production engraving engine. The real spacing and casting-off algorithms, quality-metric computation, constraint solver, and renderer remain later implementations of these interfaces.

Determinism

IR coordinates are single-precision staff spaces (StaffSpace(f32), Chapter 7 §7.2); the canonical ResolvedLayoutIR output quantizes them to the 1/1024 grid at serialization time (ResolvedLayoutIR::canonical_bytes), exactly as Appendix D §"Quantized Layout Coordinates" prescribes — quantization absorbs all f32 variation below 1/2048 staff space, so the canonical output is independent of the floating-point environment. The glyph-catalog identity hashes its consulted metrics (advance, bounding box, named anchors) under the MUSCFNTM domain tag, and the edit-barrier types carry a canonical encoding with set-valued fields emitted in canonical byte order (sorted and de-duplicated). See DECISIONS.md.

Tests

cargo test -p epiphany-layout-ir covers each module plus the round-trip on Agent B's valid_score / valid_score_rich generators. The end-to-end v0 acceptance gate (criterion 6) lives in the testkit.