The Model layout was written with the default page setup, whose "layout"
plot area is plot type 5, "Layout information" (DXF Reference, PLOTSETTINGS
group 74). That means nothing for model space: opened in AutoCAD 2027, a
drawing saved by CADCraft had a blank "What to plot", no preview and no scale
in the Plot dialog for Model. Model space now gets what PLOT does for it: the
drawing extents scaled to fit (74 = 1, 75 = 0). DWG saves go through the same
writer; the reader already ignores the Model layout's plot settings.
Co-authored-by: EP995LAB <293597958+EP995LAB@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
With a view, each span of a pattern line was cut to the view's extent
intersected with the boundary's. Spans already lie within the boundary,
and the boundary extent comes from rotating the corners directly while a
span end comes from interpolating along an edge, so where a line passes
through a corner the two differ by a rounding error and the cut moved the
end (by 3e-16 on Windows, whose sin/cos round differently). The spans are
now cut to the view's extent only, so normal_zoom_pattern_is_unchanged
holds on every platform.
MCP clients start their servers when they start, usually before CADCraft is
open, and `--connect` refuses to start then. `--lazy` starts the bridge
anyway and reaches the app at the first tool call; until the app answers,
each call fails with how to open it. `--launch` (implies --lazy) opens
CADCraft on macOS with that control port at a call that finds nothing, and
waits up to 30 s. Neither falls back to a headless session (#103).
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* HATCH/GRADIENT: points and objects in one call; GRADIENT name and centered
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* HATCHEDIT: gradient parameter (make or change a gradient fill)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* HATCHPICK: pick hatch boundaries, an origin or hatches for the dialog
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Hatch dialog: state, defaults and the OK command call
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Hatch dialog: pick points, objects, origin or hatch and come back
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Hatch and Gradient dialog window (pattern swatches, gradient, origin, boundaries, options)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* HATCH, GRADIENT and HATCHEDIT open the hatch dialog; double-click a hatch to edit; HPDLGMODE
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Hatch dialog: keep the window to its content (OK and Cancel stayed off screen); double-click test
A vertical separator between the two columns took the height available, so the window grew
every frame until its buttons left the screen. Found in the running app.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Docs: hatch dialogs in gaps, target-app parity and UI parity
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Hatch dialog review fixes
- Double-clicking a hatch at its centre opened the dialog and also started a grip edit.
- Edit mode no longer clamps an out-of-range scale or angle into a change nobody made.
- HPORIGINMODE outside 1-5 means the current origin, as HATCH reads it.
- Picks made in one space are dropped when the dialog comes back in another (layout tab).
- A gradient hatch's Pattern tab offers the current pattern (HPNAME), not SOLID.
- Ukrainian: "Default to boundary extents" said "outside the boundary".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: lloyd <lloyd@stackworx.io>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The previous release build failed in craft-common-actions, not in this
repo: riscv64 packaging got --formats deb,rpm,tar (fixed in
craft-common-actions#3), Linux jobs lacked the ALSA headers
(craft-common-actions#5), and Windows signing needed the AZURE_* secrets
listed in the caller.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Since the release workflow moved to storytold/craft-common-actions, it has
passed only the Apple and WINDOWS_CERTIFICATE secrets. The signing job reads
values from the release environment, but only for names the caller lists, so
the AZURE_* names that Trusted Signing uses came through empty and Windows
builds would ship unsigned. Same fix as storytold/craft-launcher#174.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The shared release workflow sets CRAFT_FONTS_DIR with CRAFT_FONTS_REQUIRED=1
but only checks craft-fonts out when craft-fonts-ref is given. Since #321
cadcraft-fonts reads that directory, so every native release job failed
with "fonts/manifest.txt: No such file or directory". Pin craft-fonts
3d9ab3a (current main, with the Arabic faces the web build embeds).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
EP995LAB
Books
Marco Arnulfo
aldozar
LloydNicholson
cyfung1031
Brandon Thomas
mayloglog
Lion
Diego Ospina
rangoDJ
MarekSpodBiedry
SteamSmith
Jason Brashear
CaseyKleinman
markmonkey
PedroGuille
pechnikov2026-star
Daniel Lošák
Valentin Klein
Gert Pellin - GPE
STE1200
Fabio Lussi
Muhi