When the action New Action made for the recording in progress is deleted,
Stop Playing/Recording keeps none of the recorded steps. The step and
file limits measured a new action in the original set instead, so a
recorded command could be refused while the set's file was near 8 MiB.
The recording now has no target in that case, and no limit applies.
ui.action.record's params text now says that a recorded command whose
step passes a limit only from the values it adds as it runs keeps its
edit and result, that later recorded commands are an error and do not
run, and that ui.action.stop leaves its step out.
crates/mcp/src/ui_catalog.rs now matches the desktop table again
(cargo xtask ui-commands --check), including the action-limit params
texts of the earlier commit.
A recorded command whose step passes a limit only from the values it adds
as it runs keeps its edit. The status bar names the limit, later recorded
commands do not run, and Stop Playing/Recording leaves its step out.
Load Actions refuses an action set file over 8 MiB, with more than 1,000
actions, or with an action of more than 10,000 steps. Several ways of
changing a set could pass those limits, leaving a set that Save Actions
refuses to write.
- While an action records, a command (a batch and Find Objects that
selects included) whose step would give the action more than 10,000
steps or its set's file more than 8 MiB does not run, and the recording
goes on. A stop that playback reaches is left out then. A command whose
step grows past a limit only as it runs keeps its edit; the status bar
names the limit and Stop leaves the step out. Stop also leaves out any
recorded step still past a limit. Steps recorded after an exclusion
past an action's last step are included.
- An exclusion that would make the set's file larger than 8 MiB changes
no checkmark; one that keeps the size or shrinks it always works.
- Begin Recording, New Action, Duplicate, renaming an action, Action
Options, Set Options and New Set refuse a change that would give a set
more than 1,000 actions or a file larger than 8 MiB. A change that
leaves a set no further past a limit than it is now is allowed.
- Load Actions refuses a set, .aia sets included, that Save Actions would
write larger than 8 MiB (a file with less white space, or a set name
that gets a number added).
The limits are the existing ones from files.rs, and the errors reuse the
existing messages. docs/mcp.md and the commands' params text describe the
new errors.
A client confined by --automation-read-root saw paths outside its read
roots that the person or an earlier request had put in the session:
- plugin.list: the plug-in folder last loaded and its failed files;
plugin.list and plugin.info: a plug-in's source file; plugin.list,
plugin.safeMode and plugin.setEnabled: the file of a plug-in turned
off for the next launch.
- file.recovery.list and file.recovery.restore: a document's original
file; file.recovery.list and file.recovery.save: the recovery folder.
- ui.inspect's scriptReport: the files a run wrote and the included
file a failed run stopped in.
A folder outside the read roots is now null, and a file outside them is
named by its file name. plugin.setEnabled {file} takes that name. The
restored documents keep their files, and unconfined clients and the
app's own UI see the same replies as before.
object.objectsOnPath.selectMember and object.objectsOnPath.moveMember
change only the document and its selection, as the other Objects on
Path commands do, so both join the commands a plug-in may call when its
manifest lists them.
A four-component JPEG whose EXIF orientation turns or flips it went
through the image decoder, which reads CMYK JPEGs as RGB, and was
stored as an RGB PNG without its inks. It is now stored the way a
turned CMYK TIFF is: its inks, 8 bits each, turned and written as a
CMYK TIFF with the turned resolution.
- vectorcraft_doc::cmyk::turned_cmyk turns the inks of a CMYK JPEG or
TIFF, next to stored_cmyk_tiff; tiff_inks is private again.
- raster_image swaps the resolution axes inline, as its HEIF branch
does.
- The links comment and the docs/target-app-parity.md line on EXIF
orientation now describe the turned CMYK TIFF.
A text on a path that many <use> elements show was laid out along the
whole path once per <use>, and the path was found in the file and parsed
again each time, while the 1 MiB limit on texts built for <use> elements
counted only the text's nodes and characters. A file with a short text on
a very long path and many <use> elements of it could keep the importer
busy far past that limit.
- The elements of the path a <textPath> follows now count toward the
limit. Past it, the remaining <use> elements show the text with its own
properties, and the warning names text paths as well as text.
- The path of each <textPath> is found and parsed once and shared by
every <use> that shows its text.
Files within the limit import as before.
The Dynamic Text: Block entry says the Contextual Task Bar offers the
item for point type too, and that turning it on makes point type area
type with Block on. The Dynamic Text entry no longer says point type in
the selection is left as it is.
`the_menu_bar_is_inert_while_a_file_dialog_is_open` excused a missing
menu row when the composite font or plug-in it named was gone at the
time of the check. A test running alongside can remove such a font and
define it again between the menu read and the check, and the test then
failed. It now runs inside `undisturbed`, as the file's other tests that
compare menu reads do. When the shortcut, plug-in or font generation
changes during a run, the test runs again on a new app. Every row from
before the dialog must then be back as it was.
The element a <use> shows inherits from the <use> rather than from where it
is defined (SVG 2, https://www.w3.org/TR/SVG2/struct.html#UseElement). A
text shown by a <use> now takes the font, size, weight, fill, stroke and
other text properties the <use> or its parents set, in clip paths too,
while the text's own properties still win. Uses with the same parent and
properties share one text. A <use> inside the text it shows is ignored for
inheritance, and texts built for <use> elements stop at 1 MiB of text with
a warning.
Rewrap the prose in docs/plugins.md whose lines broke well short of
the file's 120-column width or ran past it, including the Safe Mode
sentence, the permission-name and install-confirmation sentences, and
the grants.json paragraph. Each rewrapped line is at most 120 columns.
No words, punctuation, code blocks or tables change.
The save dialog read the portal's current_filter with zvariant's tuple
conversion, which panics on a structure with fewer fields than the
tuple. On Linux and the BSDs the dialog's thread then ended after the
user picked a file, and nothing was saved. The label is now read only
from a (sa(us)) structure, the shape the FileChooser portal defines.
An answer of another shape keeps the path and names no file type, as
an answer without current_filter does. A structure with more fields
than (sa(us)) also no longer names a file type.
An object with an opacity mask draws offscreen over the bounds the
renderer gives it. For a live object (a blend, envelope or repeat) those
bounds took in effects in symbol art and brush art inside it, but not a
path's own effects, so with Clip off the drop shadows of a blend's steps
were cut off at the steps' bounds and did not draw where the mask art
leaves them uncovered. The bounds now also take in how far each path's
own effects paint past it.
The drag chose its place from the point of the path nearest the pointer, but counted each point as
farther by half its distance along the path from the last one. On an open path that turns back on
itself, the object then stayed at its place while the pointer was over another object's ring 10 pt
away. The drag now uses the point nearest the pointer. Where the path passes as near the pointer
more than once, as where it runs back over itself, the drag follows the part nearest along the path
to where it was.
Type in a font found by name with a predefined non-Unicode CMap, such as
`/Ryumin-Light-83pv-RKSJ-H findfont` or a `composefont` with `GBK-EUC-H`,
opened as Latin-1 letters (`ú{A` for 日本A) in a font whose style carried
the CMap name (`Light-83pv-RKSJ-H`). Only Unicode CMaps were split off the
font name, and `composefont` failed with `undefinedresource` for the others.
- The predefined CMap decoder used by legacy `.ai` type moves to
`import/predefined_cmap.rs`, and EPS import decodes these CMaps' codes
with it (Shift-JIS, EUC, GBK, Big Five, UHC and the other public CMaps).
- A font name splits at a predefined CMap unless an installed face has
the whole name. A CMap that can't be read gives a warning.
- Type over a vertical CMap (`-V`) is set as vertical type, and each code
moves the point one em down the column, the default `DW2`
displacement.
- Every show operator sets decoded type with the same spacing and shaping
as other fonts found by name.
- Decoding a string counts against the import's memory budget.
In a full parallel `cargo test -p vectorcraft-ui-egui` run, other tests
add and remove composite fonts in the process-wide font database and
remove plug-ins from the plug-in registry. Two tests failed when that
happened between their reads, and passed when run alone.
- `font_menu::tests::the_scroll_bar_leaves_the_stars_clear` starred
`FontDb::global().families()`, but the menu lists the composite fonts
first, so the top rows had no star. The test now turns on the starred
filter and counts the rows it listed.
- `tests::nativemenu::the_menu_bar_is_inert_while_a_file_dialog_is_open`
required every menu row from before the dialog to be back afterwards.
A row may now be missing only when the composite font or plug-in it
names is gone from the database or the registry.
- Four font menu tests took the first families from
`menu_family_list()`, which can be a composite font that is removed
before the frames run. They take them from the families that stay
listed. The variable-filter test checks that every family listed
before the click is listed again, instead of comparing two frames.
Opening or placing an image whose orientation turns it a quarter
(EXIF or TIFF Orientation 5 to 8) stored the pixels turned but kept
the resolution as stored, so a photo at 300 x 150 ppi came in at the
wrong width and height. XResolution counts pixels in the ImageWidth
direction of the stored image (TIFF 6.0,
https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf; EXIF
uses the same tag, CIPA DC-008-2012,
https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf), so a quarter
turn now swaps the axes, in the size Open and Place use and in the
stored image, with jxlread::oriented_resolution as JPEG XL does.
Three kinds of TIFF did not follow their Orientation tag:
- grayscale TIFFs with extra samples and 1-bit CCITT Group 3 TIFFs
were not turned;
- a CMYK TIFF with its inks together was turned but stored as RGB,
losing its inks, and one with a plane per ink did not open
("Planar TIFF with CMYK color type is not supported").
They now turn as the other images do, and a CMYK TIFF keeps its inks,
8 bits each, written again with the turned resolution.
dotCooCoo