Clip groups clip by compound paths (with their holes), even-odd paths, text
outlines and groups (the union of their members) on screen, in raster
export, in SVG and in PDF alike, through one shared region:
Node::clip_outline (the model walk) and effects::clip_outline (text
outlined, several shapes united), cached per clipping path in the
renderer. Nothing to clip by hides the clipped art everywhere, and clicks
hit a clip group only inside its clipping region. Make Clipping Mask takes
a compound path or text object on top (it loses its paint) and Release
gives it back unchanged in kind.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Text import turns the gap between an absolutely positioned <tspan y> and the previous line into
that many line breaks, with two problems:
- At least one break was added even when the tspan sits on the current baseline. Styled or
kerned runs written with x and y on every tspan (as Illustrator writes them) were split into one
line per run: "Hello <tspan y=same>world</tspan>" came back as "Hello \nworld".
- The count had no upper bound. A tspan with y="1e15" (or any y far below its text) asked for
~10^14 '\n' characters, and opening the file aborted the app, the MCP server or
`vectorcraft-cli` with "memory allocation failed" after eating all memory.
A tspan less than half a line from the current baseline now adds no break, the gap is capped at
10 000 line breaks, and a non-finite gap counts as one; other gaps are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
VectorCraft writes and reads SVG at 1 user unit (CSS px) = 1 pt, but a root width/height in
absolute units was taken in CSS pixels (96 per inch). An A4 document from Inkscape
(width="210mm" height="297mm" viewBox="0 0 210 297") opened on a 793.7 × 1122.5 pt artboard,
i.e. 280 × 396 mm, with all art 4/3 too large, and its PDF export came out on that page size;
width="8.5in" gave an 11.3 inch artboard and width="300pt" a 400 pt one.
When the root width or height has an absolute unit (in, cm, mm, pt, pc) the import now scales by
72/96 along that axis, so the artboard and the art keep their physical size (595.3 × 841.9 pt for
A4); geometry, stroke widths and text follow through the same transform. Unitless, px, % and
viewBox-only files are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Area type was written as one <tspan> per paragraph at the frame's top-left: SVG text never wraps,
so every SVG viewer (and VectorCraft's own import) showed each paragraph as a single line running
out of the frame. Centred and right-aligned area type also got text-anchor="middle"/"end" at the
frame's left edge, so it was centred on (or ended at) that edge instead of inside the frame.
The exporter now asks the text layout for the lines: each line is a <tspan x y> at its baseline,
at the line's left edge, centre or right edge to match the text-anchor, with hyphenated breaks
written with their hyphen and the spaces at soft breaks dropped. The <text> carries the first
line's position too, so importers that place text by its own x/y (ours included) start at the
first line. Re-importing an exported file now reproduces the area type pixel for pixel as point
type with the same line breaks (justified lines lose their extra word spacing).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A dash pattern with a negative value (for example [-5, 3], from `stroke.set` or a PDF `d`
operator) was handed to the dasher whenever any value was positive. When the values sum to zero
or less the dasher never advances, so rendering the document hung forever (canvas, screenshot,
PNG/JPEG export, `vectorcraft-cli convert`).
PDF (32000-1 §8.4.3.6) and SVG (`stroke-dasharray`) both define such a pattern as invalid and the
stroke as solid. `Dash::is_dashed` now says whether a pattern draws dashes (finite, non-negative,
not all zero), and the renderer, the width-profile outline, the SVG and PDF exporters and the PDF
importer use it, so an invalid pattern is drawn, written and read back as a solid stroke everywhere
(the PDF exporter used to clamp negatives to 0, writing zero-length dashes).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
VectorCraft exports type on a path as <text><textPath href="#text-path-N"
startOffset="…%"> with the path in <defs>, but the XML text fallback read
every <text> as point type at the text element's x/y. Text on a path
therefore re-imported as a straight line at (0, 0), above the artboard
and mostly out of view, and lost its path.
Resolve the textPath's href (SVG 2 href or xlink:href) to the <path>,
bake the text's user-space transform (and the path's own transform) into
it, and read startOffset (a percentage, or a length along the path) into
TextKind::OnPath.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
