Commit graph cad-editor/tests
Author SHA1 Message Date
Karim Jerbi
5299a483da fix(hatch): flag only the outer ring as external when serializing holes
When writing a hatched region with holes to DXF/DWG, every NaN-separated ring was created with BoundaryPath::external(), so consumers treated inner loops as outer islands instead of holes. Only the first (outer) ring should carry the external / outermost flags; hole rings are left unflagged. A picked big-minus-small hatch now persists with the small rectangle as a real hole.

Adds a regression test asserting only the first boundary path is flagged external.
2026-07-13 05:55:54 +01:00
Hakan Seven
8b133ceab2 fix(layout): create the CTAB variable so the exact paper tab round-trips
Saving from a non-first paper layout still reopened on the first paper
tab: set_saved_active_layout only updated an existing CTAB entry, but
documents authored here never carried one, so CTAB was never written and
the reader fell back to $TILEMODE (which only records model-vs-paper) →
the first paper layout.

set_saved_active_layout now creates the CTAB DICTIONARYVAR under the root
named-object dictionary when it is absent (updating in place otherwise).
The root dictionary is taken from the header handle, or found by scanning
for the dictionary that holds ACAD_LAYOUT when a from-scratch document
has not populated the header handle yet. The writers persist it (they
serialize the document's objects and root-dictionary entries; the
root-dict rebuild in CadDocument::build() is not run on save).

Adds tests/active_space_roundtrip.rs, including a full DXF save→reload
round-trip asserting both $TILEMODE and CTAB survive.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-12 01:17:26 +03:00
Hakan Seven
553b91015f fix(precision): keep BLOCK base and TEXT/MTEXT insertion points in f64 (#311)
Three commit helpers narrowed a typed/picked point back to f32 before it
reached the persisted entity, so the coordinate was quantized to the f32
grid (worse at large/UTM extents):

- Scene::create_block_from_entities took the base point as glam::Vec3, so
  the block's local-space translation and the replacement INSERT's
  insert point were f32. Param is now DVec3 (matching the sibling
  define_block_from_owned_entities); the command_driver handler no longer
  downcasts with as_vec3().
- The MTEXT and TEXT in-place editors stored `pos` as Vec3 and built the
  committed insertion_point from it, quantizing a new label's position
  and re-quantizing an existing one on edit. Both `pos` fields are now
  DVec3.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-12 00:34:26 +03:00
Hakan Seven
1f89b78a7e fix(precision): keep typed hatch boundaries exact in f64 (#311)
The HATCH/GRADIENT/BOUNDARY commands built the persisted hatch through
the render-side boundary (f32 offsets from world_origin), and with a
zero world_origin that meant absolute f32 - so a typed boundary vertex
of 2000.8 was stored as 2000.8020, and at UTM scale the fill landed far
from its boundary.

HatchModel.boundary stays f32 (the GPU render contract). Added
HatchModel.boundary_wcs: Option<Arc<Vec<[f64;2]>>>, an exact absolute-WCS
boundary set only by the draw commands. Scene::add_hatch persists from
boundary_wcs when present (exact f64 -> DxfHatch), else falls back to the
f32 + world_origin reconstruction used by DXF-rebuilt hatches. manual_pts
is now Vec<DVec3>; make_hatch takes the f64 boundary, stores the exact
copy and derives the RTE render rep. The committed render model is
rebuilt from the DXF entity, so nothing renders the command model's f32
boundary. This also fixes command hatches mis-placing at large
coordinates (world_origin was [0,0]).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-11 21:55:10 +03:00
Hakan Seven
0964e97cfa fix(text): keep inline \C colours through block colour inheritance (SDF)
Ports PR #301 (by Kevin Griffin) to the SDF text renderer. Block-nested MTEXT
with inline colour codes (\C1;, \c…) collapsed to a single colour: the block
cache applies ByBlock / layer-0 colour inheritance per entity, so at emit time
every segment's colour was replaced with the inherited colour — including
segments carrying an explicit inline override.

- block_cache tessellate_sub_local: gate ByBlock / layer-0 colour inheritance
  on `wire_on_base_color` (a wire whose colour differs from the entity base
  carries an explicit override and keeps it) — #301's fix, still correct for
  the remaining stroke wires.
- block_cache emit_wire: the per-vertex analogue for SDF text — a glyph whose
  colour equals the wire's base inherits the resolved colour; a glyph with an
  inline \C / \c override keeps it. (Previously every block glyph was recoloured
  with final_color, collapsing colour-split MTEXT.)
- tests/text_font_rendering.rs: restore the block colour-split regression test
  (it had stopped compiling on main when expand_insert gained the InheritStyle
  param) and adapt it — and drawable_point_count — to SDF text_verts, since
  block MTEXT now renders as glyph quads, not colour-split stroke wires.

\C (ACI) / \c (true-colour) are parsed by acadrust (mtext_format
SpanProperties.color) → OCS InlineColor → the glyph's per-vertex colour.

Co-Authored-By: Kevin Griffin <117586586+KevinGriffin-new@users.noreply.github.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 22:17:27 +03:00
Hakan Seven
cb41910f12 fix: address review findings on merged #293/#292 hatch+snap
Three defects found reviewing the just-merged PRs:

- PLOTWINDOW forced corner snap (#293) only ran in the on_tick preview
  path, so the marker highlighted an endpoint but the click committed a
  plain snap — with the global OSNAP master (or Endpoint mode) off the
  corner landed at the raw cursor, defeating the feature. Apply the same
  snap_forced_corners branch at the click-commit recompute.

- build_dxf_pattern (#292) wrote the pattern line's LOCAL step into the
  world-frame HatchPatternLine.offset. The new prebaked reader
  inverse-rotates offset assuming world frame, so app-created hatches
  (HATCH command) collapsed their spacing by cos(angle) — ANSI31 at 45deg
  rendered 2.245 instead of 3.175 on both viewport and PDF/plot export.
  Rotate the local step into world here so it round-trips and the stored
  offset is format-correct for other CAD apps.

- far_from_origin_pattern_hatch_still_fills placed its offset ALONG the
  45deg lines (projects to k~0), so it never exercised the span-cap fix and
  passed even with the old absolute-index clamp restored. Move the offset
  perpendicular to the lines so |k| >> the cap. Add
  app_created_hatch_roundtrips_catalog_spacing to guard the offset-frame
  fix (verified: fails at 2.245 without it, passes at 3.175 with it).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-06 20:23:59 +03:00
sLuCHa
1a45f6bd97 fix(plot): correct hatch rendering in PDF / plot export
Hatched content — especially fills nested inside a block INSERT, such as a
title-block logo — plotted incorrectly: missing, mis-spaced, or with phantom
bars. Five related fixes make the PDF/plot output match AutoCAD.

1. Export block-internal hatch fills.
   The export collected only hatches owned directly by the layout block, so a
   hatch nested in a block INSERT was dropped and printed as bare monochrome
   outlines. The insert-explosion the viewport already does is extracted into a
   shared `exploded_insert_hatch_models()` and called from both the viewport
   (`synced_hatch_models`) and the export (`paper_canvas_hatches`), so a plot
   draws block-internal hatches identically to the screen.

2. Honour the hatch's own stored pattern-line spacing.
   `hatch_model_from_dxf` re-derived pattern spacing from the name-matched
   catalog entry x pattern_scale, ignoring the resolved line geometry the DWG
   stores on the hatch. When a drawing was authored against a different base
   spacing (imperial 0.125 vs the catalog's metric 3.175 for ANSI31), lines
   came out up to ~25x too coarse and a dense fill collapsed to a few stray
   lines. When the hatch carries its own line geometry it is now used directly
   (identity scale/angle); the catalog path remains the fallback.

3. Fill far-from-origin pattern hatches.
   `pattern_segments` clamped the ABSOLUTE scan-line index to
   +/-MAX_LINES_PER_FAMILY. A fine-spaced hatch far from the pattern origin has
   large-magnitude indices at both ends but a small span, so the clamp inverted
   the range and emitted nothing — silently dropping the fill. Cap the line
   count (span) instead of the absolute index.

4. Skip TEXTBOX boundary paths.
   TEXTBOX boundary paths (flag bit 3) are text bounding-boxes AutoCAD derives
   for island detection; they are never drawn or filled. Treating one as a fill
   boundary painted its rectangle solid — a phantom bar. It is now skipped when
   building the fill boundary.

5. Print white/ACI-7 hatch fills black on paper.
   Hatch fills arrive adapted to the dark screen background, so a white/ACI-7
   fill would vanish white-on-white on the sheet. Mirror the wire pass:
   near-white/near-yellow -> black, near-cyan -> dark blue, matching AutoCAD's
   colour-7-on-white plotting. Wipeouts keep their paper-white mask.

Adds `tests/block_hatch_export.rs` covering: block-internal hatch reaches the
export set, stored-line spacing is honoured, far-from-origin fills are not
dropped, and TEXTBOX paths are not filled.
2026-07-06 12:24:10 +02:00
Kevin Griffin
a3107d95e4 fix(view): exclude XLine/Ray display segments from ZOOM Extents (#284)
XLine/Ray tessellate as +/-1e6 display segments (entities/ray.rs), and
both fit_all outlier defenses miss them: the IQR reject passes because a
construction line through the drawing has its centroid at its base
point, inside the consensus cluster; and the per-point lim filter passes
because local_extent_max is computed once at document load and stays at
the 1e9 default for drawings created fresh in-app. The far endpoints
then poison the bounds and the view fits +/-1e6, shrinking real
geometry to a dot.

Exclude XLine/Ray wires from the extents up front (AutoCAD likewise
ignores infinite lines in ZOOM Extents), falling back to fitting their
base points when the drawing holds nothing else.

Regression tests verified to fail without the fix (camera distance
3,000,000) and pass with it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-05 14:08:43 -07:00
Hakan Seven
a93271c1bd fix(block-cache): address PR211 review follow-ups
- expand_defn: dedup the <1px baseline LOD branch the same way the <5px
  greek branch does, so colour-split MTEXT no longer stacks N overlapping
  baselines (one per \C segment) over the same OBB.
- sysfont: memoise canonical_family_name process-wide. resolve_font calls
  it once per word on the MTEXT measure hot path and Face::resolve re-runs
  it right after; the fontdb query + linear family scans were uncached.
- dimension/multileader/table: reword the 6 fill_tris_low FIXMEs. They
  cited a stale line and the wrong consumer — these fills render on the
  top-level path (panic-safe .get().unwrap_or), not the block cache, so
  they cannot trip emit_wire's debug_assert. State the real status:
  latent f32-precision debt, not a crash. Also fix the mis-indented
  text-fill WireModel in dimension.rs.
- tests: add a host-independent colour-split test (two \C segments in a
  block keep ≥2 distinct wire colours — guards the per-wire colour fix)
  and a TTF-gated UTM fill test (paired, non-zero fill_tris_low). Note the
  arial-style test's LFF-fallback limitation.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-28 21:57:51 +03:00
Karim Jerbi
06bb6b54ff fix(text): canonicalise TTF filename font refs in MTEXT inline overrides
resolve_font previously returned &str, passing raw stems like "arial" verbatim to Face::resolve. System font lookup requires the canonical family name ("Arial"), so inline \f/\F overrides from block-nested MTEXT were silently unresolvable and fell through to no geometry.

Change resolve_font to return Cow<'a, str>:
- no override -> Borrowed(base), zero allocation
- LFF built-in -> Borrowed(font), zero allocation
- system font resolved -> Owned(canonical), one allocation
- unresolvable -> Borrowed(base), falls back to style font

All 4 call sites updated to &font_name (&Cow<str> derefs to &str).

Adds two unit tests covering the fallback and TTF-stem-to-family-name paths. Adds integration test verifying block-nested MTEXT produces geometry and correctly separates outline/fill wires.
2026-06-28 18:44:38 +01:00
Hakan Seven
a72b143628 fix(copy): duplicate a dimension's baked block so COPY copies it (#161)
A dimension's drawn geometry lives in a baked anonymous *D block. COPY
cloned the Dimension entity (translating its definition points) but left
its block_name pointing at the source block, whose sub-entities stay at
the original location — so the copy rendered on top of the original and
appeared not to copy at all.

Add `clone_transformed_block`: when copying a dimension that has a baked
block, duplicate that block under a fresh *D name with every sub-entity
transformed by the same offset, and repoint the copy at it. The copy now
lands at the drop point with its baked geometry and text preserved (no
synthesis, so diameter/radius values stay correct). Covered by a portable
regression test.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-25 22:30:45 +03:00