morgan/editor
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

editor: improve floorplan modes and annotations (#549)
CI / quality (push) Has been cancelled
Details
mcp-ci / ci (push) Has been cancelled
Details

Browse Source 
* Add roof surface placement support for items

Items (e.g. solar panels) can now be placed on sloped roof surfaces.
The placement system computes euler rotation from the roof surface
normal so items sit flush on the slope instead of going inside.

- Add roofStrategy to placement-strategies with enter/move/click/leave
- Wire roof:enter/move/click/leave events in the placement coordinator
- Add calculateRoofRotation in placement-math using surface normals
- Support full 3D cursor rotation for sloped surfaces
- Items on roofs are parented to the level with world-space rotation

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* fixed conflict

* fix(editor): anchor floorplan cursor to snapped point

* fix(nodes): preview floorplan edits through live overrides

* feat(editor): add context-aware floorplan modes

* fix(nodes): render crisp wall selection hatching

* fix(editor): cap floorplan handles at extreme zoom

* fix(editor): keep zone labels upright after rotation

* refactor(editor): make referenced annotations registry-driven

* refactor(nodes): colocate contextual dimension builders

* fix(editor): use mode-driven angle snapping

* fix(nodes): use mode-driven move snapping

* chore(editor): update react scan tooling

* refactor(floorplan): streamline construction documentation

* refactor(floorplan): remove wall assembly roadmap

* fix(floorplan): migrate retired scene data

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Sudhir Yadav
2026-07-27 18:57:59 -04:00
committed by GitHub
co-authored by Claude Opus 4.6
parent daa1f3e99b
commit ab76686b8b
121 changed files with 3535 additions and 7840 deletions
Download Patch File Download Diff File Expand all files Collapse all files
wiki/floorplan-chapter-17-assessment.md
+26 -33
View File
@@ -2,7 +2,7 @@
## Purpose
This document compares the guidance in `Chapter_17_Floor_Plan_Dimensions_and_Notes.pdf` with Pascal's current floor-plan implementation. It records what the chapter teaches, what the editor already supports, and the remaining construction-document gaps.
This document compares the guidance in `Chapter_17_Floor_Plan_Dimensions_and_Notes.pdf` with Pascal's current floor-plan implementation. It records what the chapter teaches, what the editor supports, and the product's intentional scope boundaries.
The review covered the full 19-page chapter and the floor-plan stack across:
@@ -91,7 +91,7 @@ The planner also supports:
- Matching baseline extensions when a short value changes sides.
- A leader and true tick-to-tick baseline when both outside positions require further relocation.
The former orange/red dashed collision overlay was removed because it displayed stale pre-layout conflicts on top of labels that the automatic resolver had already made readable. Any future unresolved-collision reporting should live in a separate preflight surface rather than being painted over the drawing.
The former orange/red dashed collision overlay was removed because it displayed stale pre-layout conflicts on top of labels that the automatic resolver had already made readable.
`packages/nodes/src/shared/construction-length.ts` formats imperial construction dimensions using feet, inches, and reduced fractions rounded to the nearest sixteenth.
@@ -111,7 +111,20 @@ The existing measurement system is broader than the chapter's drafting examples.
- 2D and 3D drafting and editing.
- Smart transient measurement reports.
The architecture is documented in `wiki/architecture/measurements.md`. These measurements are analysis annotations; they are not yet a complete replacement for architectural construction-dimension strings.
The architecture is documented in `wiki/architecture/measurements.md`. These measurements remain analysis annotations rather than architectural construction-dimension strings.
### Manual construction dimensions
The editor provides a dedicated associative `ConstructionDimensionNode` for architectural drafting in Expert mode. A drafter can:
- Pick stable semantic references or free points.
- Create point-to-point, continuous, radius, diameter, center-mark, chord, arc-length, angular, and coordinate dimensions.
- Place and later move the dimension baseline.
- Reposition individual witness references.
- Suppress or restore individual segments.
- Keep dimensions associated with their host geometry as walls, openings, and other supported elements change.
Manual construction dimensions render in the live floor plan and PDF output, and their visibility is controlled independently from automatic dimensions and analysis measurements.
### Door and window documentation
@@ -132,7 +145,7 @@ The rough-opening fields intentionally remain optional rather than being invente
### Rooms, stairs, and other plan graphics
- Zones render a centered name but currently represent generic colored polygons rather than a complete architectural room model.
- Architectural room zones provide room names and numbers, finish and occupancy metadata, ceiling heights, clear dimensions, and room schedules. Generic colored zones remain available for non-room uses.
- Stairs render footprints, treads, and direction arrows, but do not yet emit a complete construction stair note.
- Columns can contribute structural center references to automatic exterior strings.
- The generic floor-plan registry already renders walls, doors, windows, slabs, ceilings, zones, roofs, stairs, columns, furniture, MEP nodes, and annotation nodes through a common geometry contract.
@@ -150,44 +163,24 @@ The rough-opening fields intentionally remain optional rather than being invente
- Preservation of persistent measurement value labels in full export.
- Respect for the existing measurement-visibility preference.
- Document-purpose wall rendering at modeled thickness.
- Document metric notation and initial paper-space sizing for construction dimensions and measurement labels.
- Document metric notation and paper-space sizing for dimensions, measurement labels, room labels, annotation text, mark bubbles, and annotation linework.
- The same automatic annotation collision layout used by the live floor plan.
The plan is fitted to an A4 landscape page. It is not yet plotted at a fixed architectural scale.
The export intentionally fits the plan to an A4 landscape page.
## Important current limitations
## Intentional scope boundaries
### Interactive measurement and construction dimension are different concepts
### Walls use one modeled thickness
The measurement system stores geometric analysis annotations. The wall planner creates automatic construction strings. There is no dedicated manual construction-dimension object that lets a drafter pick references, place a baseline, add points to a continuous string, and later reposition or suppress individual segments.
`WallNode` stores one total thickness and finish materials. It does not model separate studs, sheathing, finish layers, veneer, air space, concrete block, or furring. Face-based dimensions therefore reference the modeled wall face rather than a separately proven construction layer.
### The current datum is not truly face of stud
### Export uses the supported fitted-page presentation
`WallNode` stores total thickness and finish materials but does not describe studs, sheathing, finish layers, veneer, air space, concrete block, or furring. Automatic dimensions can reference a generic wall face, but the model cannot yet prove that this face is a structural stud face or finish face.
PDF export fits each supported plan to an A4 landscape page. Construction dimensions, measurements, annotation text, room labels, mark bubbles, and annotation linework use the existing document presentation profiles.
### Paper-space control is only partially implemented
### Automatic annotation placement uses its current obstacle set
Exported construction dimensions and measurement labels now resolve their main text, tick, extension-gap, overshoot, and label-offset sizes from paper points. Note text, mark bubbles, room labels, remaining line-weight categories, and fixed user-selectable drawing scales still require the drawing-sheet work.
### Construction dimensions have no independent visibility layer
The live floor plan exposes independent visibility controls for automatic dimensions, manual dimensions, measurements, opening marks, structural grids, room labels, and stair annotations. Full export intentionally includes every supported annotation category regardless of the live-view toggles.
### Automatic collision layout has no persistent manual override
Automatic placement now handles adjacent labels, short values, opening marks, and the first set of architectural obstacles. It does not yet let a drafter pin a chosen label position, suppress a segment, or persist a view-specific layout override. Broader fixed-symbol coverage and a separate unresolved-collision preflight also remain.
### Curved and circular construction dimensions
Curved walls emit an automatic radius leader and center mark in live plans and document output, matching the chapter's curved-wall callout method. Manual associative construction dimensions cover radius, diameter, center, chord, arc-length, coordinate-pattern, and angular-pattern workflows, with curved-wall defining geometry resolved from stable semantic host features.
### Construction systems are not semantically modeled
The editor cannot yet apply different documentation rules for wood framing, masonry veneer, concrete block, structural masonry, or solid concrete because those assembly semantics do not exist in the wall model.
### The floor plan has no drawing-sheet model
The export layer produces plan and schedule pages, but there is no persistent drawing sheet with view identity, scale, title block, drawing number, note blocks, graphic scale, north arrow, or per-view annotation visibility.
Automatic placement handles adjacent labels, short values, opening marks, walls, wall corners, door symbols and swings, windows, columns, and room labels. Drafters can pin a label position, reset it with a double-click, and suppress individual manual-dimension segments.
## Features that should not be copied blindly
wiki/floorplan-pdf-export-library-research.md
-269
View File
@@ -1,269 +0,0 @@
# Floor-plan PDF export library research
Date: 2026-07-21
## Decision summary
The missing dimension values are a conversion-boundary problem, not a limitation of PDF text.
The current export builds an SVG in the DOM and asks `svg2pdf.js` to reinterpret that SVG as PDF.
That makes the result depend on how the converter handles nested transforms, inherited SVG styles,
font discovery, text baselines, paint order, and non-scaling strokes. Replacing `svg2pdf.js` with a
second automatic SVG converter leaves those same risks in place.
The reliable design is to render the existing semantic `FloorplanGeometry` directly into PDF
primitives. Dimension values must be emitted with the PDF library's native text API, and dimension
lines/ticks must be emitted with explicit point widths. That preserves selectable vector text and
removes SVG/CSS interpretation from the critical path.
Recommended choices:
1. **Smallest and lowest-risk:** keep jsPDF but stop sending dimension annotations through
`svg2pdf.js`. Draw dimensions as a native jsPDF overlay with `doc.text`, `doc.line`, and
`doc.rect`. This is the best implementation choice even though it is not a library replacement.
2. **If a different library is required:** use **PDFKit directly**, rendering from
`FloorplanGeometry`. It has the strongest current combination of browser support, native vector
drawing, transformation support, font embedding, and active maintenance.
3. **Do not choose another automatic SVG converter** as the primary fix. In particular,
`SVG-to-PDFKit` has been inactive since 2022 and documents unsupported features and browser font
loading caveats.
No production code was changed as part of this research.
## Current architecture and why it matters
The current code already has the right source model for a direct PDF backend:
- Node builders return semantic `FloorplanGeometry`, including `dimension`, `dimension-string`,
`dimension-label`, lines, paths, polygons, circles, and groups.
- [`floorplan-dimension-renderer.tsx`](../packages/editor/src/components/editor-2d/renderers/floorplan-dimension-renderer.tsx)
resolves each dimension's line endpoints, ticks, label point, label angle, font size, and label
placement.
- [`floorplan-export.tsx`](../packages/editor/src/lib/floorplan/floorplan-export.tsx) currently mounts
a React SVG off-screen and converts it with jsPDF + `svg2pdf.js`.
That means a new export backend does not need to infer measurements from DOM nodes. It can traverse
the same geometry tree and emit native PDF operations deterministically.
The current converter itself says that custom fonts must be registered before conversion, calls
itself "by no means perfect," and notes that its visual tests can vary because of text measurement.
Those are material warnings for small, rotated architectural labels.
[Official `svg2pdf.js` repository](https://github.com/yWorks/svg2pdf.js)
## Requirements
The selected approach should provide:
- visible dimension values at every rotation;
- selectable/searchable PDF text;
- embedded or otherwise deterministic fonts;
- explicit thin vector strokes in PDF points;
- lines, curves, polygons, circles, fills, clips, and nested transforms;
- browser-side generation and Blob/download support;
- compatibility with React and TypeScript in this monorepo;
- an API that can be tested without visual browser automation.
## Comparison
| Rank | Approach | Native/selectable text | Fonts | Transforms and thin vectors | Browser/TypeScript fit | Maintenance | Integration cost |
|---:|---|---|---|---|---|---|---|
| 1 | Direct jsPDF drawing, optionally as a hybrid overlay | Yes; `text()` emits PDF text and supports an angle or matrix | Custom TTF through VFS + `addFont` | Explicit `setLineWidth`; advanced mode exposes transformation matrices | Already installed and browser-first; official typings | Active; current 4.x docs and releases | Low for annotation overlay, medium for full renderer |
| 2 | Direct PDFKit renderer | Yes; native PDF text | TTF, OTF, WOFF, WOFF2, TTC, dfont; subsetting | Canvas-like vectors, SVG path data, save/restore, translate/rotate/scale/transform, explicit line width | Browser supported, but Blob stream/bundling and separate TS types add work | Active; current 0.19.x releases | Medium-high |
| 3 | Chromium print-to-PDF | Browser's own text/SVG renderer; generally preserves vector text | Uses loaded web fonts; Puppeteer waits for fonts by default | Browser-native SVG/CSS transforms and strokes | Not a pure browser-side library: needs print UI or a headless-browser service | Very active | Low rendering rewrite, high operational cost |
| 4 | `@react-pdf/renderer` | Native `<Text>` and SVG `<Text>` | `Font.register`; TTF and WOFF | SVG primitives, group transforms, explicit strokes; `Canvas` wraps PDFKit operations | Browser + server React APIs, Blob provider, bundled typings | Active releases and commits | High because DOM SVG is not reusable as-is |
| 5 | `pdf-lib` direct renderer | Native `drawText` with rotation | Standard fonts; custom fonts through `@pdf-lib/fontkit` | Lines, shapes, individual SVG path data, explicit thickness; lower-level transform work | Browser-compatible and TypeScript-native | Stable but inactive upstream since November 2021 | High |
| 6 | `SVG-to-PDFKit` automatic conversion | Supports SVG text/tspan/textPath | Requires pre-registration or a callback; does not wait for async browser font loading | Supports common transforms, but documents unsupported `vector-effect` | Browser possible through PDFKit; has a declaration file | Last commit August 2022; no published GitHub releases | Medium |
| 7 | Canvg raster fallback | No; text becomes pixels | Whatever the canvas resolved at rasterization time | Visually faithful at sufficient resolution, but all output is raster | Browser-friendly and TypeScript-based | Maintained; 4.0.3 released in 2025 | Low-medium |
## Approach details
### 1. Direct jsPDF primitives — recommended incremental implementation
jsPDF already exposes all operations needed for dimension annotations:
- `text(text, x, y, { angle, align, baseline })` for actual PDF text;
- transformation matrices in advanced mode;
- `setLineWidth(width)` in the document's declared units;
- custom font registration with `addFileToVFS`, `addFont`, and `setFont`.
The official source documentation shows that `text()` writes a PDF text object (`BT`, font
selection, text position, `Tj`, `ET`) rather than rasterizing the label. It also documents angle and
matrix transforms. [jsPDF text and line-width documentation](https://parallax.github.io/jsPDF/docs/jspdf.js.html),
[font and advanced-mode guide](https://parallax.github.io/jsPDF/docs/index.html)
Practical design:
1. Keep the current `svg2pdf.js` pass temporarily for non-annotation geometry.
2. Exclude all `dimension`, `dimension-string`, and `dimension-label` geometry from that SVG pass.
3. Resolve them into a small `PdfDimensionAnnotation` display list containing witness lines,
dimension line, tick segments, label text, label anchor, angle, font size, and background box.
4. Transform model coordinates into page points once.
5. Draw the background plate, lines, ticks, then `doc.text()` with explicit fill color and embedded
font.
6. Later, move walls and other geometry to the same native backend if desired.
Why this is ranked first: it eliminates the observed failure path while retaining the installed PDF
engine, page setup, headers, schedules, and save flow. It also provides a narrow regression-test
surface: generated PDF content can be inspected for each expected label string.
### 2. Direct PDFKit — recommended full replacement library
PDFKit runs in both Node and the browser. Its official documentation includes:
- selectable text and embedded font support for TTF, OTF, WOFF, WOFF2, TTC, and dfont;
- vector `moveTo`, `lineTo`, Bézier and quadratic curves;
- parsing of SVG **path data** (not an entire SVG DOM);
- save/restore, translate, rotate, scale, and arbitrary transform operations;
- explicit stroke widths and Blob output in the browser.
[PDFKit browser setup](https://pdfkit.org/docs/getting_started.html),
[vector and transform APIs](https://pdfkit.org/docs/vector.html),
[text and font APIs](https://pdfkit.org/docs/text.html)
PDFKit 0.19 raised its documented browser floor to Firefox 115 and Safari/iOS 16, and its current
release line continues to include text, font, SVG-path, and browser fixes.
[Official PDFKit releases](https://github.com/foliojs/pdfkit/releases)
Practical design:
1. Add an exhaustive `renderFloorplanGeometryToPdfKit` visitor.
2. Give the visitor a coordinate transform from model metres to PDF points, including the page's
Y-axis inversion and plan rotation.
3. Draw every dimension label using `doc.text()` after `save/translate/rotate`.
4. Register an exact project font before rendering and use explicit point sizes.
5. Pipe to a browser Blob stream and keep the existing download UX.
Tradeoffs: this is a cleaner long-term backend but a larger initial migration. PDFKit's npm package
does not currently advertise bundled declarations in its package manifest, so the TypeScript package
would normally also use `@types/pdfkit`. Browser output uses a Node-style stream, commonly adapted
with `blob-stream`. Both add integration weight compared with the existing jsPDF save flow.
### 3. Chromium/browser printing
Printing a dedicated page lets the browser render the same SVG, CSS, transforms, and fonts that it
renders on screen. `window.print()` is widely available, and print-specific CSS can control the
page. [MDN `window.print`](https://developer.mozilla.org/en-US/docs/Web/API/Window/print),
[MDN printing guide](https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Media_queries/Printing)
For automatic downloads, Puppeteer's `Page.pdf()` uses Chromium print output. Its documented
options include CSS page-size preference, background graphics, and waiting for
`document.fonts.ready` (enabled by default).
[Puppeteer PDF guide](https://pptr.dev/guides/pdf-generation),
[Puppeteer PDF options](https://pptr.dev/api/puppeteer.pdfoptions)
This is the best path when exact browser-rendering parity outweighs infrastructure cost. It is not
a pure client library: either the user must use the print dialog, or the application needs a trusted
server/desktop process running Chromium. That is a substantial architectural change for the current
browser-side download.
### 4. `@react-pdf/renderer`
React-pdf produces PDFs in the browser and server and offers browser Blob/download components. It
has its own PDF primitives, including SVG `Line`, `Path`, `Text`, `Tspan`, and `G`. Its documented
presentation attributes include `strokeWidth`, `transform`, `textAnchor`, and
`dominantBaseline`. Group transforms apply to children. Its `Canvas` painter wraps PDFKit methods,
including `text`, `path`, `rotate`, `lineWidth`, `translate`, and `scale`.
[React-pdf SVG APIs](https://react-pdf.org/svg),
[components and Canvas API](https://react-pdf.org/components),
[font registration](https://react-pdf.org/fonts)
This is viable and actively maintained. It is not a drop-in renderer for the existing React DOM SVG:
the floor plan must be rebuilt with React-pdf's component types or drawn through its Canvas painter.
For a CAD-like plan, that gives no decisive rendering advantage over direct PDFKit while adding a
second React renderer and layout engine. It is more attractive if the broader drawing-sheet document
will be rebuilt declaratively.
### 5. `pdf-lib`
`pdf-lib` runs in browsers and is written in TypeScript. It provides native `drawText` with rotation,
explicit line thickness, rectangles/circles/ellipses, and individual SVG path drawing. Custom fonts
are embedded through `@pdf-lib/fontkit`.
[Official examples](https://pdf-lib.js.org/),
[`PDFPage` drawing API](https://pdf-lib.js.org/docs/api/classes/pdfpage),
[`DrawTextOptions`](https://pdf-lib.js.org/docs/api/interfaces/drawtextoptions)
It does not parse a complete SVG document; its SVG support is for one path-data string at a time.
Consequently, it requires the same complete `FloorplanGeometry` visitor as PDFKit, with a less
convenient graphics-state/transform API for this use case. The upstream repository's latest commit
and release are from November 2021, so it is not the preferred new dependency for a renderer being
introduced in 2026. [Official commit history](https://github.com/Hopding/pdf-lib/commits/master/),
[official releases](https://github.com/Hopding/pdf-lib/releases)
### 6. `SVG-to-PDFKit`
`SVG-to-PDFKit` is the only credible alternate JavaScript full-SVG converter found. Its documented
coverage includes SVG text/tspan/textPath, transforms, paths, clips, masks, fonts, gradients, and
patterns. However, it explicitly does not support `vector-effect`, warns that browser fonts must be
registered before conversion because it does not wait for asynchronous loading, warns that bugs
remain, and has not received a commit since August 2022.
[Official repository and support table](https://github.com/alafr/SVG-to-PDFKit),
[official commit history](https://github.com/alafr/SVG-to-PDFKit/commits/master/)
It is therefore not a sensible replacement for `svg2pdf.js`. It changes the converter without
removing the converter boundary.
### 7. Canvg raster fallback
Canvg parses SVG and renders it to Canvas; its stated purpose includes SVG rasterization.
[Official repository](https://github.com/canvg/canvg),
[official API](https://canvg.js.org/api)
Rendering the plan at high device-pixel density and embedding the canvas as PNG would make missing
text unlikely after `document.fonts.ready`, because the browser/canvas has already converted the
glyphs to pixels. It is an acceptable emergency fallback or diagnostic control. It does not meet the
core deliverable: dimension text is not selectable, all geometry becomes raster, thin lines depend
on export resolution, and large plans produce larger PDFs.
## Proposed implementation sequence
If implementation is approved, use this order:
1. Add a library-independent PDF display list or visitor over `FloorplanGeometry`.
2. Implement dimensions first: lines, ticks, background plates, and native text.
3. Embed one exact non-variable TTF font and wait for/load it explicitly.
4. Preserve all document sizes in PDF points; do not use CSS pixels for line weights.
5. Keep the existing SVG conversion only for unported geometry during the transition.
6. Add structural tests that inspect the generated PDF for expected text strings and page count.
7. Add fixture coverage for horizontal, vertical, diagonal, rotated-plan, short/outside-label,
metric, and imperial dimensions.
8. Only after the annotation path is proven, decide whether to port the remaining geometry and
remove `svg2pdf.js`.
For a mandated new library, substitute a direct PDFKit backend at steps 2–5 and port geometry kinds
incrementally. Do not introduce `SVG-to-PDFKit` as an intermediate layer.
## Acceptance criteria for the eventual implementation
- Every dimension value in the source geometry is present as extractable text in the generated PDF.
- Horizontal, vertical, and diagonal values remain readable at plan rotations of 0°, 45°, 90°, and
arbitrary building rotations.
- Dimension lines render at an explicit target such as 0.5 pt and ticks at 0.75 pt regardless of
plan scale.
- The chosen font is embedded or a deliberate standard PDF font is used.
- Label backing plates are drawn before text and do not obscure glyphs.
- Text extraction verifies representative metric and imperial labels.
- Geometry remains vector except for explicitly documented raster-only assets.
## Primary sources
- [jsPDF repository](https://github.com/parallax/jsPDF)
- [jsPDF documentation](https://parallax.github.io/jsPDF/docs/index.html)
- [jsPDF source/API documentation](https://parallax.github.io/jsPDF/docs/jspdf.js.html)
- [`svg2pdf.js` repository](https://github.com/yWorks/svg2pdf.js)
- [`svg2pdf.js` releases](https://github.com/yWorks/svg2pdf.js/releases)
- [PDFKit repository](https://github.com/foliojs/pdfkit)
- [PDFKit browser setup](https://pdfkit.org/docs/getting_started.html)
- [PDFKit vector graphics](https://pdfkit.org/docs/vector.html)
- [PDFKit text and fonts](https://pdfkit.org/docs/text.html)
- [PDFKit releases](https://github.com/foliojs/pdfkit/releases)
- [React-pdf components](https://react-pdf.org/components)
- [React-pdf SVG primitives](https://react-pdf.org/svg)
- [React-pdf fonts](https://react-pdf.org/fonts)
- [React-pdf releases](https://github.com/diegomura/react-pdf/releases)
- [`pdf-lib` documentation](https://pdf-lib.js.org/)
- [`pdf-lib` `PDFPage` API](https://pdf-lib.js.org/docs/api/classes/pdfpage)
- [`pdf-lib` repository](https://github.com/Hopding/pdf-lib)
- [`SVG-to-PDFKit` repository](https://github.com/alafr/SVG-to-PDFKit)
- [Canvg repository](https://github.com/canvg/canvg)
- [Puppeteer PDF generation](https://pptr.dev/guides/pdf-generation)
- [Puppeteer PDF options](https://pptr.dev/api/puppeteer.pdfoptions)
- [MDN printing guide](https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Media_queries/Printing)