Preferences > Guides & Grid gets a Lock Guides by Default checkbox
(lockGuidesByDefault), off by default. With it on, the app starts with
View > Guides > Lock Guides on. Changing the checkbox sets the lock at
once; an OK that leaves it unchanged keeps the session's lock, and
View > Guides > Lock Guides still toggles the lock for the session
without changing the preference. Reset Preferences turns it off and
unlocks guides when it was on. Headless sessions start unlocked unless
prefs.set turns it on, and older preference files read it as off.
Lock Guides works as before: new guides can still be dragged out of a
ruler or added with guide.add while guides are locked. The lock code
moves from view.guides.lock into Session::set_guides_locked so the
preference and the menu share it.
Docs: docs/mcp.md, docs/target-app-parity.md.
Flatten Transparency composited each region over white, so a blend mode
on the bare page read that white. Raster renders now draw their
background under the finished art, and the flattened color no longer
matched them: a Color Burn object on the bare page flattened to white
and rendered in its own color. The region now composites the art alone
and puts the white under it.
- Tests that relied on the white under the art now draw art under the
style (`every_builtin_style_paints_visibly_on_a_rectangle`) or compare
only whole-pixel pans with a fresh render
(`a_coarser_glow_kept_whole_draws_after_a_pan_as_made_again`).
- New tests cover every blend mode on white and blue backgrounds, a
thumbnail and the ink planes with a Screen glow, and
`over_background` at background and pixel alpha 0, 128 and 255.
A raster export filled its background into the page before the art, so
blend modes read it as art underneath: an Outer Glow in Screen mode, the
default, turned white on a white background and was missing from PNG and
JPEG files while the canvas showed it. Blending against nothing also
differed from the canvas for Difference and the other modes.
The background now goes under the finished art, in frames and in object
thumbnails. A blend mode reads only the art below it. A white object
under a Difference object still inverts.
Page Isolated Blending no longer changes a raster export on a bare page.
Docs: docs/mcp.md, docs/target-app-parity.md.
Found while testing crates/engine/src/cmd/graph/data.rs:45-47 (parse_csv)
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Direct Selection of a path, compound path or type inside a dynamic instance now applies transparency and gradient or pattern fills through the usual paint commands, and the G5 docs catch up on Overlap and Pattern auto corners.
- A custom dictionary file that is there but can't be read whole (not a
file, unreadable, or larger than the 1,000,000 bytes craft-proof reads)
is not loaded and never written over: attaching it logs why, and every
add, delete or change is refused with that reason. A missing file is
still created by the first save.
- When a save fails, the command takes back only its own change, so memory
and file agree; words the save took in from the file stay.
text.spelling.addWord, removeWord and changeWord are Check Spelling's Add
and Edit Custom Dictionary's Add, Delete and Change; text.spelling.dictionary
lists the words. They live in craft-proof, which every language's check
reads. The desktop app and vectorcraft-cli keep them in
`Custom Dictionary.txt` next to the preferences (none without preferences);
elsewhere they last until the app closes.
text.spelling.ignoreAll is Ignore All: the active document's checks skip the
word while it is open; not saved, not undoable, and not a change to the
document's revision.
Behaviour: https://helpx.adobe.com/illustrator/desktop/design-with-text/edit-format-text/check-and-correct-spelling.html
Found while testing crates/engine/src/cmd/graph/data.rs:166-172 (fmt_value)
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
A grayscale image colorized with a fill color keeps that color outside its
appearance, so the check for art without paint treated it like an uncolorized
image and new art kept its old fill while the Fill proxy showed the color.
Count a colorize paint as paint: the image then loads like any object with a
fill and no stroke.
plugin.install and plugin.remove count an entry of grants.json that this
version can't use when it can't be removed. plugin.install stops counting
a grant it can't remove when the old module can't be written back to the
Plug-ins folder.
A refused install keeps the grant, a failed write of the module to the
plug-in store leaves the grant in the store, and a stored module that is
disabled or not read in Safe Mode keeps the grant for its id. This
matches docs/plugins.md.
A grant accepted under --allow-plugin-grants is written to grants.json like a
person's approval and counts as approved in later sessions and in the desktop
app. The CLI usage text, the plugin.install params text and docs/plugins.md and
docs/mcp.md said only a person's approval in the desktop app records one.
A filter run kept a second copy of every read-only object as JSON values.
The run now keeps where each object is in the input, and checks an output
entry against it by parsing that one object, unless the entry is `{"id": …}`
alone.
An image that reaches the decoder now counts toward the 16 MiB pixel total
even when decoding fails, so broken images use up the same total as images
that decode.
The plugin.run text, docs/mcp.md and the progress line state the paint
order and that rule, and docs/plugins.md states that a CMYK image's pixels
are sRGB. New tests cover the per-image 1 MiB, the 16 MiB pixel total and
the 16 MiB text total at and one past their values, memory-budget failures
before the plug-in starts, images that are not decoded, CMYK images
included, and leading per run.
When loading the plug-in store can't remove the grant of an id whose stored
module lists no permissions, or can't read grants.json, the entry stays on
disk and still approved the bytes it covers. plugin.install has the same case
when the grant can't be removed and no earlier module can be put back.
The session now keeps those ids and does not count their grants in
plugin.inspect, plugin.install, plugin.reload or a later load of the store. A
successful update of the grant for the id ends that, and so does attaching a
different store.
dotCooCoo