A Paintbrush sample dropped for being under a pixel from the last point
left the ring computed from the pointer, while the release keeps the last
point; the ring now follows that point (CodeRabbit).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A Pencil or Paintbrush stroke released within Close Paths When Ends Are
Within of its start closes, but the cursor gave no sign of it. While the
pointer is where a release would close the stroke, the cursor is now
PencilClose (PaintbrushClose for the Paintbrush), the crosshair with a
ring, as Draw straight lines with the Pencil tool describes:
https://helpx.adobe.com/illustrator/desktop/draw-shapes-and-paths/draw-shapes/draw-straight-lines-with-the-pencil-tool.html
The check is the one the release makes, on the end the stroke would
take (snapped for the Pencil). A straight line (Shift or Alt held at the
press), a stroke that continues a selected path, a stroke that redraws
one and a smoothing drag show no ring.
Docs: docs/target-app-parity.md, docs/ui-parity.md.
Without a loader, check() scanned the script once, so a function using a
variable the global code assigns after it (`function g(){ f.write('x'); }
var f = new File('a');`) missed file.write, while the loader path found it.
The no-loader path now runs the same fix-point, keeping a scan that finds
nothing new as the report scan, so a script that includes nothing gets the
same report with and without a loader.
Fixes#4011
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Found while testing crates/doc/src/xml_id.rs:32 (from_object_name), decoded by escaped() at :72
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Within about a minute of its window no longer being visible, macOS App
Nap lowers the app's threads to the lowest priority and coalesces its
timers. On a loaded machine, control requests then took seconds to
answer, and the 60 s timeout reply arrived up to 26 s late.
When the control channel is on (--control or VECTORCRAFT_CONTROL_PORT),
the app now holds an NSProcessInfo activity (user initiated, allowing
idle system sleep, latency critical) for as long as it runs, so App Nap
does not apply. The activity does not keep the Mac awake.
docs/control-protocol.md states this in the paragraph on the 60 s
timeout.
Move the declaration pass, the significant-token helpers and the feature
recognisers into analyze/declared.rs, sig.rs and features.rs without
changing their code, and replace the duplicated line-break and directive
dispatch of scan and declarations with LineBreaks::read.
Part of #4014
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
FeatureId and OutsideId replace the string ids the analyzer passed around.
One table each gives the id, the need and the report order, so
catalog::FEATURES and catalog::need() are gone. Feature.id and the engine
JSON are unchanged; OUTSIDE is generated from the same table.
Fixes#4013
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Work out the unescaped text and the declared names of each file once and
share them between the scans, keep included files as bytes and decode
them on demand, check the cheap tokens before unquoting in the '=' case,
and stop allocating a String per recorded chain.
Fixes#4010Fixes#4012
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Found while testing crates/cad/src/import/text.rs:14-27 (mtext calls escapes at :14, which treats `^2` as a caret escape and drops it; the `\S` branch at :25 expects the `^`)
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The server lists two names for several calls (command_list and
list_commands, command_run and run_command, doc_inspect and
inspect_document, ui_inspect and inspect_ui, ui_screenshot and
screenshot with window:true), but no description said so, and the two
listing and running pairs take different argument names. Each
description now names its pair and the argument that differs, and undo
and redo name each other.
ui_screenshot took no arguments and returned the window at its full
size, which can be several megapixels on a large display.
ui_screenshot and screenshot {window: true} now take an optional
max_side (1..4096) that scales the returned image down to that many
pixels on its longer side. The reply's text gives the returned size as
width/height and the capture's as capturedWidth/capturedHeight; a file
written to path keeps the full capture. max_side on an artboard render
is an error that points to scale. render_preview reads its max_side
through the same check.
docs/mcp.md describes the pairs and the new argument.
The planar map's `RectIndex` sorted rectangles narrow in x by their left
edge and those narrow in y by their top edge, and scanned the rest for
every lookup. A long diagonal segment is narrow in neither, so a hatch of
diagonals put every line in the scanned list and `Outlines::source_at`
(one lookup per edge) cost a scan of the hatch per edge: quadratic in the
hatch below the 65,536-segment cap, as CodeRabbit found on #3357.
`RectIndex` is now a grid of about one cell per item, each cell listing
the items touching it; a lookup reads the cells around the point. An item
is filed under a footprint of rectangles: its bounds (`new`), or, for a
segment, the bounds of its pieces about a cell long (`with_footprint`,
`segment_footprint`), so a diagonal is filed under the cells along it,
not under every cell its bounds cover. A footprint rectangle covering
more than 64 cells or two rows/columns (a face covering most of the art)
is scanned for every point as before; a thin stripe face is filed under
its column of cells. Cells hold `u32` indices.
Tests: `rect_index_reads_a_diagonal_hatch_only_near_the_point` (2,000
diagonals a tenth of a point apart: a lookup got 1,001 candidates with
the old index, now at most n/4, and still every line through the point;
a hatch of stripe faces is filed, not scanned; a collinear, degenerate
grid). `rect_index_finds_every_rectangle_holding_a_point` keeps the
bounds-only contract.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014gCpjL3yUhaH3jRp7ksufh
A document opened or created between edit.undoGroup.begin and
edit.undoGroup.end opens an undo group of its own with the begun
group's name, so an atomic command_batch that starts with file.new or
document.open is one undo step in the new document. The group opens
after the command that opens the document: when that command also
edits it (a command.batch), those edits stay the command's own undo
step, and a canceled group keeps them, so the journal still replays.
Both commands also run with no document open, and a command.batch that
fails rolls back a begun group. Switching to a document that was
already open does not open a group in it.
The outlines of a run's character stroke are kept with the glyph geometry the renderer keeps for the type, in a byte-limited cache swept by frame, so type that changes in every frame (an animation) frees them within a few frames.
The installed-release section of docs/mcp.md said how to register the
server but not how to start an installed app for a live session; the
only start command in the setup steps was the cargo run from a
checkout.
It now gives the command that starts the installed app with
--control 7979 on macOS, Windows and Linux, and says that the
launchers open no control port, that the flagless server checks for
the app once when it starts, and what --connect prints when no app
is listening.
When Flat Logo finds the colors itself (no colors named), a flat bar
two pixels wide (whole pixels of one color) on a ground beside other
art was lost or traced in another color. No bar pixel has a uniform
3 x 3 neighborhood, so neither the first clustering nor the check for
unexplained colors took it. A gray bar on white beside black art was
traced as white, and a red or green bar was traced as black. Bars
three pixels wide or more were already found.
The check for unexplained colors now also takes the pixels of such a
bar: two rows or columns of one color (within about 3.5 in RGB
distance), three pixels long, with the same ground on both sides. They
count when the known colors do not explain them, and also when their
color lies less than two thirds as far from the ground's known color
as from every other known color, where the bar would otherwise be
traced as the ground. A gray bar darker than about #9B9B9B on white
beside black art stays black, #808080 included, because a black stroke
1 to 1.6 px wide on the pixel grid gives the same pixels. Named colors
are unchanged.
Review follow-up. A function-based shading is read once per import (kept
per shading pattern and inks), and all of them draw on one budget of
200,000 function evaluations; past it a shading comes in as its average
colour, then flat grey, each with a warning that names the cause. A
gradient read leaves enough of the budget to average another shading.
A colour that changes in step with the sampling grid is checked across
the middle of the domain before an axis is chosen, so it isn't read
along the wrong one. The grey fallback warning for other shadings names
only them.
Tests: the same shading on 2,000 paths is read once; 40 distinct
shadings stay within the budget; a hostile file (5,000 fills, 20
shadings with 500-step functions) opens in 0.8 s, 253 s before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
PDF import turned every function-based shading (ShadingType 1) into a
flat mid-grey. Chromium writes a CSS repeating-linear-gradient this way,
so a red and white hatch came in as a grey bar.
A function-based shading whose colour changes along one axis of its
domain only now becomes a linear gradient across the domain: stops
sampled along that axis, each hard colour change (found by halving the
interval between two samples) two stops at one offset. One whose colour
changes in two directions comes in as its average colour, with a
warning. Either paints only over the shading's domain.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Found while testing crates/doc/src/metadata.rs:108 (stamp_from_env)
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The fit of a thin outline can lose all its area. Its two sides can
straighten onto one line, which leaves two anchors whose segments run
back and forth along it. Or the fit can be a single cubic, which becomes
one anchor and has no segment. Both occur when Flat Logo traces noise
whose cells are one pixel in size. The trace kept such an outline as a
selectable path that paints nothing.
Flat Logo now leaves out an outline whose area is below 1e-6 px^2,
together with its holes, and a hole whose area is below 1e-6 px^2. The
area is summed about the outline's first anchor, as the other trace
modes already do for a filled loop (crates/trace/src/lib.rs:996-1001).
Outlines with an area of 1e-6 px^2 or more, thin slivers included, are
kept as before.
One test traces a black and cream noise with both colors named exactly
and checks that no subpath of the result lacks an area. Two more build
shapes from straight cubics: a hole without area is left out, and an
outline without area is left out with its hole.
BFlat