* test(io): a centred ATTDEF keeps its insertion point in a DWG (#2464)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* fix(io): an ATTDEF with no default value is placed by its tag's width in DWG (#2464)
The writer keeps a justified text's stored insertion point only when it is near where the
baseline starts for the text's width; an ATTDEF with an empty default value has width 0, so every
AutoCAD insertion point further than half a height from the alignment point was replaced by the
alignment point. The tag is what is drawn: judge against its width.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* fix(io): keep a stored ATTDEF point that is close to the empty text's start
The tag-width baseline check replaced a point read from a drawing whenever the
font's width of the tag put the computed start further than the allowance away,
e.g. a centred LONGTAG with group 10 at x=99.5 and group 11 at x=100 moved to
about 92.17 in DXF and DWG. A stored point close to the empty text's own start
is now kept as before; only otherwise is it judged against the tag.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* test(io): store an ATTDEF point that differs from the computed baseline
`assert_kept(start)` stored exactly the baseline the tag-width fallback computes, so a write that replaced group 10 with that baseline passed too. The point is now 1 off the start, within the tolerance. Review of #2466.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* test(io): an empty-value ATTDEF keeps its point with an empty or absent prompt too
The tag-width check applies to every ATTDEF with no default value, since the
CAD displays the tag whatever the prompt: the guard now says `attdef` instead
of reading as a prompt test, and the test covers a prompt, an empty one and none.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
* test(io): a LINE keeps its extrusion through DXF and DWG (#2241)
`line_extrusion_roundtrips_with_world_endpoints` (red: group 230 is not written for a LINE with
normal (0, 0, -1), so it comes back with (0, 0, 1)).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* fix(io): write a LINE's extrusion (210/220/230) (#2241)
A LINE's points are world coordinates and the reader already keeps its extrusion (the direction
of its thickness), but the writer left the groups out, so a normal (0, 0, -1) came back as
(0, 0, 1) from DXF and from DWG, which is written through DXF.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* test(io): a LINE's extrusion is written as a unit vector or not at all (#2241)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* fix(io): write a LINE's extrusion normalized, nothing for a zero or NaN normal (#2241)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* fix(io): write a tiny extrusion's direction, drop a non-finite one
Vec3::normalized returns zero at or below the drawing tolerance, so a LINE with
extrusion (0, 0, -1e-10) saved with no 210/220/230 and reopened as +Z, flipping a
thickness; an infinite component normalized to NaN and was written as a zero
vector. The writer now normalizes by the vector's own length and writes nothing
only for a zero or non-finite vector.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* fix(io): keep the direction of a huge finite extrusion
The length of (0, -1.5e308, 1.5e308) overflows to infinity, so the normal came out as (0, 0, 0) and was written as such. The vector is scaled by its largest component before it is normalized; the case is in `line_extrusion_is_written_as_a_unit_vector_or_not_at_all`. Review of #2417.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
* test(io): the Constant mode of an attached ATTRIB survives DXF and DWG (#2246)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* fix(io): an attached ATTRIB keeps its Constant mode through DXF and DWG (#2246)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* test(io): attached ATTRIB Constant mode over every save version and encoding
The regression covered the default DXF and DWG saves only. It now also saves
with each Version::ALL entry as ASCII DXF, binary DXF and DWG.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
* test(io): MTEXT legacy column groups stay in the AcDbMText subclass (#2247)
`legacy_column_groups_stay_in_the_mtext_subclass` (red: the column width 48 is read as the
entity's ltscale, 12.5; the height count 50 as a column height).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* fix(io): MTEXT legacy column groups no longer leak into the entity (#2247)
`common()` read the linetype scale (48) and the other AcDbEntity groups from the whole record,
so the column width 48 of an MTEXT's legacy column groups became its ltscale. They are now read
from the AcDbEntity subclass only. `read_columns` took the height count (the first 50) for a
column height and `column_tags` did not write it; both follow the DXF layout now.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* test(engine): the MTEXT entmake column heights carry their count (#2247)
Group 50 after the column type is the height count, then the heights. Thanks to austin62jake for the report and the fix.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* test(io): a marker-less MTEXT with an embedded object keeps its own ltscale (#2247)
Case from #2276 (Zaxaerith): without subclass markers, the 48 of an embedded object (101) was read as Common.ltscale.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* fix(io): stop the entity's own groups at an embedded object (#2247)
Without subclass markers, an embedded object's 48 was read as Common.ltscale. Suggested by austin62jake; case and test from #2276 (Zaxaerith).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* style(io): rustfmt the new MTEXT test
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* fix(io): keep layer and colour that follow a subclass marker in a list with no AcDbEntity marker
entity_groups ended the common region at the first subclass marker other than
AcDbEntity, so an entmake list such as (0 . "LINE") (100 . "AcDbLine") (8 . "Walls")
was read on layer 0. The region now ends at a marker only when the record has an
AcDbEntity marker (files from R13 on always do); other records are read as a
whole up to an embedded object (101), as before the column change.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* fix(io): markers inside an application-defined group do not end the entity's groups
A `102 {...102 }` group before AcDbEntity may hold any code, 100 and 101 included: `entity_groups` stopped there and the layer and colour that followed fell back to defaults. The scan now skips the contents of such groups when looking for the AcDbEntity marker and for the end of its groups. Review of #2416.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* fix(io): keep every column height of files written before the height count
CADCraft up to f536bf4 wrote group 76 = n and n group-50 heights, no count.
Reading those with the counted format dropped the first height and rewrote
76 as n - 1. The first 50 is a count only when there are 76 + 1 of them.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* fix(io): MTEXT column heights skip application-defined groups; no count for an empty list
A `102 {...}` group inside the MTEXT record may hold a 50 of its own: it
counted as a height and made a legacy record (76 = n, n heights, no count)
look counted, dropping the first height. `read_columns` now filters the
record with `outside_app` (shared with `entity_groups`).
`column_tags` wrote a lone `50 = 0` for a dynamic manual column with no
heights, which read back as one height of 0; the count is omitted for an
empty list, so `heights: []` round trips. ZWCAD 2025 also read that lone
50 as the rotation and zeroed it.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
* DXF: no CLASS instance counts in R2000 files (AutoCAD LT 2026 hung on them)
Since #635 every CLASS record carries group 91, the instance count, at every
version. The count came with the 2004 format: R2000 CLASS records are 1, 2, 3,
90, 280, 281. AutoCAD LT 2026 stops responding when it opens an R2000 DXF
whose CLASS records have a 91, so every R2000 file CADCraft saved locked it up
(a drawing opened from an R2000 file is saved as R2000 again).
Isolated black-box in AutoCAD LT 2026 with synthetic files: the same R2000
file without the 91 groups opens, as does the same content declared AC1032.
The counts are now written only when the file (or the DWG the bridge writes)
is 2004 or later; R2000 output drops the group from every CLASS record,
classes kept from a newer file included.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Test: binary R2000 drops group 91 from a kept foreign CLASS too
Review follow-up: the kept-class check covered R2000 only through ASCII
saves; it now also saves the fixture as binary R2000 and checks that the
ACME_OBJECT CLASS record is 1, 2, 3, 90, 280, 281.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Test: binary 2018 keeps a kept foreign CLASS's instance count
Review follow-up: the kept-class check now saves the fixture as binary at
both R2000 (no group 91) and 2018 (group 91 after the proxy flags, with the
class's count), through one helper.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Slopapalooza <307952167+Slopapalooza@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* test(io): `$PSTYLEMODE` round-trips through DXF and DWG (#2332)
Red test: a drawing read from a DXF with `$PSTYLEMODE` 0 (named plot
styles) is written back without the variable, so readers default to
colour-dependent plot styles.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* fix(io): write `$PSTYLEMODE` as read, in DXF and DWG (#2332)
`HEADER_VARS` did not list `$PSTYLEMODE`, so a drawing read from a
named-plot-style file (0) was saved without it; the DWG bridge then
defaulted to colour-dependent plot styles (1) and the plot came out
with thicker edges. One more entry in the list; a drawing that never
had the variable still writes nothing.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
Co-authored-by: assamaral <217119886+assamaral@users.noreply.github.com>
panic_hunt runs every command in a fresh session and fails on real panics. The guard now covers the steps after a command, so a late panic restores the drawing instead of ending the app.
* Save As suggests the default save format for opened drawings too (#2199)
Options > Open and Save > "Save as" in AutoCAD is the format every drawing
is saved in. CADCraft applied File > Default Save Format only to untitled
drawings, so Save As on an opened DWG kept DWG with DXF chosen, and the
other way round. Save As now swaps a DWG, DXF or DWT extension for the
chosen format; other names, and Save of an opened file, are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Default Save Format's echo says Save As will suggest the format (#2199)
"Save As will save drawings as DWG" promised more than Save As does: it
only swaps a DWG, DXF or DWT extension in the name it suggests, and the
path picked in the dialog decides the format. The echo now reads
"Save As will suggest DWG", and default_save_format_applies_to_opened_drawings
pins it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Add Bosnian (bs) to the interface languages
bs.tsv: Bosnian (Latin script, Ijekavian) catalog covering every key of
CADCraft's other catalogs, its wording shared with storytold/craft-i18n
locales/bs/ and the strings craft-i18n lacks translated new. Every bs-*
locale selects it; counts use one/few/other. Locale and plural tests,
localization docs and an attribution entry (AI-assisted, not yet
reviewed by a native speaker).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013Tayw8nmxoLLmKv13jK93z
* docs(localization-parity): Bosnian in the Languages table (CodeRabbit)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* Add CHPROP, asking for properties as AutoCAD does
CHPROP selects objects, then asks "Enter property to change
[Color/LAyer/LType/ltScale/LWeight/Thickness/TRansparency]" until Enter,
applying each value through properties.set. Measured from AutoCAD 2024
through AutoLISP's command: colours 1-255, names, BYLAYER, BYBLOCK or
Truecolor; 0, 256 and 300 refused; a layer must exist; a linetype not
loaded is loaded from the standard file; a lineweight goes to the nearest
standard one with a note.
Keyword prefixes now have to reach past the keyword's last capital, so
"L" alone matches none of LAyer, LType, ltScale and LWeight, as in
AutoCAD.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* CHPROP tests: transparency, and refused true colours and transparencies
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* CHPROP leaves objects on locked layers out, as AutoCAD does
Each pick and the pickfirst selection lose the objects on locked layers,
followed by "1 was on a locked layer." or "N were on a locked layer.";
with none of the pickfirst selection left, CHPROP asks for objects. The
JSON chprop leaves them out too and returns {changed, locked}.
The keywords test also pins QDIM's DA and PEDIT's vertex E, which AutoCAD
2024 refuses although only one keyword starts with them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* chprop: look up locked handles in a set, and always report "locked" (CodeRabbit)
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* Extents: an MTEXT's wrap width only narrows its box (#2465)
A garbage group 41 width (3e14) became the box width, so the drawing extents were 3e14
wide. The width is now capped at the longest line's estimate. The width 0 branch is
unchanged. Tests: a_huge_mtext_wrap_width_does_not_inflate_the_extents and
a_narrow_mtext_wrap_width_still_sets_the_box_width.
* Parity checklist: regenerated after merging main
* Parity checklist: regenerated after merging main
* SOLID: draw 2D solids, chained as AutoCAD chains them
CADCraft had the SOLID entity but no command to draw it. As AutoCAD
2024 asks from AutoLISP: first, second, third point, then "fourth
point or <exit>" (Enter makes a triangle); further solids take the
previous one's last two corners and ask their third and fourth points
until Enter. Corners stay in the order given.
The command (alias SO) has a JSON form taking the points chained the
same way. solid_chains_its_corners_as_autocad pins seven measured
calls to 1e-9.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* SOLID: offer it in the Draw menu
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Extents: count layers that are turned off, as AutoCAD does
Drawing::extents (ZOOM Extents, EXTMIN/EXTMAX, $EXTMIN/$EXTMAX, Extents
plots) left out layers turned off as well as frozen ones. AutoCAD 2024
leaves out only frozen layers: lines from the origin to (10, 10) on
layer 0, (100, 0) on a layer turned off and (0, 200) on a frozen one
give EXTMAX (100.03, 10.01); inside a block too, and a reference on a
frozen layer counts for nothing.
Drawing::in_extents keeps a layer turned off, and extent_bounds counts
block contents on one. entity_bounds, which the spatial index and
selection use, still measures only what is drawn.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Extents: leave out attributes on frozen layers
An insert's attribute lies on its own layer, else on its definition's,
as the renderer draws it. One on a frozen layer no longer stretches the
extents; one on a layer turned off still counts, as other objects do.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Extents test: build the attribute without an unreachable arm
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* -HATCH: Properties asks the pattern's scale and angle, and takes Solid
The pattern option asked only for a name, so a script answering it as
AutoCAD asks (`_P ANSI31 2 45`) got "Unknown pattern 2" and "Unknown
pattern 45" and a hatch at scale 1, angle 0, and `_P _S` reported
"Unknown pattern _S".
As AutoCAD 2024's -HATCH Properties does, the pattern name is now
followed by its scale and then its angle (Enter keeps them), Solid
(S, _S or SOLID) sets a solid fill and asks neither, and an unknown
name or a refused value is asked again. The sCale and Angle options
and the pattern picker are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* -HATCH: ask for the pattern again when a .pat file loads nothing
A .pat file that cannot be read, or holds no pattern, now repeats the
pattern prompt instead of going on to Scale and Angle with the
previous pattern.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* -HATCH: a pick at a Properties prompt asks again
Enter keeps the current pattern, scale or angle; a point or an object
(an entity name from LISP) answers none of those prompts, so the prompt
comes again instead of going on with the value unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* -INSERT: X, Y and Z presets, XYZ, and the Z factor AutoCAD stores
The insertion point prompt offers X, Y and Z: the factor for that axis
alone, the others 1, and no scale prompts after the point. The X scale
prompt offers XYZ, which asks X, Y and Z in turn. A Z factor not asked
is the size of the X factor: X -1 with Y as X stored Z -1, where AutoCAD
stores +1. Basepoint picks on the block dropped at the cursor, as
AutoCAD drops it where it is being dragged (the origin in a script),
instead of at its definition position.
Each was measured in AutoCAD 2024 from AutoLISP's command and is pinned
in insert_options_match_autocad.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* -INSERT: store the Z factor as AutoCAD does after Scale, Z and XYZ
Measured in AutoCAD 2024: Scale -2 gives X and Y -2 and Z 2; a Z preset
of -3 gives Z 3; XYZ with X -2 and Enter at Y and Z gives Z 2; a Z typed
at XYZ's Z prompt (-4) stays as typed. XYZ followed by a corner, with
Corner or a point straight away, still asks for Z, which defaults to
the size of the corner's X factor.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* -INSERT: an axis preset after Scale changes that axis alone
Measured in AutoCAD 2024: Scale -3 then X 2 gives 2/-3/3; X 2 then
Scale -3 gives -3/-3/3; Scale 2 then Z -5 gives 2/2/5. Scale now sets
all three presets, so a later X, Y or Z keeps the other two.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* -INSERT test: Basepoint with the cursor away from the origin
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
select::pick said it returns the topmost entity within the aperture,
but it returned the nearest, using the draw order only to break ties.
AutoCAD 2024 picks the object drawn last among those under the pickbox,
and DRAWORDER changes which: a circle and a line drawn after it, 0.05
and 0.45 from the pick, give the line.
Candidates already come topmost first, so pick_with returns the first
within the aperture; pick_all keeps that order for selection cycling.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Decimal and scientific numbers went through Rust's formatting, which
rounds the exact binary value and a half to even: (rtos 1500.5 2 0)
gave 1500, (rtos 0.125 2 2) 0.12 and (rtos 1.005 2 2) 1.00.
AutoCAD 2024 gives 1501, 0.13 and 1.01: it rounds at 15 significant
digits, with a half away from zero, for scientific notation too
(2.5 to none is 3E+00). units::fixed does that on the decimal digits;
format_distance's decimal and scientific forms and rtos use it.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* LISP: getvar and setvar take angle variables in radians
CADCraft keeps ANGBASE, SNAPANG, POLARANG, HPANG, CHAMFERD and
DIMJOGANG in degrees as far as sysvars::get/set go, which is right for
the SETVAR command, but AutoLISP's getvar returned those degrees and
setvar took them: (getvar "DIMJOGANG") gave 45.0, and
(setvar "ANGBASE" (/ pi 2)) set 1.57 degrees.
AutoCAD 2024 gives and takes them in radians from AutoLISP: each set to
30 by SETVAR, or to (/ pi 6) by setvar, reads 0.5235987755982987. The
LISP bridge now converts these six; the SETVAR command is unchanged.
getangle_is_relative_to_angbase sets ANGBASE in radians accordingly.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* SETVAR: keep real dimension variables real
A dimension variable whose style field is a real (DIMJOGANG, DIMSCALE
and the other real DIM* fields) is now stored as a real header value,
even when the first value set is a whole number. SETVAR DIMJOGANG 45
followed by (setvar "DIMJOGANG" 0.5) no longer rejects the fractional
degrees the radian value gives.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* SETVAR: store the value the dimension style took
A real dimension variable now stores the value its style field took after validation, so any input the style accepts (true for DIMSCALE gives 1) is stored as it was before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* LISP: entity names answer prompts that pick one object
`command` fed an entity name, alone or as `entsel` returns it (name and
point), to the running command as a pick. Prompts that pick a single
object with a point (MEASURE, DIVIDE, LENGTHEN, PEDIT, BREAK, TRIM and
EXTEND in Standard mode, FILLET, OFFSET, REVCLOUD Object, dimensions…)
only take points, so routines got "Invalid input" or nothing at all.
At such a prompt the name is now entered as its point, and a pick at
exactly that point finds the named object (Session::pick_object), so
the point says where on it, as in AutoCAD. A bare name stands at the
object's DXF group 10 point, the point AutoCAD picks it at: a line's
start, a circle's or an arc's centre, a polyline's first vertex. At an
arc's centre MEASURE runs from the arc's end, as AutoCAD does.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Keep a named object for its own input and its own space
A name given at a prompt picking one object now holds only while that
input is taken: a later pick at the same point finds what lies there.
A name for an object in another space picks nothing, instead of the
object under its point in the current space.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
UPDATE_APP (native builds; craft-update is a native-only dependency) carries our 128 px icon and accent (#3ea6e8, its colour in ArtCraft Launcher). The updater, the self-update
helper and craft-update's startup prompt all get them through crate::UPDATE_APP; the
prompt draws the icon, the accent and "by ArtCraft" (craft-update's default developer).
craft-update is pinned to storytold/craft-libs main at 1065653e7 (#434).
Clippy fixes for Rust 1.99 in untouched code (same logic):
- crates/constraints/src/auto.rs
- crates/engine/src/audit.rs
- crates/engine/src/cmd/inquiry.rs
- crates/engine/src/mtext_edit.rs
- crates/geom/src/nurbs.rs
- crates/io/src/dxf_raw.rs
- crates/io/src/dxf_read/document.rs
- crates/render/src/text.rs
- crates/ui-egui/src/cmdline.rs
- xtask/src/layers.rs
AGENTS.md (and CLAUDE.md where present) gets a CI workflows section: workflows only call
craft-common-actions at @main, with no other jobs; feature and fix PRs don't touch CI and
link or open a craft-common-actions issue (a PR only for a small fix that is safe for
every app and does not increase CI time); legacy jobs
aren't added to and move only as their own task, staying until a shared workflow runs them.
windows-arm64.yml moves from its SHA pin to @main. The pinned revision is on
craft-common-actions main and the workflow (and the actions it calls) is identical
there, so nothing changes in behaviour.
* xtask: the test suite and clippy pass on Windows
Two Windows-only failures stopped `cargo xtask ci` before it got going on
a Windows checkout (CI runs the gate on Linux only, so neither showed):
- parity::tests::civil_dates built a SystemTime 115,740,740 days after
the epoch (year 318857). Windows' SystemTime ends in the year 30828, so
the addition panicked ("overflow when adding duration to `SystemTime`").
That case now checks `civil_from_days` on the day count, which is what
it was about, on every platform.
- stats.rs imported `walk` for a test that only exists on Unix, so the
import was unused on Windows and `clippy -D warnings` refused it. The
Unix test calls `super::walk`, as its neighbour calls `super::walk_inner`.
Checked on Windows 11 x64: `cargo test --workspace` and
`cargo clippy --workspace --all-targets -- -D warnings` both pass.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(engine): refresh attribute baselines after value changes
CC-046: invalidate the derived XY baseline for changed justified attribute
values, including small changes inside the writer's imported-font tolerance.
Preserve no-op placement, alignment anchors and Aligned/Fit endpoints.
Regression reproduced on current upstream; all three focused tests pass.
Full cargo xtask ci passed all seven stages on Windows (2558 passing test
executions, zero failures, one ignored). Release Trunk web build passed.
Browser interaction verification is pending user dismissal of a Windows
Security prompt; do not treat the build as a runtime pass.
Windows validation prerequisite: original upstream PR #2198 commit a2dd814.
Independent of editor/ribbon changes; reverting restores only this setter,
its regression tests and corresponding file-format parity record.
* fix(io): preserve insertion elevation when refreshing text baselines
CC-046 review follow-up to PR #2214 comment 4377706777. Regression reproduced insertion Z 9 becoming 7. Preserve group 10 Z; test DXF independent elevations and document the DWG bridge shared elevation. Full cargo xtask ci passes all seven gates. This separate commit is reversible; reverting it restores elevation loss during baseline recomputation. Existing browser UI verification predates this writer correction.
* test(engine): cover global attribute no-ops and two-point exports
CC-046 review 5653054817: verify equal-value global JSON and scripted
-ATTEDIT preserve imported placement, and Aligned/Fit DXF save/reopen
retain both placement points and justification.
Validation: cargo xtask ci passed all seven gates on this branch;
git diff --check passed. Test-only follow-up, no application change.
Depends on CC-046 and unchanged Windows prerequisite #2198.
Revert this commit independently to remove only these assertions.
Runtime evidence remains separately recorded for the production commits.
---------
Co-authored-by: 2ez4gcx <108074836+2ez4gcx@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* DWG: post-read fix-ups run under catch_unwind; merge work is bounded (#1934)
table_merges and the other fix-ups on the acadrust document ran outside the
panic guard, and each merge range could visit rows x cols cells with no total
limit. They now run in one guarded post_process, and table_merges stops at
MAX_MERGE_CELLS cells in all. Tests: merge_work_is_bounded_by_the_cell_budget,
a_panic_in_post_processing_is_an_error.
* Parity checklist: regenerated after merging main
* DWG: test that the read and convert guards catch a panic through the public API (#2402)
The existing test only exercised guarded() itself. A test-only hook now makes post_process
or convert panic on entry, and tests go through dwg_to_dxf and dxf_to_dwg: both fail if
their guard is removed. convert()'s fix-ups, which run on the third-party reader's
document, are now under guarded() too, with their own error.
* Parity checklist: regenerated after merging main
* DWG: build the panic-test helpers only on native targets, like the tests that use them (#2402)
PanicIn and MINIMAL_DXF referenced the native-only PANIC_IN, so the dwg tests did not compile
for wasm32 (cargo check -p cadcraft-dwg --tests --target wasm32-unknown-unknown).
---------
Co-authored-by: Brandon Thomas <echelon@gmail.com>
Found while testing crates/engine/src/cmd/modify/fillet.rs:120-121 (run_chamfer) and 53-54 (fillet_lines)
Co-authored-by: Claude Haiku 5.5 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* DWG: keep block draw-order sort handles through the DXF bridge (#2410)
acadrust's DXF writer renumbers SORTENTSTABLE sort handles past every entity
handle, so an entity left out of a table (sorted by its own handle) drew below
every listed one. The table now carries its codes verbatim before writing.
Tests in io/tests/it/sortents.rs; the bridge test fails without the fix.
* Parity checklist: regenerated after merging main
* DXF: a block/space sort handle of 0 draws last (#2439)
A SORTENTSTABLE sort handle of 0 means the entity is drawn after every other
(ezdxf reorder.py, which notes AutoCAD defines it). apply_sortents sorted it
first; key it after all nonzero handles. Test: a_zero_sort_handle_draws_last (DXF and DWG bridge).
* Parity checklist: regenerated after merging main
* Draw order: test two block entities left out of a SORTENTSTABLE (#2439)
Each unlisted entity must sort by its own handle, landing between the listed ones. A
single fallback key for all of them would put them side by side. Checked in a DXF and
across the DWG bridge; test-only.
---------
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* ELLIPSE from axis endpoints matches what AutoCAD stores
Typed ELLIPSE input was checked against AutoCAD 2024 black-box (synthetic
input in accoreconsole, read back with entget); three rules differed:
- The major axis pointed at the second axis endpoint; AutoCAD points it at
the first. A full ellipse looks the same, but an elliptical arc's angles
are measured from that axis, so the arc was drawn on the opposite side of
the center, and the stored major vector, start point and quadrant order
all differed.
- A point at "Specify distance to other axis" gave its distance from the
first axis; AutoCAD takes its distance from the center (the rubber band),
then swaps the axes when it is the longer one.
- The end-angle prompt had no Included angle option, so `_I` was rejected
and the next number became an absolute end angle. AutoCAD adds the
included angle (default 180) to the start angle.
The JSON form (ellipse.axis / ellipse.arc with p1, p2, p3) follows the
same rules. The regression test pins ten AutoCAD-measured cases, among
them survey (VN-2000) coordinates, a near-millimetre ellipse and both
Included angle cases.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* docs: geometry parity says which part was measured against AutoCAD
The "How this was measured" section still said no numeric comparison
against AutoCAD had been run, next to the new ELLIPSE revision row that
reports one. It now names the 11 measured ELLIPSE cases and the test
that pins them, and keeps the rest of the document marked as read from
the source. Pointed out in review.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* ellipse: drop the import the axis-endpoint change left unused
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* Dimensions: fill in the measurement when one is created (#2421)
A dimension made in the session kept measurement 0.0 until it was saved and reopened.
add_dim now sets it with the geometry call the DXF/DWG writer uses for group 42.
Block names are still assigned at save time. Test: a_new_dimension_reports_its_measurement.
* Parity checklist: regenerated after merging main
* Dimensions: a jogged radius dimension stores its radius as the measurement (#2421)
draw_jogged_radius set the text but not DimGeometry.measurement, so DIMJOGGED dimensions
kept measurement 0 (and the DXF/DWG group 42 was 0). It now sets the radius.
Test: jogged_radius asserts the stored measurement.
* Parity checklist: regenerated after merging main
* Dimensions: fill in a new dimension's text position when it is created (#2421)
A dimension made in the session kept text_mid (0,0) until it was saved and reopened.
add_dim now sets it from the same dimension_geometry result as the measurement, the
position the writer puts in group 11, unless the user placed the text.
Test: a_new_dimension_reports_its_text_position.
---------
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* fix: keep WIPEOUT closure coherent across grips and outlines
Treat WIPEOUT as a closed polygon with an optional exact terminal closure marker, not as an open polyline. Centralize logical vertices, explicit outlines and closure-preserving vertex edits in the document type. Reuse this contract in grips, geometric primitives, rendering and DXF export without changing the stored schema or writer closure convention.
Add six-version DXF ASCII/binary and DWG regressions for implicit/explicit closure, both windings, all corners, API/interactive edits, undo/redo and repeated saves. Keep open/closed polylines and their coincident endpoints distinct. Cover multiple hot grips, hostile inputs and equivalent mask/frame output.
Validation: cargo xtask ci, all seven stages passed (2571 tests passed, one pre-existing skip). Two unrelated network tests failed transiently in earlier runs; each passed in isolation and the complete final run passed without exclusions. Direct and reopened grip edits produce byte-identical CLI PNG output.
Fixes#2256; related test-only matrix PR #2237 and tracker #2238 B3.
* fix(doc): keep coincident WIPEOUT endpoints separately editable
When an edit makes the endpoints of an implicit boundary coincide, add a separate closing marker rather than reclassifying the edited corner as that marker. Retain the logical vertex count and allow either coincident corner to move independently afterwards.
The document regression fails before the fix. Add API/interactive coverage for both endpoint directions and both closure forms, undo/redo, and subsequent separate edits across all six DXF/DWG versions including binary DXF and save-after-edit. Update the documented editing contract.
Validation: cargo xtask ci passed all seven stages; 2573 tests passed, one pre-existing skip.
Addresses the coincident-endpoint review on PR #2284; related #2256.
---------
Co-authored-by: cloudj <jonbahnes@gmail.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
Found while testing crates/engine/src/cmd/modify.rs:791 (run_offset)
Co-authored-by: Claude Haiku 5.5 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* Tests remove the temp files they write
Every test run left about 22 folders and files in the system temp
directory: xref, alias, template, insert, linetype, script and
recent-file fixtures, plus the pathless screenshot folder. The PDFBOOK
test also wrote its second book to `$TMPDIR/b.pdf`, because `a^b.pdf`
splits into `<prefix>-a.pdf` and `b.pdf`, and then removed a file that
was never written.
Tests that write files now use a `TempDir` guard
(`tests/support/temp_dir.rs`, shared by the engine's unit and
integration tests and copied for the UI crate). It gives each test its
own folder and removes it on drop, even when an assertion fails. The
PDFBOOK test also checks that both books land in its folder. The five
tests that write pathless screenshots hold a test-only lock, so the
shared screenshot folder can be removed once empty without racing
another test's write.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012FFPi6hJVyaEKV4PyE2fKq
* Pathless screenshot cleanup survives failed tests and writes
The test lock's guard now empties and removes the per-process
screenshot directory when dropped, so a test that panics no longer
leaves files behind, and the per-test remove calls are gone. A failed
PNG write or flush removes the partial file, since the reply carries
no path for anyone else to clean up.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: bmh129 <11478682+bmh129@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Bound the MCP client's reply read and the control server's total buffered bytes (#1925)
The MCP client read replies with an unbounded read_line; a process squatting on the
control port could make it allocate without limit. It now reads through take() with a
256 MiB cap (the server's own request cap) and fails with a clear error.
The control server allowed max_clients x max_line (16 x 256 MiB) buffered at once.
Request-line bytes are now charged against a shared 512 MiB budget; a request that
would pass it gets an error reply and the connection closes.
* Parity checklist: regenerated after merging main
* control_server: drop unused Read import (#1925)
* control_server: tests import Read themselves (#1925)
The unused-import cleanup removed std::io::Read from the module, but a test still calls
read_to_end, so the test build failed on CI.
Found while testing crates/dxf/src/lib.rs:189 and 267-274 (parse_with_limit via decode_ascii_file, then parse_ascii_with_limit)
Co-authored-by: Claude Haiku 5.5 <noreply@anthropic.com>
* xtask: the test suite and clippy pass on Windows
Two Windows-only failures stopped `cargo xtask ci` before it got going on
a Windows checkout (CI runs the gate on Linux only, so neither showed):
- parity::tests::civil_dates built a SystemTime 115,740,740 days after
the epoch (year 318857). Windows' SystemTime ends in the year 30828, so
the addition panicked ("overflow when adding duration to `SystemTime`").
That case now checks `civil_from_days` on the day count, which is what
it was about, on every platform.
- stats.rs imported `walk` for a test that only exists on Unix, so the
import was unused on Windows and `clippy -D warnings` refused it. The
Unix test calls `super::walk`, as its neighbour calls `super::walk_inner`.
Checked on Windows 11 x64: `cargo test --workspace` and
`cargo clippy --workspace --all-targets -- -D warnings` both pass.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* feat(web): persist validated browser panel layouts
CC-053: keep embedded floating, docked and hidden panels across reloads
through the existing host save cycle. Reject malformed/versioned records
atomically; native workspaces and drawings remain unchanged.
Validation: all seven cargo xtask ci gates passed (2558 pass, 0 fail,
1 ignored) on a2dd814 plus this exact change. Actual release Trunk bundle
and Edge floating/close/reload/reset/reload passed. Forced WebGL startup,
render and recovered layout passed; full edit cycle used default mode.
Dependency: original #2198 Windows test prerequisite. No #2226 dependency.
Revert this commit independently to stop using the optional storage key.
Upstream c3b8e7b adds nextest minimum configuration only; no runtime overlap.
---------
Co-authored-by: 2ez4gcx <108074836+2ez4gcx@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
TrueType and OpenType outlines are defined with the nonzero rule, but glyph
meshes were tessellated even-odd, so any area covered by two contours came
out empty. Arial Unicode (the macOS fallback CADCraft picks for Hangul)
builds 진 (U+C9C4) from a component that already contains the final ㄴ plus
a second copy of that ㄴ; even-odd cancelled the pair and 진 rendered as 지.
Overlapping contours in other fonts lost their overlaps the same way.
Tessellate glyph outlines with FillOptions::non_zero(). Outlines placed in
drawing coordinates without a TextGlyph (complex-script runs) go through the
same tessellator, offset to their first point to keep f32 precision, instead
of the even-odd slab filler.
An expression typed at a command's prompt is evaluated, and its value
answers the prompt. That value went back through typed(), which treated
it as typed text and evaluated it again when it looked like LISP. So
`circle (setq q "!q")` returned "!q", which evaluated to "!q" again,
forever, until the native stack overflowed and the process aborted
(a stack overflow is not a panic, so the catch_unwind guards cannot
help), losing unsaved work in every open drawing. It is reachable from
the command line, .scr scripts, the control channel and MCP.
The value now goes back with LISP evaluation off: a string that looks
like an expression is taken as text, as AutoCAD does.
Found while testing crates/engine/src/cmd/props.rs:155-157 (parse_color), with crates/color/src/lib.rs:60-66 (Color::from_aci)
Co-authored-by: Claude Haiku 5.5 <noreply@anthropic.com>
* Block Editor: BEDIT inside it switches to another block, asking to save first
BEDIT (typed, Edit Block, Tools > Block Editor) no longer refuses while the
Block Editor is open: the Edit Block Definition dialog opens on the block being
edited, and choosing another block switches to it. With changes not saved yet
it first asks whether to save them (Yes saves, No discards, Cancel stays), at
the command line as BCLOSE does and in the dialog. The JSON form takes
`save: true|false` and refuses to switch away from unsaved changes without it;
the block to switch to is checked before anything is saved or closed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Block Editor: the save question is one translatable sentence
The block name and punctuation were added around a translated fragment, so a
translation couldn't place the name or use its own quotation marks.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* BEDIT: a block the Block Editor can't switch to is refused before the save question
---------
Co-authored-by: Cody Vogt <18035288+codyvogt@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* MEASURE picks its starting end by the curve's parameter, as AutoCAD does
MEASURE started from whichever end was nearer the pick in a straight
line, and a closed curve always ran forwards from its first vertex.
AutoCAD (2024, black-box: synthetic objects in accoreconsole, every
POINT read back with entget) decides by the curve parameter of the pick,
the segment index plus the fraction along it:
- an open curve is measured from its end once the pick is halfway or
further: an L-shaped polyline picked at (10, 30) on its long leg
(parameter 1.3 of 2) runs from the end, although that end is the
farther one; a U-shape picked at (90, 0) (parameter 0.9 of 3) runs from
the start, although the end is nearer;
- a closed polyline runs from its first vertex, forwards before half its
parameter and backwards from then on;
- a circle always runs counterclockwise from angle 0.
Chain::param_of gives that parameter. The new test
divide_and_measure_match_autocad pins nine measured DIVIDE and MEASURE
cases (lines, arcs, circles, open and closed polylines with an arc
segment), every point to 1e-9.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* MEASURE: a spline's starting end comes from its own parameter
A spline's chain is a tessellation with zero-length pieces dropped, so
its segment count is not the spline's parameter range: a degree-1 spline
whose first span has zero length spends half its parameter there, and a
pick at x = 3 on its 10-unit run (parameter 1.3 of 0..2, past the middle)
was measured from the start because it is short of the drawn middle.
Splines now compare spline_param_of with the middle of their domain;
other curves keep Chain::param_of. Pointed out in review.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* MEASURE: polylines count coincident vertices in their parameter; ellipses pinned
AutoCAD's polyline parameter is the vertex index, so a coincident vertex
still takes one unit of the range. The chain drops zero-length spans, so
its segment index and count shifted the middle: (0,0) (1,0) (101,0)
(101,0) picked at x = 1.1 (parameter 1.001 of 3) was measured from the
end, and (0,0) (0,0) (10,0) (20,0) picked at x = 7 (1.7 of 3) from the
start. LWPOLYLINEs and 3D polylines now take the parameter from their
source vertices (curves::vertex_param_of). Pointed out in review.
Ellipses keep the parameter rule, which AutoCAD follows for them too:
a full ellipse picked at t = pi and an elliptical arc picked past its
middle both run from the end in AutoCAD 2024 (MEASURE-032 and -033 of the
measured set; the other direction is 200 and 4 units off). The new test
pins both, within the 1e-4 tessellation CADCraft measures along.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
