A trace handed in for imageTrace.make or imageTrace.makeAndExpand was
matched by its object, image, pixels and settings alone, so a trace made
in one document could stand in for the command in another open document
with the same image and settings. The trace's inputs now carry the
document's uid: TraceRun::current is false in any other document, and the
commands there drop the trace handed in and trace their own image, as one
undo step.
Test: a_trace_run_applies_only_in_its_own_document.
Merge copied a face's or edge's appearance to the part it rebuilds in its
place, but not its visibility, opacity or blending mode. A half-transparent
face drawn by its stroke became opaque, and a hidden edge was shown again.
Expand kept a face only when its topmost fill had paint, and an edge only
when its topmost stroke had paint and a weight. A face or edge drawn by a
lower row under an unpainted top row was removed, and one whose only
painted row was hidden was kept as a visible path.
Expand now keeps a face or edge when it is shown, its opacity is above 0,
and any fill or stroke row is shown, has paint and an opacity above 0 (a
stroke also a weight above 0), with all of its rows. The rows are checked
with the new Appearance::has_drawn_fill and has_drawn_stroke.
Merge carried a face's topmost fill paint by the same topmost-row test.
It now carries every row of each face that draws by this rule, and of
each edge, pins their unplaced gradients to the old outline as
repaint_from does, and leaves the strokes' pen pressure, tilt, bearing
and rotation behind, since the rebuilt parts are other paths.
Docs: livePaint.expand params text, docs/mcp.md, and a line in
docs/target-app-parity.md, which also drops a repeated Live Paint
Selection marquee line.
A Live Paint Bucket click or drag over faces that already have the
fill, a stroke on an edge that already has the paint and width, Gap
Options with the options the groups have and no gap to close, and Make
or Merge given one Live Paint group alone now leave the document, the
undo and redo steps and the saved state as they are, and reply as
usual. Such a fill or stroke also leaves the recent colors as they are.
Gap Options with Close Gaps With Paths makes a group's faces again only
when it adds a path or what paint stops at changes, so the faces keep
their ids otherwise.
A trace made away from its command (the background trace, #3098) counted
as current when the object, its image record and the settings were
unchanged, without looking at the image data. When other pixels came to
sit under the same image key (Rasterize after an undo reuses the key and
the id, Update Link, a replaced blob), the finished trace applied its old
paths to the new image.
The trace's inputs now include the encoded bytes it decodes, compared by
allocation first and then by content. TraceRun::current and the hand-off
in imageTrace.make and imageTrace.makeAndExpand both use them, so a stale
trace is dropped and the command traces the pixels there now. Equal bytes
in another allocation still count as the same image.
Commands that need an object id read it with `id_param`, which returns
None for a value that is not a non-negative integer, so `{"id": "5"}` or
`{"id": -1}` was refused with "missing id". They now read it with
`object_param`, which refuses such a value with "`id` must be a whole
number", naming the key. This covers `document.node`, the `path.*` anchor
and handle commands, the `text.*` range and path commands, the mesh,
envelope and slice point commands, `layer.target`, `layer.move`,
`node.move`, `select.magicWand`, and the `source`, `target`, `group` and
`path` keys of `appearance.transfer`, `appearance.copyFrom`, the
`livePaint.*` commands and `text.createInPath`.
The optional `group` of `livePaint.fill` and `parent` of `node.move` are
refused the same way when given. Before, a malformed `parent` moved the
object to the top level and a malformed `group` fell back to the
selection.
With Document Swatches as the library, traced fills and strokes take the
library color without a swatch link. Global, spot and tint swatches no
longer link the trace, so editing a swatch later leaves the trace
unchanged, and swatch order no longer decides whether a fill is linked.
Each region still takes the nearest library color, and a tint traces at
the color the tint swatch shows.
Each traced path filtered the whole library for its color, twice when
no swatch of that color was linked. The color-to-paint lookup is now
built once before the paths are filled. The first linked swatch of a
color still gives the fill, and the first swatch of that color
otherwise.
When a process swatch listed before a global or spot swatch showed the
same color, a traced fill of that color took the process swatch and
stayed unlinked. Of the swatches that trace as one color, the first
linked one now gives the fill, and the first one otherwise.
From the review of #4605. TraceParams::swatches isn't in the settings' JSON (serde skip), so a Document Library trace whose swatches were edited while it ran still applied, with the old colours; the trace's inputs now hold them. The 100 ms repaint that keeps background work moving left traces out, so without input a finished trace could wait for the next event.
Tracing a photo or a large image ran inside imageTrace.make on the UI
thread, so the window froze for as long as the trace took, with nothing
to say it was working.
A trace the user asks for (Object > Image Trace > Make and Make and
Expand, the task bar's Image Trace, the Image Trace panel's Trace and
presets) now runs on a thread of its own, as heavy plug-in filters do.
The status bar says so, and after 0.4 s a progress window shows how
many of the image's colors are traced, with Cancel and Continue in
Background (imageTrace.cancelRuns, imageTrace.hideRuns).
The result goes back to the command it was prepared for
(cmd::TraceRun, Traced::hand_in), which takes it only for the same
object, image and settings, so the edit is one undo step as before. A
newer trace of the same object replaces one still running, and a trace
whose image or settings changed meanwhile changes nothing. The control
channel, MCP, scripts and the web trace at once, as before.
The tracer reports its stages and color layers to a callback and stops
when it says so (trace_watched).
main moved session/execute.rs and cmd/buildcmds/shape_builder.rs off glob
imports, so the branch's new waits_for_tool_edit guard and Arc::ptr_eq call
needed those names added to the explicit import lists.
A Shape Builder click or drag over a selection of more than 128
segments merged on the UI thread, so the app stopped drawing and
answering until the merge was done. The tool now computes such a
merge on another thread from the map it built for the hover.
Meanwhile the canvas keeps drawing, the touched regions stay
highlighted and the pointer is the busy pointer. When the merge is
done, the tool runs shapeBuilder.merge with the gesture's params as
one undo step, and the command takes the computed shapes when it
would compute the same ones. The web build merges in the command, as
before.
A press while the map is still being built no longer waits for it on
the UI thread: the tool records the gesture and makes it once the map
is there.
Clicks, drags and the Shape Builder's arrow keys made during the
merge, and commands, menu items, the app's own dialogs, saves and tool
or document switches, run after it on the merged art; engine queries
that only read run at once. A change to the selected paths made
outside a command drops the merge. The headless host and ui.pointer
reply once the merge is applied.
The Shape Builder and the Live Paint Bucket keep their map of the
selection over a new revision of the document when the selected paths
and their outlines are unchanged, instead of building it again.
BFlat