A damaged DWG opens partially since #859 and the drawing's read notes
say how many object records were left out. OPEN echoes them and MCP
`open` returns them as `warnings`, but `cadcraft-cli info` and
`convert` stayed silent: a corpus round trip wrote thousands of skipped
records away without a word.
- convert: each read note goes to stderr as `IN: <note>`, next to the
skipped-records warning (#872). The exit code stays 0.
- drawing.inspect (and so info, MCP inspect_drawing and the control
channel): new field `readNotes`, next to `skipped`. Existing fields
are unchanged.
- run already prints OPEN's notes with the session log.
- README and docs/control-protocol.md say where the notes appear.
Part of #1039.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* render: a display list past the block-expansion budget says what it left out
* Report viewport truncation only after the expansion budget is exceeded
* fmt: keep ui-egui control.rs rustfmt-clean
Found while testing crates/io/src/dxf_write.rs:1964-1970 (xrecords written) and crates/io/src/dxf_read.rs:2049-2052 (apply)
Co-authored-by: Claude Haiku 5.5 <noreply@anthropic.com>
* DWG: scale actions keep the byte AutoCAD reads after their connections (acadrust 0.6.5)
AutoCAD's DWG scale action (BLOCKSCALEACTION) ends with one byte after its
three connections that DXF doesn't carry. acadrust 0.6.4 neither read nor
wrote it, so AutoCAD read past the object and refused every DWG CADCraft
wrote with a dynamic block that scales ("Error Decrypting Data"), even an
unchanged one. acadrust 0.6.5 keeps the byte (dwg_tail_byte).
0.6.5 also maps the dimension flags byte's bit 0 to text_user_positioned
both ways, so the bridge no longer inverts it (it would now double-invert);
it still sets bit 1, which acadrust keeps no DXF source for.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DWG: acadrust 0.6.6; multi-layout DWGs get unique paper space names
0.6.6 keeps the scale action byte and the dimension flag mapping this branch
relies on, and writes only the active layout as *Paper_Space (others get
unique *Paper_SpaceN names; hakanaktt/acadrust#143), so ACadSharp opens a
DWG CADCraft saves with more than one layout.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* io tests: a scale action survives CADCraft's own DWG save
The cadcraft-dwg test builds its DXF with acadrust's writer; this one goes
through cadcraft_io::write (the bridge DXF, then acadrust) with a scale
action added to the synthetic Door fixture, and checks the DWG holds it
with its connections and reads back as the same action.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* ui: block description field ids from Ui::scope_id (egui 0.37 deprecates Ui::id)
main's gate fails clippy -D warnings on the one Ui::id() call (#2113);
Ui::scope_id is its new name.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DWG: the scale action byte doc names acadrust 0.6.6, the version in use
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Docs: leave the parity docs to the maintainers (AGENTS.md: PRs don't edit them)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Cody Vogt <18035288+codyvogt@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A DIMENSION moved by an older AutoCAD keeps its *D block contents where
they were and the move in DXF group 12, and is drawn translated by the
insertion point. Group 12 was never read into Dimension, so the block
rendered at its pre-move position and the extents reached there too.
Read group 12 into a new Dimension::insertion_point, draw the block
translated by it, move its bounds with it in the extents, test the
block's text where it draws, and write group 12 back whenever the block
written is the one read from the file. Regenerated geometry (edits drop
the block link) sits at its definition points, so no offset is kept or
written for it.
Co-authored-by: rahul05ranjan <11793455+rahul05ranjan@users.noreply.github.com>
* OVERKILL: objects within the tolerance are duplicates wherever their numbers fall
OVERKILL compared objects by rounding every number to a multiple of the
tolerance. Two numbers closer than the tolerance on either side of a
rounding step round apart, so the objects were kept: at 0.01, circles at
x = 80.001 and 80.003 were merged but circles at 50.004 and 50.006 were
not. Arcs on one circle were bucketed the same way.
Duplicates are now found by shape (the JSON without its floating-point
numbers; counts and flags must match exactly) and a weighted sum of the
numbers on a grid of the tolerance, looking in the neighbouring cells too,
then compared pairwise to within the tolerance. Arcs and circles look in
the neighbouring cells of centre and radius and are grouped with a
union-find. Lines were already grouped by sorting and are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* OVERKILL: within the tolerance doesn't chain
Arcs and circles were grouped with a union-find over pairwise matches,
so A ~ B and B ~ C put A and C in one group even when A and C are
farther apart than the tolerance: a circle C was deleted for matching
only the arc between it and the kept circle A, and arcs were combined
across the chain. Each object now joins the first group whose every
member is within the tolerance of it, or starts its own.
In the duplicates pass, a followed object displaced an earlier keeper
that later objects had already matched, leaving them deleted up to twice
the tolerance from what stays. Followed objects are now looked at first,
so every deletion is within the tolerance of an object that stays.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Tyler Chiriboga <18270301+Tyler-Chiriboga@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* i18n(pt-BR): translate the rows the sibling catalogs cover
The Brazilian Portuguese catalog covered the reference catalog and every marked UI literal, but 191
strings that the German, French, Swedish and Ukrainian catalogs already translate still fell back to
English: the Hatch and Gradient dialog, the Block Editor and dynamic-block grips, the plot and drawing
units dialogs, multileader editing, selection preview settings and the unit names.
Rows follow the catalog's vocabulary (dimension = cota, hatch = hachura, grip = pinça, layout =
apresentação, multileader = multilinha, xref = referência externa), keep the prompt keywords, SPDX
tokens and technology names in English, and are appended after the existing entries.
* docs: leave localization parity updates to maintainers
* feat(inquiry): AREA, PERIMETER and DISTANCE system variables, as AutoCAD sets them
AREA, DIST and MEASUREGEOM now leave AREA, PERIMETER and DISTANCE for
getvar, read-only and not saved: the area just measured (the running
total in Add and Subtract mode) with the last area's perimeter, and the
distance (the total of Multiple points). After DIST's two points
LASTPOINT stays at the first point, as measured. AREA's Object option
measures splines, closed by their chord like open polylines.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Address review: spline area over narrow spans, finite distances, list order
- AREA of a spline samples it span by span (Spline::tessellate_spans), so
a narrow knot span no longer drops out of the area. The spread over the
spans is one helper shared with Spline::bounds, whose boxes are
unchanged.
- DIST refuses a distance that isn't finite on all three paths and leaves
DISTANCE as it was.
- sysvars::list puts the session's values after the drawing's header, so
it shows what get returns (AREA, ORTHOMODE, LWDISPLAY...).
- LASTPOINT after DIST's Multiple points is pinned to AutoCAD 2024's
measured behaviour: the last point entered, also after Length and Undo.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Address review: measure every knot span of a spline in AREA
A spline with more knot spans than half the sample cap fell back to an
even grid over the domain, which can step over a narrow span and measure
the wrong area: a 100 x 100 square as a degree-1 spline, its right and
top edges two spans a millionth wide after 4,500 spans along the bottom,
measured 4,998.75.
Spread the samples over the spans at any span count: at least one
segment per span, within the cap up to MAX_SAMPLES spans and one each
past it, as Spline::length integrates every span. One evaluation per
span costs 85-285 ms on a million spans in a release build, against
32-52 s for the length AREA already takes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Address review: share AREA's spline samples by how much each span bends
Past the sample cap, tessellate_spans gave each knot span one segment, so
a bent span among many straight ones was measured by its chord. Example:
a quadratic spline along the x-axis, one control point 1000 above it,
past 4,500 spans. It measured 750; the area is 1750/3.
Each span now keeps one segment. A span whose control points are
collinear is straight, so its chord is exact. tessellate's count is
shared among the spans that bend, by the cube root of a measure of their
control points' convex hull, which holds the span and its chord. The
shares are rounded on the running total, so they use the whole count
however many spans share it. The example now measures 583.33343, below
the cap and past it.
The spreading by parameter width that this replaces goes, and
span_params with it: bounds is main's code again.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DIST: a measurement refused as too large leaves LASTPOINT at the first point
Session::feed sets LASTPOINT to the second point before DIST checks the
distance, and the refusal returned before DIST put the first point back,
as it does after a measurement. It now does so before refusing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* AREA: a spline too long to measure is too large, not a perimeter of 0
Spline::length reads a length past f64's range as 0, and AREA took that
as the spline's perimeter. Spline::checked_length returns None there,
and AREA reports the perimeter too large, as it does a polyline's.
The overflow was hidden twice: in the sum, and before it in the
derivative, which read as zero speed once past f64's range. The length
integral now takes the derivative before that (Spline::velocity), so an
overflowing speed counts too. param_at_length keeps the speed it had,
and finite lengths are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Say "or" once in prompts that offer options
Twelve prompt messages ended in "or", and the command line adds "or"
before a prompt's options, so they read "or or": HELIX height, XLINE angle
and offset, BLEND, four LENGTHEN prompts, two NCOPY prompts, PEDIT and
table breaks. They now read as AutoCAD's do.
The interface catalogs are keyed by these messages: each key loses its
"or" and each translation its trailing word for "or"; where the shorter
key already had a translation, the longer row is removed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Say "or" once in HELIX's radius prompts; rename the Vietnamese keys
HELIX's base and top radius prompts ended in "or" before their Diameter
option too, so they read "Specify base radius or or [Diameter]". They
now read "Specify base radius or [Diameter] <1.0000>:", and their keys
lose "or" in all 17 catalogs, as the other twelve did.
The Vietnamese catalog, merged from main, gets the same renames as the
other catalogs; where the shorter key already had a translation, the
longer row goes. The unused "Specify rotation angle or" row goes from
every catalog too: RECTANG has asked "Specify rotation angle" since
#2554.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Write option prompts without "or", as AutoCAD does
AutoCAD writes " or [" only when a prompt asks for something besides its keywords ("Enter block
name or [?]"); a prompt asking for one of them has none ("Enter an option [...]", "Enter layout
option [...]", "New color [Truecolor/COlorbook]"). The 27 messages read without "or" from
AutoCAD 2024's command line are listed in NO_OR and displayed that way.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Address review: the window's command line drops "or" as the prompt does
The command line in the window draws a prompt's keywords itself and
wrote " or [" after every message, so -LAYER still read "Enter an option
or [?/Make/...]" there, and questions such as AUDIT's had "or" too. Only
the prompt text (the control channel, the state JSON, the tests) had
dropped it.
Prompt::keyword_lead gives what goes before the keywords; display() and
the command line both use it, and the command line translates only
" or [". A render test reads what the command line draws, in English and
German, for -LAYER, LINE and AUDIT. Suggested in review.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The interactive save only knew about DWG, so overwriting a 2013+ DXF lost SAT-text
solids on a command-line note. loss_on_save now lists them, and EXPORT reports them
with the DXF wording.
The Chinese catalog lacked 74 interface strings: the block editor
prompts and dialog, the alias editor sentences, the selection visual
effects and preview filter, units of new drawings, and the menu names
Dimension, Draw, Modify and View.
Adds them in the catalog's TSV format with the AutoCAD zh-CN vocabulary
the catalog already uses (夹点, 图案填充, 外部参照, 多行文字, 孤岛).
After this the report lists nothing missing for zh.
Co-authored-by: rahul05ranjan <11793455+rahul05ranjan@users.noreply.github.com>
`double_clicked_text_takes_ime_composition_and_commit` commits 中文 at the
command line. Without a CJK font (no CRAFT_FONTS_DIR, none installed, as on
a plain Linux CI image) the kittest harness panics on the first missing
glyph: "No glyph for 中 in Proportional". Code and tests must work without
craft-fonts.
The test now asks the harness's own fonts whether they can draw 中文 and,
only when they can't, lets the command line draw boxes for it. The IME
path it checks is unchanged: the pre-edit is shown and not saved, the
commit is inserted once, Enter stores 中文 in the text. With a CJK font
the harness still fails on any missing glyph.
Co-authored-by: Tyler Chiriboga <18270301+Tyler-Chiriboga@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* plot and exportpdf help name the `device` parameter (#2557)
`cadcraft-cli commands plot` didn't list `device`, so the only way to find it was the `unknown plotter` error.
PLOT's help now lists `device` with the built-in devices (CADCraft PDF, PNG, SVG), PLOTTERMANAGER plotters and "None". It also says the default is the page setup's device and that the device picks the output format and the papers. EXPORTPDF's help names `device` too, and notes that its output stays PDF. A test checks that both help texts name `device` and that PLOT's names every built-in device.
* plot help: say what Model, "None" and an omitted paper do
In model space, and with "None", no device is used and the plot is a PDF. When `paper` is omitted, a layout keeps its page setup's paper and model space takes the device's default.
* Dynamic blocks: a point on a frame edge of any length is on it
The frame edge test used Line::dist, which takes a segment shorter than
EPS (1e-9) for its first point: a point halfway along a frame edge that
short was neither on the edge nor, by the even-odd test, inside, so its
line moved whole instead of stretching. The distance to an edge is now
the exact one, clamped to the segment.
Tests also cover two rules from #2627 that had none: a point on an
edge's line but past its end is outside the frame, and a polyline
tilted by only 5e-10 (about a unit off at an elevation of 2e9) keeps its
stored vertex list.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Dynamic blocks: measure a frame edge's residual from its start
segment_dist added the projection back to the edge's start before
measuring, so near x = 36 the residual was rounded to that magnitude's
spacing (7e-15). A point 1.4e-15 off an edge 5e-10 long, outside the
frame, then came out 4e-20 away, within the edge's 5e-19 tolerance, and
was taken as on it. The residual is now measured from the edge's start,
where those digits are kept.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
SVG 1.1 §7.5 lets every graphics element carry a transform. Only groups'
transforms were applied, so a rect, circle, path or other shape with its
own transform came in where it would be without one. on_element now
composes the element's transform after its groups' for that element
only, the way a group around it would.
https://www.w3.org/TR/SVG11/coords.html#TransformAttribute
Co-authored-by: ashokram-si <347905169+ashokram-si@users.noreply.github.com>
Found while testing crates/engine/src/cmd/array.rs:380 (run_arraypolar, `fill: f64_or(p, "angle", 360.0)`)
Co-authored-by: Claude Haiku 5.5 <noreply@anthropic.com>
* Remember the main window's size, position and maximized state between sessions (#2595)
The main window opened at its default size, centred, on every launch: eframe's window
persistence was turned off (persist_window: false), and `centered` is applied over any saved
position. The window state is now saved; on launch, if app.ron holds a saved window, it is
restored (eframe keeps it on the connected monitors) and not centred. Only the first launch,
with nothing saved, opens centred (#1129). Wayland places windows itself, so only size and
maximized state return there.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Docs: leave the parity docs to the maintainers
The affected rows are named in the PR description instead (CLAUDE.md: PRs do not edit the parity docs).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Ethan Dale <ethandale@Ethans-MacBook-Pro.local>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* fix(fonts): single-line TEXT runs left to right, as AutoCAD lays it out (#2500)
A TEXT "- פרוייקט" took its direction from its first strong character
(Hebrew), so the leading dash went to the right of the word; AutoCAD
shows it on the left. complex::shape now takes the base direction
(shape_stroke_dir, ttf::shape_dir and shape_line_dir pass it on), and
TEXT's layout (fonts::place and its frame) asks for left to right.
MTEXT and the existing entry points keep taking the direction from the
text.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(fonts): a right-to-left base reaches LTR-only lines; Fit TEXT is measured as placed
From the review of #2618: shape_stroke_dir and ttf::shape_dir took the
simple, left-to-right path whenever a line had no right-to-left letter,
so an explicit right-to-left base did nothing there; such a line now
takes the bidi path. And Fit/Aligned TEXT was measured with the
direction from its content but placed left to right, so a line whose
last glyph changed (a stroke-font gap) missed its second point; it is
measured with the direction it is placed in.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: austin62jake <340374338+austin62jake@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* DWG save keeps OLE objects (OLE2FRAME): stop reporting them as not saved
acadrust reads OLE2FRAME from our DXF into its own entity and writes it to
DWG of every version we save, frame and embedded data unchanged; only the
"Not saved in the DWG file" warning (and the QSAVE loss prompt) listed it.
not_saved_as now skips the types the DWG bridge writes (DWG_WRITES).
Tests: a synthetic OLE2FRAME through DWG (resaved, and as 2000 and 2010
DWG) keeps every byte; OLE objects are not reported at any version.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DWG_WRITES matches the type as stored, not case-insensitively
The DXF given to the DWG bridge carries an unknown entity's type as stored, and
acadrust reads only "OLE2FRAME" into its OLE entity: any other spelling becomes
its Unknown and is dropped, so it must stay in the "Not saved" report. The test
adds a lower-case "ole2frame" that is still listed. (Review comment on #2582.)
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* fix(io): read drawings with many groups in linear time (#862)
Drawings can carry hundreds of thousands of empty anonymous groups
(*A1, *A2, ...). Two places in the DXF reader were quadratic in their
number:
- apply_groups looked up each group by name with a linear search; it now
uses an index keyed by the lower-case name, so the case-insensitive
merge (the later definition wins) is unchanged.
- retained_objects called is_xdict(parent) for every object before
consulting its cache; for a group the parent is the ACAD_GROUP
dictionary, which head() walks completely. is_xdict is now memoized
per object index.
Two drawings with 179,124 and 124,362 empty groups go from 388 s and
165 s (DWG to PDF) to 7.3 s and 8.0 s, with byte-identical output.
* test(io): check that reading groups scales linearly (#862)
The content test passes on the quadratic code as well, so add a scaling
check: 16 times the groups (2,500 vs 40,000, best of three reads each)
must take less than 64 times as long. With both fixes the ratio is
about 21; without the name index it is about 218, without the is_xdict
cache about 180. No wall-clock limit is involved.
Also document apply_groups.
---------
Co-authored-by: Walter Haslbeck <8794773+whaslbeck@users.noreply.github.com>
Quit CADCraft in the app menu, the Dock's Quit and logout end the app through AppKit's
terminate, which skipped the "Save changes to ...?" prompt, so unsaved work was lost. The
event loop now turns termination into a close request for the window (the storytold winit
fork's opt-in, as DesignCraft does), so it asks first, as the close button does. Cancel keeps
the app open; Force Quit can't be intercepted.
Co-authored-by: Ethan Dale <ethandale@Ethans-MacBook-Pro.local>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A layout without a paper-space viewport (id 1) gets one on save, sized
by the page alone; a custom plot scale (142/143) wasn't applied, so an
A3 layout at 49.6 mm per unit got a 420 x 297 viewport around its
8.4 x 6 unit sheet, and its extents went wrong. paper_view divides the
sheet by the layout's plot scale; a layout scaled to fit, at 1:1 or with
an unusable scale writes what it did.
Co-authored-by: austin62jake <340374338+austin62jake@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Every LAYOUT was written with limits 0,0 to 12,9 (AcDbLayout groups
10/11) and paper image origin 0,0 (groups 148/149), whatever the file
had, so another program drew the sheet elsewhere and a Layout plot came
out shifted. Layout::limits and PageSetup::image_origin keep what the
file had (finite, within 1e12) and a save writes it back; a layout
without them writes the old defaults, which read back as none.
Co-authored-by: austin62jake <340374338+austin62jake@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* test(io): a ByBlock plot style (group 380 = 1) survives a DXF round trip (#2242)
Red: the writer leaves group 380 out and the reader maps it to ByLayer.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* fix(io): a ByBlock plot style is group 380 = 1, written and read (#2242)
The writer only knew named styles (group 390) and left ByBlock out like ByLayer; the reader
mapped a record without 390 to ByLayer. Both now use the plot style name type.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
* fix(io): a viewport looks at its view target plus its centre (#2492)
A DXF stores a view's centre in display coordinates, whose origin is the
view target (DXF Reference: VIEWPORT 12/22 and 17/27/37, VPORT 12/22 and
17/27/37, VIEW 10/20 and 12/22/32). The readers took the centre alone, so
a file that keeps the location in the target with a centre of 0,0 (as
ArchiCAD's AutoCAD 2018 export does) showed model point 0,0 in every
layout viewport, on screen and when plotted.
The VIEWPORT entity, VPORT tiles and named views now read the target plus
the centre. A sum that overflows keeps the stored centre. The writers
already store the whole location as the centre with a target of 0, so a
save and reopen keeps the view, through DXF and DWG.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* test(io): a viewport looking along another direction centres on its target
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: austin62jake <340374338+austin62jake@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* fix(engine): WBLOCK writes only what the block or selection uses (#2423)
WBLOCK of a block, or of selected objects, copied the source drawing's
whole layer, linetype, style and block tables into the new file, so a
5-object symbol carried 40 unused layers and 20 blocks. The written
drawing is now purged of what nothing in it uses, as AutoCAD's WBLOCK
writes it: purge::purge_unused runs PURGE All's scan on a plain Drawing
until a pass removes nothing (a block can free its layer), keeping the
defaults and the current ones. Writing the entire drawing is unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(engine): PURGE's scan counts leaders' dimension styles and styles used by other styles
From the review of #2621: PURGE (and now WBLOCK, which runs its scan)
took as unused a dimension style only a LEADER used, a linetype only a
dimension style or a dimension's override named (DIMLTYPE, DIMLTEX1,
DIMLTEX2), and a text style only a complex linetype's text used, and
removed them while the objects still named them. The scan counts all
three now; text_styles_in_use, which STYLE's delete also asks, includes
complex linetypes' text styles.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(engine): PURGE's scan counts multiline styles' linetypes and table styles' text styles
From the review of #2621: a linetype only a multiline style's element
used, and a text style only a table style's cell style used, were taken
as unused and purged while the styles still named them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: austin62jake <340374338+austin62jake@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Dynamic blocks: stretch the points inside the frame, as AutoCAD does
A dynamic block made by a third-party tool came out distorted when a
distance changed: its stretch action has distance multiplier 0 with
angle offset 1, and stored vertex lists that don't match its objects.
apply turned the 0 into 1 but kept the angle (a 57 degree slant), and
moved exactly the listed points.
AutoCAD 2024, on a copy of that drawing, moved the block straight along
the parameter, and every point of its lines and polylines exactly when
it was inside the frame, whatever the lists said. So:
- a zero multiplier moves as 1, without its angle offset;
- a line's or lightweight polyline's moving points are those inside
the frame where the dynamic block has them; a selected one wholly
outside the frame moves whole, as in AutoCAD's own stretched copies;
- a frame of fewer than 2 or more than 1,000 points keeps the stored
lists, so a huge frame can't make every point test every edge.
Against AutoCAD's own anonymous copies in two library drawings (556
references set back to their block's distances), 249 come back exactly
on main and 258 with this change; none stops matching.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Dynamic blocks: a point on a polygon frame's edge is inside it
in_frame counted a point on a two-corner frame's edge as inside, but
the even-odd test of a polygon frame put one on its right edge outside.
A line whose end lay there, with its other end outside, then had no
point inside the frame and moved whole instead of its end alone.
A polygon frame now counts a point on an edge (within 1e-9, relative
to the edge's length) as inside too, as the two-corner frame does.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Dynamic blocks: frame edge tolerance by the edge's length; tilted polylines keep their lists
A point counted as on a polygon frame's edge within 1e-9 * (1 + the
edge's length), so never less than 1e-9 drawing units: in a tiny frame,
a point visibly outside was taken as inside. The tolerance is now a
billionth of the edge's length.
A lightweight polyline's vertices are in its own plane. The reader
flips a mirrored one (extrusion along -z) into the block's plane, but
leaves a tilted one's in its OCS, which the frame (block coordinates)
can't be tested against. A tilted polyline keeps the stored vertex
list, as before the frame test.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* dynblock: only an exactly untilted polyline is tested against the frame; a tilted one keeps its stored list
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fmt
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* feat(engine): INSERT of a drawing file keeps an attribute definition's field
The attribute definitions of a drawing file read by INSERT name=file lost their
extension dictionary, so the ACAD_FIELD dictionary and the FIELD objects of an attribute
whose value is a field (the file name in a title block) were gone from the block.
adopt() now copies that object tree to the drawing under new handles, with the FIELD
class and a field list if the drawing has none.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* foreign: index the kept objects once when walking and copying a dictionary tree
A file can keep many objects; a linear lookup per pointer grew with their product.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: andrewbrake <6925387+andrewbrake@users.noreply.github.com>
Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* OOPS brings back what -WBLOCK erased
-WBLOCK erases the objects it writes, and OOPS brings back what the
last ERASE or BLOCK removed; the two landed separately, so OOPS never
saw what -WBLOCK erased. -WBLOCK now erases through erase_kept, as ERASE
and BLOCK do.
As AutoCAD 2024 does (accoreconsole, the drawing's entnext order read
back): OOPS after -WBLOCK brings its objects back, each where it was and
with its handle; only the last erase counts, -WBLOCK's or ERASE's; and
-WBLOCK * erases nothing, so OOPS still brings back the erase before it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* OOPS: keep the last erase through a refused REFEDIT command; Block Editor
During REFEDIT, a command that removes an object outside the working set
is undone (refedit::after_command), but erase_kept had already replaced
what OOPS kept: the objects came back, and the erase before them was
lost. erase_kept now leaves OOPS as it was when an object it removes is
outside the working set. That covers BLOCK, -WBLOCK, ERASE and the
Delete key.
In the Block Editor, its objects keep the handles they have in the block
definition, so in_blocks found them there and OOPS brought back nothing
erased in the editor. in_blocks now skips the block open there.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Polyface meshes stay one object through DXF and DWG
A polyface mesh (POLYLINE flag 64) was read as loose 3D faces. It is now
read, drawn, exploded into its 3D faces and written back as a POLYLINE.
Hidden edges aren't drawn. A mesh too large for the 16-bit groups 71-74
is saved as 3D faces.
Split from #1005.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* A polyface face ends at its first zero index
A face record with a gap ([1, 2, 0, 3]) has two corners and is dropped,
not read as a triangle.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Polyface meshes: write only faces that name their vertices; ID gives their Z
The writer drops the faces the reader would drop, so no record names a
missing vertex, and the 16-bit check only needs the counts. ID and DIST
give a mesh the Z of its nearest visible edge, as they do for 3D faces.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
There was no OOPS. It now brings back what the last ERASE removed (the
Delete key too), or BLOCK deleting the objects it makes a block of, as
AutoCAD 2024 does (accoreconsole, the drawing's entnext order read
back):
- Each object keeps its handle and goes back directly above the object
that was under it, or under the one that was above it when that is
gone. An erase records both neighbours (EntityStore::neighbours).
- Only the last erase counts; entdel doesn't. OOPS says nothing and is
one undo step.
- An object stays out when it is already in the drawing, when an undo
took the drawing back to before it was made, when its layer, block or
layout is gone, and, during REFEDIT, when it isn't in the working set.
REFCLOSE forgets the working copies; the Block Editor has an OOPS of
its own.
- The command's label is in the 17 interface catalogs.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* Plot: a layout's saved page setup is used by default (#2493)
A layout whose page setup says plot window, scale to fit or a plot scale was plotted 1:1 from
the sheet origin unless the caller passed fit. plot, exportpdf, the PNG device and preview now
read the layout's saved window, scale to fit, scale and centring when the options don't say
(render::paper::saved_plot); explicit options win, and fit: false without a scale is still the
plain 1:1 sheet. Tests: saved_setup_tests in pdf.rs (four), and
preview_uses_the_layouts_saved_page_setup_by_default.
* Parity checklist: regenerated after merging main
* Parity checklist: regenerated after merging main
* Plot: saved page setup in preview and PNG matches the PDF (review on #2586)
Preview honours the saved centre when fitting a window and an explicit scale beats a saved scale to fit (PDF too); PNG places a saved window without fit and clips to the printable area.
* Preview: a saved window clips to the printable area (review on #2586)
The preview drew the placed plot over the margins while the PDF and PNG blank them. The blanking helper now lives in the render crate and both the PNG plot and the preview use it. Test: preview_clips_a_saved_window_to_the_printable_area.
* Preview: pin hostile saved page setups and the default setup (review on #2586)
Degenerate or far-away saved windows and saved scales of 0 or not finite already fall back to the plain plot in the PDF, PNG and preview; tests now pin that, and that a layout with no saved setup plots as before.
* Preview: the printable clip follows the view's fit (review on #2586)
The clip assumed the sheet filled the image; when the height cap applies
View::fit scales and centres it. The printable corners now go through
View::to_screen. Test: preview_clip_follows_the_view_when_the_height_cap_applies.
* docs: leave the generated parity checklist to maintainers
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Brandon Thomas <echelon@gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* DXF: link dimension sources to their associations (#2221)
Source objects lacked the persistent reactor back to their DIMASSOC.
Register validated source and intersection references once through the existing
reactor list, keeping a self-link from duplicating the dimension's own reactor.
Synthetic regressions cover missing links, repeated references and self-links.
* Parity checklist: regenerated for dimension reactor gate
* Parity checklist: regenerated after merging main
* DXF: a dimension source keeps its other reactors next to the DIMASSOC (review on #2589)
The DIMASSOC reactor made the writer emit an ACAD_REACTORS group, so the raw
passthrough skipped the source's retained foreign reactors. They are now merged,
deduplicated, into that one group. Test: a line reactor-linked to a kept object keeps
both links after an associative dimension is added.
* DXF: an unmodelled DIMASSOC source gets the DIMASSOC reactor (review on #2589)
Unknown entities are written by the raw passthrough, which never saw the planned
reactors. The map is now passed to dxf_raw::finish and merged into the entity's
reactor group. Test: an unknown entity with a dimension snapped to it names the DIMASSOC.
* Docs: leave the file-format parity document to maintainers (review on #2589)
* DXF: pass the unknown-entity reactors as one argument (review on #2589)
* DXF: collapse the extension dictionary condition (review on #2589)
* Test: pin the reactor merge for dimension sources (review on #2589)
* DXF: a kept extension dictionary follows the reactors group (review on #2589)
When a written record already had its reactors group, the kept extension dictionary was
inserted right after the handle, ahead of it; the DXF reference puts the reactors first.
The reactor tests now find each group by name, so either order can no longer pass.
* docs: leave the generated parity checklist to maintainers
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Brandon Thomas <echelon@gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Hit tests don't lay out dashes: moving the mouse over a block stays smooth (#1285)
Every mouse move hit-tests the block references under the cursor, and
hit_polylines built them with a full-detail display list, one primitive per
dash. A fine pattern on long lines in a block inserted at 0.001 made millions
of dashes per move.
Options::linetypes off draws every line whole and continuous, and
hit_polylines uses it for blocks, dimensions and multileaders. A dashed line in
a block is now hit across its gaps, as one outside a block already was.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* render: with linetypes off, a lightweight polyline is one continuous stroke
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Steffen <camperking@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
* Persist QuickCalc history, variables and last answer
Store bounded calculator data in app preferences for desktop and web. Restore finite numeric and point variables, normalize names and ignore malformed entries without resuming transient drawing input.
Covers gaps F22. Validation: 3079 workspace tests passed; wasm, fmt, assets, layers and i18n passed; UI screenshot inspected. Strict CI remains blocked by pre-existing nonminimal_bool lints in DXF and UI code; scoped UI Clippy passes with only that lint disabled.
* quickcalc: apply the variable limit after validation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Brandon Thomas <echelon@gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* DXF: escape carets in TEXT, ATTDEF, ATTRIB and DIMENSION strings
AutoCAD reads `^x` in a DXF string as a control character, so a TEXT of
`10^2` opened in AutoCAD showed a control character instead of the caret.
The DXF Reference writes a caret as `^` and a space: the writer now does
for the text (group 1) of TEXT, ATTRIB, ATTDEF and DIMENSION and an
ATTDEF's prompt (group 3), and the reader turns it back. A bare `^x` from
older files stays as it is; single-line strings keep `^J` literal (they
hold no line feeds). AutoLISP's entget shows the plain caret, and a
DIMENSION's style name (also group 3) is left as written.
Tests: crates/io/tests/it/text_carets_roundtrip.rs.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* entget gives TEXT strings as the file has them, like MTEXT
Decoding the carets in entity_groups broke entmod (it reads the groups
as a file, so `A^ B` came back as `A^B`) and reached into an ATTDEF's
embedded MTEXT. entity_groups is left as on main: it gives the file's
groups, as it already does for MTEXT, and entmod reads them back
unchanged (test entmod_of_entget_keeps_the_strings).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* entget unescapes carets, entmake and entmod escape them
e61b4dd left entget with the file's escapes, but entmake still read a
plain `p^ q` as `p^q`. Now one rule, map_carets, picks the groups that
hold an escaped string (the text, 1, and an ATTDEF's prompt, 3, up to an
embedded MTEXT at group 101): entity_groups unescapes them and
entity_from_groups escapes them before reading, so entget is plain,
entmake takes plain strings and entmod of entget changes nothing.
Tests: entget_shows_plain_carets_and_entmake_takes_them,
entmod_leaves_the_embedded_text_alone.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Leave the parity docs to the maintainers
CLAUDE.md: PRs don't edit the parity docs; the affected rows are named in
the PR description instead.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Single-line strings read like MTEXT: a tab from AutoCAD survives
AutoCAD writes a tab in a TEXT as `^I`. The reader left it as two
characters and the writer then saved `^ I`, so the tab was lost. Single-line
strings are now read with decode_contents, as MTEXT is (`^ `, `^I`, `^J`;
other bare carets stay), and encode_line writes a caret as `^ ` and a tab
as `^I`. unescape_carets is gone.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Rename map_carets to map_text_groups (it encodes tabs too)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Single-line strings keep a bare ^J; entity_from_groups doc
A TEXT holding `A^JB` (from a file saved before this change, which wrote
carets bare) was read as a line feed and saved as `A B`. Single-line
strings now decode only `^ ` and `^I` (decode_line, decode_contents
without line feeds), so `^J` stays two characters. entity_from_groups
documents that it takes plain strings, as entity_groups gives them.
The caret test also goes through a DWG.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Test a caret before a space and at the end of a TEXT
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
