A deferred drawing that holds shows each dimension's last reading until drawing.update. drawing.status now says so
for each one, as it says so for each view: a dimension whose view is out of date, or one read from another model or
record than it has now, has `out_of_date: true`. `held` is true when views or dimensions wait. Before, a change that
left the views current (a sketch, which shows the same) held their dimensions with no sign in the status.
The list comes from one rule, `out_of_date_dimensions`: the rule `drawing.scene` and `drawing.export` wrote inline for
their own `out_of_date`, moved into one function that they and the status share. `standing` gives it the views out of
date and the stale dimensions of every sheet. The status
reply's schema says what the new field means.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Drawings: a sphere's size reads SØ when the sphere is whole and SR on the arc a dome shows
A dimension can now name a face on a sphere (drawing.dimension.add {sphere: {face}}). It reads SØ, the
diameter, when the body's faces on that sphere are the whole sphere, and SR, the radius, when they are
part of one (a ball end, a dome, a cap), as ISO 129-1 writes them.
Both are decided on exact geometry, with no mesh. Whole or part comes from the record's topology: the
faces are the whole sphere when every edge of their loops is used only by them. SR is read on the arc of
the sphere's contour in the view that lies on the faces: the contour is cut where it crosses each rim
circle's plane, and one point classification at each arc's middle says whether it is on them. Arcs on
them next to each other join, and the longest run carries the number. A view that sees only a cap's rim
refuses it.
The cylinder's rule that a name's faces all lie on one surface is now one function for both kinds
(Lookup::on_surface), and the number's label comes from the measure where the kind alone doesn't say.
The paper draws a sphere as a circle's or an arc's radial dimension.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawings: a cone's included angle reads between its two silhouettes
A dimension can now name a face on a cone (drawing.dimension.add {cone: {face}}), such as a
chamfer's, a countersink's or a drill point's. It reads the cone's included angle, twice its
half-angle, between the cone's two silhouettes in the view. It is foreshortened when the view's
plane doesn't hold the axis, and a view along the axis, or within the half-angle of it, is refused.
Both silhouettes must lie on the body's faces on the cone, so half a cone is refused. This is
decided on exact geometry, with no mesh. Each silhouette is a ray from the apex, cut where it
crosses each rim circle's plane, and one point classification at each piece's middle says whether
it is on the faces. The pieces on them join, as a sphere's contour arcs do: one function now joins
runs for both.
In crates/geom, drawing_measure gains Cone and its two silhouettes, worked out analytically from
the apex, the axis and the half-angle. It holds no kernel geometry. Faces lie on one cone when they
share its apex, its axis's way and its half-angle, within the cylinder rule's margins; the kernel
reports a cone's surface but has no rule of its own for that. The paper draws the angle as an
angle dimension between the two silhouettes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A drawing whose updates are deferred, closed while held, then opened again keeps its views' and its
dimensions' last lines until something reads its sheet. An export to a file runs on a copy of the
session, and that copy didn't carry those kept lines: exported before the sheet was read, the file came
out with no views and no dimensions.
The copy now carries the lines kept for the open drawing, and takes them back the way the session does.
The test exports from the copy first and from the session after, and both write the same sheet.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* claim: #12802
* Drawings: a deferred drawing keeps its dimensions across a close, and lists them out of date (#12802)
A deferred drawing closed during a model change came back with its views' last lines but no
dimensions: the close kept only the views', and a held drawing reads nothing again. Now the close
keeps each dimension's entry too, beside the views' lines, with its world state let go (an empty
one), so a closed drawing still holds no model. Opened again, each comes back read from a state
that has gone: a drawing that may draw reads it again once its view is up to date, as before, and a
held one shows it as it was.
A held view's dimensions are out of date with it, so every command that reads a sheet now lists
them in `out_of_date`, after the views, with the drawing open or reopened. They are listed only:
the page never reads them again against the view's old lines. A dimension or view gone while the
drawing was closed is forgotten by the rule that was already there when the sheet is put together.
Tests: a deferred drawing closed during a change keeps its dimension and lists it, reads it again
once updated, and lists it held with the drawing open; a dimension gone while closed is not shown,
listed or kept; a deleted drawing keeps no dimension either. #10431's held export test now
expects the held view's dimension listed with its views (3, was 2), and takes the shared edge helper.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawings: a closed drawing's kept dimensions hold no world state, like its views
A dimension kept at a drawing's close is now a `KeptDimension`: its record, its view's drawing, its
lettering and its lines, with no world state, as `KeptView` already is for a view. So the type keeps
"a closed drawing holds no model", where before a swap for an empty state in `forget_closed` did.
`take_kept` gives the views and the dimensions the one gone state, so both are read again from the
same place. Nothing changes in what a drawing shows or lists.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The title block's text and a dimension's text each chose for themselves between waiting for the
search for fonts to fall back to (an export, drawing.inspect) and asking it (the window's sheet),
then each mapped the answer to set, pending or refused. That rule is now in one place, in sketch
beside the fonts: PaperFonts holds the drawing's family and language with the font folders listed
once, and sets lines or text the waiting or the asking way; Outcome is the one mapping of its
answer. The title block's lay and the dimensions' paper_group take a PaperFonts, made once for
each block and each read of dimensions. Nothing else changes: the same text in the same fonts,
pending and refused in the same cases. A parts list's words on paper will use it too.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
PartsList::rows gives each row of a bill of materials with its values formatted, each followed by the
rows listed under it. The item comes from the rule a balloon reads, so the two can't disagree. A mass
follows the list's unit and decimals and a length the drawing's units; a value a row hasn't got is left
out, for the table to mark. A nested row's quantity is how many are in one of its parent, and `count`
has them all.
A row's key names each member, so one part listed in two places keeps two keys, and the limit is now
2048 bytes to fit the 65 members of the deepest list. The plan's "item with its padding" has nothing to
do: no padding exists. The text measure goes with its first caller, the sheet's tables (P8b).
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing export: a sheet exported to a file runs in the background, like the view DXF (#4890 EX2)
A sheet exported to a file through the control channel was drawn and written on the window's
thread, so a large PNG at a high dpi held the window up until it was done. `drawing.export` with a
`path` now goes through `file_load` as `Kind::ExportSheet`, beside the view DXF's `ExportDxf`: on a
copy of the design, off the window thread, with an "Exporting sheet" card. Without a path the
reply holds the document, so it runs at once as before. Cancel on the card says which export it
stopped: it said "DXF export cancelled" for every export while the view DXF was the only one.
`Kind::exports()` holds what the two export kinds share (the copy, never adopting the worker's
session, Cancel waiting for the worker, a drop cancelling it, a finished export staying finished),
in place of seven `ExportDxf` tests and a check on the command's name.
`paper_png`'s band loop reports its rows to the current `solidcraft_kernel::watch` and stops
between bands once it is cancelled. The command writes the file only after the PNG is complete, so a
cancelled export writes nothing. With no watch, every other caller, the bytes are unchanged.
`drawing.export`'s checks and write, its commands and its schema are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing export: a held sheet exported in the background has its views, as on the page (#4890 EX2)
A sheet exported to a file runs on a copy of the session. `Session::scratch` leaves the copy's
drawing-scene cache empty, so a deferred drawing that was held (the model changed since its last
`drawing.update`) exported from the copy with no views or dimensions. The same export without a
path, on the window's session, wrote the lines the sheet page shows.
`Session::scratch_as_shown` is `scratch()` plus `Cache::shown_copy`: the world state the cache last
updated against, each view's and dimension's last drawing, and the serial they were numbered to.
That is what `as_shown` reads. The lines kept for closed drawings, the last answer and a request in
flight stay out, since only the window's page uses them. `file_load` takes that copy for its two
export kinds; inserts, updates and opens keep `scratch()`, which is cheaper and never draws a sheet.
Tests: the engine compares the export (svg and out-of-date list) from the session and from the copy
for a drawing that isn't deferred (also after a view's edit), a deferred one with a view edited
since its update (drawn at once), and a held one, its dimension included, on the sheet last shown
and on a second sheet. The window
test writes a held sheet through the background export and compares the file with the synchronous
export.
Co-authored-by: theironchef <6278036+theironchef@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: theironchef <6278036+theironchef@users.noreply.github.com>
* Drawing text: a font search that stops part-way no longer leaves text waiting for the rest of the session (#4890)
The search thread clears its running mark only when it ends normally. If a search stopped
part-way (a panic), the mark stayed set: nothing was searched again, and text needing a fallback
font waited for the rest of the session. The thread now holds a `Running` mark; dropped before it
finishes, it clears the mark, and what it held or was asked meanwhile is answered as a miss, so that
text is set as no font has it. A character asked for next starts a search of its own.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing text: a font search that stops part-way answers what it held under the same lock that clears its mark (#4890)
Drop for Running cleared the running mark and answered the held queries as misses under two
locks. Between them, a request for one of those queries found no answer and no search running,
and started a new search for it: the query that may have stopped the search was searched
again. Both now happen under one lock. store keeps its shape and shares store_in with the
Drop, so the cap on kept answers stays one rule.
Found and fixed by @theironchef in review.
Co-authored-by: theironchef <6278036+theironchef@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: theironchef <6278036+theironchef@users.noreply.github.com>
* Paper scene: what a font adds to a table, a run's reach, and text in the sheet reply's schema (#4890)
One rule for everything that puts text on a sheet: `Scene::font_records_beyond`
counts only what a scene's font table doesn't hold yet, `TextRun::reach` says
how far a run's glyphs go along its baseline, and `drawing.scene`'s schema has
text runs and fonts, never a font's bytes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Paper scene: a font's records are found by its id, not by its place in the table
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing dimensions: their numbers on the sheet, in the drawing's font (#4896 W19h)
A dimension on a sheet now carries its text: each value is set in the
drawing's font and language, measured, and placed along the dimension's
text direction, reading from the bottom or the right. Arrows flip by the
measured text width. A text the font can't set leaves the lines and says
why. The scene adds each dimension's fonts to its table once, counting their
records against the scene's limit, and measures text by its outlines for an
object's bounds. A dimension is read again when the drawing's units,
language or font change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets: a title block's labels and values set on paper (#4890 B3, #3875)
Each label is set as one line at its place, and each text cell's value in its
value box by the cell text rule, broken between words to the box's width when
its fit wraps, in the drawing's font and language. What doesn't fit is shown
whole and noted; a text no font can set is left off the sheet and noted with
why, so the sheet and its export never fail over one cell. drawing.inspect
lists each cell's notes; the sheet scene sets what was measured.
What a cell shows is worked out in one place for drawing.inspect and the scene.
The block's fonts count toward the scene's records with the border, so no view
takes them, and the scene is drawn again when the design or a cell's text
changes.
Ported from the personal PC's 1951bc696 onto today's drawings.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Sheet scene: a title block's text set once while its sheet fills in, and its faces in the key (#4890 F5)
The sheet scene read its title block's fields and set their text again on
every extract that missed its last answer, and views are drawn one a tick,
so a sheet filling in weighed the documented component and laid out the
block once for each view drawn. The text is now kept with the last scene
and set again only for another sheet, drawing, design, model or lettering.
A scene is reused only for the same faces too: one family name can mean
another face once a font is installed or removed, and that face is another
scene. A family with no face is set in the built-in font, so it stays the
same scene until it's found.
Ported from the personal PC's d82fd03e7 onto today's title block text.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Sheet text never waits on the window's thread: a title block's and a dimension's text wait for no font search, and inspect names the fonts fallen back to (#4890 F7)
A text in a script the drawing's font lacks needs a search of the installed
fonts. The window's sheet (`drawing_scene::extract`, `step` and the view's
job, on the UI's tick) now asks the search's thread instead of waiting for it:
- sketch: `paper_lines_now` beside `paper_lines_in`, as `paper_text_now` is
beside `paper_text_in` (FontPending until the search answers).
- title block: `title_block_text::lay(.., wait)`. A text whose font is still
being looked for is off the sheet and marks the `Laid` as `pending`, never as
refused. While the last scene's block is pending, the fast path and the
text's reuse both miss, so `extract` sets the block again until the search
has answered.
- dimensions: the same rule for a dimension's number (`paper_group(.., wait)`,
a `wait` flag on `draw_dimensions`). The step, its dimension step and the
view's job (#11126) all ask; a dimension whose text is pending is kept as
pending, and `extract` reads those dimensions alone again
(`set_waiting_dimensions`), keeping each one only once its text is set.
- `SheetView::waiting_for_fonts` says when text is still waiting. `step` does
not: pending text has no lines to draw again, so a `true` from it would spin
on no work.
- `build` (export, `drawing.scene`) and `drawing.inspect` wait, so their
answers are whole. `drawing.inspect` adds `font_fallbacks`: which font set
each script of the title blocks' text that the drawing's font lacks
("Kana set in BIZ UDPGothic").
The scene tests' `settled` asks as the window does (extract, then steps,
until neither has more to do), with a time bound.
Ported from the personal PC's cae4a2969 onto F5; the dimensions' half is new
(one rule for every text the window's sheet sets). On `drawings` f50edc1ed:
`draw_dimensions` takes #12516's (frame, line group) pair as well.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Adding one on a part the view's saved settings leave out (its hide, or a source that doesn't
choose it) is refused, naming the view and the setting, and the parent view when it set it. One
added before a later view edit stays, and its inspect reply warns until the edit is undone.
The rule stays the view's own (`chosen`): `left_out` asks it about one occurrence path and says
why; `check_drawn`, `not_drawn` and `drawn_warning` beside the view commands use it for the three
annotations. `DimensionKind::paths` and `Anchor::path` list what each points at, so every kind of
dimension is checked. No model is evaluated.
On drawings a7c0310ab, #12516 (line groups) gave a resolved setting two more setters, the
view's sheet and the drawing. The words for where a setting was set are one function, set_on,
with an arm for each: a parent names its view, a sheet and a drawing say so, and a view's own
setting and the default add nothing. Hide and the chosen occurrences come only from a view's
chain today, so no refusal says "its sheet" yet; the match keeps the compiler checking each
new setter.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A script that calls drawing.create or drawing.set with a misspelt setting now gets an error
naming the setting. Before, the call reported success and the setting was lost. The two
commands now read their parameters through input schemas, like every other drawing command.
- schema/drawing.rs gains DrawingCreateParams and DrawingSetParams. Each field's reader keeps
the refusal words the hand readers used.
- The hand readers for units, projection, updates and revision_numbering move into the schema.
- The drawing's line_group reads through cmd::line_group_of, so it keeps its sheets' words.
drawing.view.edit is unchanged.
- The output types are their own slice.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Straight after a drawing opened again, drawing.status said out_of_date for views whose kept lines
still show what the model shows, and drawing.update counted them as waiting. The first extract then
found them up to date and drew nothing. status read the cache as it was: the kept lines came back
and the keep pass ran only inside extract and the drawing step.
One function, catch_up, now brings the cache to the drawing open and the world state: the kept
lines come back, then each view that shows the same takes the state. extract, step, begin and
drawing.status (and so drawing.update) all start there, so each says the same of a view.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Drawings: views drawn beside the window (#4892 B7)
`drawing_scene::begin` asks for the first view out of date, `Job::run` works
its lines out on a copy of the session (pending moves cleared: the design's
placements, as dimensions use), on any thread, and `finish` takes them only
for the latest request while the revision, the model's world state and the
view as it resolves are as they were; `cancel` forgets the request. Request
numbers come from one counter for every session, so a drawing closed and
opened again never takes an old job's lines.
A job carries what `step` draws in one swap: the view's lines, what they
show, and the view's dimensions through its new frame. `step` and `begin`
start from one helper, so both keep the views that show the same and both
draw nothing while a deferred drawing holds. `step` is the same three run at
once. The window's hook is `drawing_jobs::tick` (the shape of `save_job`): no
caller yet, no UI.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawings: a built sheet leaves uncaptured moves out too (#4892 B7)
`build` (every export) draws the parts where the design places them, as the
provider's jobs do: one rule for lines, dimensions and files, and once
nothing waits the provider's scene is still the built one. Exports change
only while an occurrence move isn't captured.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawings: the window reads a sheet's dimensions too, once no view is waiting (#4892 B7)
Sheets now read their dimensions after their views (`drawing_scene::step`). Drawing views beside
the window went through `begin`, which asks only for views, so with every view drawn the
dimensions out of date were never read. With no view waiting, `tick` now steps on the window as
before; reading dimensions is quick. The tick test adds a dimension and ends with none out of date.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A drawing saves the ISO 128 line group its views and dimensions are drawn
in; a sheet or a view may save its own. A view's group is resolved like its
other inherited settings: its chain, then its sheet, then the drawing, and
inspect says which gave it. The group joins the display settings a projected
view follows. drawing.create and drawing.set take it; the sheet commands and
drawing.view.edit take it or null to follow.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A drawing's views follow the model automatically, or, when deferred, only on
drawing.update, which lets them draw from the model as it is now, for this
session only. The next model change holds again, and a close drops the update,
so a reopened deferred drawing waits. While it waits, its views show their last
lines, out of date.
drawing.set and drawing.inspect take and say `updates`, saved only when
deferred (a drawing-format pending note). drawing.scene, its hit and line
commands and drawing.export read what the page shows and list what is out of
date; drawing.status says held.
The ribbon's Update Drawing button stays planned as drawing.update.planned with
its art awaiting review, as Export does; the command itself takes the existing
update icon.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A view's entry keeps what it was drawn from: each body of the world state by
its occurrences, name, reference mark and geometry key. A view drawn from a
world state that showed the same takes the new one and draws nothing, so a
sketch, or an edit taken back, projects no view.
A drawing closed keeps its views' lines in the sheet scene's provider, and
opened again starts from them: with nothing changed it draws no view, and with
the model changed its last lines show, out of date, until drawn. Dimensions are
read again. Only in memory, never saved; a deleted drawing's lines go with it.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Drawings: which line of a view is under a point, and drawing.scene.line (#4816)
A view's group now keeps what drew each of its strokes (the body, and the edge or silhouette of it),
one entry per item with none for its pictures, from the same walk that paints the strokes
(paper_lines). line_at finds the view under a point (hit, over the views alone), then the nearest
of its strokes within a band, the one painted later of two as near, and names it as
drawing.view.snapshot names its lines (one From<Source> for both). drawing.scene.line draws the
sheet's views out of date first, as the page does, and evaluates nothing. The two tests that built
the two-part design inline now share one fixture.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawings: a pressed line names what drew it on each placement (#4816, #4892 Re)
A test: a round bar placed twice. A press on either one's outline names the silhouette's face
through the occurrence pressed, and a press on its top names the top rim's edge.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The sheet page draws through the provider, which brings one thing up to date per tick. After a model
change it drew a view's new lines in one step and that view's dimensions in a later one, so for a
step the old dimensions sat on the new lines. `step` now reads the view's dimensions through the
frame it has just drawn and keeps them in the same swap; an edited dimension is still read alone and
projects nothing.
Keeping drawn dimensions is one method, `Cache::keep_dimensions`, which the view step and
`step_dimensions` both call. The same reads happen as before, a step earlier.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A sheet's text is drawn from the same glyph outlines the SVG writer fills,
filled nonzero so a glyph's overlapping contours fill whole, where the PNG
writer refused any text before. Text counts toward the point cap and is
drawn band by band like any fill, in every colour.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
paper_lines measures a text for paper in the drawing's font and language:
its lines, each with its width, and the pitch between them, broken at each
line break and, given a width, between words (a word is never cut, so a
one-word line may be wider). A word the font lacks is measured in the font
it falls back to. PaperLines::set only places what was measured, and
paper_text is paper_lines then set, so one rule measures and sets text.
Ported from the personal PC's abefb3713 onto today's fallback fonts.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
To pick a view or a dimension on a sheet, something has to say which one is under the pointer.
drawing_scene::hit takes the objects a sheet's scene lists, a point and a band: of the boxes that
hold the point within the band, the smallest, then the topmost, and whether the point is on the
box's edge. A view's box is its boundary, so one that can't be drawn can still be picked; the
drawing border is never hit. It is one pass over the objects, cheap enough for every hover.
drawing.scene.hit answers it for scripts and agents, from the sheet as drawing.scene draws it:
read-only, with input and output schemas, its label in a pending locale file and an EXEMPT line.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Paper scene: kinds of line and their widths by ISO 128-20 (#4890 D2a)
A line's kind (visible, hidden, centre, thin) and a line group give its width in one place:
the standard's series of widths, and a group's wide and narrow lines two steps apart. Nothing
reads it yet; the next commit draws every line on paper from it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Paper scene: every line on paper takes its width from its kind and line group (#4890 D2d)
A view's lines and a dimension's lines are drawn in a line group: a visible edge is its wide
line, a hidden edge, a reference part's edge and a dimension's lines its narrow one, and a
hidden line is dashed 12 line widths on and 3 off. The five width constants that waited for
this go. Every caller draws in the default 0.5 mm group, so today's sheets are unchanged; a
drawing, a sheet and a view choose their own group next.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
#12170 added drawing.balloon.repair and drawing.dimension.repair without a
line in tests/kernel-cases/EXEMPT, so the kernel rig's coverage check now
fails on every drawings pull request that runs it ("NO CASE"). Like the
other drawing commands, both are tested in their area's test files
(drawing_balloon_tests.rs, drawing_dimension_tests.rs), so each gets the
same line, in sorted order.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A saved view now keeps the occurrences it draws and the ones it leaves out,
as the snapshot takes them. drawing.view.base, edit and inspect take them; each
follows the parent until a view sets its own, and a copy made alone keeps what
it showed. Boundaries, fitted scales and lines all read them through one rule.
A path whose occurrence was deleted never refuses the file: a hide path goes
quiet, and a view with nothing left is a placeholder that says why.
Replayed onto drawings fd4b7a7bc: the fit and the lines take reference_shown_percent
(the rename of reference_margin_mm in #7316) through shows(); the path limits now live in doc.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A dimension or balloon whose edge, corner or face is lost now lists up to 16 leads, offered and never taken: the
blend face named after a filleted edge, that face's edges, then the faces the same feature made. Lookup still never
writes the record, so undo brings a lost reference back.
drawing.dimension.repair {dimension, slot, pick} and drawing.balloon.repair {balloon, pick} point a lost or
ambiguous reference at a pick of the same kind, on the reference's own occurrence path: same id and paper place, one
undo step, through one shared helper. Only a reference that no longer finds the one thing it names is repaired, so a
dimension's other, still-found reference is kept, and silhouettes repaired onto one cylinder are refused as add
refuses them. A pick takes the forms add takes, so a lead of the slot's kind from inspect passes back as it stands.
The saved format is unchanged.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The web covered Japanese only (F6): any other script on a drawing was
refused. Now each script the web covers has its own font, fetched once
from the web app's origin the first time a drawing's text needs it:
- kana and Japanese Han: BIZ UDPGothic, as before;
- Hangul and Korean Han: Noto Sans KR;
- simplified or traditional Chinese Han: Noto Sans SC or TC;
- Arabic: Noto Sans Arabic.
Han takes the font of whose Han the text wants (Han::of, the desktop's
rule), so a drawing in English with Han asks for the simplified Chinese
font, as a desktop does; F6 sent all Han to the Japanese font. A text in
two scripts waits for both fonts; one whose fetch failed is refused by
name, and the rest sets. Thai is still refused by name (Hebrew is in the
built-in font).
The four fonts and their licences are unmodified, in assets/fonts/<family>/
with ATTRIBUTION rows, and trunk copies each to fonts/<family>/. Four
files rather than one CJK collection: a session fetches only its own
language's font (4.6 to 8.3 MB), where the collection is one large file.
The folder the web app fetches fonts from is named once (FONTS), and a test
checks that index.html copies each font from its asset into that folder.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
#12152 put an SVG's text back under `svg` in drawing.export's reply and
missed two readers: the delete test that selects a drawing's objects and the
pictures test that draws an image under the views.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
fit works inside the sheet's free space by the same rule as leaves (drawing_view::Room): it takes the
largest preset the border allows, then steps down until the view's box is off the block. A sheet with
no block fits as before; the snapshot, with no sheet, passes none. The default position stays the
sheet's middle.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
#10681 renamed the reply's `svg` key to `text`, and that broke the commands'
existing readers: three tests on drawings read `svg` and failed. The SVG goes
back under `svg`; a PNG's base64 stays under `data`. The output schema and the
params doc follow, and #10681's own export tests read `svg` again.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
drawing.dimension.add, with no offset_mm, puts a linear, length or chain
dimension 10 mm on paper to the side of its line away from the material
beside it: it looks half a paper millimetre either way across the line, in
the view's plane, at the depth of what it measures, and asks each shown
body's B-rep exactly (Body::classify_point; inside or on its boundary is
material). With material on both sides or neither, it goes away from the
middle of the view's model box; on that middle, the fixed rule is above or
to the left (+10). Radial, angle, cylinder and silhouette dimensions keep
+10, and an offset given keeps its sign.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The rig's "Every command has a case" check failed on drawings for the ten
commands #11898 added. Each is tested in crates/engine/src/cmd/drawing*_tests.rs,
as the other drawing commands are, so they join them in EXEMPT.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing export: a sheet as PNG at a chosen dpi and colour, and one reply shape (#4890 EX1)
drawing.export {format: png, dpi?, colour?} writes the sheet's scene
through the sheet PNG writer: 25 to 2400 dpi (300 when not given), grey,
black and white, RGB or transparent (grey when not given). dpi and
colour are refused on an SVG. A path must end in the format's extension,
which ExportFormat::extension gives for every format.
One reply shape for every format: text (SVG) or data (base64 PNG) when
no path is given, in place of svg; report.pixels gives a PNG's size. A
PNG held for the reply stops at 64 MiB, as an SVG does, and the refusal
says to give a path; a file may be as large as the sheet needs.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing export: a sheet on blue paper, in SVG and PNG (#10679)
One rule for the two papers and their ink, used by both writers. White stays the default, byte for byte. A blue paper's PNG is rgb; the other colours are refused by name. A picture keeps its own colours.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A drawing view's setting for how it is drawn (visible lines, with hidden lines, shaded)
was display_style while the viewport calls the same idea its visual style. The field,
its command parameters, its schemas and its replies are now visual_style, on a view's
settings and on its own overrides. display_style is refused as an unknown field, as
drawings haven't shipped and no saved design holds it.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A table's column can be left off paper (printed: false, saved only then): the
layout places the printed columns only, while filters and overrides still read
every column. No printed column may read the ballooned row field, and a table
prints at least one column.
A new parts list gets a seventh column, ballooned, not printed.
Drawing::balloons_by_list works out once which list each balloon reads, and
balloons_by_row counts one list's balloons row by row, every row listed, 0
included; drawing.inspect gives parts_lists with each
list's counts. Worked out on each read and never saved.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The view lines' errors were the view DXF's, remedies included, so a drawing
view could say "DXF export cancelled" or "increase tolerance". The module now
answers a Refused (cancelled, over the work or memory limit, across the eye
plane, invalid) that says only what happened. The view DXF adds what to do in
a DXF's terms (hide bodies or sketches, increase tolerance, zoom out), and a
drawing view in a drawing's (raise chord_mm, or choose a smaller scale).
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing templates: the built-ins carry SolidCraft's title block again, so a new drawing starts with it (#3875)
Every built-in template, ISO A4 to A0, is one sheet with the ISO border and
the built-in title block, so drawing.create with no template (iso-a3)
gives a drawing with the block. #7208 made them the border only; the
decision since is that a drawing starts with SolidCraft's block, and a
user replaces or changes the default template.
- A drawing saved as a template is the user's own: a copy of the built-in
with a company's name in the block and its tolerances typed in starts
drawings that keep both (tested through drawing.template.save and
drawing.create).
- The built-in block by name stays, for a sheet without one.
- The general tolerances stay empty, and the five names (iso-a4 to
iso-a0) and the one drawing_template setting stay: the part and
assembly versions would be the same.
- The tests that gave a new drawing the block first no longer do.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing templates by kind: a part starts on A3, an assembly on A2, each with its tolerances note (#3875)
Ten built-ins, iso-a4-part and iso-a4-assembly up to iso-a0-part and iso-a0-assembly, each with its kind's general
tolerances note typed over the title block cell. template::default_for(assembly) is the one rule for the default, and
template::is_assembly says a design that places components is an assembly. drawing.create with no template uses it,
and drawing.template.list marks the design's default and says whether each built-in is an assembly's. The older names
iso-a4 to iso-a0 still read as that size's part template.
Preferences gets one setting per kind in place of the one; a saved name of the other kind reads as the kind's default,
and the old drawing_template key is ignored.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A saved view or a snapshot's scene in visible_hidden now draws its hidden lines,
0.25 mm wide in ISO 128's dashed line, under the visible ones; a reference part in
visible_hidden draws its hidden lines the same way. Paint order from the bottom:
hidden lines, reference parts' visible lines, the model's. The sheet no longer fails
for that style, so it exports; only shaded styles with lines still refuse.
The paper scene's output schema takes a stroke's dash pattern, so a reply
with hidden lines still matches it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* geom/hlr: per-curve work on worker threads, shared work limits
Silhouette tracing, screen sampling, shadow cuts, classification, coverage and
the crossing search (by grid rows) with crossing refinement run on worker
threads through one ordered map: results go back in item order, so drawings
are the same bit for bit on any number of threads. Options::threads picks the
workers (0 = one per core, small views stay on the calling thread); the
browser build stays serial. Placements sharing a body and a turn share one
silhouette tracing.
Cancellation is polled before every item and inside long ones from every
worker; the first error stops the others; a panicking worker becomes
HlrError::Internal instead of escaping. Ray, curve, crossing, shadow and
coverage budgets are totals over all threads (shared counters; crossing pairs
are counted before the search).
Limits: placements and the default max_tracks are hlr::MAX_ITEMS, which is
section::MAX_ITEMS (also the brep record limit); trim_samples must be 1..=4096.
* docs/drawing-hlr: link the parallel-work PR
* geom/hlr: clearer limits and parallel-work docs, faster thread tests
docs/drawing-hlr.md now separates input limits (with the error each returns:
body records fail with Invalid, not Budget) from the work budgets, names every
budget's error, and states how errors and panics behave on worker threads.
Code comments say the same in plainer terms. The budget and cancellation
tests drop the oblique torus, and the freeform pass of the identity test
compares one parallel run, which keeps the HLR suite under 4 s.
* geom/hlr: poll cancellation inside long items, find spline spans by bisection
Review found two items a worker could run for seconds without seeing a
cancellation: tracing a body with many curved surfaces, and sampling one long
spline (up to 4096 control points). Silhouette tracing now asks before each
surface, screen sampling at every refinement pass, the cuts at left-out faces
every 4096 chords and coverage every 65536 checks.
The long spline was slow because every point and every part hull scanned all
of its knot spans. de Boor evaluation now finds its span by bisection over the
ordered knots, and a part's hull starts at its first piece and stops after
its last: the same spans, so the same bits (checked on the fixture scenes),
and a 4096-point spline edge prepares in 0.9 s instead of 2.2 s and samples
in 0.23 s instead of 1.47 s.
* geom/hlr: poll cancellation while forming and trimming silhouette sets
Review found that forming a body's silhouette sets scanned each face's whole
surface group before the first poll, quadratic in the faces on one surface
(about 4e8 steps for 20 000 faces). The group scan now stops at its first
supported face (groups list faces in order, so that is the same face), the
loop polls every 256 faces, and trimming a traced curve asks before each
face. A cancellation seen while trimming drops the partial curves, even if
the callback answers false later. Output unchanged on the fixture scenes.
* geom/hlr: poll cancellation per boxes met when cutting at left-out faces
Review found that one chord crossing the screen boxes of very many left-out
faces bisects every side without a poll (polls came only every 4096 chords).
It now also polls every 1024 boxes met. The docs state the cancellation
contract precisely: polls are where listed, and the work between two polls is
bounded by the input limits rather than by a time.
* docs/drawing-hlr: say where coverage polls cancellation
* geom/hlr: body records have brep's own, larger limit now
Main raised brep::MAX_ITEMS to 1 000 000 (#3093, which stores whole evaluated
models), so it no longer equals section::MAX_ITEMS. hlr::MAX_ITEMS stays
section's 100 000 for placements and the default curve budget; the docs and
the limits test now say that a body's records are bounded separately, by
brep's limit.
* geom/hlr: a panicking worker stops the others; the ray budget is HLR's own
A worker that panics now sets the shared stop flag while it unwinds, so the
other workers end the phase early instead of finishing work the call throws
away. The docs no longer compare the ray budget with the occlusion work
budget of file.export_view_dxf: the two count different work.
* geom/hlr: an ignored timing test, prepare and drawing timed apart
hlr_timing prepares four bodies, then draws 100 differently turned placements
on one thread, two workers and one worker per core, printing the total, the
phase timings and the ray count. SOLIDCRAFT_BENCH_HLR sets the placement count.
* geom/hlr: timing scenes for sharing and crossings; placements keep their lines when permuted
hlr_timing now starts its prepare clock after the fixtures are built, adds the
same grid at one turn (shared definitions against one per placement) and
sixteen thin bars crossing 8x8 from above, rotates the thread order over three
rounds and checks the drawings match across thread counts outside the timed
part. A new test permutes three placements of one prepared box and removes one:
each line keeps its own placement index, and the boxes' lines stay exact.
* docs/drawing-hlr: the review's limits and fixtures in the parallel tables
* geom/hlr: follow the B-rep record into solidcore-record
The record, its version and its item limit now come from solidcore-record
(#11496): the new tests build their bodies at `solidcore_record::brep::VERSION`
and make a spline's curve with `C3::bounded`, as the other fixtures do, and
the limits table gives the record's own limit, 4 000 000 items, checked by
`brep::check::validate`.
---------
Co-authored-by: MateuszSychXpl <151755914+MateuszSychXpl@users.noreply.github.com>
* Issue a revision: drawing.revise (#3874 R1)
drawing.revise appends a copy of a row to the issued history: an existing row as
it reads, or a new revision with the texts given, in one undo step. A row is
issued once. The copy keeps what it read through an edit, a hide or a delete, and
nothing is filled in: no date, checker or approval.
Issuing used to make a drawing unreadable, as a copy has its row's id and the
drawing's check refused any id seen twice. Each id now counts once, and issued
ids are unique among themselves.
model_version becomes {path, change}, on issued copies only. One function on the
session answers it, and answers nothing until version control exists.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing revisions: numbered 1, 2, 3 (#3874)
A drawing's new revisions are numbered 1, 2, 3, never lettered
(@CamWight, 3 Nov). drawing.set's revision_numbering is {start: 0 or 1},
the first number. A revision typed by hand is kept as typed; the next one
follows the highest number, and drawing.inspect says where numbering
starts. A record in letters is refused (drawings haven't shipped).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Revision tags on a sheet: add, edit and delete (#3874 R3)
A tag gains the sheet it sits on and its place there. drawing.revision.tag.add,
.edit and .delete keep them, inspect and every revision reply list them with what
each shows, and a sheet's delete counts and takes the tags on it. A deleted row
still leaves its tags showing the revision they had. Tags draw on paper once scene
text lands.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Saved tables on a sheet: drawing.table.add, .edit and .delete (#3874)
A drawing saves its parts lists and revision tables, each on a sheet with its
definition and place. Rows are never saved. A parts list starts at the top right
listing what its sheet documents, else the design; a revision table at the bottom
left; headings on top, QTY, rows of 7 mm.
Placing a list saves the numbers its view shows, once per view, so what is printed
doesn't move. Numbers are the design's: undoing the placing puts back only the
drawing, as every drawing step does, and the numbers stay. That one command changes
both, and the proof that nothing needs evaluating now allows it.
The tables are a ById list, as the balloons and images are, and keep its rules: at
most 1000, listed by id. Revision tags take their own id type.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* A balloon reads its row in a parts list (#3874 L1)
A balloon can name the parts list it reads; else it reads its sheet's only list,
else the drawing's only one, else none, with the choices listed. Its row's item is
worked out on each read and never saved: drawing.balloon.inspect gives item and
row_status (ok, no_list, reference, no_row or not_found). A lost row never removes
the balloon. A list's delete reports the balloons that named it and clears their
links.
Bom::item_of cuts a path from the top of the design to start below the assembly
listed, and row_of is no longer test-only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Notes on a drawing: the record and commands (W19e, #4896)
A note sits on a sheet, a view, or an edge or corner of a view's model, saved by
name as a dimension's is, with the title block's text and fields, its place and
its text height. drawing.note.add, .edit and .inspect, one undo step each, no
model evaluated. Its one leader is worked out, never saved: a lost reference keeps
the note and its text, with no leader. Anchor is one type so other symbols placed
on a sheet can use it.
A view's notes go with its copy and delete; a sheet's with the sheet. The plan left
delete for later, but selection.delete now handles a drawing's objects, so notes
join it. Balloons and notes share Lookup::middle. Drawing them waits for text in
the paper scene (slice 12).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Picker::placed, face_corners and BodyEdges::new decide with the display mesh.
They are listed on this branch only and must be cleared before drawings lands
on main, where the list takes no new lines.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The kernel rig's coverage check exempts the drawing and bill of materials
commands, each naming where it is tested. The mesh decisions check follows the
view line modules to mesh_lines/, and skips the two that only draw and count a
drawing's view lines.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Labelled measurements on a view's snapshot (#5866)
measure: linear, aligned, angle from model points, radius from an edge, with
units and decimals for the labels. No new maths: drawing_measure's rules, and
a dimension's radial rule through one Lookup::whole_arc. Labels go through one
function, reading_label, which dimensions' text now uses too.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Pieces on one circle are that circle, and one piece is that edge (#4892)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* A dimension between two flat faces (#4892)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* A suppressed or failed feature's references say so, not lost (#4892)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Labelled measurements on a view's snapshot (#5866)
measure: linear, aligned, angle from model points, radius from an edge, with
units and decimals for the labels. No new maths: drawing_measure's rules, and
a dimension's radial rule through one Lookup::whole_arc. Labels go through one
function, reading_label, which dimensions' text now uses too.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Pieces on one circle are that circle, and one piece is that edge (#4892)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The raster walked a triangle's whole box, testing every sample, and the pixel budget counted that box.
A plain plate's few long triangles have boxes that are mostly misses, so a view at 2:1 counted 18 tests
a sample. Now each row of the box tests only the span the triangle can touch there, and the budget
counts those spans (an empty row costs one unit, as the walk does).
row_span works the span out from each edge's weight along the row, allowing for the test's own
tolerance and the rounding of its arithmetic, so it is never short; sample_weights is the raster's test
pulled out unchanged. Pictures are the same to the byte. A product image shares the raster and the
count, so its 128 M admits more; the tests built on its old count hold more triangles.
With the misses gone nearly every counted test paints, and a painted surface costs about 240 ns a
test on one thread, so a picture's limit falls from 400 M to 250 M to stay near a minute at worst.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Each dimension of a view on the sheet is one group, ObjectKind::Dimension,
after the views: extension and dimension lines and filled arrowheads
(Terminator::place, #9466), laid out by dim_layout_sized in paper millimetres, so it is the same size at any
view scale. All seven kinds draw; a chain is one line of frames at one offset
with each extension line once, an angle sits where its lines meet on the view,
and a cylinder's line runs across its silhouettes at the end on its offset's
side.
drawing.scene and drawing.export list each dimension: its status, whether it
is drawn, and why not. A lost one, or one on a view that isn't drawn, has no
lines and leaves the sheet and the file written. The provider keeps each
dimension's group by its record, world state, view drawing and units: a moved
view moves them unread, and an edit reads that dimension alone, in one short
step after the views. Text joins with B1.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
`Seg2::mapped(f, arc)` is a segment under a map of the plane that keeps shapes. Points go
through `f` itself (an arc's centre, every control point). `ArcMap { angle, mirrored, scale }`
says how the map moves an arc: it turns it by `angle`, after a mirror across the x axis when
`mirrored` (start `angle - start`, sweep reversed), and scales its radius by `scale`.
`ArcMap::turn(angle, mirrored)` keeps lengths; `ArcMap::rigid(f)` measures a map of points that
keeps lengths, from where it puts the origin and the unit axes, with a scale of exactly 1.
`Seg2::similar` and the three arc maps written out by hand use it:
- a sheet-metal region onto a panel's flat (`region_to_flat`, which measured its map by hand and
now asks `ArcMap::rigid`);
- the mirrored flat (`flip_x_loop`);
- a sketch region mirrored in its x axis (`mirror_y`).
The points go through the same functions as before, so every result is the same, bit for bit.
This comes from the architecture review of the drawing work (2026-10-25): four places wrote the
arc rule out, each its own way, and one measured its map by hand.
`map_controls` is private to geom now: on its own it hands an arc back unmapped, which is what the
three hand-written arms were there to avoid.
Tests: every kind of segment under a mirrored map with a turn, a scale and a shift, point by point,
its length scaled and an arc's sweep reversed; the three old formulas, bit for bit (the sketch
mirror keeps a +0.0 start's -0.0); a rigid map's turn and mirror measured whatever its shift, and
the identity; the sheet-metal and mirror tests unchanged.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A run's glyphs count once in a scene's records, for a writer that embeds its font, but the
walk onto a writer's grid copies every placed glyph's whole outline, so a sheet dense with
text could reach any size. The walk now counts the pieces it places and refuses a scene past
MAX_GRID_PIECES (1 << 22), saying to move some text to another sheet. place() is public so
a writer that draws text as outlines (PDF) counts with the same rule.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets: a copy of a title block on the drawing border, saved with the sheet (#3875)
`Sheet.title_block` holds a copy of its definition, as `border` does. Each sheet's check lays it
out on the drawing border, so a sheet without a border, a block wider or taller than the border,
or a change of paper that leaves no room is refused. `drawing.sheet.add` and `drawing.sheet.set`
take `title_block` (a definition, or null for none), a new sheet takes the block of the sheet it
follows, and `drawing.inspect` lists it. A sheet without a block saves no `title_block`, so an
older drawing reads as having none (pending format file `sheet-title-block.rs`).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets: the built-in title block, on every new drawing (#3875)
`title_block::default_block()` is the 180 x 54 mm block of twelve cells approved on #3875, with
the legal owner read from the drawing's `organization` and the general tolerances as text to
change. `drawing.create` starts its sheet with it. The geometry tests read the built-in block
instead of their own copy of it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets: a title block's lines on paper, drawn after the views (#3875)
`TitleBlockLayout::paper` draws the outline, then every cell edge inside it, each once:
neighbours' shared edges, and edges that meet along one line, are one stroke. The sheet scene
paints the block after the views, and counts its records with the border's, so no view takes
its room. The view tests' drawing leaves the block off, so their scene is still the border and
the views.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets: the title block's projection symbol, in the drawing's projection (#3875)
ISO 5456-2 (Annex A): a truncated cone and its end view, h across the cone's
small end from table A.1's sizes (3.5 to 20 mm), the largest that fits the
cell, lines h/10 wide. The end view is on the right in first angle and on
the left in third. The block only says a cell holds the symbol; the angle
comes from drawing.projection, and the sheet scene redraws when it changes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets: a title block's fields, and text typed over its cells (#3875)
A title block cell reads its fields from the component the sheet documents (its
name, part properties, material and mass from the bill of materials), the
drawing, the sheet (number and count among the counted sheets) and the newest
revision row; a field with no value shows "-". A key its source doesn't have is
refused when a block is given or read. Sheets save text typed over their cells by
cell name; drawing.inspect lists each text cell with its value beside an override.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing templates as data: a drawing with no model, and ISO built-ins (#3875)
A template is a drawing with no sources, views, dimensions, balloons, revision
rows or documented components, so it is saved and read as a drawing is. A new
drawing is a copy with ids of its own. The built-ins, ISO A4 to A0 for parts and
for assemblies, are made in code when asked for and differ only in their general
tolerances.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing templates: drawing.create from a template, and the preferred ones (#3875)
drawing.create takes template? (default ISO A3, for a part or, for a design with
components, an assembly) and projection? over the template's. The new
drawing.template.list lists the built-ins and marks the one a new drawing starts
from. Preferences add a template for part drawings and one for assembly drawings;
the app fills in the preferred template and projection before drawing.create
runs, so a template named keeps its own projection, instead of changing the
projection after the drawing is made. A saved template this version doesn't know
reads as the default.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing templates: apply one to the drawing open, moving nothing (#3875)
drawing.template.apply {template, dry_run?} gives each sheet the paper, drawing
border and title block of the template's sheet in its place (its last for the
sheets past its own). Text typed over a cell stays while the new block has a
text cell of that name; the cells whose text is dropped are listed. Nothing
moves: the views a new paper leaves outside the drawing space are listed. A dry
run answers the same and changes nothing; applying is one undo step, none when
nothing changes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets: views a title block covers are listed, never moved (#3875)
A view lying over its sheet's title block is listed with the ones the drawing
space leaves out, after a change of paper or block (drawing.sheet.set) and when
a template restyles a sheet. Where a block sits is one rule, the one a sheet is
checked by (Sheet::title_block_outline), and the overlap of two boxes is one
rule in Aabb2::overlaps, which the title block's own cell check now uses too.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing templates: save one as a file, and start or restyle drawings from it (#3875)
drawing.template.save {path} writes the drawing open as a template: its format,
and nothing it draws or documents. drawing.create and drawing.template.apply take
a .json template file as well as a built-in's name. A file is read as a drawing
is, then held to the template rules; files are read and written through the same
file check and atomic write as the sheet export. A drawing made from a file keeps
its own copy, so a later save changes no drawing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets: the built-in title block is 180 x 49 mm (#3875)
The top row is 15 mm, Sheet is 30 mm wide, lined up with Mass, and Date of
issue is 32 mm. The top row now holds one line of the legal owner, two of the
general tolerances and the 3.5 mm projection symbol.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets: one operation sets a sheet's title block, and drawing.sheet.set names the typed text it drops (#3875)
A sheet's block was set in two places: drawing.sheet.set kept the typed
text of the text cells the new block still has, and drawing.template.apply
did the same and listed what it dropped. Sheet::set_title_block is now the
one rule both use. drawing.sheet.set's reply gains `lost`, the cells whose
typed text a new block drops, as drawing.template.apply's reply has it, and
its help says that a view over the title block is listed too.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing templates: the built-ins and a new drawing start with the border only; the built-in title block is added by name (#3875)
A template now holds only the ISO border by default. A title block,
tables, references and text are added to a drawing, and a template saved
from it keeps them.
- The ten built-ins (iso-a4-part ... iso-a0-assembly) become five,
iso-a4 to iso-a0: one sheet with the ISO border. Without the block, the
part and assembly versions were the same.
- drawing.create with no template starts from iso-a3. The two
preferences for parts and assemblies become one, drawing_template,
"Template for new drawings".
- drawing.sheet.add and drawing.sheet.set take title_block: "built-in".
The built-in block's general tolerances are a part's or, for a design
with components, an assembly's, through Sheet::set_title_block.
- An old name such as iso-a3-part is refused with the list of names;
drawings haven't shipped.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing title blocks: a drawing with no number of its own is numbered by the component its sheet documents (#3875)
The identification number cell read the drawing's part number property,
and showed "-" for a drawing that has none, which is every new one. Now
such a drawing shows the name of the component the sheet documents, so a
new drawing of a part is numbered by the part until it is given a number.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing templates: a template saved from a drawing keeps typed text only over plain text cells (#3875)
A template saved from a drawing kept all the text typed over its title
block's cells, including text over a cell that shows a field, such as
the material or the title, which belongs to the design the drawing
documents. Now it keeps the text typed over cells of plain text, such as
the general tolerances, and leaves the rest behind.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing title blocks and tables: a field without a value shows nothing (#3875)
A title block cell or a table row whose field has no value (a property
nobody gave, a row field its row doesn't have, an uncounted sheet's
number) now shows nothing instead of "-".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing title blocks: the built-in block's general tolerances start empty (#3875)
The general tolerances cell of the built-in title block now starts empty for
parts and assemblies alike, rather than ISO 2768-m in the block and a part's
or an assembly's text added by drawing.sheet.set. A shop types its own, or
its template carries them, and an empty cell shows nothing.
- template::PART_TOLERANCES, ASSEMBLY_TOLERANCES, for_assembly and
built_in_block go: "built-in" is title_block::default_block.
- drawing.template.list's help no longer speaks of part and assembly
built-ins.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A conic of weight other than 1 and a Bézier above degree 3 become cubic Béziers within
1e-4 mm of the curve (`paper::cubic_pieces`), so the walk takes them and every writer
draws them with the cubics it already writes. Each piece's cubic has the curve's ends
and end tangents; its distance is bounded from the Bernstein form, not sampled: for a
Bézier, by the control points of its difference with the cubic raised to its degree;
for a conic, by Q·D − N over the denominator's least value. A piece over the error is
halved exactly and tried again, up to 4096 a curve and 1,000,000 a scene; past that the
curve is refused, never drawn coarser. The walk counts the cubics it made. Circular arcs
are left to the shared `paper::cubics` helper.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* A drawing's list of one kind of record: ById, with balloons first (#5426)
Each kind on a sheet writes out the same add, find by halves, cap, order and check loop. ById holds
those, so a kind's own file holds only its own rules, and the file's bytes don't change: it saves as
the plain list. Views and dimensions stay on their own lists for now, since other work is on them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* A drawing keeps an image's file once, however many places it sits (#5426 W38e-1)
images holds the files and sheet_images each place one sits, so a logo on every sheet costs what one
does. drawing.image.add reads the file (bytes and pixels checked from its header before anything
decodes it), reuses a file with the same bytes, and saves the bytes without the path. A file goes
with the last thing that uses it, which Drawing::images_in_use alone says, and reading a drawing
refuses a file nothing uses or a record its file disagrees with. A sheet's list and delete take the
placements on it. Deleting one placement waits for selection.delete to take a drawing's objects. Its
pixels on paper are W38e-2.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Sheet images: an image file's pixels on any paper grid (#5425, W38e-2)
A PNG or JPEG decoded once, then stretched over its paper rectangle onto the pixel grid a writer
asks for: a box filter in linear light with alpha premultiplied, so a shrunk logo keeps its edges
and gains no dark fringe. The size is read from the header and refused over 64 megapixels before
anything is decoded. An EXIF orientation is applied; colour profiles are not read.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Sheet images: a placement in the sheet's scene and its SVG (#5425, W38e-2)
Each image placed on a sheet is a group of the new kind `sheet_image`, between the drawing border
and the views, so a view's lines draw over a photo. `drawing_pictures` holds both that group and
the provider a writer asks for its pixels, so the two read the same placement.
The provider holds what one sheet uses, decodes a file when it is first asked, once however many
placements show it, and refuses a sheet whose files hold more than 64 million pixels, from their
headers, before anything decodes. `drawing.export` passes it to the SVG writer in place of
`NoPictures`, and a file that won't decode refuses its sheet by name.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Render: pin the product image's output before it is drawn in tiles (#5624, W17b S1)
The decoded rows of five product renders (orthographic on a transparent background, perspective on a
solid one, a PBR surface, two glass layers sorted back to front, triangles crossing every edge of the
picture), taken on this tree. The next change reshapes ImageTask into a prepare stage, tiles and a PNG
sink; they must not move. The PNG bytes are not pinned: their compression depends on the deflate
backend the build unifies (flate2's zlib-rs when the UI crate is built alongside, miniz_oxide
without), not on this code.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Render: pictures drawn tile by tile into any pixel window (#5624, W17b S1)
The CPU product renderer, reshaped so drawings can use it: one rasteriser (`Raster`) prepares a
scene once (appearances, projected triangles, glass sorted back to front), then draws each tile of
the picture on a canvas of its own. A sample's position comes from its whole-picture index, so tiles
put side by side are the picture drawn whole, to the byte.
- `ImageTask` (render.image) is that rasteriser over one whole-picture tile from the product camera,
then its PNG: the same output, pinned by the previous commit's rows.
- `PictureTask` draws a `PictureRequest`: a `Projection` (the product camera, or an `OrthoFrame`,
W17a's view frame as plain data: a `Plane` basis, a scale and a paper shift, on a
`geom::pixel_grid::PixelGrid`), any list of `PixelWindow` tiles, `Supersample::One` (pixel centres)
or `Two` (i + 1/4 and i + 3/4), a `BodyRole` per body (`DepthOnly` hides what lies behind it and
draws nothing itself) and an optional background (none: transparent). Each tile comes back as
straight-alpha sRGB RGBA rows, blended in linear light.
- The orthographic map is the frame's paper map, onto the grid, so lines drawn from the same frame
register with the pixels (to 1e-9 mm in the test).
- Limits: 65,536 px a side, no total cap; each tile under the resolver's `RenderLimits`, as the
product image is; at most 65,536 tiles; the prepared lists as a product image's; pixel tests up to
8 per sample of the picture (128 M for a product image, as before), counted at admission by the
one projection the raster uses, as main counts a product image's.
Not here: the drawing light, stored per-tile bins (S2, measured), the paper scene's picture item
(S3), 4x sampling, and `raster::render`, the snapshot rasteriser, which stays as it is.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Render: time the tile renderer (#5624, W17b S2)
An ignored timing test, as `simplify_timing` is: a 65,548-triangle front view drawn as the
product image, as one 300 dpi picture, and in 64-row strips at 300 and 1200 dpi, each the median
of three runs. It is the measure S2's speed-ups are judged by.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Render: a tile passes over a triangle outside it before painting it (#5624, W17b S2)
Each tile placed and painted every triangle of the picture, then dropped those outside it: the
appearance lookup, the PBR normals and the colour decode ran for every triangle in every tile. A
triangle's work is now three steps, `corners`, `look` and `place`. Preparation runs them in
today's order, so its checks and errors are the same. A tile places a triangle first and paints
only those inside it. What is drawn doesn't change: the pin and the tile tests stay as they were.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Render: one light per picture (#5624, W17b S2)
`raster::shade` normalised its key light and highlight directions again for every sample,
although both depend only on the view. `raster::Light` works them out once per view and shades
with them. The tile renderer and the snapshot rasteriser (`raster::render`) both use it, so the
product light is written in one place. The arithmetic is the same, so every pixel is too.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Render: sRGB codes from tables (#5624, W17b S2)
Each shaded sample was stored as sRGB through a power (three per sample), and each output pixel
was averaged from its samples through twelve more and written back through three: the powers
were most of a sample's arithmetic. Decoding is now a 256-entry table of `geom::srgb`'s own
values (#7162), which also ends this file's own copy of the formula. Encoding counts the code
starts (the linear values halfway, in sRGB, between two codes) at or below the value. Within a
billionth of a start, where the formula's rounding could fall either way, `srgb::encode8`
decides, so every code is the one it gives. A test checks both against `geom::srgb` at every
start, the numbers around it, the band's edges and a million values in and outside 0 to 1.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Render: a tile's passes run in loops (#5624, W17b S2)
The raster went back through its step loop for every sample: the cancel check, the stage match,
the tile's window and its canvas bounds, once per sample cleared, tested or averaged. Clearing,
the opaque and glass passes and the downsample now each loop on their own up to the step's budget,
counting a unit as before; preparation and the glass sort still take one unit a call. A step
still checks for cancellation before each stage's run and still does at most 16384 units, so the
host's slices and the progress counts are the same.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Render: tests for a picture's light, glass order and test budget (#5624, W17b S2)
Three planted faults went through the image tests; each now has one
that fails:
- an orthographic picture lit from another direction than its eye: a
face square-on to the view is the colour the product image gives it;
- glass placed by a triangle's first corner, not its middle: a tilted
square whose first corners lie in front of the near one, its middles
behind;
- a picture held to the product image's pixel-test budget: a face
across most of an A0 sheet at 1200 dpi is prepared.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets: a shaded view's picture on paper (#5624, W17 V9b)
A saved view in a shaded style draws on its sheet and in drawing.export:
draw puts one picture per entry of the view's parts under its lines, and
ViewPictures renders each on the writer's grid through the frame that
placed the lines. SheetPictures answers for a sheet's images and views.
The styles with lines stay refused until W06's exact lines.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Render: a picture's count of its tiles and its fixed limit, as #6483 has them (#5624)
A triangle counts only where it meets the tiles asked for, and a picture has a fixed 400 M pixel tests,
as #6483 at bf93e890e. V9b's stack holds an older copy of that slice; this drops away when drawings
takes main. PictureTask says what admission counted, for the view's running sum.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views: a shaded view's pictures add up to one limit (#5624, W17 V9b)
A writer asks for a picture a band at a time, and each request is limited on its own, so ViewPictures
keeps what each view's requests have counted and refuses the next one past the limit, by name, before it
paints. That makes 400 M a bound on a whole view.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Paper scene: clips of lines and arcs, cut once before every writer (#4890 A8a)
Scene::prepare_clipped(clips) cuts each group of an object to that
object's Clip, a rectangle or a circle (a detail view's), and keeps what
lies inside; prepare() is prepare_clipped with none. Prepared holds a
Cow: a scene without clips is borrowed as it is, and Group and Scene are
unchanged, so today's scenes are the same bytes.
- Lines and arcs are cut where they cross the edge; a part is kept when
its middle is inside, the edge included. Parts no longer than EPS go.
- Kept parts that follow one another stay one open stroke. A stroke
wholly inside is kept whole, closed if it was; a closed one cut open
rejoins across its seam.
- A dashed stroke keeps its pattern: each part's phase is where it
starts along the stroke. Across a closed one's seam the pattern runs
on only when its length is whole patterns, so the parts rejoin only
then.
- Checked: one clip an object, a rectangle from its lower-left to its
upper-right corner or a circle with a radius above 0, within 1e5 mm;
a clipped object's items strokes of lines and arcs. What the cuts
made is validated again.
SVG and PNG draw the cut scene through Prepared as they are.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Paper scene: clips of every curve, and fills kept or dropped whole (#4890 A8b)
A clipped object's strokes may now hold any curve, not only lines and
arcs, and its fills are checked against the clip.
- A line or an arc is still cut where its equation says. Any other
curve is halved while its control points lie either side of the edge
(widened by EPS), until they span at most CUT_MM (1e-9 mm), and is cut
there. A curve that needs more than MAX_HALVINGS halvings (one that
runs this close along the edge) is refused as not supported yet.
Each part is the same kind of curve as the whole.
- Seg2::part gives the piece between two parameters, starting and
ending exactly where split_at puts those points; a conic's tail is
re-normalised, so its second parameter is carried into it.
Seg2::MIN_SPLIT names split_at's distance from the ends.
- A line or a circle within EPS of touching a circle only touches it:
one cut there, never a sliver of chord.
- A fill wholly inside its clip is kept and one wholly outside is
dropped. One that crosses the edge, or lies round the whole clip, is
refused as not supported yet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Paper scene: pictures in a clipped object, cut by the SVG and sheet PNG writers (#4890 A8c)
A picture wholly outside its object's clip is dropped when the scene is prepared. One crossing the clip's edge reaches its writer with the clip, on the grid item, since pixels can't be cut as geometry: SVG cuts it with a clipPath, the sheet PNG by whether each pixel's middle is inside. Both draw only the pixels that meet the clip's box. Text in a clipped object stays refused.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A stroke can carry a pattern, `Dashes { lengths_mm, phase_mm }`: dash and
gap lengths in turn, in paper millimetres, and how far into the pattern
the stroke starts. Without one a stroke is solid, and a solid stroke
reads and writes as before.
- Checks: 2 to 12 lengths, an even count, each above 0 and at most
1000 mm; the phase from 0 up to the pattern's length; at most a
million dashes along the stroke, counted from its pieces' own lengths.
- The walk puts the pattern on the writer's grid: a dash or gap under
half a step is one step, counted, as widths are.
- SVG: stroke-dasharray, and stroke-dashoffset when the phase isn't 0.
- PNG: tiny-skia's dashing on the flattened line; its points count
against the sheet's, a line in a gap draws nothing, and one tiny-skia
won't cut is refused rather than drawn solid.
- The paper fuzz cases carry a dashed arc.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
drawing.status says each view's status (current, out of date, placeholder or
failed, with why) from what the sheet page last drew, and each dimension's in the
words inspect uses, reading each body once for the call. Nothing is drawn.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The walk puts a text run on the grid as its glyphs' outlines, placed by the run
(`TextRun::outlines`), each loop walked as a fill's: `GridItem::Text`, with the run's
index among its group's items, so a writer that sets real text (PDF) finds it in paint
order. SVG writes one path a run, filled black with its default nonzero rule, so text
looks the same without the font and never reflows. The sheet PNG refuses text by name
until B2b, and its refusal test says so.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Where a sheet's objects sit: bounds beside the scene (#4894 WE3)
The sheet scene now says where its border and each view sit on paper: the box
round what each draws, and a view's boundary, so one that can't be drawn can
still be picked. It is worked out once per assembly, beside the scene rather
than in it, so no writer sees it and the page needn't inspect each view.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Selected drawing objects: a view, dimension or balloon in the selection (#4894 WE4)
select.set takes {type: drawing, drawing, object} for the drawing open. It adds no
undo step and changes nothing saved, and a selected object leaves the selection
when an undo takes it or its drawing closes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Delete on a sheet: views, dimensions and balloons in one step (#4894 WE5)
selection.delete now works with a drawing open: a view goes with its dimensions
and balloons as one undo step, and one with views projected from it is refused,
naming them, unless they are selected too or contents: delete takes them. A sheet's
delete and this one share the record's one removal rule.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Tests: a view's box holds what it draws, and what's chosen goes in any order (#4894 WE3, WE5)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Where a sheet's objects sit: bounds beside the scene (#4894 WE3)
The sheet scene now says where its border and each view sit on paper: the box
round what each draws, and a view's boundary, so one that can't be drawn can
still be picked. It is worked out once per assembly, beside the scene rather
than in it, so no writer sees it and the page needn't inspect each view.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Selected drawing objects: a view, dimension or balloon in the selection (#4894 WE4)
select.set takes {type: drawing, drawing, object} for the drawing open. It adds no
undo step and changes nothing saved, and a selected object leaves the selection
when an undo takes it or its drawing closes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Delete on a sheet: views, dimensions and balloons in one step (#4894 WE5)
selection.delete now works with a drawing open: a view goes with its dimensions
and balloons as one undo step, and one with views projected from it is refused,
naming them, unless they are selected too or contents: delete takes them. A sheet's
delete and this one share the record's one removal rule.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Tests: a view's box holds what it draws, and what's chosen goes in any order (#4894 WE3, WE5)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* What's on each sheet: drawing.inspect lists its views (#4894 WE1)
Each sheet in drawing.inspect now lists its views: each base view by id, followed
by those projected from it, with what it is called and its dimensions and balloons.
It is one pass over the record with no model read, so the Browser can read it once
per revision.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The browser has no font folders, so `font_dirs` is empty there. The first
kana or Han a text's font lacks asks for the font the web app already
fetches on demand (BIZ UDPGothic); no new file. The text is pending until
it comes, then sets whatever it has a glyph for. If the fetch fails, or
the font lacks a character, that character is refused by name, and the
refusal says the web covers Japanese for now.
The web app starts the fetch through its existing loader, once, when a
text waits for the font, and hands the font over when it arrives.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
TableLayout::paper gives a placed table's lines as one paper group of
the kind it is (parts_list or revision_table), so both sheet tables reach
paper through one function:
- the outline as one closed stroke, outline_line_mm wide;
- a stroke cell_line_mm wide across the whole table at each row boundary
inside the outline, the heading's too, from the top whichever side the
heading is on;
- a stroke down the whole table at each column boundary inside it.
Each line is drawn once, centred on its edge, on the layout's own
corners. The cells' text follows once the paper scene has text (D3b,
after #4813); hatch clearance waits for hatching.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Drawings: the font a drawing's text is set in, by family (#4890 F1)
A drawing names the font family its text is set in (`font`, saved only when
set; a pending drawing-format file). `drawing.create` and `drawing.set` take
it, and `drawing.inspect` reports it, with `font_note` when this computer sets
the text in the built-in font instead ("Futura isn't on this computer: set in
Liberation Sans"). Drawings name fonts by family, so they travel: a font file
is refused.
Paper text finds the family among the installed fonts as sketch text does
(`paper_text_in` for given folders), admits each face once a process, and
sets a family that is missing or can't be set on paper in the built-in font.
Bold takes the family's bold face; the serif flag comes from the face's OS/2
family class. The fixed list of drawing fonts is gone.
New drawings made in the app take the interface font when it is a family.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Paper text: any face with outlines is set, and says how a PDF may carry it (#4890 F2)
A face is admitted for paper whatever its tables lack:
- a variable face is set at its default instance, which is what a PDF draws;
- its cap height is the one sketch text scales it by (OS/2, else the top of
its `H`, else 70 % of the em);
- its PostScript name is what a PDF name can hold of its own, else of its
family and style, else `Font-` and the start of its id;
- without a `post` table it has no italic angle, and a fixed pitch when every
glyph advances alike;
- its stem width is measured across its `l`, else taken from its weight.
A bitmap or colour-only face, with no outlines to fill, is refused by name.
`Font.embed` says how a PDF may carry the face, from its embedding permissions:
a subset, the whole face (no subsetting), or not at all (restricted, bitmap
embedding only, or CFF2 outlines), when the PDF draws the runs' outlines with
their text beside them. Which characters a PDF name may hold is now one rule,
`is_postscript_char`, that the record's check and sketch share.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Paper text: a font's family, for readers that pick fonts by family (#4890 F2)
`Font.family` is the face's own family name: its typographic family (name
ID 16), else its family (ID 1), read from the face itself (in a collection,
not the first face), without control characters and at most 255 characters;
empty when it has neither. A DXF text style picks a font by it; `Font.id`
stays the identity, so two faces of one family are still two fonts
(@0xlillith on #4890). The name lookup PostScript names use is one function
now, shared by both.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Fonts: one list of fallback fonts per script, in sketch (#4890 F3)
The interface's lists of fonts to try for a script move down to
`sketch::fonts::fallback`, so drawings can use the same ones. Each row is
a family and the files it's known to be in. The interface reads the files
in the order it always did, so what it finds is unchanged.
- `CRAFT_FONTS_DIR` joins `font_dirs`, as the interface already has it:
`SOLIDCRAFT_FONT_DIRS`, else the pack, then the system's folders.
- `font_files` sorts the files within each folder, so a search doesn't
depend on how the system lists a folder.
- The Windows folder search takes its names from the Japanese list
instead of its own copy of them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Paper text: a character its font lacks falls back to a font that has it (#4890 F4)
A text on paper was refused for any character its font lacks. Now each
such character falls back to an installed font that has it: the script's
list in `sketch::fonts::fallback` first, Han by the drawing's language,
then the first face in sorted order with outlines and the character.
- Runs split by direction, then by font. Every font takes the same em
size, on the line's baseline and pitch. A space, a digit or punctuation
stays with the run it follows when that font has it; a mark stays with
its letter. A font fallen back to is shaped, with the drawing's
language. Its nearest style is used: bold or italic isn't refused.
- A line its own font has all of is set as it was.
- A character no font has is still refused by name.
- The last-resort search reads each file's character map alone, stays
within `MAX_FONT_FILES`, and keeps its answers, misses too, for the
process.
- `paper_text_now` is for the window's thread: the search runs on a thread
of its own (`font-search`) and it refuses with `FontPending` until the
answers are in. `paper_text` searches where it's called.
- `paper_fallback_notes` names what fell back, for a drawing's status,
from the answers so far: it looks for no font.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* docs: plan drawing workspace UI implementation
* assets: add drawing icon drafts for owner review
* feat(ui): add drawing workspace scaffold with shared ribbon and docked settings
Expose planned Drawing tools without introducing drawing documents, paper rendering or CAD behavior. Reuse existing source BOM, properties and flat-pattern services; retain placeholders for unapproved icon drafts.
Validation: full UI, kernel, icon, clippy, wasm and layout checks passed. Full cargo xtask ci reports three geometry failures that also reproduce on unchanged drawings base 3b982ca: counterbored chamfered-disc ring cut, robustness seed 36 and seed 71. No geometry source or golden fixtures changed.
* Preserve default icon palette in Drawing scaffold tests
* Preserve Drawing providers and complete scaffold translations
reference_margin_mm becomes reference_shown_percent, 0 to 100. At 0 the
boundary is the model's box, as before, and no reference part is measured.
At 100 it holds the model and all the view's reference parts. Between, each
side moves on its own, so a part on one side grows only that side.
The model's middle now places a view, not the middle of what it shows, so a
view stays lined up with its projected views as its box grows. With nothing
grown the two are the same point and the picture is the same.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views made by command: drawing.view.base and drawing.view.projected (#4816)
drawing.view.base {sheet, view?, scale?, position_mm?, the view settings?} adds a base view of the
drawing's design to a sheet. Without a scale it takes the largest ISO 5455 preset at which it lies
inside the sheet's drawing space, centred where it goes, its margin included, as the snapshot fits
it; that scale is saved as the view's own (1:1 with nothing to measure).
drawing.view.projected {parent, side, place?} adds a view projected from a saved view, on its
parent's sheet, following its parent's scale and display settings. Without a place it is lined up
with its parent, its boundary 20 mm past the parent's (DEFAULT_GAP_MM, until a drawing style
gives it).
Each is one undo step through edit_drawing, refused with nothing changed when the record's rules
refuse it; the reply gives the view, its sheet, its scale, its boundary and, when it leaves the
sheet's drawing space, itself as outside (it isn't moved back in). Unknown fields are refused.
One rule, one place: whether a view leaves its drawing space is drawing_view::leaves, and the sheet
of an id is drawing_view::sheet, used by outside() and both commands.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views made by command: a build fix, and each view one undo step, tested (#4816)
From the review of the view create commands:
- drawing.view.base measures the shown bodies (`measure` takes them, not the session), so it builds.
- The nothing-to-measure case is a design with one sketch and no bodies, as the other view tests
make it: drawing.create refuses an empty design.
- The schema test gives drawing.view.base its own key list (it takes no snapshot-only keys).
- Every view a test makes is checked to be one undo step, not only the first: a second step made
under the first (a nested edit) still let one undo take the view away.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Paper scene: one walk onto a writer's number grid, for every writer (#4890, C4)
The SVG writer kept its own number grid: each coordinate whole nanometres, every joint written once,
a closed path ending exactly on its first point, slivers merged into the next piece and a path's
last piece kept. PDF, PNG and the Drawing workspace's canvas need the same rules, so they move into
`geom::paper::grid`, and the SVG writer only formats what the walk gives it.
- `Grid`: `per_mm` steps a millimetre. `Grid::NANOMETRE` (six decimals of a millimetre) is SVG's.
`Grid::new` takes 1 to 1e9; a power of two keeps every number exact as a binary float, which a
writer of 32-bit numbers such as PDF can use.
- `Prepared::on_grid(grid) -> OnGrid`: each group's items as paths of `Piece`s (lines, arcs of at
most a quarter turn, cubics, parabolas), y up as in the scene, a closed path's closing line left
to the writer's close, and a report of widths snapped and pieces merged. Slivers are measured in
the grid's own steps, so a coarser grid merges more.
- The SVG writer flips y on the whole numbers it's given and writes the same bytes as before.
`SvgReport` is the grid's report.
- Ellipses, hyperbolas and Béziers above degree 3 are still refused (A3b), now by the walk.
DXF stays on its own number rule for now: it writes exact entities (ELLIPSE, SPLINE) and is being
reworked under #5318 to #5321; whether its polylines take a grid is decided there.
Tests: every SVG test unchanged, bytes included; the grid's rounding and its bounds; the A3 border
on the grid (y up, closing line left out, fill loops closed); slivers in the grid's own steps, with
the merge boundary both ways (10 and 11 steps, a 6-8 and a 7-8 step); an arc's quarters with their
radius and turn in steps; a width under half a step made one step; an ellipse refused.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Paper scene: a sheet PNG at a chosen dpi and colour (#4890 A4)
A new writer, io::paper::paper_png, that reads the shared walk on the
nanometre grid, the one the SVG writer uses, so a PNG draws the same joints,
closures and merges. Neither the walk nor the SVG writer changes.
- Curves are flattened within 1/8 px by geom::paper::flatten, which turns
each walked piece back into its Seg2 (an arc's centre from its ends, radius
and direction) and takes Seg2::chords' steps. chords is the bound
Seg2::polyline already used (the chord's bulge for arcs, Wang's bound for
the rest), moved out of polyline unchanged so both read one rule.
polyline itself doesn't fit: it floors an arc's tolerance at a millionth of
its radius and caps a piece at 4096 steps, coarser than asked without a
word (0.1 mm, 9 px, on a 100 m arc at 2400 dpi). Over 2^20 points a path,
or 2^24 a sheet, is refused instead. tiny-skia only gets lines: its own
flattening stops at 64 lines a curve, more than a pixel off on a large arc
at a high dpi.
- 25 to 2400 dpi (300 by default). 8-bit greyscale (the default), 1-bit
black and white (no anti-aliasing, every line at least a pixel wide), 24-bit
colour, or 32-bit colour with transparent paper.
- The file records its dpi (pHYs) and sRGB, so it prints at the sheet's size.
- Each line is stroked once, then the sheet is drawn in bands of 16 MiB of
pixels streamed into the file, so memory doesn't grow with the sheet. Each
band also draws a row above and below that isn't written: tiny-skia starts
an edge a little differently where a clip cuts it (one subsample, 16
levels, in a few pixels), so no written row sits on a cut and the bytes are
the same whatever the band.
- A line under a pixel wide (in greyscale and colour) is drawn as tiny-skia's
hairline, its coverage scaled by its width: its stroked outline would fall
between the rows the rasteriser samples and vanish.
Tests: the pixel size and pHYs of A4 at 300 and 25 dpi; a line's and a fill's
pixels at 254 dpi (butt ends, the fill's hole); each colour's PNG type, ink
and paper; a hairline between two rows' centres that is light grey in
greyscale and stays one pixel in black and white, and a bar a fifth of a pixel
wide that black and white inks by its centre; a closed outline joined at its
start; a 40 mm circle round to the pixel at 600 dpi; the same bytes drawn 1, 3
or 7 rows at a time or all at once, and again; the refusals; the flattener's
bounds and counts, and its point cap at the exact boundary; the scene-JSON
fuzz through the PNG writer.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Geom: the pixel grid of a paper rectangle (#5624, W17b S1)
One rule for where a picture's pixels lie on paper, shared by the picture renderer and the writers
that place it: anchored at the rectangle's lower-left corner, rounded outward (W = ceil(w / p - 1e-9)
with p = 25.4 / dpi), so the overhang is at the top and the right; rows run top-down. At most
65,536 px a side; nothing caps the total, as pictures are drawn in tiles and strips.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Paper scene: pictures, and a sheet's pixel grid and windows (#5624, W17b S3; #4890 A9)
A picture on a sheet is `Item::Picture`: the rectangle it sits in, the name of its pixels
(`source`, opaque as a group's object id is) and its opacity. The pixels stay out of the scene: a
writer asks a `Pictures` provider for them on the grid it draws on. A PNG at 1200 dpi then gets a
shaded view drawn at 1200 dpi, not one stretched, and a scene stays small, plain data.
The pixel grid gains the two rules a sheet needs, beside the rectangle's own grid:
- `PixelGrid::sheet`: the whole sheet's grid, anchored at its top-left corner, as an image of
the sheet is drawn.
- `PixelGrid::window`: the columns and rows a rectangle meets; a side on a pixel edge takes no
sliver beyond it. A picture drawn into its window of the sheet grid is placed by copying whole
pixels.
`Picture::grid` is a picture's own grid at a dpi, for SVG and PDF to embed. `Scene::validate`
counts a picture as one record. It refuses a rectangle outside the coordinate bound or without
area, and an opacity that isn't above 0 and at most 1. `Aabb2` is read and written as
`{min, max}`.
On the walk (C4), which S3 follows here: `GridItem::Picture` passes a picture through with its rectangle in
millimetres, since the pixel grid places its pixels, and the SVG and PNG writers refuse it ("not supported yet:
pictures (A9)") until their own slices. `GridItem`, `GridGroup` and `OnGrid` are `PartialEq` only, as a
picture holds numbers that aren't `Eq`.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Paper scene: pictures in a sheet PNG (#5624, W17b S5)
The sheet PNG writer draws the scene's pictures (S3's Item::Picture) where
the scene orders them, between its lines and fills, from a Pictures provider.
- The PNG is now the sheet's pixel grid (PixelGrid::sheet, S1): anchored at
the sheet's top-left corner and rounded outward, so nothing is clipped.
210 mm at 300 dpi is 2481 px (it was 2480, rounded to the nearest). A side
over 65,536 px is refused and the refusal names the limit ("a sheet PNG
side of ... px at ... dpi is over the limit of 65536 px"); an A0 sheet
fits up to about 1400 dpi.
- A picture fills exactly its window of that grid, so it registers with the
lines drawn over the same rectangle. Each band asks the provider for just
its own rows, as straight-alpha sRGB RGBA, and the bytes are checked: too
few or too many, or the provider's error, refuse the PNG with the picture's
source named. paper::NoPictures refuses every picture.
- Pictures are asked for at most MAX_PICTURE_DPI (1200): above it, on the
grid k = ceil(dpi / 1200) times coarser, whose pixels each fill exactly
k x k of the sheet's (both grids share the top-left anchor), so a 2400 dpi
export doesn't ask a renderer for four times the pixels.
- Source-over in sRGB, the picture's alpha times its opacity; transparent
paper keeps the alpha. In black and white each picture pixel is dithered
with an 8 x 8 ordered (Bayer) matrix at its place on the sheet, so bands
don't show; lines stay solid. PngReport says whether anything was
dithered.
- In the writer a picture is one more shape a band draws, beside A4's
outlines, fills and hairlines; the walk's picture arm passes pictures
through, and the SVG writer still refuses them (A9).
Tests: a picture's exact window and its register with a fill over the same
rectangle, also on a sheet 100.8 px high (the grid anchored at its top);
pictures keep their place in the paint order; opacity scales the alpha (on
white and transparent paper, and the picture's own half alpha); above 1200
dpi a coarser picture's pixels are each copied 2 x 2; black and white
dithers half of mid grey and keeps a line over it solid, whatever the band;
a provider's short rows, its error and no provider are refused, and a
picture off the sheet asks for nothing; the bands test draws three pictures
1, 3 or 7 rows at a time, the same bytes and each picture row asked for
once; the sheet sizes on the outward grid and the 65,536 px refusal; the PNG
fuzz with a picture.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Paper scene: pictures in a sheet SVG (#5624, W17b S5)
A picture is an <image> holding a PNG as a data URI, on the picture's own
pixel grid (Picture::grid) at the picture resolution the caller gives,
25 to 1200 dpi: paper_svg(scene, pictures, picture_dpi), the same shape as
paper_png. Only its window over the sheet is embedded and asked for, so it
never costs more pixels than the sheet holds; one off the sheet is left out.
Its x, y, width and height are the grid's own pixel edges put on the
nanometre grid every line is on, so a line on its edge has its number.
Opacity below 1 is written, in millionths as lengths are.
The PNG writer gives the embed its encoder settings (sRGB, the dpi
recorded) and its provider check, now one function each, and streams the
picture a band of rows at a time, refused once it passes the room left
under the file's 64 MiB.
Tests: the 1182 x 591 px grid at 300 dpi and its edges, a line on the
edge, paint order and opacity, the crop and the picture off the sheet, the
bands, and each refusal; the SVG fuzz case gains a picture.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Paper scene: one walk onto a writer's number grid, for every writer (#4890, C4)
The SVG writer kept its own number grid: each coordinate whole nanometres, every joint written once,
a closed path ending exactly on its first point, slivers merged into the next piece and a path's
last piece kept. PDF, PNG and the Drawing workspace's canvas need the same rules, so they move into
`geom::paper::grid`, and the SVG writer only formats what the walk gives it.
- `Grid`: `per_mm` steps a millimetre. `Grid::NANOMETRE` (six decimals of a millimetre) is SVG's.
`Grid::new` takes 1 to 1e9; a power of two keeps every number exact as a binary float, which a
writer of 32-bit numbers such as PDF can use.
- `Prepared::on_grid(grid) -> OnGrid`: each group's items as paths of `Piece`s (lines, arcs of at
most a quarter turn, cubics, parabolas), y up as in the scene, a closed path's closing line left
to the writer's close, and a report of widths snapped and pieces merged. Slivers are measured in
the grid's own steps, so a coarser grid merges more.
- The SVG writer flips y on the whole numbers it's given and writes the same bytes as before.
`SvgReport` is the grid's report.
- Ellipses, hyperbolas and Béziers above degree 3 are still refused (A3b), now by the walk.
DXF stays on its own number rule for now: it writes exact entities (ELLIPSE, SPLINE) and is being
reworked under #5318 to #5321; whether its polylines take a grid is decided there.
Tests: every SVG test unchanged, bytes included; the grid's rounding and its bounds; the A3 border
on the grid (y up, closing line left out, fill loops closed); slivers in the grid's own steps, with
the merge boundary both ways (10 and 11 steps, a 6-8 and a 7-8 step); an arc's quarters with their
radius and turn in steps; a width under half a step made one step; an ellipse refused.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Paper scene: a sheet PNG at a chosen dpi and colour (#4890 A4)
A new writer, io::paper::paper_png, that reads the shared walk on the
nanometre grid, the one the SVG writer uses, so a PNG draws the same joints,
closures and merges. Neither the walk nor the SVG writer changes.
- Curves are flattened within 1/8 px by geom::paper::flatten, which turns
each walked piece back into its Seg2 (an arc's centre from its ends, radius
and direction) and takes Seg2::chords' steps. chords is the bound
Seg2::polyline already used (the chord's bulge for arcs, Wang's bound for
the rest), moved out of polyline unchanged so both read one rule.
polyline itself doesn't fit: it floors an arc's tolerance at a millionth of
its radius and caps a piece at 4096 steps, coarser than asked without a
word (0.1 mm, 9 px, on a 100 m arc at 2400 dpi). Over 2^20 points a path,
or 2^24 a sheet, is refused instead. tiny-skia only gets lines: its own
flattening stops at 64 lines a curve, more than a pixel off on a large arc
at a high dpi.
- 25 to 2400 dpi (300 by default). 8-bit greyscale (the default), 1-bit
black and white (no anti-aliasing, every line at least a pixel wide), 24-bit
colour, or 32-bit colour with transparent paper.
- The file records its dpi (pHYs) and sRGB, so it prints at the sheet's size.
- Each line is stroked once, then the sheet is drawn in bands of 16 MiB of
pixels streamed into the file, so memory doesn't grow with the sheet. Each
band also draws a row above and below that isn't written: tiny-skia starts
an edge a little differently where a clip cuts it (one subsample, 16
levels, in a few pixels), so no written row sits on a cut and the bytes are
the same whatever the band.
- A line under a pixel wide (in greyscale and colour) is drawn as tiny-skia's
hairline, its coverage scaled by its width: its stroked outline would fall
between the rows the rasteriser samples and vanish.
Tests: the pixel size and pHYs of A4 at 300 and 25 dpi; a line's and a fill's
pixels at 254 dpi (butt ends, the fill's hole); each colour's PNG type, ink
and paper; a hairline between two rows' centres that is light grey in
greyscale and stays one pixel in black and white, and a bar a fifth of a pixel
wide that black and white inks by its centre; a closed outline joined at its
start; a 40 mm circle round to the pixel at 600 dpi; the same bytes drawn 1, 3
or 7 rows at a time or all at once, and again; the refusals; the flattener's
bounds and counts, and its point cap at the exact boundary; the scene-JSON
fuzz through the PNG writer.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Geom: the pixel grid of a paper rectangle (#5624, W17b S1)
One rule for where a picture's pixels lie on paper, shared by the picture renderer and the writers
that place it: anchored at the rectangle's lower-left corner, rounded outward (W = ceil(w / p - 1e-9)
with p = 25.4 / dpi), so the overhang is at the top and the right; rows run top-down. At most
65,536 px a side; nothing caps the total, as pictures are drawn in tiles and strips.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Paper scene: pictures, and a sheet's pixel grid and windows (#5624, W17b S3; #4890 A9)
A picture on a sheet is `Item::Picture`: the rectangle it sits in, the name of its pixels
(`source`, opaque as a group's object id is) and its opacity. The pixels stay out of the scene: a
writer asks a `Pictures` provider for them on the grid it draws on. A PNG at 1200 dpi then gets a
shaded view drawn at 1200 dpi, not one stretched, and a scene stays small, plain data.
The pixel grid gains the two rules a sheet needs, beside the rectangle's own grid:
- `PixelGrid::sheet`: the whole sheet's grid, anchored at its top-left corner, as an image of
the sheet is drawn.
- `PixelGrid::window`: the columns and rows a rectangle meets; a side on a pixel edge takes no
sliver beyond it. A picture drawn into its window of the sheet grid is placed by copying whole
pixels.
`Picture::grid` is a picture's own grid at a dpi, for SVG and PDF to embed. `Scene::validate`
counts a picture as one record. It refuses a rectangle outside the coordinate bound or without
area, and an opacity that isn't above 0 and at most 1. `Aabb2` is read and written as
`{min, max}`.
On the walk (C4), which S3 follows here: `GridItem::Picture` passes a picture through with its rectangle in
millimetres, since the pixel grid places its pixels, and the SVG and PNG writers refuse it ("not supported yet:
pictures (A9)") until their own slices. `GridItem`, `GridGroup` and `OnGrid` are `PartialEq` only, as a
picture holds numbers that aren't `Eq`.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Paper scene: pictures in a sheet PNG (#5624, W17b S5)
The sheet PNG writer draws the scene's pictures (S3's Item::Picture) where
the scene orders them, between its lines and fills, from a Pictures provider.
- The PNG is now the sheet's pixel grid (PixelGrid::sheet, S1): anchored at
the sheet's top-left corner and rounded outward, so nothing is clipped.
210 mm at 300 dpi is 2481 px (it was 2480, rounded to the nearest). A side
over 65,536 px is refused and the refusal names the limit ("a sheet PNG
side of ... px at ... dpi is over the limit of 65536 px"); an A0 sheet
fits up to about 1400 dpi.
- A picture fills exactly its window of that grid, so it registers with the
lines drawn over the same rectangle. Each band asks the provider for just
its own rows, as straight-alpha sRGB RGBA, and the bytes are checked: too
few or too many, or the provider's error, refuse the PNG with the picture's
source named. paper::NoPictures refuses every picture.
- Pictures are asked for at most MAX_PICTURE_DPI (1200): above it, on the
grid k = ceil(dpi / 1200) times coarser, whose pixels each fill exactly
k x k of the sheet's (both grids share the top-left anchor), so a 2400 dpi
export doesn't ask a renderer for four times the pixels.
- Source-over in sRGB, the picture's alpha times its opacity; transparent
paper keeps the alpha. In black and white each picture pixel is dithered
with an 8 x 8 ordered (Bayer) matrix at its place on the sheet, so bands
don't show; lines stay solid. PngReport says whether anything was
dithered.
- In the writer a picture is one more shape a band draws, beside A4's
outlines, fills and hairlines; the walk's picture arm passes pictures
through, and the SVG writer still refuses them (A9).
Tests: a picture's exact window and its register with a fill over the same
rectangle, also on a sheet 100.8 px high (the grid anchored at its top);
pictures keep their place in the paint order; opacity scales the alpha (on
white and transparent paper, and the picture's own half alpha); above 1200
dpi a coarser picture's pixels are each copied 2 x 2; black and white
dithers half of mid grey and keeps a line over it solid, whatever the band;
a provider's short rows, its error and no provider are refused, and a
picture off the sheet asks for nothing; the bands test draws three pictures
1, 3 or 7 rows at a time, the same bytes and each picture row asked for
once; the sheet sizes on the outward grid and the 65,536 px refusal; the PNG
fuzz with a picture.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Paper scene: pictures in a sheet SVG (#5624, W17b S5)
A picture is an <image> holding a PNG as a data URI, on the picture's own
pixel grid (Picture::grid) at the picture resolution the caller gives,
25 to 1200 dpi: paper_svg(scene, pictures, picture_dpi), the same shape as
paper_png. Only its window over the sheet is embedded and asked for, so it
never costs more pixels than the sheet holds; one off the sheet is left out.
Its x, y, width and height are the grid's own pixel edges put on the
nanometre grid every line is on, so a line on its edge has its number.
Opacity below 1 is written, in millionths as lengths are.
The PNG writer gives the embed its encoder settings (sRGB, the dpi
recorded) and its provider check, now one function each, and streams the
picture a band of rows at a time, refused once it passes the room left
under the file's 64 MiB.
Tests: the 1182 x 591 px grid at 300 dpi and its edges, a line on the
edge, paint order and opacity, the crop and the picture off the sheet, the
bands, and each refusal; the SVG fuzz case gains a picture.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views: shaded snapshots and their pictures' parts (#5624, W17b S4)
drawing.view.snapshot takes `shaded` as a display or reference style and,
when a picture is drawn, says which: picture {pixels, dpi, rect_mm}, the
boundary's pixel grid at the sheet's dpi or 1200, the lower, since lines
may export finer. It renders nothing. A shaded part's own lines are left
out of the reply, as its picture draws it; it still hides what lies behind
it. shaded_visible and shaded_visible_hidden stay refused until the view's
exact lines (W06), and shaded with `scene` (and on a sheet) until the
paper scene draws pictures.
- engine::drawing_picture: the pictures a view draws, bottom first, and how
each body takes part in each (painted, depth only, left out). The model
always hides reference parts behind it; reference parts hide the model
only when reference_hides_model is on; shaded reference parts that don't
get a picture of their own under the model's, so they never cover it.
- product_scene::extract_where: the scene for the bodies a caller picks;
extract keeps the browser's eye, a drawing draws every body.
Tests: every style and hide case, reference parts through a subassembly
and a part, the picture's size at 300, 1200 and 2400 dpi, a view with
nothing shaded, the hidden body in the filtered scene, and which lines a
shaded model or shaded reference parts leave.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
`Item::Text` is a run of placed glyphs in one font, with its logical text and the clusters that
tie the two together, and `Scene.fonts` the table of the fonts the runs use (as posted on #4890,
with each glyph's `hmtx` advance). `Scene::validate` holds them to the posted rules. Writers never
parse a font.
- A run names its font by the font's id (a hash of its face's bytes and index), so groups laid
out apart name a font alike whichever machine's font it is; `Scene::add_fonts` joins their
tables at assembly, kept in order of id, so the same input gives the same bytes.
- A font's bytes never go through serde: a scene read from JSON is refused until they come from
the font of the id it names.
- `TextRun::outlines` places the glyph outlines on the sheet, for the writers to fill nonzero.
The SVG writer refuses text by name until B2. `Scene::new` builds a scene without text, so the
next field doesn't touch every caller again.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Paper scene: text runs and their fonts, as records with their rules (#4890 B1a)
`Item::Text` is a run of placed glyphs in one font, with its logical text and the clusters that
tie the two together, and `Scene.fonts` the table of the fonts the runs use (as posted on #4890,
with each glyph's `hmtx` advance). `Scene::validate` holds them to the posted rules. Writers never
parse a font.
- A run names its font by the font's id (a hash of its face's bytes and index), so groups laid
out apart name a font alike whichever machine's font it is; `Scene::add_fonts` joins their
tables at assembly, kept in order of id, so the same input gives the same bytes.
- A font's bytes never go through serde: a scene read from JSON is refused until they come from
the font of the id it names.
- `TextRun::outlines` places the glyph outlines on the sheet, for the writers to fill nonzero.
The SVG writer refuses text by name until B2. `Scene::new` builds a scene without text, so the
next field doesn't touch every caller again.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Paper text: a text laid out by sketch's rule, as the scene's runs and their drawing font (#4890 B1b)
`paper_text` lays a text out with `TextMetrics`, the rule sketch text draws and measures with, and
returns the paper scene's runs of placed glyphs (B1a) with the font they are set in, holding the
glyphs they place: each one's `hmtx` advance and its outline in font units.
- Drawings are set in bundled fonts only (`DRAWING_FONTS`: Liberation Sans for now). A font is
admitted once: a static face with a PostScript name, a cap height and a `post` table, its stem
width measured across its `l`, and its id hashed then. A run names its font by that id.
- A character the font has no glyph for is refused by name; bold is refused; an italic leans as
sketch text's made-up italic does; text on paper follows no path.
- Lines break a pitch apart and align as sketch text's do. A line with right-to-left characters
is a run per direction, shaped, with clusters from the shaper; any other is one run, a
character to a glyph.
`TextMetrics` keeps one layout: it now reports each glyph's cluster and the line's runs, and the
glyph outline walk gives loops of `Seg2`, which sketch text turns into the geometry it drew before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Paper text: the fonts a text uses, each once (#4890 F0)
`paper_text` returns its runs with the list of fonts they use, each once in order of id (so the
same text gives the same list) and each holding exactly the glyphs its runs place, where it
returned one font. Still one drawing font today; the list is the shape a text set in several
fonts (a Latin, Arabic or CJK line) needs, and `Scene::add_fonts` already takes it as it is.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Reference parts in a drawing view's lines (V5a, #5866)
A body placed through an occurrence that counts as reference is a reference
part: one rule, Document::reference_occurrences. Its lines say so in replies.
With reference_hides_model off (the default) the model's lines skip reference
parts at the one occlusion test, and reference lines test against everything.
The two roles merge apart, so a reference line never takes a model line's
place on one stretch. Extents come from the model parts when there are any. A
sketch curve is the model's: a reference part hides it only as it hides the model.
One thing the plan didn't name: reference lines stop at the view's boundary
(extents and reference margin) when model parts are there too, which is what
the margin is for; a part much bigger than the model would otherwise run off
the sheet.
Hidden reference lines in a scene are refused until dashed lines (V7b), as the
model's are.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Reference parts on paper: thin, under the model's lines (V5b, #5866)
Saved views and the snapshot's scene alike, 0.25 mm until the drawing styles
slice sets widths by kind of line.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Reference parts: tests the planted faults asked for (#5866 V5)
A reference line against a model line on one stretch, and against another reference part; one part
placed through a reference assembly and on its own; a dimension on a reference part's edge; undoing
and redoing a change of type, set on the occurrence or its component; and a saved view's setting.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* A test reads any other paper item as no stroke (#5866 V5)
Naming Fill alone would stop compiling when #7590 adds a kind of item, with
no conflict for git to show.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A drawing's fixed unit may be any length unit of the expression unit
table (expr::UNITS: um, inch, yd, mil and the rest besides a design's
five), but the display functions knew only the five and showed the
others' measurements as millimetres. unit_scale now reads the same
table, so the two can't drift apart again; the five keep exactly the
scales they had (1 over 10, 1000, 25.4 and 304.8). The inch rule (a
fourth digit when it means something) follows an inch's size, so
`inch` reads as `in` does.
A design's own units are only the five, so nothing it shows changes.
The test that pinned `inch` to millimetres becomes one that checks
every length unit of the table shows its own numbers; angle names
(`deg`, `rad`) and other text keep the millimetre fallback.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing dimensions: a hole's or an arc's centre as a point to measure from (#4896, W20c)
A linear dimension's point can be the centre of a circle or an arc, saved as its one edge's name
with `centre`. It is found again as construction geometry finds a round edge's centre
(`construct::as_circle`), in 3D, so any view can measure it; a split edge is ambiguous, and an edge
that is no longer round can't be measured. `drawing.dimension.add` takes `{centre: edge}` wherever
a corner goes, and refuses a straight edge.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing dimensions: a chain of distances along one line (#4896, W20c)
A chain dimension runs through 3 to 64 points in order (corners or hole centres) and reads the
distance from each to the next along one line as the view shows it: horizontal, vertical, along a
direction, or aligned from the first point to the last. The line runs the way the first point to
the last goes, and a point out of order is refused, never moved, so the members add up to the
overall from the first point to the last (`drawing_measure::chain`). It reads projected only (true
lengths of points off one line don't add up) and shows its members' numbers, never a text instead.
`drawing.dimension.add` takes `{chain: {points, direction?}}` and counts the points before looking
any up; `drawing.dimension.edit` changes its direction; inspect lists its members, its value being
the overall.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing dimensions: a whole cylinder's diameter between its silhouettes (#4896, W20b)
A cylinder dimension saves a face by name (ModelFace, as ModelEdge names an edge) and reads Ø
between the cylinder's two silhouettes, which any view but one along its axis shows 2r apart
(`drawing_measure::silhouette_side`). The face, or the pieces it was cut into, must lie on one
cylinder (the kernel's own condition for faces on a common cylinder); every face of the body on
it counts, since the kernel builds a whole cylinder as two half faces; and both silhouettes must
lie on those faces, so a fillet's quarter round is refused. `Document::face_reference` picks a
face by a point on it or by its index; `drawing.dimension.add` takes `{cylinder: {face}}`, edit
refuses its settings, and inspect can list face candidates.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing dimensions: between two cylinders' silhouettes (#4896, W20b)
A dimension between a silhouette of one cylinder and a silhouette of another, as the view shows
them. Each is named by a face of its cylinder and by its side: the one nearer the other cylinder
on the view, or the one farther (SilhouetteSide). So it keeps to them whichever way round the
view shows the cylinders.
- geom: drawing_measure::between_silhouettes takes the two cylinders (Cylinder, now geom's: the
type doc kept privately), their sides and a direction as a linear dimension takes it (aligned:
square to the silhouettes). The silhouettes must be parallel on the view and the axes apart
there. Foreshortened when the axes aren't parallel in the model, or the silhouettes lie at
different depths.
- doc: DimensionKind::Silhouettes { a, b: Silhouette { face, side }, direction }, read as the
view shows it. Each silhouette must lie on its cylinder's faces (Lookup::on_cylinder, now shared
with the cylinder kind). Document::silhouettes_kind makes two silhouettes of one cylinder of
one body that cylinder's diameter (which takes no direction), else the distance between them.
- engine: drawing.dimension.add takes {silhouettes: {a, b: {face, side}, direction?}};
drawing.dimension.edit changes its direction only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Recovery: a change to a drawing alone is autosaved and recovered (#3890, K9')
A design's drawings are part of its document (K3b), so the autosave already sees a drawing's
change as unsaved work and writes it with the design, and recovery reads it back. This test
holds that: with the model saved, a change to a drawing's properties alone is autosaved, and the
recovered design has the drawing as changed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Recovery: a drawing that breaks a rule is left out of the autosave and the crash copy, named (#3890)
Reading a design refuses it whole for one drawing that breaks a rule of the record, so an autosave
or a crash report's design holding one never opened again: all the unsaved work was lost. Both
copies now keep the rest of the design (drawing::openable) and name each drawing left out and the
rule: the autosave as its error, the crash report in its notes. A design's save error names the
drawing it couldn't save too (Drawing::label).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Recovery: a copy that must open keeps a design's drawing rules too (#3890)
drawing::openable now leaves out what a read refuses at the design's level as well: the later of
two drawings with one id, and the drawings past MAX_DRAWINGS, each named with its rule. So an
autosave never keeps a stale copy over a drawing problem. The id rule is take_id, which
check_in_design uses too.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Recovery: a drawing too large to save is left out too, and the status line names it (#3890)
The autosave and the crash copy already leave out a drawing that breaks a rule of the record.
A drawing too large to save failed the whole autosave instead; `openable` now leaves it out the
same way, before its id, so the rest of the design is kept. Nothing is skipped silently: the
autosave's error names each drawing left out, and the status line shows it.
Tests: a drawing left out takes no id from a later one; an autosave leaves out one too large to
save; an autosave keeps what is hidden; the status line names a drawing the autosave left out.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Dimension::last_good saves the value the session last read, written only when
there is one, and a save takes it from the session's reads as it takes what is
hidden: no read touches the document, makes an undo step or asks to be saved.
drawing.dimension.inspect answers this session's read first, else the file's.
resolve_dimensions never sees it, so a lost dimension stays lost. A value past
the drawing format's limit is left out of the save, not written into a file that
then can't open.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
An edge given as a point looked along the edge's mesh lines, within a point's tolerance, so a point on a
circle or an arc that fell between two chords found no edge: a radial dimension on most points of a rim
said "no edge at". A point off every chord now takes the edge whose chords are within what its body was
meshed to, and only when no edge passes through the point itself, so a point on a straight edge beside
a curve is still that edge.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Dimension layout: sizes for paper, and text above the line (#4896, W19c)
A dimension's sizes become a parameter, so a drawing can lay its
dimensions out in paper millimetres with the same code as a sketch:
DimSizes { arrow, gap, overshoot, offset, above } and
dim_layout_sized. dim_layout and dim_layout_reaching keep their
signatures and use DimSizes::screen(px), today's 9, 3, 4 and 22 px;
the other default text places stay the same fractions of the offset
(18, 48 and 20 to 22), and default_text takes its 22 from the same
place. A size that isn't a finite number above 0 (or is beyond MAX_COORD,
the largest length a sketch takes) falls back to its 1 px value, as a
bad px does today.
`above` puts a linear dimension's text above an unbroken dimension
line (ISO 129-1), running along the line and reading from the bottom
or the right; DimLayout::text_dir gives its direction (level for text
in the line). The arrows go inside or out by the same test, with the
text's length along the line; a leader to text outside runs on under
it.
On main, #7056 moved the four default places into
default_text_offset(frame, px). This leaves those lines as they are,
so when main next comes into drawings the layout's arms call it with
this px (the offset's 22nd), and lib.rs's export line takes both lists.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Format the dimension layout's re-exports (#4896, W19c)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
`paper::annotate` places the marks that point at things on a sheet as plain
strokes and fills in sheet millimetres: open, closed and filled arrowheads,
the oblique stroke and the dot, and leaders (points, a landing line in the
reading direction, a terminator at the first point). Every size is the
caller's; ISO 128-2's dot and landing ratios and ISO 129-1's 15° to 90°
arrowhead angle are constants beside them. A closed or filled arrowhead stops
its line at the base. Dimension layout stays W19c's (#4896) and the datum
triangle the datum symbol's (#7257).
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Brings the 1,270 commits on main since the drawings branch last met it,
including the first drawings landing (#8249), into drawings.
Merged with the drawings snapshot that #8249 landed (ebafe0748) as the
merge base, so only the drawings work after that landing is replayed on
top of main. Main's structure wins; drawings' additions are kept and
adapted to main's APIs (metadata Owner/KEYS table, checked! without a
contract argument, Snapshot visibility, crash journal outcome, the
part-properties normalisation, model_body_components, io helpers).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets on paper: the drawing border, grid and marks (#4890 A6, #3875)
SheetLayout::paper gives what a sheet's drawing border draws as paper
groups of kind drawing_border, in order, each left out when empty:
- the drawing border, one closed stroke drawing_border_line_mm wide
(0.7 mm in the built-in profile, ISO 5457);
- the grid: the grid reference border, closed, and a mark at each edge
between two fields from the drawing border out to it, on all four
sides, GRID_LINE_MM (0.35 mm, ISO 5457's grid line width as the
drawings study's section 11.3 gives it) wide; none without fields or
with the grid reference border on the drawing border;
- the centring marks, as the layout places them, in the drawing
border's width, as the profile says;
- the trimming marks, each rectangle filled.
The grid's labels are text and come once the paper scene has text
(#4813). Only the function, its constant and its tests are added.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets on paper: one sheet's scene, its border then its views by id (#4890 W10, #3890 W15)
`drawing_scene::build` draws one sheet of a drawing as one paper scene, the
one the sheet page and every export will draw, and `drawing.scene {sheet}`
answers it (in_drawing, noundo, doc_only, typed contract and output schema).
In paint order: the sheet's drawing border groups as `SheetLayout::paper`
gives them (object: the sheet), then each view on the sheet by id (object:
the view), its visible lines as `paper_group` makes them.
- A view's lines are worked out centred on the view and then moved to its
centre, exactly (each point plus the centre), so the same lines on the same
centre are the same bytes. They match the snapshot's within rounding.
- The shown set is worked out once per sheet. No model is evaluated.
- A view with nothing to measure is a placeholder, and one that can't be
drawn yet (shaded, or hidden lines) fails with the snapshot's reason. Each
draws nothing, and the sheet's other views are still drawn.
- A view is placed only while the sheet stays within the paper scene's
100,000 records. One that would pass the limit fails and says so, and later
views that fit are still drawn. Each view's lines are placed as they are
drawn, so at most one view's lines are held beside the scene.
- A view above 100:1 takes a coarser chord rather than asking the mesh for
chords below its floor. A saved view has no chord setting to give.
One rule, one place:
- the snapshot's two style refusals are `drawing_view::not_drawable`;
- a group's record count is `paper::Group::records`, which `Scene::validate`
now counts with;
- the stats reply is `From<Stats>`;
- both paper scene schemas come from `paper_scene_schema`.
Tests: the border then the views by id, byte for byte against the layout,
with hand-worked outlines and lengths; the command's reply and its schema; the
SVG's group order; each view against the snapshot, and one of many lines (a
block with eight holes, from above); an empty sheet; a failed and a
placeholder view; no evaluation; refusals; the record limit at exactly 100,000
and one past it; a 200:1 view.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets on paper: the provider the sheet page draws through (#4890 W10, #3890 W15)
The sheet page asks for a sheet every frame, so it draws through a provider
that keeps each view's lines between frames, instead of through `build`.
- `drawing_scene::extract(session, sheet)` returns the last scene at once,
with each view as it was last drawn and the ones out of date. Nothing is
drawn there. When the drawing, the world state and the views drawn are all
as they were, it returns the same answer without looking at the sheet.
- `drawing_scene::step(session)` draws the first out-of-date view of the
sheet last extracted and says whether more wait: a short piece of work for
the UI's tick, one view's projection.
- `generation` comes from one counter for every session. It goes up only
when a sheet's scene is assembled again, so a page never sees one number for
two scenes, even across closing and opening its drawing.
The cache is the session's view state, beside the record: never saved, never
an undo step. `Session::execute` drops it when a command closes the drawing or
opens another. One entry per view, keyed by the world state it was drawn from
(held in the entry and compared with `Arc::ptr_eq`) and the view as it resolves.
A drawing-only edit keeps the world state, so a move, and its undo, project
nothing: the same centred lines are moved to the new centre. The shown set is
worked out once per world state. Views no longer in the drawing are forgotten
when a scene is assembled again.
Tests:
- a new cache gives the border with both views out of date;
- each step draws one view, in id order, until the scene is `build`'s, byte for
byte;
- the generation stays put while nothing changes;
- a move and its undo project nothing, and the views move by exactly the move;
- after a model change (a checkpoint restored) the last scene shows, and a view
listed as up to date always draws as `build` does;
- closing drops the cache, and the scene after reopening has a new generation;
- seeded mixes of moves, setting edits, undos, redos, extracts and steps
always end at `build`'s scene.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing export: a sheet of the open drawing as SVG, from its scene (#4890 A7)
drawing.export {sheet, format?, path?} writes one sheet of the open
drawing from drawing_scene::build's scene, the scene the sheet page
draws, so a file shows what the page does: its drawing border, then
each view's visible lines, through the SVG writer. With a path (a .svg
file, checked by vfs::check before and again just before writing, as
the view DXF is) the file is written atomically; without one the reply
holds the SVG. The reply gives its size, what the writer snapped or
merged, and each view's status as drawing.scene reports it.
A sheet with a view that failed isn't written: the refusal names each
such view with why. A placeholder view (nothing to measure) draws
nothing and is exported all the same. PNG and DXF are "not supported
yet": they come with the sheet PNG writer (#4890 A4) and the shared DXF
writer (#5319). No undo step; no model is evaluated.
One rule, one place: the scene's sheet look-up is
drawing_scene::sheet_id, and a view's reply entry is
From<ViewState> for SheetSceneView, both used by drawing.scene and
drawing.export. The scene tests' drawing fixture is open to the crate's
tests.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
`bom_quantity` is a part property of any component: what one placement of it means, an expression
evaluated with the design's parameters (pieces without a unit, else a length). A row's `quantity`
is what its placements add up to, with `quantity_unit`; pieces beside a length, or a quantity that
no longer evaluates, give none and say why. A quantity is a parameter user: a rename follows it, and
a parameter it uses can't be deleted. The CSV gains a `quantity` column at the end.
`virtual` marks a component with no geometry (grease, paint, a label): listed with its quantity,
weighing nothing. It can't be the active component, and one check after each undoable outermost
command refuses any change that puts a body, a sketch or a placed component into one, whichever
command made it. A file a damaged virtual component already fills opens, and other changes go on.
Mass, volume and area quantities wait for the expression units of #4811.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials types on one occurrence (#3874)
An occurrence can count in the bill of materials as another type than its
component, for that occurrence only: `bom_type` on the occurrence, set with
occurrence.bom_type (one undo step; it changes no geometry, so nothing is
evaluated). An occurrence without it counts as its component, so older
designs need no step; the format change is one pending file
(occurrence-bom-type.rs).
assembly.bom counts each placement by its own type: a purchased placement of
a kit part is one row without the kit's contents, a phantom placement lists
what it holds where it sits, and one component placed as two types gives a
row for each. Paste New keeps the types; Paste Instance counts as the
component. The compact list and the locales (en, de, ja, ko, zh) carry it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials rows: material, and mass when asked (#3874)
Every row of assembly.bom (and every part folded into a row) names the
physical materials of its definitions' own bodies, each once, with "; "
between several. An unassigned body's is Default. A subassembly or an
empty component has none of its own.
With mass: true each row also carries mass_g, what one of its parts
weighs as the row stands for it, so the rows of any list add up to the
assembly once:
- at the top level, all it holds;
- in parts only, its own bodies, because what it holds is listed beside
it; but a folded part's row is the kit (all it holds), a purchased part
is all it holds, and an inseparable one all but its purchased parts;
- a reference placement adds nothing, nor does anything inside it.
It is null when nothing in the part has a body, a body can't be
measured or measures a negative volume (inside out, such as an open mesh
facing the origin), or the definitions sharing the row's part number
weigh differently.
Measuring runs the kernel, so it is asked for: the Bill of Materials
window re-runs assembly.bom after every change and doesn't ask (0.2 ms
without mass, 135 ms with it on a bolted bracket). Placements are rigid,
so each definition is weighed once however often it is placed, and each
body is measured once with measure_mass (the same volume as measure,
without the topology counts' tessellation).
A body's material and its density now follow one rule:
Document::body_material (new, beside Document::density) is the material
its mass is worked out with, named as the library or the design spells
it: the assigned one when it is known and has a usable density, else
DEFAULT_MATERIAL (new, beside DEFAULT_DENSITY). Document::density is
that material's density, with the same values as before. So a damaged
file's unknown or broken material reads as Default, as it weighs, and a
hand-edited "steel" reads as Steel. The bill of materials uses both; the
other places that read a body's material or spell "Default"
(component.properties, inspect and others) move to them in a separate
cleanup PR for #4783, which brings the same two functions to main.
Document::body_owners returns each body's owner in order, so the rows
find their bodies in one pass. It no longer repeats the owner rule:
model_body_component, legacy_body_component and body_owners go through
the rule written once, given how to find a feature's component (the
timeline for one body; body_owners still builds its map once). The CSV
columns are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Physical properties: a reference placement adds nothing (#3874)
component.properties and occurrence.properties now leave out a placement
that counts as a reference in the bill of materials (its occurrence's
bom_type, else its component's: a fixture shown for context), and
everything inside it: no body entry, mass, volume, area, centre of mass
or bounding box, and it isn't in placement_count. That is the bill of
materials' rule, so a reference part is in neither the parts list nor
the assembly's mass, and every bill of materials list still adds up to
the assembly's Properties. The placement asked for counts whatever its
type: a reference fixture's own Properties still measure it and what it
holds, as a component's own bill of materials lists what it holds.
Only the totals change. The placements walk that face picking, sketches
on placed faces and the occurrence path lookup use stays complete, so a
reference fixture's faces can still be picked.
The type an occurrence counts as is now written once:
Document::occurrence_bom_types (new, beside BomType) gives each
occurrence's type in their order, looking each component up once. The
bill of materials, occurrence.bom_type's reply and the physical
properties use it, in place of the two copies in the bill of materials.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials: one module of typed rows in doc (#3874)
The bill of materials now lives in solidcraft_doc::bom as the typed rows
of a bill of materials view. assembly.bom's JSON and CSV and the Bill of
Materials window present those rows; parts lists, item numbers and
balloons are to read them too.
- list(tree, request) walks the placements below the assembly once. One
rule (classify) decides for each placement whether it is counted in a
row, how what it holds is walked and what its row stands for when
weighed, from the type it counts as, the view and the component's
shape. "An inseparable part's purchased parts are listed beside it" is
written there once, and the mass walk reads it.
- A row carries its identity (RowKey: the rows it is listed under and
its lowest member, a component and the type it counts as), its item,
count, each, the placements it counts by occurrence path, what it
stands for (Holds), its part properties, materials, mass and children.
- Mass is a Mass: not asked, grams, or unknown with the reason (nothing
to weigh, unmeasurable, the definitions differ). Each definition is
weighed once for each kind of row and kept in the Tree. The assembly's
total is weighed from the design the same way, not added up from rows,
so it is known even when a row's definitions weigh differently.
- Bom::row_of(tree, path) finds the row a placement is counted in (a nut
inside a purchased bolt is in the bolt's), or says why there is none:
no such placement, a reference, or no row of its own.
- rows_deep() lists each row followed by its children (1, 1.1, 1.2, 2);
Request::default() is assembly.bom {}; View and Group carry the
commands' words.
What changes, beside that the output is otherwise the same:
- One placement budget (100,000) and one depth limit (64 levels) cover
the whole list. A folded part's contents used to be walked under a
budget of their own, so a design past the limit was listed with
group_children; it is refused now, as it already was without it.
- Kits are compared by what they hold (part, type and count), not as
text: a part without a part number whose id is 12 no longer reads as a
part numbered "#12", nor a part numbered "P×1\nQ" as a P and a Q. Kits
holding the same parts through different definitions (two bolt
definitions, each with its own nut definition of one part number) are
one row, and its children count every bolt's placements, where they
showed the first bolt's definitions only.
- A folded part's row always stands for all it holds. It used to stand
for its own bodies when nothing inside it was listed, which differs
only for a phantom with bodies of its own inside it.
- An inseparable part's row in parts only names the material of what it
stands for (its steel blocks read Steel) where it was blank, and a
subassembly whose parts share one material names it at the top level.
- A damaged file's component placed inside itself is refused at the first
level too, since naming a row's material walks inside it, as weighing
it already did.
- A row's body count saturates, so a compact assembly with more placed
bodies than a count holds (a block placed 2^64 times) is weighed
instead of overflowing.
Materials follow Cameron's rule for a row that stands for an assembly
(C3, 2026-10-23): a part's row lists its own bodies' materials, as before;
a row that weighs what is placed inside it (a subassembly at the top level,
a purchased or inseparable part with parts inside it, a folded part) names
a material only when everything it stands for shares it, else none. A frame
of steel and aluminium parts reads blank, and a bought bearing of steel
parts reads steel. One walk (adding) decides what is placed inside a row's
part for both its mass and its materials, and each definition's materials
are read once.
Components are looked up by id once per list; they were searched for
each row and each kit. The window reads the rows directly instead of
running assembly.bom after every change, so it no longer adds an entry
to the crash journal each time it refreshes. The engine keeps the
command, its parameters and the files.
Tests check rows. The module's own: an empty assembly, one part, a row
named by its lowest member through part-number edits, one part number
of two types, a phantom in a phantom, a reference at the root and its
own list, the 64-level limit, the budget hit exactly with and without
folding, kits told apart by what they hold and the types they hold it as, a folded part's contents not
folded again, row_of for every type, every placement in one row or
none, a damaged file's missing component and cycle, the mass agreement
rule (moved from the engine with row_mass) and what adds to a row. In
the engine: the material rule for every kind of row, the JSON against the
rows for every option, why a mass is
unknown, the total against component.properties in every view, what a
row stands for and its placements, and the overflow. The assembly.bom
tests from #1888 on pass unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials: structured, all levels (#3874)
P4: `assembly.bom {levels: "all"}` lists the assembly's direct contents, each subassembly a row with
its own rows listed under it, to any depth (items 1, 1.1, 1.1.1), each child counted `each` per one
of its parent and `count` in all.
- `doc::bom::View::AllLevels` goes through the one rule (`classify`) the other views use: a
normal subassembly is a row holding what it holds, listed under it as all levels again; a
phantom has no row and what it holds joins the level it sits in, merged with the same parts
there; a purchased part is a row with nothing under it unless `show_purchased_contents`
(Request::purchased_contents) asks for its contents; an inseparable part is a row with nothing
under it; a reference counts nowhere.
- The rows under a row are the folded-part rows already built (kits), so subassemblies with one
part number and different contents are different rows, and no second nested builder is written.
All levels gathers every level as it gathers the first; a folded part's contents are still
gathered by part number in the other views.
- The JSON and CSV already nest to any depth; `show_purchased_contents` is echoed with the other
options. Each row's mass still adds up to the assembly at the top.
Tests, worked by hand: four bolts and a two-bolt subassembly placed twice (8 bolts in parts only;
in all levels the subassembly twice with 2 bolts each, 4 in all, beside the top's 4); three levels
deep (2 x 3 x 2: counts 2, 6, 12, items 1, 1.1, 1.1.1, the CSV in that order); each type (a
phantom's bolt merged into its subassembly's, purchased with and without its contents,
inseparable, reference); two subassemblies of one part number with different contents as two
rows; `levels: "deep"`, a flag that isn't one, and an assembly over 100,000 placements refused.
D's test that a folded part's contents are listed as parts only lists them now names the two views
it holds for, and checks all levels' nested rows (the subassembly inside the folded part a row with
its own rows).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials: parts with one part number are one row only when they hold the same to any depth (#3874)
The kit compare looked one level down: two parts with one part number whose contents differed two
levels below merged into one row, and the children that only one of them held came out at each 0.
Each placement now has a kit, a number interned from what it holds (each child's part, type and
own kit), built in one pass from the last entry back: an entry's children come after it in the
walk, so their kits are known first. Rows are told apart by that number.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials: a phantom's own bodies are a row of their own (#3874)
A phantom had no row, and its own bodies were weighed in the assembly's total but in no row, so
the rows didn't add up. Its own bodies, when it has any, are now a row of the phantom's type that
stands for them alone, as a subassembly's own bodies are in parts only; what it holds still counts
where it is placed. Inside an inseparable part in parts only, nothing changes: the part's row
weighs them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials: the assembly's total mass in assembly.bom (#3874)
`list` weighed the assembly as a whole (from the design, not added up from rows) and the command
dropped it. `assembly.bom` now gives it as `total_mass_g`, and so does a JSON file it writes, only
when `mass: true` (null when it isn't known).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials: all levels as JSON lists its rows one after another (#3874)
All levels nested each level's rows in the row above it: two JSON containers a level, so the
64 levels a list may hold came to 129, past the 128 that serde_json (and so the MCP server and
the control channel) reads. In all levels `assembly.bom` now gives the rows one after another,
each followed by the rows under it (items 1, 1.1, 1.1.1), as its CSV does; a row listed under
another still reads its item as text and gives `each`. A folded part's contents, one level, stay
inside its row as `children`.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials: a row whose definitions weigh something and nothing differs (#3874)
A row gathering a definition with bodies and one with none (one part number on a steel block and
on an empty assembly) said there was nothing to weigh. Their masses differ, so it says so; only a
row where none of them has a body has nothing to weigh.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials: definitions agree on a mass within the measurement accuracy (#3874)
A row's definitions had to weigh the same to 1e-9, but the kernel measures a volume from
tessellations, and one part modelled another way is tessellated differently: a pin made as a
cylinder and as a revolved rectangle measured 1.05e-5 apart, so it read as two masses. The bill of
materials now has its own `bom::MEASURE_ACCURACY` (1e-4: ten times that gap, with its doc on what
it follows: the kernel's `measure` gives one solid's volume to about that, relative, however the
solid was modelled), and a row's definitions agree within it. A pin 0.1% wider (0.2% heavier) still
differs. The kernel is unchanged: its work is paused while it is being replaced.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials guide: all levels, purchased contents and this round's changes (#3874)
The guide had no `levels: "all"` or `show_purchased_contents`. It now has both, with how all
levels tells subassemblies apart and lists its rows as JSON, a phantom's own bodies as a row, the
assembly's `total_mass_g`, and definitions that agree on a mass within the measurement.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials: materials are bodies', as the code says (#3874)
The rule stays as built (a row that stands for an assembly names a material only when everything
in it shares one), but its comment and the guide said a material set on a component is set on
all its bodies. `material.assign` takes bodies only: a component has no material of its own yet.
The module notes now say so, and where component materials will join the rule.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials: a body's volume measured once with the evaluated model (#3874)
`assembly.bom` measured each definition's bodies anew for every list, and `component.properties`
measured each placed body again. A body's measure depends on nothing but the body, so the evaluated
model keeps its volume (`ModelBody::volume`, shared by clones, as its outline box is), and both
commands weigh that one measurement: the same grams to the bit. A body offset scales it by the size
of its determinant (`mat_volume_scale`) instead of copying the B-rep to measure it. The physical
properties still measure the placed body for its area, centre, box and counts.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials: row keys, what rows stand for, members and row_of stay in doc (#3874)
Nothing outside `doc` reads them yet: `RowKey`, `Unlisted`, `Holds`, a row's `key`, `stands_for`
and `members`, and `Bom::row_of` are crate-private until item numbers and balloons need them, so
they can still change without breaking another crate. The engine test that read them is covered
by doc's own (`row_of_finds_the_row_a_placement_is_counted_in`, `every_placement_is_in_one_row_or_none`).
`Unknown` stays public: `Mass::Unknown` carries it, and a public enum can't carry a private type.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Assemblies: one fallible placement walk for totals that cover the whole assembly (#3874)
The physical properties walked the placements twice in their own code, with the 64 levels and
100,000 placements written as literals, and the bill of materials gave the same refusal in words
of its own. `Document::placements_below` is that walk once, from any placement, refusing what is
past `MAX_PLACEMENT_DEPTH` or `MAX_PLACEMENTS` (never walking it in part), and both use its
refusal: "the assembly is deeper than 64 levels or has more than 100000 placements". The physical
properties now allow 100,000 placements below the start, as the bill of materials does (they
stopped at 99,999).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials: the same rows for less work (#3874)
- Part numbers are borrowed from their definitions (`Part<'a>::Number(&'a str)`) instead of copied
for every placement grouped and every kit.
- A row's members, the placements' paths, are built only when the list is asked for them
(`list_with`, for item numbers, balloons and `row_of`): the walk then keeps paths and moves each
into its one row instead of copying it. A list made for its rows alone builds no paths at all.
- `row_of` reads an index of member paths, built once with the list, instead of scanning every
row's members for each placement asked about.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* occurrence.bom_type: input and output schemas (#3874, #4035)
`OccurrenceBomTypeParams` takes the occurrence (an id or a name), its path when given and the
type (one of the five, `same_as_component` or null), each read by the handler's own reader: the
path through `cmd::path_ids`, split out of `occurrence_path`, the type through
`cmd::occurrence_bom_type`, split out of the handler. The handler builds its reply from
`OccurrenceBomTypeResult` ({occurrence, bom_type, effective, changed}).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials tests: all levels presented at every depth, and its caps (#3874)
- `assembly_bom_presents_the_typed_rows` now covers all levels (with mass, purchased contents and
by definition) and the total mass, on a three-level design with a purchased gearbox holding a
gear, comparing every field of every row down to 1.1.1.1.
- All levels lists 100,000 placements and 64 levels, and refuses 100,001 and 65.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials: static materials, typed in for a component (#3874)
A value the bill of materials works out can now be typed in by hand for a component (a static
value, Cameron's choice of word). Material comes first:
`component.metadata.set {component, material}` takes any text up to MAX_TEXT_BYTES, and
`component.metadata` reads it back as `material`. It is shown wherever the component is listed,
at every level and in every view, over the materials worked out from its own bodies or an
assembly's blank, and the row carries `static: ["material"]`. Clearing it (empty text or null)
brings the worked-out material back.
It is kept the way `bom_type` is: a part property in the component's metadata (`material`), so
there is no format change and older releases keep it. `PART_ONLY` names both keys in one place:
Design Properties doesn't list them and `document.metadata.set` refuses them. Another tool's
non-text value is kept and reads as no static material.
The bill of materials says one thing about the part everywhere: a static material also stands for
the part in the one material an assembly around it shares (two parts typed in as S355 make their
frame read S355; S355 beside plain steel reads blank). A phantom's row is its own bodies, so its
static material names those only, and what it holds keeps its own. A row gathering several
definitions takes the first one's that has a static material, as its description does. It only
names: mass still comes from the bodies.
The CSV gets a `material` column at the end, so the other columns keep their places: what the row
shows, the static material or the worked-out ones joined with "; ".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials: stable item numbers, saved with the design (#3874, P5a)
A numbered parts list keeps each row's item number under the row's key in
`assembly.item_numbers`, so a row keeps its number when others are added,
removed or reordered. New rows take the next number after the highest at
their level; Renumber restarts a view in list or item order and leaves
locked rows alone; duplicates are marked; numbers change no geometry and
are part properties in the undo history.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* View DXF: its lines come from one module both view commands share (#5866, W07 V1)
The view DXF (file.export_view_dxf) finds its lines in four files private to the command: the
export meshes, the projection, the hidden-line scene and the progress stages. Drawing views
(W07's drawing.view) need the same lines, so the four move to engine/src/mesh_lines, with
three changes that let a caller other than the DXF use them:
- prepare takes the bodies to draw from its caller (the DXF passes the shown ones), and
names the caller's command in its errors;
- the lines are seen from a View (an origin, a right/up/back basis and, for perspective, the
eye's distance) instead of a viewport Camera; the DXF builds one from its camera, with the
same arithmetic as before;
- a sketch's polyline (Part) belongs to the module, so the sketch code no longer defines what
the scene draws.
The DXF writing stays in cmd/view_dxf.rs, with connect (the dashed-line joining), and the stage
names and cancellation text stay the DXF's. Nothing else changes: the module is the DXF's own
code, moved, and the DXF writes the same bytes as before for every case checked (see the PR).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* View DXF: the sketch runs go once the lines are made, and a box's outline pinned (#5866, review)
From the review of #6482:
- The sketch runs (up to 4,000,000 points) are dropped once the lines are made, as they were
before the move, instead of living through the DXF writing.
- `mesh_lines::prepare`'s doc says which errors name the command: those about the placements.
A body with no exportable surface, the memory budget and cancellation come back as the meshing
stage's own.
- A new test pins the lines themselves by hand: a plain 40 x 30 x 10 box seen from the front is
its 40 x 10 outline. Every line lies along a side, they add up to the 100 mm perimeter, and
nothing is hidden.
- The shared-geometry test hides the definition's first placement: the other two are still
drawn from the one shared mesh.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views: the bodies a view shows, worked out once per request (#5866, W07 V3)
A view's extents and, next, its lines read one list: each body the design places, with the
occurrences that place it and its definition's body name, in the world state's order. Choosing
occurrences and hiding parts (V4) and the reference split (V5) become filters on it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views: a view's lines from the mesh projection, each named by what drew it (#5866, W07 V3)
drawing.view.snapshot now returns its lines: every shown body's edges and silhouettes from the
view DXF's mesh projection, seen orthographically on the view's basis, in pieces of one visibility
on the sheet. Each line names its occurrence path, its body and its source (an edge, as model.edges
numbers it, with whether it is a tangent edge, or a silhouette across a face). They are marked
approximate and sampled (Cameron's choice, 2026-10-27): the exact lines (W06) take over per body
after the kernel swap (V8).
- display_style visible or visible_hidden; tangent_edges hide or show; chord_mm, the paper chord
the meshes are asked for (0.001 to 1, 0.01 by default). The model chord is chord_mm over the
scale: the view DXF's 1 mm cap doesn't apply, so a view below 1:100 keeps its chord on paper;
its 0.0001 mm floor does, and a chord under it is refused with the chord_mm that would do.
- max_error_mm is a check, never a setting (the accuracy rule on #5866): refused while any piece
is sampled, with the count of pieces short of it.
- The three view DXF changes moved here from V1: each segment keeps its owner (its placement and
its edge or silhouette face); a stretch two sources share belongs to the nearest visible one,
else the nearest hidden one (level ones in owner order), ends where that changes, and counts as
covered; the triangles keep their faces for that. The view DXF asks for neither, so it merges and
writes as before. (Nearest, not first: a hole seen end on has its bottom rim under its top one,
and by owner order the bottom rim took the stretches it shows through, cutting the top rim up.)
- A mesh side between two faces every edge between which is drawn is no silhouette: it lies on one
of those edges, already drawn from its own curve. (Seen end on, a hole's wall faces neither way,
and the side it shares with the top face drew stray chords just inside the rim.) The triangles
keep their faces for it in both commands (4 bytes each, in the memory budget); without them the
view DXF drew a hole's rim twice, and a view DXF test now finds every line drawn once.
- A triangle seen edge on, its normal at most 1e-3 (cosine) toward the view, faces away whatever
sign the mesh's own error gives it, so no silhouette lies between two of them. (Seen end on, a
bend's surface drew its rows as chords beside its arcs: a 60° bend's outer arc 1.76 times over.
A view DXF test now finds each of its arcs drawn once.)
- Mesh positions within the tolerance weld: a position takes the key of the first one within it,
in its own rounding cell or a neighbouring one. (The faces round a hole's rim are meshed apart,
their copies of a rim vertex up to about 1e-7 mm apart, and copies either side of a cell
boundary never met: each copy's side was a boundary, drawn as a silhouette.) The view DXF takes
these three rules too; they change its lines only where a side lies along a drawn edge, a
triangle is seen edge on or a weld was missed. The sample designs' view DXFs lose lines, and
each line they gain lies within 0.0011 mm of an old one.
- One source's stretches join into runs within twice the tolerance the lines were merged at: the
merge drops spans up to that long, so a stretch can stop that short of a corner on either side.
- The tangent test is a stadium of cubic segments: the kernel marks a join smooth only between
faces swept from cubic segments, and one between two pieces of one surface is a seam, never
drawn; a fillet's round keeps its edges, as the viewport draws them.
compile fix by the personal PC
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views: a circle facing the view is drawn as its exact arc (#5866, W07 V3)
An edge that is a circle, or part of one, in a plane parallel to the view
is drawn as its exact arc from Body::planar_edges instead of the mesh's
chords. Where the mesh projection says its visibility changes, the arc is
cut there: a piece that runs along all of the edge is analytic, a cut
piece keeps the mesh's sampled accuracy; its ends may stop within the
stretches' join tolerance of the edge's own, as the merge leaves them.
planar_edges is asked once per shared mesh and placement turn, for the
curved edges only; a part placed again the same way takes the arcs
shifted on the view's plane.
compile fix by the personal PC
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views: a view's visible lines as a paper scene group (#5866, W07 V7a)
The paper scene gains a kind for views (ObjectKind::View, layer VIEW).
drawing_view::paper_group turns a view's lines into its group: each
visible piece one stroke, 0.5 mm wide until D2 sets widths by kind of
line, closed when it ends where it starts; a line with no length is left
out and an arc too short to sweep is its chord. W14 calls it for saved
views.
drawing.view.snapshot takes scene: true and replies with the lines as a
paper scene of its sheet, checked by Scene::validate before it is
returned. Hidden lines need dashed strokes (A5, #7430), so scene with
visible_hidden is refused until V7b.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views: a view draws the occurrences its source names and hide leaves out (#5866, W07 V4)
drawing.view.snapshot takes source: {occurrences: [[ids]]}, the occurrence
subtrees it draws ([] the design's own bodies; every body when not given),
and hide: [[ids]], subtrees left out. A body is drawn when its path is under
a source path and under no hide path, so a hidden path wins over a source
path above it. The rule is one filter on the shown set (ShownSet::keep), so
the extents, the lines and the paper scene follow it; each body costs one
look-up per head of its path, at most 64.
Each path is checked by Session::occurrence_placement as it is (each id in
its parent, no id twice, 1 to 64 ids), with at most 1000 paths in each list
and 4096 ids in all. [] in hide and a choice that leaves nothing are
refused. M2's occurrence tree will make the check one step per id later,
inside occurrence_placement.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views: a bend seen end on draws its arcs once at any angle (#5866, W07 V4b)
A triangle whose surface is seen edge on at each of its corners (the mesh's own normals, at most
1e-3 toward the view) now faces away, whatever lean its facet has. A thin triangle's facet leans by
the mesh's chord error over its own width, which can be far past the 1e-3 a facet may lean and
still count as edge on. Seen end on, a 90° bend's surface is meshed with its edges' samples at its
ends and its rows at even angles inside, 1.667 mm in; the triangles that join the two lean 1.1e-3
to 5.8e-3, so each one facing the view among its neighbours facing away drew silhouettes along its
sides: chords beside the arcs, 1.14 times the inner arc and 1.69 times the outer. The view DXF
takes the rule too.
The export meshes keep their normals for it: 24 bytes a vertex, a position's size again, counted
in the export's 512 MB mesh budget, so the largest view that budget takes is about 30%
smaller. A mesh without normals keeps its facets' facing.
Tests: the bend test takes a 90° bend beside the 60° one; each bend circle's lines add up to its
arc, less only what sampling takes off.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* cell: rules both kinds of table share (#3874)
Sheet tables (parts lists first) use the title blocks' cell content, so
the rules both read live in cell.rs:
- Source::Row: the row of a sheet table a cell is on. A title block has
no rows, so its validation refuses a cell that reads one.
- Warning::Width: a word wider than its value box, shown whole, never
cut: the width warning that measured text brings.
- is_snake_case moves here from title_block.rs: table columns are named
by the same rule as cells. check_text is shared the same way.
Tests: a title block cell reading a row is refused, beside other parts.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
(cherry picked from commit 640cc3e0f5)
* Sheet tables: the parts-list table model and layout (#3874, P7a)
A Table is a sheet table's definition: its columns, the side its heading
is on (top, or at the bottom with the first row just above it, ISO
7573), its row height (7 mm by default), text height, line widths, a
filter and overrides. A column's cells are the title blocks' cell
content read against each row: row fields and text. Rows are input, in
their listed order, with their values worked out and formatted, so a
filter (parts, assemblies, purchased, text per column ignoring case)
hides rows and never changes a count or a quantity.
Table::layout places it with a text measurer, from the right end of the
heading's outer edge:
- a column without a set width is as wide as its widest line, padding and
line insets added; a set width is kept;
- every cell in a set-width column breaks between words to fit, and its
row grows to hold its lines, 10/7 cap heights apart (ISO 3098-0); a
word wider than its column is shown whole with Warning::Width;
- a row field the row doesn't have shows "-"; an override shows its text
and keeps the value it replaces, an empty one is a blank cell, and one
for a row that has gone is kept;
- cells sit inside their lines as a title block's do.
Limits, refused and never truncated: 10,000 rows and overrides, 64
columns, 1 MiB of text in all (each cell's text counted before it is
built), 256-byte keys, a measured width that isn't finite and at least
0, a table off the paper's coordinates.
Nothing is saved or drawn yet: the real measurer, DXF and CSV output and
the command come with P7b.
Tests: hand-worked cell corners and text anchors with a fixed-width
measurer, the heading at the top and at the bottom; wrapping and the
row it grows; a word too wide; overrides, blanks, "-"; each filter
leaving every shown value as given; JSON round trip, defaults and
unknown fields; every limit and one past it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
(cherry picked from commit 0c5180267d)
* Revision record and table (#3874, W31, P14a)
A drawing's revisions as data (geom::revision): one RevisionRecord for
the whole drawing, or per sheet with each sheet numbered apart.
- A row holds what people type: revision, description, designer,
checker and date. Adding a row fills in only the next revision;
nothing fills in a date, a checker or an approval.
- Numbers run from 1, or 0; letters run A to Y without I, O, Q, S, X
and Z, then AA, AB. The next revision follows the highest in its scope
among the rows and the issued history, so an issued revision is never
given out again. A typed revision is kept as typed; in letters one
with a skipped letter is accepted with a SkippedLetter warning.
- Rows are added, hidden and deleted; issue() appends a copy of a row to
the issued history, which nothing removes or changes (private, read
through issued()). Row and tag ids come from the caller (the
design's random ids), never from a counter, so two people adding rows
never take the same id; an id in use is refused.
- Triangular tags bind to a row id and show its revision or their own
text; deleting a row reports its tags, which keep the revision they
showed, marked lost.
- The revision table is the sheet table (table()): Revision,
Description, Designer, Checker, Date, heading at the top; hidden rows
are left out. The table's rows and a title block's revision fields
(newest(), hidden rows included) read RevisionRow::field, one path.
This is the drawing's revision only: the model's revision and the
export time are kept apart. Release, approval and frozen snapshots
(G16/G22) are not in this slice. Nothing is placed or saved on a sheet
yet (W12, W15).
Tests: numbering both ways with the skips and past Y and YY, typed
revisions and the warning, the next after issued and deleted rows, per
sheet; add fills in nothing else; history kept through hide and
delete; tags reported and lost; the title block's fields and the table
rows from one function, laid out by the sheet table; JSON round trip,
unknown fields and damaged records refused; the caps; an id in use refused.
- An issued copy keeps the model version it was issued against
(model_version, given to issue(); none until version control gives
versions, #2869), so the release step has its field here. It is read
by the label rule, like the revision.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
(cherry picked from commit fa7849ada7)
* Drawing revisions: rows added, edited, deleted and listed by command (#3874, W31)
A drawing saves one revision record for all its sheets (Drawing::revisions, behind an Arc as the
sheets are, so an undo step shares it; validated with the drawing; its ids among the drawing's ids
in use), in the order its rows were added, the newest last. Pending drawing format: revisions.
- drawing.revision.add {set?}: a row with the next revision, after the highest the drawing has
given, and any texts given: one undo step.
- drawing.revision.edit {row, set: {revision?, description?, designer?, checker?, date?,
hidden?}}: the texts as typed (a revision is one line) and what changed; a revision in letters
with a letter the lettering skips is kept and warned about.
- drawing.revision.delete {row}: the row, and the tags it leaves showing the revision they had.
- drawing.revision.list: every row, the oldest first, and the revision a new row gets.
An id's text form (13 characters of lowercase Crockford base32) moves down to solidcraft_geom::ids,
with an option helper, so the revision record (geom) writes its row and tag ids as every drawing id
is written; solidcraft_doc::ids gives them on, beside IdSource.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing revisions: listed by drawing.inspect, a table row keyed by its id's text, and a record per sheet tested (#3874, W31)
The rows show in drawing.inspect beside the sheets, as `revisions: {rows, next}`, from the same
function the revision commands answer with; drawing.revision.list goes, so a drawing's rows have one
place to be read. A revision table's row is keyed by its id as a file writes it, the one spelling
every drawing id has (a table's cell overrides name a row by its key). A record kept per sheet whose
rows keep its own rules is refused by the drawing, so that rule has a test of its own.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing balloons: the record, its rules and the sheet hooks (#3874)
A balloon points at a part placed in its view's model by an edge of it, saved
by name as a dimension's edge is (ModelEdge), with the occurrence path as the
part it numbers, and sits at a place on paper from its view's centre. The
dimension module's reference checks and strict lookup are shared, not copied.
Balloons go with their sheet, list in on_sheet and take ids from the drawing.
One pending drawing format file; a drawing without balloons saves as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing balloons: add, edit and inspect, with their schemas (#3874)
drawing.balloon.add puts a balloon on a saved view, pointing at a placed part
by an edge picked as a dimension's is and saved by name; edit moves it on
paper; inspect says where it stands with the model now, with the arrow's
point on its edge's middle. Add and edit are one undo step each, and none of
them evaluates the model. The status words come from one function shared with
the dimension commands.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing balloons: a copied view takes its balloons, and views and sheets list them (#3874)
A view's balloons are part of what it shows, so copying a view copies them,
with ids of their own, as its dimensions are copied. drawing.view.inspect
lists a view's balloons, and deleting a sheet names the balloons on it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Drawings saved inside the design's file, in both forms (#3890)
K3b of the drawing storage plan, after #7098: a drawing lives in the file of the design it draws
(bherbruck's proposal, Cameron's choice), so the separate drawing file goes.
- `Document.drawings`: the design's drawings, each its own record of the drawing family
(`solidcraft-drawing/N`), each behind its own `Arc`. Every reader and writer of a design now
carries them: save, Save As, autosave and recovery, crash copies, the CLI.
- A design container keeps each drawing in its own entry, `drawings/<id>.json` (Deflate), beside
`document.json`, which holds nothing of them: its bytes, and the model cache keyed to them, are
the same with drawings or without. A plain JSON design keeps them inline under `drawings`.
- Each drawing is read by its own family's rules, taken out of the design's JSON before the design's
own checks. One a build can't read (a newer number, a change it doesn't know, damage) refuses the
whole design, never dropped. So does an entry under `drawings/` that isn't a drawing's, one whose
record has another id, drawings inline in a container's `document.json`, two drawings with one
id, or more than 1,000 (counted before any is read). A design is never saved with two drawings of
one id.
- Drawings are listed by name, then id: no stored order, nothing to merge when two people add
drawings.
- A drawing has an `id`, unique among its design's drawings (`Drawing::new` takes the ids already
taken). Its source is the design it is in: at most one, an id and no path.
- One pending design change, `drawings`: the last release refuses a design saved with it, so it
never opens one and saves it without its drawings. One pending drawing change, `in-design`, for
the record's new shape.
- Gone: `read_drawing`, `read_drawing_file`, `write_drawing_container`, `file_kind`, `FileKind`,
`DRAWING_EXT` and `is_drawing_path`. `read_document`, `read_design` and the container writer are
as they were before #7098, with the drawings added.
Tests: a design's drawings round-trip through both forms byte for byte, with `document.json` and
`container.json` the same with drawings or without; their order; every refusal above; a drawing's
properties kept as other tools wrote them while a sheet's number out of range is refused; the
drawing's id among its objects', a new drawing's id none of the design's; a design with two
drawings of one id not saved; mutation fuzz of a design with drawings in both forms.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing commands on the design's own drawings, each drawing its own undo (#3890)
K4' of the drawing storage plan, on K3b (a drawing lives in its design's file): make, list, open,
close and delete a design's drawings, and read and change the open one's settings and properties.
It replaces #3891's drawing sessions, which held a drawing as a file of its own.
- `drawing.create {name?, language?, units?}` adds a drawing of the design (one ISO A3 landscape
sheet with the ISO border, the design its one source) and opens it; refused on an empty design.
`drawing.list`, `drawing.open {drawing}`, `drawing.close`, `drawing.delete {drawing}`.
`drawing.inspect`, `drawing.set`, `drawing.properties`, `.properties.set`, `.properties.remove`
work on the open drawing. Labels in en, ja and zh.
- The open drawing is the session's (`Session::open_drawing`, kept in checkpoints), and the part
gate keeps the parts apart: a command says the part it works on, the model unless it says
otherwise (`.in_drawing()`, `.any_part()`). While a drawing is open the model's commands wait
("a drawing is open: close it to change the model"); the drawing's run only while one is.
Files, recovery, undo and redo, checkpoints, selection, diagnostics, the command list and
choosing a drawing work either way. `CommandSpec::allowed` is the one check running a command,
running it inside another and listing it make.
- `Session::drawing` and `Session::edit_drawing` are the open drawing's one way in: an edit is kept
when it changed something and still keeps the record's rules, in a new design whose other
drawings are shared.
- A change that only touches drawings evaluates nothing: `Document::differs_only_in_drawings`
joins the render-only path, as render settings and part properties do. A model edit shares
every drawing, so it pays nothing for the check.
- Undo per part: a step records the part it changed (`Snapshot::part`: a drawing, or the model
and its list of drawings). Undo and redo go through the open part's steps only. A drawing's
step puts back only that drawing; the model's step puts back the design as it was, keeping each
drawing it had as it is now. Making and deleting a drawing are the model's steps. A new step
ends what could be redone in its own part only. `Snapshot::of` is the one place a step is
taken.
- An agent's message that changed several parts keeps their steps apart, rather than merging them
into one step that would undo only one part.
- `cmd::metadata`'s rules for reading, setting and removing properties are written once
(`reading`, `setting`, `removing`) and used by the design's and the drawing's commands.
- `drawing::sort` is the one place the drawings' order (by name, then id) is kept;
`Document::put_drawing` adds or replaces one in that order.
Tests: making, listing, opening, closing and deleting; what making one refuses, at the cap too; the
gate both ways, inside another command and in the command list; drawing edits as undo steps that
evaluate nothing over 100 rounds; undo and redo per part with model and drawing steps interleaved;
redo ended per part; the order by name, then id, after renames; delete and its undo; refused
changes; checkpoints; save and open in both forms; properties; hostile values for every command
that runs with a drawing open, from the registry; a fuzz of the steps in any order.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Unknown-command tests: the closest id first (#3890)
drawing.open now joins doc.open in the suggestion for `file.open`, as the rule says: both end in
the same word. The engine's and the CLI's tests check that doc.open comes first and let other
close ids follow, as the `solid.extrud` line beside them already does.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Model bodies: their extents seen on a plane, for a drawing view's size (#5866)
ModelBody::mesh_bounds_in(plane) is the box of a body's mesh in a plane's own coordinates
(Plane::to_local), beside mesh_bounds and in the same way: a body meshed already is measured from
its own mesh, and a placement of a part from its definition's shared mesh, with the placement
folded into the plane's two axes once (two dot products a point), so no moved copy is made. W07's drawing.view measures a view's extents with it.
Tests: a 100 x 50 x 20 block seen on the three principal pairs of axes and from an isometric
corner (150/sqrt(2) by 190/sqrt(6), worked by hand), a plane away from the origin, and every
placement in the shared-mesh test against its moved mesh, still without a moved copy, and the
same again from its own mesh once it is meshed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views: projected views in first or third angle, lined up with their parent (#4816, W17a)
W17a's second slice: the principal views derived from a base view.
- `ProjectedSide` (left, right, above, below): the side of its parent a
projected view sits on.
- `projected_basis(parent, side, projection)`: in third angle a view shows
the side of the model it sits on (one to the right looks from the right), in
first angle the side away from it (ISO 5456-2). It's the parent's basis
turned a quarter turn about one of its paper axes, through its origin, with
no -0. From the front view it gives exactly the named views: right, left, top
and bottom in third angle; left, right, bottom and top in first.
- `ViewFrame::aligned(side, projection, centre, position_mm)`: a projected
view at its parent's scale, lined up with it, so it moves only along the free
axis.
- The projection is S2's `cell::Projection`, the value the title block's
symbol reads, so a drawing has one first-or-third setting.
Tests: the front view's projections are the named views in both angles, with
no -0; from every named view and a leaning one, a projected view looks from
its side and keeps the parent's other axis and origin, four turns or a turn
and its opposite bring the parent back; a box's corners line up across
aligned views in both angles; hostile parents, centres and positions refused.
Corner (isometric) projected views wait for one convention check on first
angle. The derivation graph (projected from, aligned to, cycles refused) moves
to the view record in the drawing file, where the view ids live.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing dimensions: measurement on view frames (#4896, W19a)
`geom::drawing_measure` is what a dimension on a view reads, in model mm or radians, from model
points and edges and the view's basis: one rule for every dimension. The view's scale and place
on the sheet never enter.
- `linear`: horizontal and vertical along the view's paper x and y, aligned as the view shows
the segment, or along a direction picked on the view; a true reading is the segment's own
length (aligned only).
- `angle`: from the view's horizontal or vertical, a model axis as the view shows it, or
another edge, from 0 to π as each line is oriented; a true reading is between model lines.
- `foreshortened` says a measured line isn't parallel to the view's plane.
- Refused with a reason: points that aren't finite or are past 1e12 mm, an invalid basis, a
zero-length segment, a line seen end-on, a zero direction, a zero reading, parallel lines,
and a true reading where there is none. `drawing_view`'s `PARALLEL` and `require` are shared.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* drawing.view.snapshot: a view's scale, place and boundary on its sheet (#5866, W07 V2)
The first slice of W07: one orthographic view of the design, worked out and returned as data,
before any line is drawn, so scripts can lay views out by their boundaries.
- `drawing.view.snapshot` takes the view's settings, the sheet it goes on (A3 landscape at
300 dpi when not given) and where its centre goes (the sheet's centre when not given). With no
scale it takes the largest ISO 5455 scale at which the view, centred there, lies inside the
sheet's drawing border. It returns the resolved view, the scale (and whether it was fitted),
the extents on the view's plane, the boundary on the sheet and what it was drawn from.
Read-only and not undoable; it opens nothing and saves nothing.
- Every body the design places is in the view, wherever its occurrences place it; the browser's
eye counts for nothing (`engine::drawing_view::extents`, from P2's `mesh_bounds_in`). A design
whose assembly walk stops at its limits (deeper than 64 levels, or past 100,000 placements) is
refused rather than drawn with parts left out: `Document::placements_complete`, beside the walk,
says whether every placement it holds had its occurrences walked.
- `doc::drawing_view::ViewSettings` is the view's one parameter set: the view (named, or a
direction and an up), the scale, the two visual styles, the reference settings and tangent
edges. A saved view (W12) keeps the same fields; no scale is written as none, not null, so
what it writes reads back as the snapshot's parameters.
- `render::VisualStyle` names the five styles: visible, visible_hidden, shaded, shaded_visible
and shaded_visible_hidden. The shaded ones are refused as not supported yet until the drawing
renderer (#5624).
- The command has a typed contract (input and output schemas). Its handler reads the contract's
own type through `schema::read`, in the contract check's own words, so the check's levels give
one message for one mistake and an unknown field is refused by name. The reply includes the
sheet, its defaults filled in.
Tests: the 100 x 50 x 20 block's boundary in the front, top, right and isometric views at 1:2,
worked by hand; the fitted scale on A3 and A4 and near the border; scale, position and margin;
the browser's eye ignored; the design untouched; each hostile setting refused; the walk's
depth limit one level either side; the contract's keys the same as the settings' own.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views in the drawing record: base and projected views, and the projection (#4816)
E4 of the view-boundary plan, with #4816's derivation graph (plan on #4816).
A drawing now saves its views, as one pending drawing-format change
(`drawing/format/pending/sheet-views.rs`):
- `Drawing.views`: each view an object of the drawing, on one of its sheets.
A base view draws a source from a direction (`ViewDirection`, as
`drawing.view.snapshot` takes it); a projected view sits on one side of its
parent. Its place is a point of the sheet, or, lined up with its parent, only
how far along the free axis, as the other comes from the parent. A projected
view's source and basis come from its chain, so neither is saved.
- `ViewOverrides` beside V2's settings: what a view sets itself, each setting
on its own (scale, display style, reference style, reference parts hide the
model, tangent edges); none is written when left out. Each view has its own
reference margin.
- `Drawing.projection`: first or third angle (S2's `cell::Projection`). Third
angle is the type's own default (Cameron, 2026-10-26), for a drawing that
doesn't say and for a new one until a template or a preference chooses.
- The rules, checked on reading and after every edit: a view is on one of the
drawing's sheets; a base view draws one of its sources, has a scale and a
direction that makes a view; every parent is a view, no chain of parents
loops, and a chain is at most 32 views; a lined-up view is on its parent's
sheet; a place is on paper; at most 4,096 views. A view's id is the
drawing's, never another object's.
- `Drawing::resolve_view`: one rule for every reader. It turns the base view's
basis down the chain (`projected_basis`, in the drawing's projection) and
takes each setting from the nearest view that sets it, then the default,
saying who gave it.
- geom's `is_paper_coordinate`: the one rule for a view's place on paper, now
used by `ViewFrame::new` and the record.
The record tests' seed drawing has views, so its round trip and mutation tests
cover them; their unknown-field examples no longer use `views`.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Engine tests: one temporary folder helper and the schema check for every test module (#4816)
The view tests use the drawing tests' temporary folder and the schema tests' `conforms`, which were
private to their modules. `Folder` moves to the engine's test module and `conforms` is open to the
crate.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views: inspect and edit a saved view (#4816, W17c)
E5 of the view-boundary plan (plan on #4816): what the view's window reads and
writes, for the views of a drawing (E4). Both are drawing commands with
input and output schemas, and neither evaluates a model.
- `drawing.view.inspect {view}`: its kind (base or projected), sheet, source,
parent and side, its direction as resolved (named only when it is exactly a
named view), its place, and each setting as {value, from, parent?, set}:
where the value comes from (the view, a parent by id, the default) and what
the view saves itself. A projected view says whether its display settings
follow its parent (`linked`: true, false or "partly"). `choices` gives the
display styles and the preset scales, so a window keeps no list of its own.
- `drawing.view.edit {view, set}`: one undo step. Each setting takes a value,
or null to follow the parent (a base view keeps a scale); the margin, a base
view's direction and the place change too. `linked: false` saves the display
settings at the values they have, `linked: true` clears them so they follow.
The reply names the fields changed and the views projected from it whose
settings changed with it. The record's rules hold after every edit; an edit
that changes nothing is no step.
The contract test keeps the edit's fields and the record's (ViewOverrides) one
list. The view's boundary comes with the next slice, which works out where each
saved view sits on its sheet from its design's extents.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views: where a saved view sits on its sheet (#4816)
`Drawing::view_centre` gives a view's centre on its sheet: its point, or, lined up with its
parent, its own place along the free axis and the parent's centre across it. The free axis is
one rule on `ProjectedSide` (`along`, `on_free_axis`), which `ViewFrame::aligned` uses too.
`engine::drawing_view::on_sheet` puts a saved view on its sheet: its design's extents on its
plane, grown by its reference margin, at its scale, round its centre. The snapshot and saved
views share `measure` (refusing an assembly past the walk's limit or one with no bodies) and
`boundary`. With nothing to measure (the design has no bodies or places more than a view walks) a
view gets a 20 x 20 mm placeholder round its centre. A view's source is the design the drawing
is in, so the session's own model is what it measures.
`drawing.view.inspect` adds `boundary_mm` and `extents` (status `placeholder` and why, when there
is nothing to measure). It still evaluates no model.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Projection of new drawings: a preference, and drawing.set takes the projection (#4816)
A drawing's views follow its projection, first or third angle (third when nothing chooses).
`drawing.inspect` now shows it and `drawing.set {projection}` changes it as one undo step.
Preferences > Design gets a Drawings section with "Projection of new drawings"
(First angle / Third angle). A new drawing takes it as a new design takes "Units of new
designs": the app sets it after `drawing.create`, with no undo step of its own. A saved
value this version doesn't know reads as third angle; asked for over the control channel,
it is refused.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets: one edit, one lookup, a border that lays out, and schemas (#3875)
The sheet commands change the drawing through `Session::edit_drawing`, so the same settings or
order again leave no undo step, and answer from one reply type. A sheet is looked up by id or
name on `Drawing` (`sheet_index`), where later commands that name sheets find it too.
A sheet's border must lay out on it: the record's check runs the border's own layout, the one
rule drawing uses, so a 15 x 15 mm sheet with the ISO border is refused when it is made, not
when it is drawn. `excluded` must be an object of `count` and `print`: a mistyped key changed
nothing unseen. A new sheet documents nothing and leaves nothing out unless told, and the add's
parameter documentation says it takes `documents` and `excluded` too.
The drawing's properties sit behind an `Arc`, as its sheets do, so an undo step shares them.
Each sheet command has an input and an output schema (#4035). A flattened part of a contract
reports its keys as the parent's own (`schema::flattened`, which `FeatureCommon` now uses).
The tests add the missing cases: 1000 sheets and the 1001st, `after` by id and unknown, the
resolution's bounds, a name two sheets share, the same order and settings again, an undone
delete in place, and the add's reset of what it documents and leaves out.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing ids: one id source per session, its seed kept for replays (#3890)
The drawing commands drew ids from a fresh random source each time, so a crash replay of a drawing
could never find what an earlier command made by its id. A session now has one id source
(`Session::ids`), kept across a file change, from which `drawing.create` draws its drawing's,
sheet's and source's ids: seeded alike and run alike, a session gives the same ids, and a failed
command draws none, so a replay of what succeeded draws the same. The crash journal keeps the seed
at each base and `replay.json` carries it, which `solidcraft-cli crashes replay` seeds the replay
with (`Session::seed_ids`).
Tests: two sessions seeded alike make a drawing with the same ids, another seed other ids.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets: add, change, reorder and delete a drawing's sheets (#3875)
W18 S4: the sheets of a drawing, on the drawing session K4 made (#3890). Each command is one undo
step of the drawing and names a sheet by its id or, when only one has it, its name.
- `drawing.sheet.add {after?, name?, size?, orientation?, dpi?}`: a new sheet after the one named
(the last when not), taking that sheet's paper, border and resolution, with a name of its own
("Sheet 2") and nothing documented yet.
- `drawing.sheet.set {sheet, name?, size?, orientation?, dpi?, documents?, excluded?}`: one
setting at a time, the rest kept; `documents: null` clears what it documents, and `excluded`
changes only the flags it gives.
- `drawing.sheet.reorder {sheets}`: every sheet's id once, in the new order.
- `drawing.sheet.delete {sheet}`: a drawing keeps at least one sheet.
- Every change goes through the drawing's own rules (`Drawing::validate`), so what a saved file
would refuse is refused here. Changing a sheet's paper changes only the paper: regrowing its
border and moving what is on it is S5's. Labels in en, ja and zh.
Tests: a new sheet copying the paper it follows, after a named sheet too, and undone; each setting
changed with the others kept; nine refusals (resolution, sizes, orientation, name, an unknown
source, a flag, an unknown sheet, no sheet named) with the drawing unchanged; reordering, and four
orders that aren't every id once; a name two sheets share refused in favour of the id; the last
sheet kept.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets: a new sheet's id from the session's id source (#3875)
`drawing.sheet.add` draws its id from `Session::ids` (#3890's one id source per session), so a
crash replay of "add a sheet, then change it by id" finds the sheet: seeded alike and run alike, a
session adds sheets with the same ids, and a failed add draws none.
Tests: two sessions seeded alike add the same sheet ids, another seed others, a failed add none.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views: move or copy a view to a sheet (#4816)
`drawing.view.move_to_sheet {view, sheet, position_mm?, break_alignment?}` puts a saved view on
another sheet as one undo step, keeping its id, direction, source and settings. The views lined
up with it go with it and keep their places beside it; a view placed apart stays. Without a
position it keeps its place. A view lined up with its parent moves only with `break_alignment`,
and is then placed apart: at the position, else the sheet's centre. Its own sheet changes
nothing.
`drawing.view.copy_to_sheet {view, sheet, position_mm?, with_linked?}` makes new views, each
following none of the views it was copied from (Cameron's rule). A view with views lined up
with it needs `with_linked`: true copies them too, lined up with the copy; false copies it
alone. A projected view copied alone becomes a base view, looking the way it did (by name when
it is exactly a named view) with the settings it had as its own. The copy goes to the position,
else the sheet's centre.
A lined-up view's centre comes from the places alone: its place along the free axis, and its
parent's centre across it. So the views that travel with a view are shifted along their free
axis, and nothing needs the design's extents. `descendants` takes which views it follows, so the
edit's followers and the views lined up with a view are one walk.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views: move and copy take a view's centre from the record (#4816)
Moving or copying a view to a sheet worked out a view's centre with its own copy of the
lined-up rule. It now uses `Drawing::view_centre`, and a lined-up view's place moves along
its free axis by `ProjectedSide::along`, so the rule is written once.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets: a change of paper lists the views it leaves outside, and moves none (#3875)
W18 S5, its first part. `Sheet::drawing_space` is where a sheet's drawing goes: inside its
drawing border, or the whole paper with none. Nothing on a sheet is saved against the border,
so a change of paper regrows the border and its zones by itself.
`engine::drawing_view::outside` lists the views whose boundary (`on_sheet`) leaves their sheet's
drawing space, sides included. `drawing.sheet.set` lists them after a change of paper (size or
orientation; nothing else moves the space, so nothing else is measured), and moving or copying a
view to a sheet lists those it puts outside there. None is moved: where a view goes stays the
author's choice. A view with nothing to measure is listed by its placeholder, with why.
Tests: the drawing space with the ISO border, a filing margin and no border, and margins that
leave none; A3 to A4 either way up listing the right and top views with their boundaries and
moving nothing; a border through a view's edge leaving it inside, 0.1 mm less paper putting it
outside; a change of name checking nothing; undo; a move to a smaller sheet listed and a copy
that fits not; a placeholder listed as `past_walk_limit`.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing ids and the sheet border: the tests the slices left out (#3890, #4816, #3875)
What the slices' planted faults found untested, now each caught by a test:
- a file change keeps the session's id source: a drawing made after `file.new` draws the same ids
in two sessions seeded alike;
- a copied view's ids come from the session's id source, seeded alike giving the same copies;
- a crash report's replay carries the session's id seed, from a caught panic (the seed when the
command started) and from the journal of an unclean exit (the seed at its base);
- a view short of the sheet's border by less than a rounding is still inside it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views: listed by id, whatever order they were added in (#4816)
The record's rule says a drawing saves its later records by id, never in
the order they were added in. Views were kept, and saved, in the order they
were added, so the same views added in another order saved as other bytes.
- `Drawing::add_views` adds views where their ids put them. It is the one way
views are added: `drawing.view.copy` uses it, and so do the test fixtures.
- `Drawing::validate` checks the order, so every edit keeps it.
- Reading puts a file's views in id order before it checks the record. The
order means nothing, so a file in another order (saved before views went by
id, or edited by hand) isn't damaged: it opens, and saves by id.
- What a command lists in the drawing's order (the views a change of paper
leaves outside, an edit's followers) now comes by id.
No format change: no release has saved a view (the views change is still
pending).
Tests:
- views added out of id order are listed and saved by id;
- the same views added the other way round make the same drawing and the same
bytes, which read back as saved;
- a file that lists them the other way round reads by id, as the same
drawing, and saves as those bytes;
- an edit that leaves them in another order breaks the record's rule;
- the existing tests now index the file by id order, and the engine's lists
are by id.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing dimensions: the dimension record, saved by name on a view (#4896, W19b)
A drawing saves its dimensions: each on one of its views, measuring named
corners or edges of the view's model (a linear distance between two corners,
a straight edge's length, or the angle between two edges), with the direction
and reading W19a measures with, how far its line sits from what it measures,
where its text sits on paper, its decimals and any text shown instead of the
number. A reference names its body, the feature that made the body and its
occurrence path, never a picked point. Nothing worked out is saved.
- Dimensions are listed by id, read in that order whatever order a file has,
as views are: one helper pair (add_by_id, in_id_order) now keeps both lists.
- One cap for the names a saved model reference keeps
(MAX_REFERENCE_NAME_BYTES, used where 512 was written three times), and the
corner's edge cap shared with construct's vertex references.
- LinearDirection and Reading save as snake_case words; a direction along a
line saves as its two coordinates.
- A direction along a line is at most 1e9 each way (format::MAX_REAL, the
limit the file's number check holds every real number to): a whole number
past it passes that check, reads as a real, and would save as one the next
read refuses (found by the mutation test).
- One pending drawing-format file (dimensions.rs).
Tests: what each dimension saves and reads back as the same bytes, a file in
another order reads by id, an older drawing has none; every rule on both sides
of its cap, unknown fields at every level, the id rule, and the count cap; the
plate fixture carries one dimension of each kind, so the existing round-trip
and mutation tests cover them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Edges and corners by name: the matching step and the shared ends, each in one place (#4896, W19b)
A dimension finds an edge by name the way a fillet does, but never takes
the piece nearest an old pick, and finds a corner where its named edges
meet, refusing to choose between two. Both steps are split out of the code
that already does them, so there is one rule each:
- BodyEdges: a body's edge and face names, worked out once for every name
looked up on it, and `matching(name)`: the edge with that name, else the
one edge between the faces it names, else the pieces of it. locate_edge
now calls it and then takes the piece nearest the pick, as before.
- construct::shared_ends: the ends every named edge has, each once.
named_vertex keeps the one nearest its point, as before.
No behaviour change: every caller of locate_edge, find_edge and the vertex
references gets the same results. The existing naming, joint and
construction tests cover both paths; three new ones pin what they left
open: a vertex only where every named edge ends, the piece of a split
edge nearest the pick, and a lone match through the stem of a face taken
as a piece, with the warning.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* A body's frame through an occurrence path, in one place (#4896, W19b)
Document::body_frame_at(body, path): the placement the path leads to,
then the body's offset, without expanding every assembly instance. It is
what EmbossFace::body_frame composed for its saved path; that now calls
it, and drawing dimensions use it for the occurrence path they save. No
behaviour change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing dimensions found again in the model, strictly (#4896, W19b)
Document::resolve_dimensions(model, drawing, ids) works out each dimension
as the model has it now:
- An edge by its name, or the one edge between the faces it names
(BodyEdges::matching), never the piece nearest an old pick. A corner is
the one end all its named edges, or their pieces, share; two shared ends
are ambiguous, never "the nearer one".
- The body by its name and the feature that made it, placed through the
saved occurrence path (Document::body_frame_at). A same-named body made
by another feature isn't it.
- Status: ok; overridden (the text given is shown, the value still worked
out); ambiguous (the candidates, at most 16, none chosen); suppressed (its
feature is suppressed or rolled back, read from the evaluation's own
skipped mark); lost (why); unmeasurable (found, but the view can't
measure it so, in W19a's words, such as a line seen end-on).
- The value comes from W19a on the view's basis. An angle is the smaller one
between the two lines, or pi minus it on its other side, whichever way the
kernel runs the edges; a split edge's pieces on one line are still that
line. A split edge's length is ambiguous.
- The text: the override, else length_number in the drawing's unit (or the
design's) with the dimension's decimals, or degrees for an angle.
- The cost: each body named is looked up once per call, and its edge names
worked out once, however many dimensions name it. A body none names isn't
touched.
Not saved: nothing here changes the drawing. The last good value of a lost
dimension needs the session, so it comes with the commands (W19d).
Tests (engine, an 80 x 40 x 30 box, values by hand): front and right view
values, foreshortening and text, the drawing's own unit, several at once
and an unknown id; a change and its undo; a chamfer's 45 and 135 degrees,
and end-on in the front view; lost after a fillet and back on undo,
suppressed and back, a path to no occurrence, a new box with the same body
name; a notched edge's length ambiguous with both pieces while its end
corners still read 80 and its angle to the left edge 90 degrees, neither
exact; an angle on a piece of an edge whose slot is then suppressed still
reads 90 degrees, found through the stem of the face it was cut from, so
not exact; one edge named twice gives two corner candidates;
an override shown while the value follows the model.
Not covered by a test here: a part placed twice through real occurrences
(only a path to no occurrence is); the once-per-body cost (not measured).
A drawing unit outside display_units' five (um, yd, km, mil, nm, inch, µm)
shows millimetre numbers, the formatter's existing fallback; named as its
own follow-up.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets: a sheet with anything on it goes only with it, when asked (#3875)
drawing.sheet.delete refuses a sheet with anything on it, and its
error names what is there: its views and the dimensions in them, the
first few ids of each. With `contents: "delete"` the sheet goes with
everything on it as one undo step, which an undo brings back whole.
What is on a sheet is said once, in the record (Drawing::on_sheet),
and Drawing::remove_sheet takes the sheet out with exactly that; each
later kind of record on a sheet (a sheet's own sketches) adds itself
there, so delete covers it with no change here. drawing.sheet.set's
list of a sheet's views uses the same function.
Nothing on another sheet goes with it: a view there projected from one
of the sheet's views would lose its parent, so the delete is refused
naming those views, to be moved or deleted first.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views: a view found by id by halves, in one place (#4816)
The views are listed by id, so Drawing::view and Drawing::view_index
find one by halves instead of walking the list. Every lookup by id
uses them: a view's chain of parents (so resolving a view no longer
walks the list once for each parent), the views' rules (which no
longer build a map of every view to check each chain), a dimension's
view, and the engine's view commands and outside check.
The rules check the id order before anything looks a view up, so a
file with its views out of order is still refused as before.
Measured on a drawing of 4096 views (1024 chains of a base view and
three views projected one from another), median of 30 runs: 4096
lookups by id took 6.85 ms by a linear find and take 105 us by
halves; the rules' check took 1.77 ms and takes 1.45 ms.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views: a damaged chain names the view whose parent is missing (#4816)
A view whose chain of parents breaks further up was refused with "its
parent X isn't one of the drawing's views", naming a view that isn't
its parent. Further up the chain, the refusal now names the view whose
parent is missing: "its chain of parents reaches view Y, whose parent
X isn't one of the drawing's views". A missing parent of the view
itself reads as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing dimensions: add one to a view, and read it back (#4896, W19d)
drawing.dimension.add puts a dimension on a saved view of the open
drawing; drawing.dimension.inspect reads one back with what it
measures now. Adding is one undo step of the drawing; neither
evaluates the model.
What a dimension measures is picked and saved by name, never by the
point picked. Document::edge_reference and corner_reference turn a
pick into the record's names: an edge is a point on it in the design's
frame or {body, index} (its index among the body's edges as the model
lists them, as an ambiguous dimension's candidates are given), and a
corner is a point or the edges that meet there, each with the
occurrence path its body is placed through. A pick that doesn't name
one thing is refused, saying what it found: no edge, a point on
several edges, a corner of more than one body, edges that don't meet.
Each body's edges are placed in the design's frame once per pick, and
only the body picked has its edge names worked out.
The kind is given as the record saves it ({linear: {a, b, direction?,
reading?}}, {length: …}, {angle: …}), read by the record's own types,
so a command and a file read the same words. A new dimension's line is
10 mm from what it measures (until a dimension style gives it), shows
2 decimals, and its text is centred on its line; the text's default
place at its centred point (Q58) comes with the layout on paper.
The inspect reply has the record, the status (ok, overridden,
ambiguous, suppressed, lost or unmeasurable, with why), the value
(model mm, or degrees for an angle), whether it is foreshortened, the
text, whether every name was found by exact history, and an ambiguous
dimension's candidates.
One rule, one place: the corner rule's point tolerance is
construct::point_tolerance, shared by the picks; a dimension by id is
Drawing::dimension, which the resolver uses too.
Not here yet: edit, the view's list of its dimensions, the layout on
paper and the last good value (the next slices); delete waits with
view delete for the drawing UI's choice of one delete command or one
for each kind.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing dimensions: change a dimension's settings (#4896, W19d)
drawing.dimension.edit {dimension, set} changes what a dimension
shows and where, as drawing.view.edit changes a view: the offset of
its line, its text's place, its decimals, the text shown instead of
its number (null shows the number again), and its kind's direction,
reading or other side. The reply names the fields that changed. The
same values again change nothing and add no undo step (the drawing is
put back only when it differs). What a dimension measures isn't a
setting: to measure something else, add a new one.
A setting its kind hasn't got is refused (an angle has no direction,
only an angle has an other side); every changed record passes the
check a file read runs, so an edit can't save what opening the file
would refuse. A dimension's place in the list is
Drawing::dimension_index, which Drawing::dimension now uses too, as a
view's is.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views: inspect lists a view's dimensions (#4896, W19d)
drawing.view.inspect answers `dimensions`: the ids of the view's
dimensions, in id order, so a caller can find them and read each with
drawing.dimension.inspect.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views: a copied view takes copies of its dimensions (#4896, W19d)
drawing.view.copy_to_sheet copies each copied view's dimensions with
it, each with an id of its own on the copy, in the same undo step:
they are part of what the view shows (the W19d plan's question 1, its
recommended answer). A dimension's text placed `at` a point is from its
view's centre, so it keeps its place on the copy. A moved view keeps
its own dimensions as they are: they name the view by id.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing dimensions: the last good value, in memory (#4896, W19d)
A dimension that can't be measured now (its edge filleted away, its
corner gone) gives `last_good`: the value it last read this session,
as `value` gives it (model mm, or degrees for an angle). Each value a
dimension reads is kept by drawing and dimension in the session, and a
scratch copy keeps the session's. It is never saved (the W19b plan's
question 3), so a design's drawings don't change with every model
edit, and after reopening a lost dimension shows no number.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing dimensions: hostile values anywhere in the commands' params (#4896, W19d)
A hostile value in each place of drawing.dimension.add, .edit and
.inspect's parameters, at every depth (the kind, its picks and paths, a
corner's edges, the edit's settings), with 1 000-item lists, the
largest index and 600-byte text besides the engine's shared hostile
values: no panic, and the drawing keeps its rules. The engine's own
hostile test sends only its list of key names, none of which these
commands read.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing dimensions: a new dimension's defaults, tested (#4896, W19d)
The offset (10 mm), the text's place (centred) and the decimals (2) a
dimension is added with when not told.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* A plane carried by a transform, in one place
`assembly::map_plane` is public and gives `None` for a transform that flattens the plane; its two
copies (the occurrence mapping, which keeps the plane as it was, and the face anchor's, which
refuses) now call it and keep their own fallback. W20a's radial dimensions use it to carry a
view's plane into a body's frame.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing dimensions: a circle's or an arc's radius and diameter (#4896, W20a)
A radial dimension saves its edge by name and whether it shows the diameter. It reads the edge's
exact circle in the view's plane through the edge (`Body::planar_edges`, as the view draws it), so
a view that doesn't see the circle face on can't measure it; its text is R or Ø before the number.
`drawing.dimension.add` takes `{radial: {edge, diameter?}}`, a diameter by default for a whole
circle or half a turn or more (a hole's rim is two halves), and refuses a dimension of any kind its
view can't measure; `drawing.dimension.edit` switches `diameter`, keeping the id.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing W06a: exact orthographic hidden lines for the analytic subset (#2455)
crates/geom/src/hlr (L0): prepare once per body, then hidden_lines for a
scene of placed bodies. Edges and face silhouettes are projected from their
exact curves, split where projections cross, and each piece is classified by
rays toward the viewer against the trimmed faces: visible, hidden or
explicitly uncertain, never guessed. Planes, cylinders, cones, spheres and
tori are supported whether stored as analytic records, revolutions or spline
patches; freeform faces are reported and make what they could hide
uncertain. Screen geometry is Seg2 with the W01a accuracy vocabulary: exact
lines and conic arcs where the projection is exact, bounded chords
otherwise. docs/drawing-hlr.md holds the contract and its limits.
* geom/hlr: handle the brep records main gained in #3093
Main's exact model storage (#3093) added Curve::SurfaceIntersection,
Surface::PlaneThrough and Surface::PlacedRevolution, and the HLR matches on
the records no longer compiled. A plane through three points is a plane: it
is trimmed and intersected as one, and a box stored that way draws the same
bits as one with axis-stored planes. The procedural intersection curve and
the placed revolution (whose affine placement may scale it unevenly) are
refused by prepare as not supported yet, until the kernel adapter handles
them. The records' positions move with the body's centre like the others.
* geom/hlr: pad plane faces' boxes, so a plane record off by rounding still hides
Plane faces took the box of their boundary chords unpadded, flat along the
normal. When the plane record and its edges disagree by rounding (a unit cube's
top plane one ulp above its edges, a 100 mm cube's 1e-11), the ray toward the
viewer reached the plane just outside that box, the slab test culled the hit,
and the back edges came out Visible with no doubt. Every face's box is now
padded by 1e-6 of its size, as curved faces' boxes already were. Reported by
DevonHope on #2457.
* geom/hlr: limits from review: trim samples, scene extent, crossing pairs, surface groups
From DevonHope's review of #2457:
- Options::trim_samples must be 1 to MAX_TRIM_SAMPLES (4096).
- Placed bodies must stay within MAX_COORDINATE (1e12 mm, as section and brep
bound stored numbers). Placements 1e200 apart made the scene's size infinite
and every tolerance taken from it with it, so everything came out Visible.
- The crossing search counts its candidate pairs before it starts and meets
each pair only in the first grid cell the two segments share, instead of
keeping a set of the pairs met, which could outgrow wasm's 4 GB before the
500 million pair budget tripped. The same pairs in the same order.
- prepare groups faces on one quadric or torus by comparing each face with
the faces of its kind whose size agrees to the tolerance (sorted), not with
every face; at most 50 million comparisons. prepare_cancellable polls a
cancel callback between edges, faces and comparisons.
* geom/hlr: boundary chords on a grid, and no fine pass over coincident curved chords
The cost items of DevonHope's review of #2457:
- Every ray hit asked how far it lies from its face's boundary by scanning all
of the face's chords (4096 per circle; a plate's face with 256 holes has
about a million). The chords are now bucketed on a uniform grid over the
boundary's box, cells at least as long as the longest chord, and the test
looks only at the cells around the point. It finds exactly the chords the
scan finds.
- Chords of two curved curves that lie on each other end to end (aligned holes
seen along their axes) were cut into 16 by 16 pieces and intersected, to
find crossings that are only noise within the curves' tolerance. They are
now skipped; visibility changes where a coincident run starts or ends, and
chords that only partly overlap still find those.
- Fixtures: a plate with holes, coaxial cylinders seen along their axis, and
300 placements.
* geom/hlr: pad boxes by the body's coordinates too; coincident chords only to rounding
Review of the previous commits found two holes:
- The padding grew with the face's size, but rounding grows with where the body
was modelled: a 0.001 mm cube 1e7 mm out, its top plane one step (1.9e-9 mm)
above its edges, still had its hit culled. The pad now adds 1e-12 of the
body's offset.
- Two chords were taken for coincident when their ends lay within each other's
sag, which in a coarse scene can hide real crossings: an arc can bulge across
a line 1 mm off its chord twice. Only chords that coincide to rounding are
skipped now; identical projections, the costly case, still are.
* geom/hlr: coincident curves meeting at shared sample points do not cross
Timing the review's scenes showed that skipping coincident chords was not
enough: chords of two coincident curves also touch end to end at every sample
point they share, and each touch was a crossing to refine and split at. 64
coaxial cylinders seen along their axis gave 8.3 million crossings (19 s), 64
cylinders one behind another along the line of sight 4.2 million (214 s;
before these commits the crossing budget refused it). A touch at a shared
sample point is now dropped when the two curves also coincide, to rounding, on
both sides of it. Where a coincident run starts or ends one side differs, and
the touch is kept.
* geom/hlr: the own-face margin allows for rounding where a body was modelled
The far 0.001 mm cube of the previous commit showed a second effect of records
rounded at large coordinates: its top plane, one ulp (1.9e-9 mm) above its
edges, hid the top edges themselves, because a ray leaving an edge met its own
face 3.2e-9 mm along, past the own-face margin of 1e-6 of the face (1.4e-9).
The margin now also covers 1e-14 of the body's offset (about 45 ulps of its
coordinates), which only matters for parts far smaller than their distance
from the origin.
* geom/hlr: no parity test for a hit on the boundary, where it is uncertain anyway
* docs/drawing-hlr: the fixtures of the review's second round
---------
Co-authored-by: MateuszSychXpl <151755914+MateuszSychXpl@users.noreply.github.com>
* Title blocks: what a cell shows and where its text goes (#3875)
geom::cell holds a title-block cell's content: parts of text and fields
(component, drawing, sheet, revision or prompt, by key, with an optional
unit and decimals kept as written for the resolver to check), at most 64
parts and 4096 bytes of text, with no control character but a line break.
Beside it are a resolved value (live, overridden and drifted, or missing,
with "-" for each part that couldn't be read and why), an override with
the value it replaced, and the projection a drawing's views use (first or
third angle), which the title block's symbol will read.
A fit warns and never cuts: a count of characters, not bytes, with its own
count for text in Chinese, Japanese, Korean or Yi characters.
The cell text rule places a label and a value: the label's baseline 1 mm
plus its cap height below the cell's top, the value box under it inset by
1 mm, one line centred in the box, and wrapped or several lines down from
its top at the font's pitch, with a warning when the last falls below the
box. Wrapping by width, width warnings and glyphs a font lacks need the
text measured, so they wait for the paper scene's text.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Title blocks: definitions and their place on a sheet (#3875)
geom::title_block holds a title block's definition: its size (1 to 1000
mm a side), its outline and cell line widths, and up to 64 cells. Each cell
has a snake-case name of its own, a rectangle measured from the block's
lower-right corner, an optional one-line label with its cap height, and a
value: text from cell content, with its cap height, alignment and fit, or
the projection symbol, which reads the drawing's projection and is never
fixed in the block.
validate() checks a definition on its own, as when one is read: cells
inside the block and not overlapping (touching is fine), label and value
cap heights that fit, and the content's own limits. layout() puts the
block on the drawing border's lower-right corner of a sheet, refusing one
that doesn't fit, and gives each cell's rectangle, its label's place and
its value box by the cell text rule. On A3 landscape a 180 x 54 mm block
runs from (230, 10) to (410, 64); it fits A5 landscape and every larger
sheet, but not A5 upright.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Cell text: a value box lies within the paper's coordinates (#3875)
place_lines took any finite, ordered value box, but centring one far out (min x 1e308, max x
1.1e308) overflows: the anchor came back infinite, with no warning. 0xlillith found it in review
of #3877.
The paper scene already bounds every coordinate it holds by MAX_COORDINATE_MM (twenty times
the longest sheet side). That limit is now public, and place_lines keeps its box inside it, so
its anchor is always finite: one rule for what a paper coordinate may be.
Tests: the hostile-box test refuses both overflow cases from the review and a box just past the
limit on each side, and places lines in a box the size of the whole paper limit. The fuzz test's
numbers now include values past the limit (1.1e5, ±1e308).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Title blocks: padding from the lines' inner edges, one label rule, nothing unread (#3875)
A cell's text is padded from the inner edge of its lines: each side of a cell moves in by half
the line drawn on it (the outline's on the block's edges, a cell line's inside), so a wide
outline never covers the text. Before, the padding ran from the line's centre.
The label's one-line rule lives with the cell text rules (`cell::check_label`), where parts
lists will find it. The cell types nothing read yet (`Override`, `Resolved`, `State`,
`Problem`, `Reason` and `MISSING`) wait for the resolver that will read them.
The tests check the exact thresholds inside the lines (a label that leaves no room, a value
that just fits), pick each of the lines, alignment and wrapping on their own so every
combination comes up, and lay fuzzed blocks out on every standard sheet, either way, with and
without the filing margin.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Title blocks: the drawing border's line, descenders, room where the block sits (#3875)
From DevonHope's review of #3877:
- Each cell's lines are clamped to the inner edge of the drawing border's line. That line runs
along the block's right and bottom edges, and along any other edge it reaches, as when the
block fills the border. Aabb2::intersection, the 2D twin of Aabb3's, does the clamping.
- layout checks each cell's room again where the block sits (place_cells, which validate runs
at the origin), so rounding at the real corner can't turn a cell inside out.
- The cell text rule counts descenders, at 3/10 of the cap height (ISO 3098's lettering B).
They may reach into the padding under a value box, never past it to a line. place_lines
warns Height when they would, and validate asks it whether one line fits.
- The module doc no longer links to a private function.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* claim: #4816
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views as data: named views, scales and the map onto paper (#4816, W17a P1)
What a drawing view is, before anything draws it (geom::drawing_view):
- NamedView: the six principal views and the isometric views from the four upper corners, each
an exact basis (a Plane whose normal points back at the viewer), never taken from a camera,
whose pitch clamp would tilt a top view, with no -0 to write out; `iso` reads as the
front-right one.
- basis_looking: any other view from its direction, an up and an origin (paper x = direction x up,
paper y = x x direction), refusing a zero direction, an up along it, or an origin that isn't
finite or within 1e12 mm. W07's
{direction, up, origin} view reads through it.
- Scale: paper : model as two positive numbers, read and written as "1:2", from 1:100000 to
1000:1; Scale::fit picks the largest ISO 5455 preset (50:1 to 1:10000) at which a view fits a
space (W07's "fits the page" default), compared as size x paper <= room x model so an exact
fit at a reduction isn't lost to rounding.
- ViewFrame: a view's basis, scale and place on paper, the point of its plane at `centre`
landing at `position_mm`. Its paper map moves the view's curves and their accuracy onto
paper (paper error = scale x model error); `boundary` maps a box of its plane onto paper from
its four corners.
In geom, where Seg2 lives:
- Similarity2 and Seg2::similar (new): scale, turn and shift a segment exactly, an arc staying an
arc. Similarity2::new refuses a scale that isn't above 0 and works the turn out once, not per
point;
- Seg2::map_controls: a segment's control points mapped by any function. It was doc's
sheet::map_controls; its four callers in doc use the method now, unchanged.
CurveAccuracy::scaled gives a curve's accuracy at another scale.
Tests: each named view's basis and viewer side, and the same bases from a direction and up; a 50 mm cube in every principal view at 1:1 and
1:2, and in isometric (edges 50 x sqrt(2/3), outline 50 x sqrt(2)); the view's centre on its
position (W07's 100 x 20 front view on A3 at 2:1); scales read, written and refused; the fitted
scale, an exact fit at 1:5 and ISO's smallest; no -0 in any named view's axes; an origin refused by
its own message; hostile bases, centres and positions; every segment kind moved by a similarity,
and the similarities refused; scaled accuracy.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing views: the bottom view pinned, square near parallel, bounded scales and boxes (#4816)
From DevonHope's review of #4817:
- The tests pin all six principal views exactly. The direction-and-up test uses literal ups,
so a bottom view turned half round now fails it.
- basis_looking squares x to the direction before normalising. Near the 1e-9 threshold the
normal was up to 8.8e-9 rad off; now it is about 1e-16.
- Scale::fit fits nothing for a size or room that is negative or not finite. A size of 0 still
sets no limit that way.
- Each side of a scale is 1e-6 to 1e6, so a scale writes at most 49 characters.
- ViewFrame::boundary returns a Result. It refuses a box that is inside out or not finite on
paper, instead of dropping a corner.
- paper_map, boundary and seg_to_paper say which coordinates they take.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The first export of a paper scene, as SVG first (jyviko and 0xlillith on #4890), from the research
in the plan's §16. A3b adds ellipses, hyperbolas and Béziers above degree 3, which this refuses as
"not supported yet".
- `geom::paper::Prepared`: writers read a scene through `Scene::prepare`, which checks it first, so
none reads one unchecked. Clipping goes there too, once (A8).
- `geom::paper::arc_pieces`: an arc's ends in pieces of at most a quarter turn, the last its own end.
A half turn drawn from its ends is ill-conditioned: rounded to the nanometre (six decimals of a millimetre) its
centre moves up to 1e-2 mm, where a quarter turn's stays under 1e-6 mm.
- `io::paper::paper_svg`: one user unit a millimetre, the size in mm on the root; y flipped by
writing the height less y, so the file's numbers are page coordinates and an anticlockwise arc
has sweep flag 0; lines `L`, arcs `A` (never large-arc), cubics `C`, parabolas `Q`; fills
black and even-odd; one path per item; groups as `data-object` and `data-kind` (object ids can't
be XML ids). No background, so cutters see only the marks.
- Numbers are whole nanometres (six decimals of a millimetre): no exponent, no "-0", the same bytes every time. They are the
writer's own state too, so a joint is written once and a closed path ends exactly on its first
point. Numbers are written straight onto the document, with no text made per number. A width
under half a nanometre is written as one, and a piece too short for the grid is merged into the
next, both counted in the report; a path's last piece has no next, so it is kept however short
(unless it has no length). Output over 64 MiB is refused.
Tests: the A3 drawing border's whole document; quarter, 270°, clockwise and whole-turn arcs, and a
circle of two halves giving the same four quarters; the quarter-turn boundary both sides; cubics and
parabolas, and the conics refused; the number format; a closed path whose start and end round
apart; a sliver merged; an open path's short last line and arc kept, and one of no length dropped; read back through our own SVG reader (lines exactly, the arc as an arc);
the scene's JSON mutated into the writer (never a panic).
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* File format families: drawings share the design format's versioning (#3890)
The format code works for a family of files: its own tag, its own numbers and
its own folder of change files, with one reading of a file's format, one
refusal of a file a newer build saved and one upgrade for every family. Designs
(solidcraft/N) are one family and keep everything they had: FORMAT and FORMATS
are as they were, and pending_names, format_string, version_of and read mean
what they did. Drawings (solidcraft-drawing/N) are the other, with format 1 as
their first record and each later change one file in
crates/doc/src/drawing/format/pending/, as design changes are. Nothing saved
changes.
A design tag never reads as a drawing's or the other way round, and a file that
names no format is a design from before format strings, never a drawing. Every
refusal names its family; a design's read word for word as before. A design
listing a pending change this build doesn't have is now refused as a newer
build's before its content is checked, as a newer number already was, so a
newer build's fields never read as damage. The list reader is
take_names(v, key, noun), the shape #4811 uses for its own list.
For the maintainer, the release step changes: scripts/fold-format-pending.sh
now folds every family that crates/doc/build.rs lists (FAMILIES), each into
its own next number: designs into crates/doc/src/format/v<N>/ as before,
drawings into crates/doc/src/drawing/format/v<N>/ from 2. With nothing pending
in a family it says so and moves nothing. Its test folds a drawing change into
v2 beside the design changes. docs/releasing.md, CONTRIBUTING.md and AGENTS.md say so.
build.rs lists each family's changes from its own folder, each folder's
versions contiguous from its own base.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing record: format 1 of the drawing family (#3890)
A drawing is now a record of its own (crates/doc/src/drawing.rs): its name,
the designs it draws (sources: an id and the design file's path, relative to
the drawing's folder as a linked design's is), its properties under the design
metadata's rules, its units (each design's own, or one length unit of the
expression unit table), its content language (a BCP 47 tag) and its sheets.
A sheet holds its paper, a copy of its drawing border's profile, the
resolution its pictures are rendered at (300 dpi unless it says, 25 to 2400),
the component it documents and whether it is left out of the sheet count or
of printing. This is format 1 of the drawing family; each later kind of
record adds one file in crates/doc/src/drawing/format/pending/.
The rules: one id counter for every object, raised above the largest id when
a file is read and never rewound; every reference is an id that must resolve,
or the file is damaged and refused, never patched; 1 to 1,000 sheets, at most
64 sources, names of 1 to 256 bytes, paths of 1 to 4,096 bytes without NUL.
The same drawing always saves as the same bytes.
Drawing::from_json reads at most 16 MiB of text, then runs the family's format
check, the number check, the upgrade, the typed record (unknown fields refused
everywhere) and Drawing::validate. The number check is now one function every
family calls, Family::check_numbers, told which field holds other tools' data;
a design's refusals read as before.
Nothing saves or opens a drawing yet: the container is the next step.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing ids: random and collision-free from format 1 (#3890)
A drawing's objects now take random ids, the form jyviko chose on #3890 from
#1017: no counter, so objects added on two branches never share an id and
never edit one line. The allocator is one module for drawings now and designs
later (#626 Phase 3), crates/doc/src/ids.rs: an IdSource gives nonzero u64s by
splitmix64 from a seed, each checked against the ids in use and drawn again
when it is one, or when it is 0. A run never draws a number twice, so at most
one draw per id in use comes before a free one, and a seeded run over a file
the same seed made still gets a new id. IdSource::seeded gives the same ids
for tests and replays; IdSource::from_entropy seeds a session from the
standard library's hash keys, the time and a count, with no new dependency.
In a file an id is 13 characters of Crockford base32, lowercase
(0000000000001 to fzzzzzzzzzzzz): ids::encode writes it and ids::decode reads
only that spelling, case-sensitive, so an id has one form to search for.
Anything else, 0 included, makes the drawing damaged. The drawing loses
next_id (a file that holds one is refused), and Drawing::new and allocate_id
take the IdSource. Messages name ids as the file writes them. The component a
sheet documents stays its design's own number until designs move over.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing record: a drawing too large to reopen isn't saved (#3890)
from_json reads at most MAX_DRAWING_BYTES (16 MiB), but to_json had no limit. Other tools'
properties are kept as they came, and indenting them can grow a drawing read in at about 4 MB
past 16 MiB (two million zeros in one array), so the next read refused what the save had just
written. 0xlillith found it in review of #3891.
to_json now returns a Result and refuses JSON longer than a read takes ("drawing too large to
save (at most 16 MiB)"), so every drawing saved opens again. Nothing writes drawing files yet, so
the error reaches the future file writer before it publishes anything.
Test: that case is refused, and a smaller compact drawing saves and reopens unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing files: a drawing saved as a container or as plain JSON, never read as a design (#3890)
K3 of the drawing storage plan (W11.2): the file a drawing is saved in. Nothing writes one from a
command yet; opening and saving come with K5.
- A drawing container is a design container holding `drawing.json` (Deflate, as `document.json`)
in place of `document.json`, and `container.json` says so:
{"content": "drawing", "format": "solidcraft-container/1"}. A design's `container.json` is as it
was, with no `content`. The plain JSON form is the drawing's own text. Both give the same bytes
every save, so a drawing can live in version control as text.
- `io::file_kind` tells a design from a drawing by `container.json` or by the JSON's format. The
design reader refuses a drawing ("this file is a SolidCraft drawing, not a design: open it as a
drawing") and the drawing reader a design; plain JSON only asks when it isn't a design, so
reading a design costs nothing more. A container's content this build doesn't know, or a drawing
container that also holds a design's `document.json`, is refused.
- `read_drawing` (bytes, either form), `read_drawing_file` (one seekable handle, the design
reader's checks) and `write_drawing_container`; `DRAWING_EXT` (`scdwg`) and
`is_drawing_path` beside the design's.
- The container writer's set-up and finish, the file opening and the container sniffing move into
one function each, which designs and drawings both use. The container's own checks (budgets,
entries, the ZIP directory) are the design container's, word for word.
Tests: a drawing round-trips through both forms byte for byte, and the container holds exactly
`container.json` and `drawing.json`; `file_kind` on both forms of both kinds; each reader refuses
the other's file; unknown content, a stray `document.json`, a missing drawing, an unknown
container version and a damaged drawing refused; both forms from disk, and a directory refused;
mutation fuzz of both forms (an error or a drawing, never a panic).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials types: phantom, reference, purchased and inseparable (#3874)
A component's bill of materials type is a part property (`bom_type` in its metadata, set with
component.metadata.set and read by component.metadata, as part_number is), so older releases
keep it and no format change is needed. It isn't a design property: the Design Properties
dialog doesn't list it and document.metadata.set refuses it. A word this build doesn't know
reads as normal and is kept.
assembly.bom counts by type: a phantom has no row and what it holds counts where it is placed,
in the same rows as the same parts there; a reference counts nowhere, and nothing inside it
does; purchased and inseparable components are one row, and in parts only an inseparable
component's purchased parts are listed too. Rows of one part number but different types are
different rows. Rows and children carry bom_type. With no types set the rows are as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Glossary: bill of materials and bill of materials type (#3874)
The bill of materials types are a new idea, so the glossary gets their
term, with the five types, and "normal" gets its fourth meaning in the
table of words with more than one meaning.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials types: a plain line for each (#3874)
The guide's table and the glossary entry say what each type is for in
plain words: something you make, something just to group, something to
use as a reference, something you buy, something made as one piece.
The names stay the five standard ones.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Bill of materials: kits fold together only when their contents' types match (#3874)
With group_children, two kits with one part number share a row when what they hold reads the
same. That reading (kit_key) compared each child by part number and count, but not by its bill
of materials type, though rows themselves are told apart by type. So a kit holding a made bolt
and a kit holding a bought one, both KIT, folded into one KIT x2 row listing the first kit's
bolt twice: the other type was lost, and which one depended on creation order. 0xlillith found
it in review of #5107.
kit_key now includes each child's type. Equal part number, type and contents still fold.
Test: two KIT kits each holding a BOLT fold into one row of two; once one bolt is purchased they
are two rows, each listing its own bolt. Planted fault (the type left out of the key): caught.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A border profile capped every length at 5000 mm (the largest sheet's side) but two: a
centring mark's reach inside the drawing border and a trimming mark's length. A file could
give either a huge whole number, such as 18446744073709551615. The read's number check passes
whole numbers, so the profile took it as 1.8e19 mm, and saving wrote it as a decimal the next
read refused: a drawing that saved but didn't open again. K2's fuzz test of drawing files
(#3890) found it.
Both now take the cap the margins have, `MAX_SIDE_MM`, in `validate`, so the file is refused
when it's read. Layout's own checks against the sheet are unchanged, so a 5000 mm mark still
validates and is refused only on a sheet too small for it.
Tests: the hostile-profile test refuses 5000.000001 mm and 1.8e19 mm for each mark, and takes
5000 mm on its own; 4 planted faults (each cap removed or made one short) are all caught.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The built-in sheet's centring marks now run from the trimmed sheet's edge to the drawing border.
From the grid reference border, as before, a mark was the same length as a grid field mark, and on
A3 it sat on one (the sheet's centre falls on a field edge), so it no longer read as a mark once the
grid reference border's outline is left out (Cameron, after the prototype on #3875).
- DrawingBorderProfile.centring_mark_start: sheet_edge (the built-in's, and when not given) or
grid_border (ISO 5457's figure 5); ISO's full border in the tests asks for grid_border.
- A mark still needs a length: one that stops on the drawing border needs room outside it on the
side it starts from, every margin for sheet_edge, the grid reference border for grid_border.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
geom::paper holds what a sheet shows as plain data: groups of strokes and fills, each group tagged
with the object that drew it (an opaque id) and its kind, with one validation pass over a bounded
record count. Seg2's checks and the coordinate rule move into profile.rs so section and paper share
them, and drawing_sheet takes its side and line limits from paper, so each limit is written once.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* test(oracle): reviewer-aligned parameterized workshop plate fixtures (#4950)
Independent analytic W23 expected values and seven verified models,
including four R10 corners and the 2 mm tangent top chamfer.
Document accepted Drawing states and commit regenerated docs/oracle.md
from successful workflow run #29 (90/90 pass).
* fix(oracle): correct W23 chamfer centroid and clarify drawing session ownership
* Drawing sheets: sizes and the ISO 5457 border (#3875)
A sheet is a paper size and an orientation: ISO A0 to A5, Letter, Legal,
ANSI A to F, architectural A to E1, or a custom size (finite, above 0 and
at most 5,000 mm a side), landscape by default and either way for every
size.
A border profile is the rule for its border, and layout() works it out
for a sheet: the frame inside the margins, and the reference fields with
their labels. The ISO profile has a 20 mm filing margin on the left and
10 mm elsewhere, a 0.7 mm frame, fields of 50 mm out from the centre
lines with the corner fields taking what's left, rows lettered from the
top without I and O (AA, AB and on past Z), columns numbered from the
left, and an A4 sheet labelled on its top and right only. A profile can
divide the frame equally instead, or have no grid.
The records sit in geom, next to the section records, so saving,
rendering and export can all use them. Nothing is saved or drawn yet:
there is no command and no format change. Margins that leave no drawing
space, values that aren't finite, fields outside 1 to 1000 mm, more than
200 equal fields and unknown JSON fields are refused.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets: ISO 5457's centring and trimming marks (#3875)
A drawing border profile now also holds the grid reference border and the
centring and trimming marks, either of which can be left out. The ISO
profile follows ISO 5457:1999 (read in its identical adoption,
IS 10711:2001):
- the grid reference border 5 mm outside the drawing border on every
side, with the field labels between the two;
- four centring marks on the sheet's centre lines, from the grid
reference border to 10 mm inside the drawing border;
- at each corner a trimming mark of two overlapping 10 x 5 mm
rectangles, in the margin outside the grid reference border.
The labelled sides are now a rule worked out for each sheet: ISO 5457's
(the top and right of A4, all four sides of the others) or fixed sides.
So one profile labels every size correctly. validate() checks what
doesn't depend on the sheet, for when a profile is read; layout() calls
it, then checks the rest against the sheet.
Refused:
- a grid reference border that isn't finite, is negative or is wider
than a margin;
- a centring mark that isn't above 0, would reach past the sheet's
centre lines, or is on a drawing border those lines miss;
- a trimming mark that isn't above 0, is wider than it is long, is
wider than the margin left outside the grid reference border, or is
longer than half the sheet's shorter side.
The grid rule's JSON is now externally tagged ("none",
{"from_centre": {"field_mm": 50}}), as the sheet size is, so an unknown
field is refused in every form; the internally tagged "none" ignored
one. Nothing is saved yet, so the shape change costs nothing.
The names follow the glossary, and ISO 5457's "drawing sheets": the
module is drawing_sheet (was sheet, which means sheet metal elsewhere
here), DrawingBorderProfile and SheetLayout (were BorderProfile and
BorderLayout), sheet_border and drawing_border (were paper and frame),
and Sheet::size_mm (was paper_mm). The first part of S1 is still a draft,
so the renames are made here rather than in a commit of their own.
The extra centring marks ISO 5457 asks for on sheets larger than A0
aren't here yet. Still nothing is saved or drawn.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Drawing sheets: a lighter built-in border, the filing margin a choice (#3875)
Cameron's decisions after seeing the sheet in the app, 2026-10-23:
- No trimming marks in the built-in profile: the filled corner blocks
take a lot of ink. trimming_mark_mm stays, so a profile can still ask
for them.
- Centring marks stop at the drawing border: from the grid reference
border to the drawing border, never into the drawing area (on A4 they
crossed the tables). centring_mark_mm keeps its meaning, how far a
mark reaches inside the drawing border, and now takes 0, the built-in
value, as grid_border_mm already takes 0 for "on the drawing border".
A mark of no length (a reach of 0 with no grid reference border) is
refused.
- Margins of 10 mm all round. ISO 5457's 20 mm filing margin on the
left, for drawings that get bound, is a named choice: filing_margin,
off when not given. On, it stands in for margins.left_mm, which is
kept, and still checked, for when it's off again. The 20 mm is
FILING_MARGIN_MM, and validate() and layout() both take the margins
from one helper, laid_out_margins().
A3 landscape is now 400 x 277 at (10, 10), with eight 50 mm columns.
With the filing margin it is 390 x 277 at (20, 10) again, the same as a
20 mm left margin set by hand. A profile with all three choices on
(ISO 5457's full border) lays out exactly as the built-in profile did
before, and the tests keep the old hand values for it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-23 03:01:08 -04:00
1238 changed files with 72953 additions and 184322 deletions
SolidCraft is a clean-room, pure-Rust parametric 3D CAD app (sketch solver, feature timeline, B-rep kernel, an egui UI that agents drive). This file is a router: the hard rules, then the skill to read for your task. Humans: CONTRIBUTING.md.
## Start here
Work: ROADMAP.md, "Where help is wanted most" in CONTRIBUTING.md, issues labelled `help wanted`, `good first issue`, `needs-triage`; architecture in `docs/architecture.md`. Local `plan/` notes are optional.
Work: ROADMAP.md, "Where help is wanted most" in CONTRIBUTING.md, issues labelled `help wanted`, `good first issue`, `needs-triage`; architecture in `docs/architecture.md`. Act when the code, docs and rules settle a question; ask only when it changes what users see. Local `plan/` notes are optional.
## Hard rules (what enforces each)
- Independent: never copy another product's code, icons, text or templates; never drive or take data from commercial CAD. `skills/solidcraft-ground-rules/SKILL.md`.
- No GPL/LGPL/AGPL code, not even reading it (OpenCASCADE, FreeCAD, SolveSpace, CadQuery, LibreCAD, QCAD): `cargo xtask licences --check`.
- Every asset is original or openly licensed with a row in ATTRIBUTION.md; read `assets/AGENTS.md` before icon work: `cargo xtask assets`, `cargo xtask icons`.
- Never crash: no unwrap/expect/panic/unsafe in non-test code, errors are `Result`, input is hostile: clippy `-D warnings`, `hostile_params_never_panic`.
- Never crash: no unwrap/expect/panic/unsafe in non-test code (unsafe allowlist in crash-safety), errors are `Result`, input is hostile: clippy `-D warnings`, `hostile_params_never_panic`.
- Model decisions (what an operation does, which bodies it touches, which face or edge a point or name means, depths, nearness) use exact geometry; a mesh is for display, export, previews and mesh bodies (`xtask/mesh-decisions.txt` only shrinks): `cargo xtask mesh-decisions`.
- New kernel cases go to solidcore: `cargo xtask lists`.
- Everything is a command and programmatic calls never open dialogs: `skills/solidcraft-commands/SKILL.md`.
@@ -21,14 +21,12 @@ Work: ROADMAP.md, "Where help is wanted most" in CONTRIBUTING.md, issues labelle
- A design-format change is ONE new file in `crates/doc/src/format/pending/`: `scripts/test-format-pending.sh`.
- A command has input and output schemas (will become required; `schema/unconverted.txt` only shrinks): `skills/solidcraft-commands/SKILL.md`.
- New UI strings go in `assets/locales/pending/<slug>.json`, ATTRIBUTION rows in `attribution/pending/<slug>.md`: `cargo xtask lists`.
- A changed default keeps the old behaviour behind a preference and fills the PR's `Changes a default:` line: `pr-checks.yml`.
- A changed default keeps the old behaviour behind a preference and fills the PR's `Changes a default:` line, and no second PR for an issue a lower-numbered one closes: `pr-checks.yml`.
- A regression test goes in the area's existing test file, never a per-bug file (#3226).
- Look at open PRs first, claim with a draft PR (lowest number wins), one topic per PR: `skills/solidcraft-contributing/SKILL.md`.
- Look at open PRs first, claim with a draft PR (lowest number wins), one topic per PR, never force-push `main`, no pushes just to catch up with `main`: `skills/solidcraft-contributing/SKILL.md`.
- A PR's title and first sentence make sense to someone who never saw your chat or the issue: `skills/solidcraft-contributing/SKILL.md`.
- Code, comments, commit messages and docs are in English, always: `skills/solidcraft-contributing/SKILL.md` ("Working as an agent").
- Independent work runs in parallel, dependent work stays sequential: `skills/solidcraft-contributing/SKILL.md` ("Working as an agent").
- Show observable changes with real screenshots or a recording, captured yourself.
- Run `cargo xtask ci` before every commit. `cargo xtask skills` keeps this file and `skills/` honest.
- Run `cargo xtask ci` before every commit, without switching branches while it runs. `cargo xtask skills` keeps this file and `skills/` honest.
@@ -82,6 +82,7 @@ Editable drawing code, native projects and shipped exports are collected under `
| assets/fonts/ibm-plex-mono/IBMPlexMono-Regular.ttf | IBM Corp. (IBM Plex Mono) | https://github.com/IBM/plex (via google/fonts), unmodified; licence text in assets/fonts/ibm-plex-mono/OFL.txt; the interface monospace font | SIL OFL 1.1 |
| assets/fonts/ibm-plex-sans/IBMPlexSans-Variable.ttf | IBM Corp. (IBM Plex Sans, variable wdth and wght) | https://github.com/IBM/plex (via google/fonts), unmodified; licence text in assets/fonts/ibm-plex-sans/OFL.txt; the default interface font | SIL OFL 1.1 |
| docs/book/src/generated/tool-preview.png | SolidCraft contributors | rendered by `cargo xtask book` (`solidcraft-cli snapshot docs/book/scripts/tool-preview.json`; gitignored) | MIT OR Apache-2.0 |
| assets/fonts/liberation-sans/LiberationSans-Regular.ttf | Red Hat, Inc. (Liberation Fonts 2.x; digitized data Google) | https://github.com/liberationfonts (Debian fonts-liberation), unmodified; licence text in assets/fonts/liberation-sans/OFL.txt; used for sketch Text outlines | SIL OFL 1.1 |
| assets/fonts/biz-udp-gothic/BIZUDPGothic-Regular.ttf | The BIZ UDGothic Project Authors | https://github.com/googlefonts/morisawa-biz-ud-gothic (Google Fonts), unmodified; licence text in assets/fonts/biz-udp-gothic/OFL.txt; used for web UI Japanese font | SIL OFL 1.1 |
| assets/fonts/craft-ui-sc/CraftUI-SC.otf | Adobe / Google Inc. (Noto Sans SC); SolidCraft subset | https://github.com/notofonts/noto-cjk Sans/SubsetOTF/SC Regular, glyph-subset for assets/locales/zh.json and renamed Craft UI SC (OFL reserved-name); licence text in assets/fonts/craft-ui-sc/OFL.txt; web UI Simplified Chinese | SIL OFL 1.1 |
| assets/fonts/craft-ui-tc/CraftUI-TC.otf | Adobe / Google Inc. (Noto Sans TC); SolidCraft subset | https://github.com/notofonts/noto-cjk Sans/SubsetOTF/TC Regular, glyph-subset for assets/locales/zh-TW.json and renamed Craft UI TC (OFL reserved-name); licence text in assets/fonts/craft-ui-tc/OFL.txt; web UI Traditional Chinese | SIL OFL 1.1 |
@@ -146,6 +147,7 @@ Editable drawing code, native projects and shipped exports are collected under `
| assets/fonts/craft-ui-tc/OFL.txt | Adobe / Google Inc. (Noto CJK); SolidCraft header | Accompanying OFL for CraftUI-TC.otf | SIL OFL 1.1 |
| assets/fonts/ibm-plex-mono/OFL.txt | IBM Corp. | Unmodified accompanying font licence | SIL OFL 1.1 |
| assets/fonts/ibm-plex-sans/OFL.txt | IBM Corp. | Unmodified accompanying font licence | SIL OFL 1.1 |
| assets/fonts/liberation-sans/OFL.txt | Red Hat, Inc.; Liberation Fonts contributors | Unmodified accompanying font licence | SIL OFL 1.1 |
| assets/icons/app/linux/exports/hicolor/128x128/apps/io.tangencylabs.solidcraft.png | SolidCraft contributors | Generated from assets/icons/app/shared/source/app_icon.rs with the original CLI/ICO encoders | MIT OR Apache-2.0 |
| assets/icons/app/linux/exports/hicolor/16x16/apps/io.tangencylabs.solidcraft.png | SolidCraft contributors | Generated from assets/icons/app/shared/source/app_icon.rs with the original CLI/ICO encoders | MIT OR Apache-2.0 |
| assets/icons/app/linux/exports/hicolor/24x24/apps/io.tangencylabs.solidcraft.png | SolidCraft contributors | Generated from assets/icons/app/shared/source/app_icon.rs with the original CLI/ICO encoders | MIT OR Apache-2.0 |
@@ -213,7 +215,6 @@ Editable drawing code, native projects and shipped exports are collected under `
| assets/styles/ui/themes/one-dark.json | SolidCraft contributors | original SolidCraft theme file with colours adapted from the One Dark palette (Atom One Dark by GitHub Atom, https://github.com/atom/atom, MIT) | MIT OR Apache-2.0 |
| assets/styles/ui/themes/tokyo-night.json | SolidCraft contributors | original SolidCraft theme file adapting the colours of a published palette (Tokyo Night by enkia, https://github.com/enkia/tokyo-night-vscode-theme, MIT) | MIT OR Apache-2.0 |
| assets/styles/ui/themes/solarized-light.json | SolidCraft contributors | original SolidCraft theme file adapting the colours of a published palette (Solarized by Ethan Schoonover, https://github.com/altercation/solarized, MIT) | MIT OR Apache-2.0 |
| assets/styles/ui/themes/solarized-dark.json | SolidCraft contributors | original SolidCraft theme file adapting the colours of a published palette (Solarized by Ethan Schoonover, https://github.com/altercation/solarized, MIT) | MIT OR Apache-2.0 |
| assets/styles/ui/themes/nord.json | SolidCraft contributors | original SolidCraft theme file adapting the colours of a published palette (Nord by Sven Greb and the Nord contributors, https://github.com/nordtheme/nord, MIT) | MIT OR Apache-2.0 |
| assets/styles/ui/themes/high-contrast.json | SolidCraft contributors | original SolidCraft theme file | MIT OR Apache-2.0 |
| assets/styles/ui/themes/graphite.json | SolidCraft contributors | original SolidCraft theme file | MIT OR Apache-2.0 |
@@ -316,6 +317,7 @@ Editable drawing code, native projects and shipped exports are collected under `
| assets/icons/ui/design/svg/model/circle_ttt.svg | SolidCraft contributors | two-tone modelling icon master (64 grid), original SolidCraft artwork | MIT OR Apache-2.0 |
| assets/icons/ui/design/svg/model/coil.svg | SolidCraft contributors | two-tone modelling icon master (64 grid), original SolidCraft artwork | MIT OR Apache-2.0 |
| assets/icons/ui/design/svg/model/colored_components.svg | SolidCraft contributors | original icon master (64 grid) | MIT OR Apache-2.0 |
| assets/icons/ui/design/svg/model/colored_components_off.svg | SolidCraft contributors | original icon master (64 grid) | MIT OR Apache-2.0 |
| assets/icons/ui/design/svg/model/combine.svg | SolidCraft contributors | two-tone modelling icon master (64 grid), original SolidCraft artwork | MIT OR Apache-2.0 |
| assets/icons/ui/design/svg/model/component.svg | SolidCraft contributors | two-tone modelling icon master (64 grid), original SolidCraft artwork | MIT OR Apache-2.0 |
@@ -785,63 +787,6 @@ Original SolidCraft drawings, Open for owner review; no runtime assignments.
| assets/locales/pending/theme-blur-ui.json | SolidCraft contributors | Original blur controls, notices and translations | MIT OR Apache-2.0 |
| crates/ui-egui/tests/fixtures/theme-blur.json | SolidCraft contributors | Original theme for blur option scenarios and manager review | MIT OR Apache-2.0 |
| assets/locales/ka.json | David Machakhelidze (devius) | Original Georgian translation of SolidCraft's English catalog, written with Claude Code from the meaning of each English string; terminology and doubtful strings decided by a native Georgian speaker; no commercial CAD text used | MIT OR Apache-2.0 |
| assets/branding/logo/solidcraft-mark.svg | SolidCraft contributors | static SolidCraft mark: the five faces and gradients of assets/icons/app/macos/source/SolidCraft.icon/Assets/03-solid-blue-cutout.svg (the final frame of assets/styles/web/loading-logo.svg), cropped to the mark's bounds; original artwork | MIT OR Apache-2.0 |
| assets/branding/logo/solidcraft-mark-mono-black.svg | SolidCraft contributors | one-colour (black) version of assets/branding/logo/solidcraft-mark.svg, same paths; original artwork | MIT OR Apache-2.0 |
| assets/branding/logo/solidcraft-mark-mono-white.svg | SolidCraft contributors | one-colour (white) version of assets/branding/logo/solidcraft-mark.svg, same paths; original artwork | MIT OR Apache-2.0 |
| assets/branding/logo/solidcraft-mark-512.png | SolidCraft contributors | transparent 512 px render of assets/branding/logo/solidcraft-mark.svg (cairosvg); original artwork | MIT OR Apache-2.0 |
| assets/branding/logo/solidcraft-mark-1024.png | SolidCraft contributors | transparent 1024 px render of assets/branding/logo/solidcraft-mark.svg (cairosvg); original artwork | MIT OR Apache-2.0 |
| assets/branding/logo/solidcraft-mark-2048.png | SolidCraft contributors | transparent 2048 px render of assets/branding/logo/solidcraft-mark.svg (cairosvg); original artwork | MIT OR Apache-2.0 |
| assets/branding/logo/solidcraft-wordmark.svg | SolidCraft contributors | the name SolidCraft set like the loading logo's wordmark (bold, +0.02 em tracking, #15499e) in IBM Plex Sans Bold from assets/fonts/ibm-plex-sans (SIL OFL 1.1, IBM Corp.), outlined to paths; no font file is embedded | MIT OR Apache-2.0 |
| assets/branding/logo/solidcraft-lockup-horizontal.svg | SolidCraft contributors | assets/branding/logo/solidcraft-mark.svg beside assets/branding/logo/solidcraft-wordmark.svg, in the proportions of assets/branding/web/source/og.png; original artwork | MIT OR Apache-2.0 |
| assets/styles/ui/themes/onyx.json | SolidCraft contributors | original Onyx stone-grey palette, option overlays and semantic icon-role mapping; existing SolidCraft artwork is unchanged | MIT OR Apache-2.0 |
| docs/book/src/media/ui-tour/window.png | SolidCraft contributors | screenshot of SolidCraft 0.29.0 itself (`solidcraft --sample`, default dark theme, software renderer, 1280x800) with original numbered callouts (digits set in DejaVu Sans Bold), captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/ui-tour/navigate.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (`--sample`, default dark theme, software renderer) orbiting, panning and zooming, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| assets/locales/pending/sketch-tool-hints.json | carlymx | Original sketch tool hints and engine error translations | MIT OR Apache-2.0 |
| assets/locales/pending/primitive-pick-field-tips.json | SolidCraft contributors | Original primitive pick-field tooltip translations | MIT OR Apache-2.0 |
| assets/locales/pending/ribbon-panel-hover.json | SolidCraft contributors | Original ribbon panel menu preference labels and translations | MIT OR Apache-2.0 |
| docs/screenshots/box-insert-designer.gif | Shawn Marx | original recording made with BoxInsertDesigner's own Motion export (its three.js viewer) of its example game `examples/ccg-example` (https://github.com/ShawnMarx/BoxInsertDesigner): a card game box insert whose trays were built by SolidCraft through `solidcraft-cli`; the published card, board and box art in it is pixelated beyond recognition, and no logos or game names are shown (2.5× playback, 800 px wide) | MIT OR Apache-2.0 |
| docs/screenshots/box-insert-designer.mp4 | Shawn Marx | original recording made with BoxInsertDesigner's own Motion export (its three.js viewer) of its example game `examples/ccg-example` (https://github.com/ShawnMarx/BoxInsertDesigner): a card game box insert whose trays were built by SolidCraft through `solidcraft-cli`; the published card, board and box art in it is pixelated beyond recognition, and no logos or game names are shown (1280×720) | MIT OR Apache-2.0 |
| assets/locales/pending/agent-http-consent.json | SolidCraft contributors | Original endpoint-specific HTTP consent messages and translations | MIT OR Apache-2.0 |
| assets/locales/pending/ground-shadow-placement.json | SolidCraft contributors | Original ground-shadow placement preference messages and translations | MIT OR Apache-2.0 |
| docs/book/src/media/assemblies/components.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (default dark theme, software renderer) making components from two original hinge-leaf bodies, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/assemblies/joint.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (default dark theme, software renderer) creating a revolute joint between two hinge leaves, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/assemblies/drag.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (default dark theme, software renderer) dragging a jointed hinge leaf, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/assemblies/drive.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (default dark theme, software renderer) driving a revolute joint between two hinge leaves, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/features/extrude.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (default dark theme, software renderer) extruding a sketch's profile, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/features/shell.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (default dark theme, software renderer) shelling a block, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/features/fillet.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (default dark theme, software renderer) filleting four edges, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/features/edit.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (default dark theme, software renderer) editing a feature from the timeline, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/features/hole.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (default dark theme, software renderer) placing a hole, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/features/pattern.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (default dark theme, software renderer) patterning a hole around an axis, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/parameters/dialog.png | SolidCraft contributors | screenshot of SolidCraft 0.29.0 itself (default dark theme, software renderer) showing the Parameters dialog, with original numbered callouts (digits set in DejaVu Sans Bold), captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/files/menu.png | SolidCraft contributors | screenshot of SolidCraft 0.29.0 itself (`--sample`, default dark theme, software renderer) showing the File menu, with original numbered callouts (digits set in DejaVu Sans Bold), captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/getting-started/start.png | SolidCraft contributors | screenshot of SolidCraft 0.29.0 itself (default dark theme, software renderer, 1280x800) showing the start page with its built-in sample thumbnails, with original numbered callouts (digits set in DejaVu Sans Bold), captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/getting-started/sample.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (default dark theme, software renderer) opening the built-in Sample Plate from the start page, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/sheet-metal/base.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (default dark theme, software renderer) making a sheet metal base flange, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/sheet-metal/flange.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (default dark theme, software renderer) adding sheet metal edge flanges, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/sheet-metal/flat.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (default dark theme, software renderer) showing a sheet metal flat pattern, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/sketching/create.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (default dark theme, software renderer) starting a sketch on the Top plane, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/sketching/draw.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (default dark theme, software renderer) drawing a rectangle and a circle with typed values, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/sketching/dimension.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (default dark theme, software renderer) dimensioning a sketch until it is fully constrained, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/sketching/parts.png | SolidCraft contributors | screenshot of SolidCraft 0.29.0 itself (default dark theme, software renderer, 1280x800) showing a fully constrained sketch, with original numbered callouts (digits set in DejaVu Sans Bold), captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/sketching/offset.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (default dark theme, software renderer) offsetting a sketch outline, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| docs/book/src/media/sketching/trim.mp4 | SolidCraft contributors | original screen recording of the actual SolidCraft 0.29.0 English desktop UI (default dark theme, software renderer) trimming a notch in a sketch, with the original drawn pointer of examples/demo/overlay.py and labels set in DejaVu Sans Bold, captured with examples/demo/doc_shots.py | MIT OR Apache-2.0 |
| assets/locales/ca.json | carlymx | Catalan translation of the English catalog, contributed upstream | MIT OR Apache-2.0 |
| assets/locales/pending/sketch-mirror-auto-line.json | SolidCraft contributors | Original Mirror preference label and translations | MIT OR Apache-2.0 |
| docs/screenshots/7452/demo-01-extrude5-edge-frame.png | SamD98 | screenshot of the actual SolidCraft desktop UI showing the revolve axis pick on the Cat Post Topper repro design (docs/screenshots/7452/revolve-edge-frame.solidcraft), for #7452 | MIT OR Apache-2.0 |
| docs/screenshots/7452/demo-04-preview-outer-l11.png | SamD98 | screenshot of the actual SolidCraft desktop UI showing the revolve axis pick on the Cat Post Topper repro design (docs/screenshots/7452/revolve-edge-frame.solidcraft), for #7452 | MIT OR Apache-2.0 |
| docs/screenshots/7452/demo-05-preview-inner-l8.png | SamD98 | screenshot of the actual SolidCraft desktop UI showing the revolve axis pick on the Cat Post Topper repro design (docs/screenshots/7452/revolve-edge-frame.solidcraft), for #7452 | MIT OR Apache-2.0 |
| docs/screenshots/7452/demo-06-result-outer-120.png | SamD98 | screenshot of the actual SolidCraft desktop UI showing the revolve axis pick on the Cat Post Topper repro design (docs/screenshots/7452/revolve-edge-frame.solidcraft), for #7452 | MIT OR Apache-2.0 |
| docs/screenshots/7452/demo-07-preview-360.png | SamD98 | screenshot of the actual SolidCraft desktop UI showing the revolve axis pick on the Cat Post Topper repro design (docs/screenshots/7452/revolve-edge-frame.solidcraft), for #7452 | MIT OR Apache-2.0 |
| docs/screenshots/7452/demo-08-cancelled.png | SamD98 | screenshot of the actual SolidCraft desktop UI showing the revolve axis pick on the Cat Post Topper repro design (docs/screenshots/7452/revolve-edge-frame.solidcraft), for #7452 | MIT OR Apache-2.0 |
| docs/screenshots/7452/demo-13-colliding-id.png | SamD98 | screenshot of the actual SolidCraft desktop UI showing the revolve axis pick on the Cat Post Topper repro design (docs/screenshots/7452/revolve-edge-frame.solidcraft), for #7452 | MIT OR Apache-2.0 |
| docs/screenshots/7452/demo-14-surface-l1.png | SamD98 | screenshot of the actual SolidCraft desktop UI showing the revolve axis pick on the Cat Post Topper repro design (docs/screenshots/7452/revolve-edge-frame.solidcraft), for #7452 | MIT OR Apache-2.0 |
| docs/screenshots/7452/demo-15-surface-result.png | SamD98 | screenshot of the actual SolidCraft desktop UI showing the revolve axis pick on the Cat Post Topper repro design (docs/screenshots/7452/revolve-edge-frame.solidcraft), for #7452 | MIT OR Apache-2.0 |
| docs/screenshots/7452/revolve-selected-edge.mp4 | SamD98 | screen recording of the actual SolidCraft desktop UI showing the revolve axis pick on the Cat Post Topper repro design (docs/screenshots/7452/revolve-edge-frame.solidcraft), for #7452 | MIT OR Apache-2.0 |
| assets/locales/bg.json | Yasen-55 | Original translation | MIT OR Apache-2.0 |
| crates/sketch/assets/fonts/liberation-sans/LiberationSans-Regular.ttf | Red Hat, Inc. (Liberation Fonts 2.x; digitized data Google) | https://github.com/liberationfonts (Debian fonts-liberation), unmodified; licence text in crates/sketch/assets/fonts/liberation-sans/OFL.txt; used for sketch Text outlines | SIL OFL 1.1 |
| crates/sketch/assets/fonts/liberation-sans/OFL.txt | Red Hat, Inc.; Liberation Fonts contributors | Unmodified accompanying font licence | SIL OFL 1.1 |
| assets/locales/pending/drag-to-zoom.json | SolidCraft contributors | Original drag-to-zoom labels and translations | MIT OR Apache-2.0 |
## Code adapted from sibling projects
@@ -893,7 +838,7 @@ into THIRD-PARTY-LICENSES.txt when `main` regenerates it.
## FreeCAD and Rhino import library
FreeCAD `.FCStd` and Rhino `.3dm` files are read with [cadmpeg](https://github.com/cadmpeg/cadmpeg)
0.6.7 (Apache-2.0), linked as the crates `cadmpeg-core`, `cadmpeg-ir`, `cadmpeg-registry`,
0.6.3 (Apache-2.0), linked as the crates `cadmpeg-core`, `cadmpeg-ir`, `cadmpeg-registry`,
`cadmpeg-container`, `cadmpeg-codec-freecad`, `cadmpeg-codec-rhino` and `cadmpeg-codec-step`
in native and browser builds (`crates/io/src/native_cad.rs`). Only those open-format codecs are built: no
default features, so cadmpeg's codecs for commercial CAD formats and its ShapeManager/ACIS
@@ -911,10 +856,11 @@ copied into SolidCraft.
| Directory | Source | Licence | Changes |
|---|---|---|---|
| vendor/accesskit_macos | accesskit_macos 0.26.3, https://github.com/AccessKit/accesskit (The AccessKit contributors) | MIT OR Apache-2.0 | the subclassing adapter and its tests from 0.27.2: dropping the adapter keeps AppKit's key-value observers (vendor/README.md) |
## Vendored renderer compatibility fix
`vendor/egui-wgpu` is egui-wgpu 0.37.0 from https://github.com/emilk/egui
`vendor/egui-wgpu` is egui-wgpu 0.36.2 from https://github.com/emilk/egui
(MIT OR Apache-2.0; both original licence texts are included). Rust sources and
its original `egui.wgsl` shader are retained; no images or other artwork are copied.
SolidCraft's narrow patch selects a safe 1x MSAA path on the chosen OpenGL adapter
Desktop view DXF export runs in the file-operation worker with five-stage progress and
cooperative cancellation. Curve tolerance (0.0001–1 mm, default 0.01 mm) is remembered alongside
the hidden-edge setting. Cancelled exports preserve the model and the previous destination;
@@ -225,12 +231,6 @@ completed drawings publish atomically. The browser still exports synchronously.
## Render foundation
- Wood surface images (#1345): native CPU and GPU opaque rendering share physical
repeat frames and filtered mip chains. Imported maps retain exact bytes and
declared provenance in the design, reopen offline, and expose grain-angle
controls. Scalar face appearances suppress body maps. Planar projection and
CPU encoding/optical limits remain explicit; see [portable surfaces](docs/render-portable-surfaces-and-stages.md).
- Original starter appearances (#1722): 34 opaque recipes through existing commands, with six explicitly unavailable glass recipes and preserved legacy looks; see [the contract](docs/render-starter-appearances.md).
- Bounded linear film accumulation (#1696) supplies caller-admitted mean/variance storage and complete-pass views; actual progressive consumers remain separate. See [the film contract](docs/render-film.md).
//! solidcraft-cli mcp setup [--dry-run] [--client NAME] [--live] (alias: mcp install) add it to OpenCode, Claude Desktop, Claude Code, Cursor
//! solidcraft-cli licences SolidCraft's licence and the third-party licences
@@ -62,9 +62,9 @@ struct Command {
}
/// `run`'s lines in the usage.
constUSAGE_RUN: &str=" solidcraft-cli run <script.json|design.sc|part.step> [--in design.sc|part.step] [--out FILE]... [--save FILE] [--quiet] [--results] [--timings] [--profile] [--profile-out trace.json] [--json-out FILE] [--allow-errors] [--validation each_step|each_feature|off]\n [--param-check off|warn|strict] [--quality standard|fine|finest]\n solidcraft-cli run --in <design.sc|part.step> [--out FILE]...\n (a timeline feature that fails fails the run and nothing is written; --allow-errors writes anyway)\n (--quality: how closely an STL, OBJ or 3MF --out follows curved faces, as file.export's quality: a chord of\n 2e-4, 5e-5 or 1e-5 of each body's size, never under 1 µm, default standard)\n (--validation: when SMLib's full check runs on the features computed (diagnostics.validation), default each_feature)\n (--param-check checks each step against its command's contract: warn reports on stderr, strict stops the run)\n (--timings prints {timings: [{index, command, ms}], total_ms} for a script, with --results its results too;\n --profile adds each command's profile: {boolean_ms, tessellate_ms, other_ms}, the kernel's share)\n (--profile also records where the time goes, SMLib's calls, kernel operations, features, commands and import stages,\n and prints the table to stderr: count, total, self time and longest per span; --profile-out FILE writes the spans\n as a Chrome trace for chrome://tracing or ui.perfetto.dev; SOLIDCRAFT_PROFILE=1 does the same for any command)\n";
constUSAGE_RUN: &str=" solidcraft-cli run <script.json|design.sc|part.step> [--in design.sc|part.step] [--out FILE]... [--save FILE] [--quiet] [--results] [--timings] [--profile] [--profile-out trace.json] [--json-out FILE] [--allow-errors] [--validation each_step|each_feature|off]\n [--param-check off|warn|strict]\n solidcraft-cli run --in <design.sc|part.step> [--out FILE]...\n (a timeline feature that fails fails the run and nothing is written; --allow-errors writes anyway)\n (--validation: when SMLib's full check runs on the features computed (diagnostics.validation), default each_feature)\n (--param-check checks each step against its command's contract: warn reports on stderr, strict stops the run)\n (--timings prints {timings: [{index, command, ms}], total_ms} for a script, with --results its results too;\n --profile adds each command's profile: {boolean_ms, tessellate_ms, other_ms}, the kernel's share)\n (--profile also records where the time goes, SMLib's calls, kernel operations, features, commands and import stages,\n and prints the table to stderr: count, total, self time and longest per span; --profile-out FILE writes the spans\n as a Chrome trace for chrome://tracing or ui.perfetto.dev; SOLIDCRAFT_PROFILE=1 does the same for any command)\n";
/// `eval`'s lines in the usage.
constUSAGE_EVAL: &str=" solidcraft-cli eval <script.json|design.sc|part.step> [--in design.sc|part.step] [--json-out FILE] [--profile] [--profile-out trace.json] [--validation each_step|each_feature|off] (alias: inspect)\n solidcraft-cli eval --in <script.json|design.sc|part.step> [--json-out FILE]\n (with both inputs, runs the positional script on --in before measuring; does not automatically save the modified design)\n (--json-out FILE writes the JSON that run (with --results, else the measurement) and eval print to FILE instead of stdout,\n as plain UTF-8: a shell's > can re-encode it, e.g. Windows PowerShell adds a byte-order mark)\n (--profile, --profile-out and --validation as for run)\n";
constUSAGE_EVAL: &str=" solidcraft-cli eval <script.json|design.sc|part.step> [--in design.sc|part.step] [--json-out FILE] [--profile] [--profile-out trace.json] (alias: inspect)\n solidcraft-cli eval --in <script.json|design.sc|part.step> [--json-out FILE]\n (with both inputs, runs the positional script on --in before measuring; does not automatically save the modified design)\n (--json-out FILE writes the JSON that run (with --results, else the measurement) and eval print to FILE instead of stdout,\n as plain UTF-8: a shell's > can re-encode it, e.g. Windows PowerShell adds a byte-order mark)\n (--profile and --profile-out as for run)\n";
/// `script`'s lines in the usage.
constUSAGE_SCRIPT: &str=" solidcraft-cli script <design.sc|script.json> [--out script.json]\n (the design's history as a command script that eval and run replay)\n";
constUSAGE_MCP: &str=" solidcraft-cli mcp [--headless] [--in design.sc|script.json] [--connect 127.0.0.1:PORT [--token T]] [--allow-path DIR]... [--allow-any-path]\n [--param-check off|warn|strict] [--render-gpu] [--compact]\n (--compact, SOLIDCRAFT_MCP_COMPACT=1 or the app's Preferences › AI (with --connect): compact tool output for\n agents: inspect_design summarises sketches and takes `sketches` by name and a `bodies` filter, and tool JSON\n is not pretty-printed; off by default)\n solidcraft-cli mcp setup [--dry-run] [--client opencode|claude-desktop|claude-code|cursor] [--live]\n (adds a `solidcraft` server, with this program's path, to each installed AI client; --live adds `solidcraft-live` for the running app; alias: mcp install)\n";
constUSAGE_MCP: &str=" solidcraft-cli mcp [--headless] [--in design.sc|script.json] [--connect 127.0.0.1:PORT [--token T]] [--allow-path DIR]... [--allow-any-path]\n [--param-check off|warn|strict] [--render-gpu]\n solidcraft-cli mcp setup [--dry-run] [--client opencode|claude-desktop|claude-code|cursor] [--live]\n (adds a `solidcraft` server, with this program's path, to each installed AI client; --live adds `solidcraft-live` for the running app; alias: mcp install)\n";
/// `crashes`'s lines in the usage.
constUSAGE_CRASHES: &str=" solidcraft-cli crashes [list [--json] | show <id> | replay <id> | dir | clear [<id>]]\n";
/// Runs `solidcraft-cli eval` (and its `inspect` alias), opening the input design or script with the requested `--validation` mode and reporting both `inspect.measure` and `document.inspect`.
| AppImage | Uses the Linux 256 px image and `.DirIcon` alias |
| FreeBSD | Shares Linux hicolor images and freedesktop metadata |
| Web | HTML/Trunk and `manifest.webmanifest` stay in `apps/solidcraft-web/`; copies Japanese font/licence to `fonts/`, uses the collected CSS, and copies the Linux 32/256/512 px images to `icons/` for the favicon and installed app |
| Web | HTML/Trunk and `manifest.webmanifest` stay in `apps/solidcraft-web/`; copies the Japanese font/licence to `fonts/` and the Noto Sans Arabic, KR, SC and TC fonts with their licences to `fonts/<family>/` (fetched when a drawing's text needs them), uses the collected CSS, and copies the Linux 32/256/512 px images to `icons/` for the favicon and installed app |
| Docs and link previews | `xtask book` copies the shared card to the existing `/solidcraft/og.png` public path |
## Code and provenance
Resources remain compiled by their owning layer through existing APIs:
`ui-egui::icons::paint_icon` and `Tokens` at L5, model presets in L2 `doc`, and sketch
fonts at L1. The sketch crate owns its built-in Liberation Sans font and OFL
licence under `crates/sketch/assets/fonts/liberation-sans/`, so Cargo source
packages and vendored builds include both files. State, projection, interaction, commands and GPU bindings stay in
fonts at L1. State, projection, interaction, commands and GPU bindings stay in
their current modules. Embedded data uses `CARGO_MANIFEST_DIR`; application code
needs no runtime resource registry or repository lookup.
| `logo/solidcraft-mark-mono-white.svg` | One-colour print on dark material, such as a white print on a dark shirt. |
| `logo/solidcraft-mark-512.png`, `-1024.png`, `-2048.png` | Transparent square PNGs for places that don't take SVG: avatars, social posts, slides, print shops that ask for a bitmap (send the 2048). |
| `logo/solidcraft-wordmark.svg` | The name on its own, outlined to paths. |
| `logo/solidcraft-lockup-horizontal.svg` | Mark and name side by side: headers, banners, shirt fronts, wide stickers. |
| `web/source/og.png` | The existing link preview card for the docs site. |
The gaps between the faces are part of the logo. In the colour and one-colour files they are
transparent, so the material shows through. For a die-cut sticker, cut around the outer shape
and let the backing colour (white is best) fill the gaps.
## Colours
The mark's five faces each use a two-stop gradient from the icon source:
"cmd.inspect_colored_components":"Omogući boje komponenti",
"cmd.inspect_colored_components_disable":"Onemogući boje komponenti",
"cmd.inspect_compare":"Uporedi tijela",
"cmd.inspect_compare_picture":"Uporedi sliku",
"cmd.inspect_continuity":"Analiza kontinuiteta",
@@ -1621,7 +1623,7 @@
"help.sketch.insert_svg":"Učitava putanje SVG crteža u skicu, skalirane, zakrenute i postavljene gdje zadate. Koristite ga da logotip ili vektorski obris pretvorite u krive koje možete ekstrudirati.",
"help.sketch.inspect":"Otvara izvještaj o otvorenoj skici: koliko je stepeni slobode preostalo i je li potpuno ograničena. Koristite ga da saznate šta se još pomjera prije nego što završite skicu.",
"help.sketch.intersect":"Dodaje krive ili tačke gdje tijela, lica, ivice ili druge skice sijeku ravan skice. Ostaju povezane i prate model kada se promijeni.",
"help.sketch.intersection_curve":"Pravi 3D krive tamo gdje se dva tijela, lica ili krive drugih skica sastaju, povezane s njima. Koristite ih kao putanje ili vodilice koje prate model.",
"help.sketch.intersection_curve":"Pravi 3D krive tamo gdje se dva tijela ili lica sastaju, povezane s njima. Koristite ih kao putanje ili vodilice koje prate model.",
"help.sketch.isoparametric_curve":"Pravi 3D krivu u smjeru U ili V lica kroz tačku koju izaberete, povezanu s licem. Koristite je kao putanju ili liniju razdvajanja koja prati površ.",
"help.sketch.line":"Crta povezane linije tačku po tačku, kao otvoreni lanac ili zatvoren obris. To je osnovni alat za većinu profila.",
"help.sketch.line.midpoint":"Crta liniju od njene središnje tačke do jednog kraja, a drugi kraj se preslikava. Koristite je za linije centrirane na tački, npr. simetričnu ivicu.",
"help.sketch.insert_svg":"Læser stierne i en SVG-tegning ind i en skitse, skaleret, drejet og placeret, som du angiver. Brug den til at gøre et logo eller en vektorkontur til kurver, du kan ekstrudere.",
"help.sketch.inspect":"Åbner en rapport om den åbne skitse: hvor mange frihedsgrader der er tilbage, og om den er fuldt bundet. Brug den til at finde ud af, hvad der stadig kan bevæge sig, før du afslutter skitsen.",
"help.sketch.intersect":"Tilføjer de kurver eller punkter, hvor emner, flader, kanter eller andre skitser krydser skitseplanet. De forbliver linkede og følger modellen, når den ændres.",
"help.sketch.intersection_curve":"Opretter 3D-kurver, hvor to emner, flader eller kurver fra andre skitser mødes, linket til dem. Brug dem som baner eller styrekurver, der følger modellen.",
"help.sketch.intersection_curve":"Opretter 3D-kurver, hvor to emner eller flader mødes, linket til dem. Brug dem som baner eller styrekurver, der følger modellen.",
"help.sketch.isoparametric_curve":"Opretter en 3D-kurve langs en flades U- eller V-retning gennem et punkt, du vælger, linket til fladen. Brug den som bane eller delelinje, der følger overfladen.",
"help.sketch.line":"Tegner forbundne linjer punkt for punkt som en åben kæde eller en lukket kontur. Det er det grundlæggende værktøj til de fleste profiler.",
"help.sketch.line.midpoint":"Tegner en linje fra dens midtpunkt ud til den ene ende, og den anden ende spejles. Brug den til linjer centreret om et punkt, f.eks. en symmetrisk kant.",
@@ -3807,8 +3809,6 @@
"sample.plate.name":"Eksempelplade",
"sample.vents.about":"Slidser i et rektangulært mønster: Rækker, kolonner og deling er parametre",
"sample.vents.name":"Ventilationsplade",
"scale.per_axis":"Per akse",
"scale.uniform":"Ensartet",
"search.command_keys":"Enter kør Shift+Enter kør og hold åben Esc luk",
"cmd.render_effects_describe":"Lens and Creative Effects",
@@ -86,7 +87,6 @@
"prefs.max_file_size_web":"The web app opens STEP and import files up to 512 MB and designs up to 256 MB: a browser tab can't hold larger files. The desktop app can raise these limits.",
"prefs.megabytes":"MB",
"prefs.network_locations_note":"For organisations that keep designs on file servers. Off: only servers you allow.",
"prefs.select_hidden_edges_help":"Select edges through faces when Shaded with hidden edges is active, including for Fillet. Off keeps v0.30.1 selection behaviour. Hidden bodies stay unselectable.",
"prefs.sketch.center_arc":"Centre-point arc follows the cursor",
"prefs.sketch.conflict_colour":"Conflict colour",
"prefs.sketch.tracking_guides":"Centre and midpoint guides",
"render.aging_raytrace_help":"Ageing is applied by CPU ray tracing and GPU path tracing. Raster keeps schematic rendering.",
"render.aging_refresh_targets":"Inspect current bodies",
"render.aging_roughness":"Layer roughness",
"render.aging_rust":"Oxidized iron / rust",
@@ -160,7 +159,6 @@
"render.background_workflow":"Choose the background you intend: a camera-only colour/gradient, a physical stage that receives light, or HDR illumination. They are independent. Live Preview is a modelling view; render a new image or regrade a retained master to see camera finishing.",
"render.base_color":"Base colour · sRGB",
"render.bloom_help":"Creative output-only glow from positive linear highlights, spread with three normalised box passes. Radius is in output pixels. Added in linear display light before sRGB; not a lens, volumetric effect or convergence improvement. The raw EXR is unchanged.",
"render.check_media_remaining":"Density grids, displacement, full spectral integration and propagated polarisation remain unavailable.",
"render.cpu_area_editor_help":"Full side vectors in millimeters; U cross V points towards the emitting side. This differs from GPU half-edge vectors.",
"render.cpu_light_help":"Up to eight directional lights. An empty custom list turns them off; selecting a preset restores its lights. Colours are linear RGB and intensity is relative, not watts.",
"render.glass_model_help":"Glass roughness scatters transmitted rays. Dispersion and film colour use three wavelength bands. Rough sheets require straight transmitted shadows off.",
"render.hdr_primaries_declared":"The source declares its colour primaries.",
"render.hdr_primaries_undeclared":"The source does not declare primaries; review the renderer colour requirements.",
@@ -238,12 +235,6 @@
"render.studio_area_help":"Up to four one-sided rectangles. Orthogonal half-edges U and V define size; U × V faces the lit side. Coordinates are world-space millimetres.",
"render.studio_center":"Centre X, Y, Z (mm)",
"render.studio_hdr_help":"Radiance .hdr, 2:1 panorama, up to 2048 × 1024. EXR is unavailable. The colour assumption applies only when primaries are unspecified.",
"render.surface_import.complete":"Choose an image and enter its author, source and licence.",
"dialog.cylinder_face_tip":"La face ou le sommet du modèle sur lequel le cylindre est posé : cliquer ici, puis dessus dans la vue. Laissé vide, X, Y et Z le placent.",
"dialog.dimension_insert_hint":"Double-cliquez sur une autre cote pilotante pour insérer son nom",
"dialog.dimension_name":"Cote : {name}",
"dialog.edit_title":"MODIFIER {title}",
"dialog.no_shown_body":"Aucun corps affiché à modifier: affichez-en un ou choisissez Nouveau corps",
"dialog.pattern_sketch_not_object":"Choisissez des corps ou des fonctions : une esquisse n'est ni l'un ni l'autre. Répétez ses courbes avec la Répétition ou la Symétrie de l'esquisse, ou extrudez-la d'abord.",
"dialog.primitive_point_tip":"Un point qui remplit X, Y et Z : cliquer ici, puis sur un sommet, une arête ou une face du modèle, sur un point d'une esquisse ou sur l'origine.",
"dialog.reference_edge_tip":"Une arête droite de la face choisie, depuis laquelle la distance ci-dessous est mesurée : cliquer ici, puis sur l'arête.",
"file_load.reading_percent":"Lecture du fichier... {percent} %",
"file_load.rebuilding":"Reconstruction de l’entité {done} sur {total}",
"file_load.recovering":"Récupération de la conception",
"file_load.reloading_cloud":"Rechargement du nuage de points",
"file_load.stopping":"Attente de l’arrêt de l’opération précédente...",
"file_load.updating_links":"Mise à jour des liens",
"file_load.waiting":"En attente d’une opération sur fichier",
@@ -1628,7 +1623,7 @@
"help.sketch.insert_svg":"Lit les tracés d'un dessin SVG dans une esquisse, mis à l'échelle, tournés et placés comme vous le définissez. À utiliser pour transformer un logo ou un contour vectoriel en courbes que vous pouvez extruder.",
"help.sketch.inspect":"Ouvre un rapport sur l'esquisse ouverte: combien de degrés de liberté il reste et si elle est entièrement contrainte. À utiliser pour savoir ce qui bouge encore avant de terminer l'esquisse.",
"help.sketch.intersect":"Ajoute les courbes ou points où des corps, faces, arêtes ou d'autres esquisses traversent le plan d'esquisse. Ils restent liés et suivent le modèle lorsqu'il change.",
"help.sketch.intersection_curve":"Crée des courbes 3D là où deux corps, faces ou courbes d'autres esquisses se rencontrent, liées à eux. À utiliser comme trajectoires ou rails guides qui suivent le modèle.",
"help.sketch.intersection_curve":"Crée des courbes 3D là où deux corps ou faces se rencontrent, liées à eux. À utiliser comme trajectoires ou rails guides qui suivent le modèle.",
"help.sketch.isoparametric_curve":"Crée une courbe 3D le long de la direction U ou V d'une face, par un point que vous choisissez, liée à la face. À utiliser comme trajectoire ou ligne de partage qui suit la surface.",
"help.sketch.line":"Dessine des lignes connectées point par point, en chaîne ouverte ou en contour fermé. C'est l'outil de base de la plupart des profils.",
"help.sketch.line.midpoint":"Dessine une ligne de son milieu vers une extrémité, l'autre extrémité étant son symétrique. À utiliser pour des lignes centrées sur un point, comme une arête symétrique.",
@@ -1640,7 +1635,6 @@
"help.sketch.pattern.circular":"Copie la géométrie d'esquisse autour d'un centre, sur un cercle complet ou un angle donné. À utiliser pour des cercles de perçages, des rayons et des dents.",
"help.sketch.pattern.rectangular":"Copie la géométrie d'esquisse en lignes et colonnes à des espacements donnés. À utiliser pour des grilles de trous, de rainures ou d'aérations.",
"help.sketch.point":"Place un point d'esquisse. À utiliser comme référence pour des cotes, des contraintes, des centres de perçage ou des fonctions ultérieures.",
"help.sketch.point.divide":"Place des points qui divisent les courbes choisies en longueurs égales. Les points restent sur chaque courbe et gardent leur espacement quand elle change.",
"help.sketch.point3d":"Place un point dans l'espace, avec Esquisse 3D activée. À utiliser comme référence pour des courbes et trajectoires 3D.",
"help.sketch.polygon.circumscribed":"Dessine un polygone régulier autour d'un cercle, dimensionné du centre au milieu d'un côté. À utiliser lorsque la largeur sur plats est connue, comme pour un écrou hexagonal.",
"help.sketch.polygon.edge":"Dessine un polygone régulier à partir des deux extrémités d'un côté. À utiliser lorsque la longueur et la position d'un côté sont connues.",
@@ -2206,8 +2200,6 @@
"prefs.edges":"Arêtes et ombrage",
"prefs.extend":"Étendre",
"prefs.extra_navigation":"Ctrl+glisser gauche dans le vide fait orbiter; maintenir Espace pour un panoramique.",
"prefs.extrude_arrow_face_stops":"La flèche d'extrusion s'arrête aux faces",
"prefs.extrude_arrow_face_stops_note":"En faisant glisser la flèche de distance d'Extrusion, elle s'arrête aux faces planes parallèles au profil, comme l'autre côté d'un bloc qu'on découpe, et souligne la face. Désactivé : la flèche avance seulement par pas ronds.",
"prefs.extrude_view_isometric":"Passer la vue en isométrique à l'ouverture de l'extrusion",
"prefs.extrude_view_return":"Revenir à la vue précédente à la fermeture de l'extrusion",
"prefs.follows_os":"Suit le système",
@@ -2287,8 +2279,6 @@
"prefs.mouse":"Souris et pavé tactile",
"prefs.mouse_heading":"Souris",
"prefs.mouse_mapping":"Affectation des boutons de la souris",
"prefs.move_drag_highlights":"Mettre en évidence ce qui est sous le pointeur pendant que les flèches de Déplacer font glisser un composant",
"prefs.move_drag_highlights_tip":"Désactivé : pendant que les flèches de Déplacer font glisser un composant, rien n’est mis en évidence sous le pointeur, ce qui garde les grands assemblages fluides. Avec une coupe ou une analyse affichée, la mise en évidence reste, et une pièce glissée le long de ses liaisons n’en montre jamais.",
"prefs.navigation":"Navigation",
"prefs.navigation_note":"Comment la souris, le pavé tactile et la souris 3D déplacent la vue.",
"prefs.navigator_fit":"Cadrer le modèle après un changement de vue du repère de navigation",
@@ -2364,8 +2354,6 @@
"prefs.shortcuts":"Raccourcis",
"prefs.single_surface_analysis":"Utiliser une seule analyse de surface",
"prefs.single_surface_analysis_help":"Désactivé, l'ombrage de surface et Continuité peuvent rester actifs ensemble. Activé, seule la dernière analyse lancée ou modifiée est conservée.",
"prefs.sketch.escape_twice_finishes":"Un double Échap termine l'esquisse",
"prefs.sketch.escape_twice_finishes_note":"Deux pressions rapides sur Échap terminent l'esquisse. Désactivé : Échap annule seulement l'outil ou la sélection, et Terminer l'esquisse ferme l'esquisse.",
"prefs.sketch_align_points":"S'aligner sur d'autres points d'esquisse pendant le dessin",
"prefs.sketch_align_points_note":"Pendant le dessin, un point s'aligne à la fois horizontalement sur un point d'esquisse et verticalement sur un autre, avec un guide en pointillés, et le clic conserve les deux alignements. Désactivé : uniquement sur le point précédent, un axe à la fois.",
"prefs.sketch_conflict_colour":"Géométrie en conflit dans la couleur de conflit",
"render.cpu_maps_saved_help":"Le rendu CPU accepte les cartes opaques enregistrées : choisissez une surface, puis enregistrez ses cartes dans la vue. Avec l’éclairage indirect, un autre corps peut utiliser Verre ; le corps avec les cartes ne le peut pas. Désactivez les réflexions sélectionnées, l’anisotropie et les effets procéduraux. Les fichiers temporaires de cartes utilisent le GPU.",
"render.cpu_material_certification":"La vérification CPU valide la géométrie de verre prise en charge avant le rendu. Le verre fermé utilise la distance géométrique.",
"render.cpu_neutral":"Neutre",
"render.cpu_opaque_required":"Le lancer de rayons CPU nécessite un arrière-plan opaque. Décochez Arrière-plan transparent pour continuer.",
"render.cpu_options_pending":"Ce panneau CPU ne peut pas encore modifier l'émission, les effets de surface, le verre ni l'anisotropie. Effacez ces options d'API avant de l'utiliser.",
@@ -3015,11 +3001,9 @@
"render.frame_wide":"16:9 · Écran large",
"render.gpu_depth":"Profondeur maximale des chemins",
"render.gpu_options_help":"Les échantillons, la profondeur, la graine et l'exposition sont enregistrés avec ce préréglage. Seule la méthode d'image active est enregistrée.",
"render.gpu_path_crashed":"SolidCraft s’est fermé pendant sa dernière préparation sur cet adaptateur graphique, très probablement dans le pilote graphique ; il n’est donc plus préparé de lui-même. Utilisez le lancer de rayons sur le CPU, ou réessayez (une mise à jour du pilote réessaie aussi).",
"render.gpu_path_failed":"Traceur de chemins GPU indisponible",
"render.gpu_path_first_setup":"La première initialisation sur ce GPU peut prendre plusieurs minutes; SolidCraft reste utilisable pendant ce temps. Les démarrages suivants réutilisent les shaders compilés lorsque le pilote les conserve.",
"render.gpu_path_preparing":"Traceur de chemins GPU: compilation des shaders…",
"render.gpu_path_retry":"Réessayer",
"render.gpu_seed":"Graine aléatoire",
"render.gpu_unavailable":"Le tracé de chemins GPU n'est pas prêt sur cet appareil.",
"render.ground_apply":"Ajuster et enregistrer le sol",
@@ -3827,8 +3811,6 @@
"sample.plate.name":"Plaque d'exemple",
"sample.vents.about":"Rainures en répétition rectangulaire: lignes, colonnes et pas sont des paramètres",
"sample.vents.name":"Plaque d'aération",
"scale.per_axis":"Par axe",
"scale.uniform":"Uniforme",
"search.command_keys":"Entrée exécuter Maj+Entrée exécuter et garder ouvert Échap fermer",
"sketch.dimension_applied_renamed":"Cote appliquée; paramètre nommé `{name}`",
"sketch.divide_hint":"Les points divisent chaque courbe en longueurs égales et les gardent quand elle change.",
"sketch.dof_left":"{count} degrés de liberté restants",
"sketch.dof_left_one":"{count} degré de liberté restant",
"sketch.draw_curves":"Dessiner en {linetype}",
@@ -4459,7 +4440,6 @@
"ui.click_selects_whole_bodies":"Un clic sélectionne des corps entiers",
"ui.click_then_press_key":"Cliquer, puis appuyer sur la nouvelle touche",
"ui.close":"Fermer",
"ui.close_tab":"Fermer l’onglet",
"ui.coil":"Hélice",
"ui.coincident":"Coïncidence",
"ui.collapse":"Réduire",
@@ -4706,7 +4686,6 @@
"ui.heading_create_sketch":"CRÉER UNE ESQUISSE",
"ui.heading_cylinder":"CYLINDRE",
"ui.heading_design":"DESIGN",
"ui.heading_divide_curve":"DIVISER LA COURBE",
"ui.heading_draft":"DÉPOUILLE",
"ui.heading_edit":"ÉDITION",
"ui.heading_equation_curve":"COURBE PAR ÉQUATION",
@@ -4864,8 +4843,6 @@
"ui.mesh_format_3mf":"3MF",
"ui.mesh_format_3mf_tagged":"3MF avec étiquettes de faces",
"ui.mesh_format_stl":"STL",
"ui.mesh_import_origin":"Déplacer à l'origine",
"ui.mesh_import_origin_tip":"Centre le maillage en X et Y et pose sa base sur Z = 0. Désactivé, le maillage garde les coordonnées enregistrées dans le fichier.",
"ui.minor_radius":"Petit rayon",
"ui.mirror":"Symétrie",
"ui.mirror_line":"Ligne de symétrie",
@@ -4946,7 +4923,6 @@
"ui.point_cloud_add_filter":"Ajouter un filtre…",
"ui.point_cloud_auto_range":"Plage automatique",
"ui.point_cloud_color_by":"Colorer par",
"ui.point_cloud_dots":"Points isolés",
"ui.point_cloud_file_colors":"Couleurs du fichier",
"ui.point_cloud_filter_by":"Filtrer par",
"ui.point_cloud_height_high":"Plus haut",
@@ -4955,7 +4931,6 @@
"ui.point_cloud_no_file_colors":"Le fichier n'a pas de couleurs",
"ui.point_cloud_pause":"Pause",
"ui.point_cloud_play":"Lire",
"ui.point_cloud_reload":"Recharger le fichier",
"ui.point_cloud_single_color":"Couleur unique",
"ui.point_cloud_size":"Taille des points",
"ui.point_cloud_units":"Unités du fichier",
@@ -5048,7 +5023,6 @@
"ui.second_rail":"Second rail",
"ui.section_analysis":"Analyse de coupe",
"ui.section_size":"Taille de la section",
"ui.segments":"Segments",
"ui.select":"Sélectionner",
"ui.selectOther":"Sélectionner un autre…",
"ui.selectTangentChain":"Sélectionner la chaîne tangente",
"cmd.inspect_accessibility":"Análise de accesibilidade",
"cmd.inspect_center_of_mass":"Centro de masas",
"cmd.inspect_clearance":"Folga",
"cmd.inspect_colored_components":"Activar as cores dos compoñentes",
"cmd.inspect_colored_components_disable":"Desactivar as cores dos compoñentes",
"cmd.inspect_compare":"Comparar corpos",
"cmd.inspect_compare_picture":"Comparar a imaxe",
"cmd.inspect_continuity":"Análise de continuidade",
@@ -1621,7 +1623,7 @@
"help.sketch.insert_svg":"Le os trazados dun debuxo SVG nun bosquexo, escalados, xirados e colocados onde indiques. Úsao para converter un logotipo ou un contorno vectorial en curvas que podes extruír.",
"help.sketch.inspect":"Abre un informe do bosquexo aberto: cantos graos de liberdade quedan e se está totalmente restrinxido. Úsao para saber o que aínda se move antes de rematar o bosquexo.",
"help.sketch.intersect":"Engade as curvas ou os puntos onde corpos, caras, arestas ou outros bosquexos cruzan o plano do bosquexo. Quedan ligados e seguen o modelo cando cambia.",
"help.sketch.intersection_curve":"Crea curvas 3D onde se atopan dous corpos, caras ou curvas doutros bosquexos, ligadas a eles. Úsaas como traxectorias ou guías que seguen o modelo.",
"help.sketch.intersection_curve":"Crea curvas 3D onde se atopan dous corpos ou caras, ligadas a eles. Úsaas como traxectorias ou guías que seguen o modelo.",
"help.sketch.isoparametric_curve":"Crea unha curva 3D na dirección U ou V dunha cara por un punto que escollas, ligada á cara. Úsaa como traxectoria ou liña de división que segue a superficie.",
"help.sketch.line":"Debuxa liñas conectadas punto a punto, como cadea aberta ou como contorno pechado. É a ferramenta básica para a maioría dos perfís.",
"help.sketch.line.midpoint":"Debuxa unha liña desde o seu punto medio ata un extremo, co outro extremo reflectido. Úsao para liñas centradas nun punto, como unha aresta simétrica.",
@@ -3807,8 +3809,6 @@
"sample.plate.name":"Placa de exemplo",
"sample.vents.about":"Ranuras nun patrón rectangular: filas, columnas e paso son parámetros",
"sample.vents.name":"Placa de ventilación",
"scale.per_axis":"Por eixo",
"scale.uniform":"Uniforme",
"search.command_keys":"Intro executar Maiús+Intro executar e manter aberto Esc pechar",
"cmd.inspect_colored_components":"Omogući boje komponenti",
"cmd.inspect_colored_components_disable":"Onemogući boje komponenti",
"cmd.inspect_compare":"Usporedi tijela",
"cmd.inspect_compare_picture":"Usporedi sliku",
"cmd.inspect_continuity":"Analiza kontinuiteta",
@@ -1621,7 +1623,7 @@
"help.sketch.insert_svg":"Čita putanje SVG crteža u skicu, skalirane, zakrenute i postavljene kako zadate. Upotrijebite ga za pretvaranje logotipa ili vektorskog obrisa u krivulje koje možete ekstrudirati.",
"help.sketch.inspect":"Otvara izvješće o otvorenoj skici: koliko je stupnjeva slobode preostalo i je li potpuno ograničena. Upotrijebite ga kako biste saznali što se još pomiče prije dovršetka skice.",
"help.sketch.intersect":"Dodaje krivulje ili točke u kojima tijela, lica, bridovi ili druge skice presijecaju ravninu skice. Ostaju povezane i prate model kad se promijeni.",
"help.sketch.intersection_curve":"Izrađuje 3D krivulje na mjestu gdje se dva tijela, lica ili krivulje drugih skica susreću, povezane s njima. Upotrijebite ih kao putanje ili vodilice koje prate model.",
"help.sketch.intersection_curve":"Izrađuje 3D krivulje na mjestu gdje se dva tijela ili lica susreću, povezane s njima. Upotrijebite ih kao putanje ili vodilice koje prate model.",
"help.sketch.isoparametric_curve":"Izrađuje 3D krivulju u smjeru U ili V lica kroz točku koju odaberete, povezanu s licem. Upotrijebite je kao putanju ili liniju razdvajanja koja prati plohu.",
"help.sketch.line":"Crta povezane linije točku po točku, kao otvoreni lanac ili zatvoreni obris. To je osnovni alat za većinu profila.",
"help.sketch.line.midpoint":"Crta liniju od njezine središnje točke do jednog kraja, a drugi kraj zrcali. Upotrijebite ga za linije centrirane na točku, primjerice simetričan brid.",
"help.sketch.insert_svg":"Beolvassa egy SVG-rajz útvonalait egy vázlatba, az Ön által megadott léptékkel, elforgatással és helyen. Használja egy logó vagy vektoros körvonal kihúzható görbékké alakítására.",
"help.sketch.inspect":"Jelentést nyit a megnyitott vázlatról: hány szabadságfok maradt, és teljesen kényszerezett-e. Használja annak kiderítésére, mi mozdul még, mielőtt befejezi a vázlatot.",
"help.sketch.intersect":"Hozzáadja azokat a görbéket vagy pontokat, ahol testek, lapok, élek vagy más vázlatok metszik a vázlatsíkot. Kapcsoltak maradnak, és követik a modellt, ha az megváltozik.",
"help.sketch.intersection_curve":"3D görbéket hoz létre ott, ahol két test, lap vagy más vázlatok görbéi találkozik, hozzájuk kapcsolva. Használja őket útvonalként vagy vezérgörbeként, amely követi a modellt.",
"help.sketch.intersection_curve":"3D görbéket hoz létre ott, ahol két test vagy lap találkozik, hozzájuk kapcsolva. Használja őket útvonalként vagy vezérgörbeként, amely követi a modellt.",
"help.sketch.isoparametric_curve":"3D görbét hoz létre egy lap U vagy V iránya mentén egy kiválasztott ponton át, a laphoz kapcsolva. Használja útvonalként vagy osztóvonalként, amely követi a felületet.",
"help.sketch.line":"Összefüggő vonalakat rajzol pontról pontra, nyitott láncként vagy zárt körvonalként. Ez a legtöbb profil alapeszköze.",
"help.sketch.line.midpoint":"Vonalat rajzol a felezőpontjától az egyik végéig, a másik véget tükrözve. Használja egy pontra középen álló vonalakhoz, például szimmetrikus élhez.",
@@ -3807,8 +3809,6 @@
"sample.plate.name":"Mintalemez",
"sample.vents.about":"Hornyok téglalap mintában: a sorok, oszlopok és osztás paraméterek",
"sample.vents.name":"Szellőzőlemez",
"scale.per_axis":"Tengelyenként",
"scale.uniform":"Egyenletes",
"search.command_keys":"Enter futtatás Shift+Enter futtatás és nyitva tartás Esc bezárás",
"cmd.inspect_colored_components":"Aktifkan Warna Komponen",
"cmd.inspect_colored_components_disable":"Nonaktifkan Warna Komponen",
"cmd.inspect_compare":"Bandingkan Bodi",
"cmd.inspect_compare_picture":"Bandingkan dengan Gambar",
"cmd.inspect_continuity":"Analisis Kontinuitas",
@@ -1621,7 +1623,7 @@
"help.sketch.insert_svg":"Membaca path gambar SVG ke dalam sketsa, diskalakan, diputar, dan ditempatkan sesuai pengaturan Anda. Gunakan untuk mengubah logo atau kontur vektor menjadi kurva yang dapat diekstrusi.",
"help.sketch.inspect":"Membuka laporan tentang sketsa yang terbuka: berapa derajat kebebasan yang tersisa dan apakah sketsa terbatasi penuh. Gunakan untuk mengetahui apa yang masih bergerak sebelum Anda menyelesaikan sketsa.",
"help.sketch.intersect":"Menambahkan kurva atau titik tempat bodi, muka, tepi, atau sketsa lain memotong bidang sketsa. Semuanya tetap tertaut dan mengikuti model saat model berubah.",
"help.sketch.intersection_curve":"Membuat kurva 3D di tempat dua bodi, muka, atau kurva sketsa lain bertemu, tertaut padanya. Gunakan sebagai jalur atau rel pemandu yang mengikuti model.",
"help.sketch.intersection_curve":"Membuat kurva 3D di tempat dua bodi atau muka bertemu, tertaut padanya. Gunakan sebagai jalur atau rel pemandu yang mengikuti model.",
"help.sketch.isoparametric_curve":"Membuat kurva 3D sepanjang arah U atau V sebuah muka melalui titik yang Anda pilih, tertaut ke muka itu. Gunakan sebagai jalur atau garis pisah yang mengikuti permukaan.",
"help.sketch.line":"Menggambar garis-garis tersambung titik demi titik, sebagai rantai terbuka atau kontur tertutup. Ini alat dasar untuk sebagian besar profil.",
"help.sketch.line.midpoint":"Menggambar garis dari titik tengahnya ke satu ujung, dengan ujung lainnya dicerminkan. Gunakan untuk garis yang dipusatkan pada sebuah titik, seperti tepi simetris.",
@@ -3807,8 +3809,6 @@
"sample.plate.name":"Pelat Contoh",
"sample.vents.about":"Slot dalam pola persegi panjang: baris, kolom, dan pitch adalah parameter",
"sample.vents.name":"Pelat Ventilasi",
"scale.per_axis":"Per sumbu",
"scale.uniform":"Seragam",
"search.command_keys":"Enter jalankan Shift+Enter jalankan dan tetap buka Esc tutup",
"dialog.cylinder_face_tip":"La faccia o il vertice del modello su cui poggia il cilindro: fai clic qui, poi su di esso nella vista. Se resta vuoto, lo posizionano X, Y e Z.",
"dialog.dimension_insert_hint":"Fai doppio clic su un’altra quota di controllo per inserirne il nome",
"dialog.dimension_name":"Quota: {name}",
"dialog.edit_title":"MODIFICA {title}",
"dialog.no_shown_body":"Nessun corpo visibile da modificare: mostrane uno o scegli Nuovo corpo",
"dialog.pattern_sketch_not_object":"Seleziona corpi o lavorazioni: uno schizzo non è nessuno dei due. Ripeti le sue curve con Ripetizione o Specchia dello schizzo stesso, oppure estrudilo prima.",
"dialog.primitive_point_tip":"Un punto che compila X, Y e Z: fai clic qui, poi su un vertice, uno spigolo o una faccia del modello, su un punto di uno schizzo oppure sull'origine.",
"dialog.reference_edge_tip":"Uno spigolo rettilineo della faccia scelta da cui si misura la distanza sotto: fai clic qui, poi sullo spigolo.",
"dialog.select":"↖ Seleziona",
"dialog.selected_count":"↖ Selezionati: {count}",
"dialog.selection_constraint":"Vincolo {id}",
@@ -1627,7 +1624,7 @@
"help.sketch.insert_svg":"Legge i tracciati di un disegno SVG in uno schizzo, scalati, ruotati e posizionati come imposti. Usalo per trasformare un logo o un contorno vettoriale in curve che puoi estrudere.",
"help.sketch.inspect":"Apre un rapporto sullo schizzo aperto: quanti gradi di libertà restano e se è completamente vincolato. Usalo per scoprire cosa si muove ancora prima di terminare lo schizzo.",
"help.sketch.intersect":"Aggiunge le curve o i punti in cui corpi, facce, spigoli o altri schizzi attraversano il piano dello schizzo. Restano collegati e seguono il modello quando cambia.",
"help.sketch.intersection_curve":"Crea curve 3D dove si incontrano due corpi, facce o curve di altri schizzi, collegate a essi. Usale come percorsi o guide che seguono il modello.",
"help.sketch.intersection_curve":"Crea curve 3D dove si incontrano due corpi o facce, collegate a essi. Usale come percorsi o guide che seguono il modello.",
"help.sketch.isoparametric_curve":"Crea una curva 3D lungo la direzione U o V di una faccia passante per un punto che scegli, collegata alla faccia. Usala come percorso o linea di divisione che segue la superficie.",
"help.sketch.line":"Disegna linee collegate punto per punto, come catena aperta o contorno chiuso. È lo strumento di base per la maggior parte dei profili.",
"help.sketch.line.midpoint":"Disegna una linea dal suo punto medio fino a un'estremità, con l'altra estremità speculare. Usalo per linee centrate su un punto, come un bordo simmetrico.",
@@ -1639,7 +1636,6 @@
"help.sketch.pattern.circular":"Copia la geometria dello schizzo attorno a un punto centrale, su un cerchio completo o su un angolo stabilito. Usalo per cerchi di bulloni, raggi e denti.",
"help.sketch.pattern.rectangular":"Copia la geometria dello schizzo in righe e colonne con spaziature stabilite. Usalo per griglie di fori, asole o prese d'aria.",
"help.sketch.point":"Colloca un punto dello schizzo. Usalo come riferimento per quote, vincoli, centri di fori o lavorazioni successive.",
"help.sketch.point.divide":"Posiziona punti che dividono le curve scelte in lunghezze uguali. I punti restano su ogni curva e ne mantengono la spaziatura quando cambia.",
"help.sketch.point3d":"Colloca un punto nello spazio, con Schizzo 3D attivo. Usalo come riferimento per curve e percorsi 3D.",
"help.sketch.polygon.circumscribed":"Disegna un poligono regolare attorno a un cerchio, dimensionato dal centro al punto medio di un lato. Usalo quando è nota l'apertura chiave, come per un dado esagonale.",
"help.sketch.polygon.edge":"Disegna un poligono regolare a partire dai due estremi di un lato. Usalo quando sono note la lunghezza e la posizione di un lato.",
@@ -3816,8 +3812,6 @@
"sample.plate.name":"Piastra di esempio",
"sample.vents.about":"Asole in ripetizione rettangolare: righe, colonne e passo sono parametri",
"sample.vents.name":"Piastra di ventilazione",
"scale.per_axis":"Per asse",
"scale.uniform":"Uniforme",
"search.command_keys":"Invio esegui Maiusc+Invio esegui e tieni aperto Esc chiudi",
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
CamWight
