Paste ignored a bitmap on the system clipboard: a screenshot or an image
copied in a browser had to be saved and placed. Paste now places it.
- edit.pasteImage {base64, name?, spread?, at?} embeds the image in the
selected empty frame, or in a new frame centered on `at` at its stored
resolution (72 ppi when none) and at most 60% of the page width, as
File > Place sizes it. Save and reopen and IDML export keep the pixels.
Images over 64 million pixels and names without an image extension are
refused.
- Ctrl/Cmd+V pastes the image egui delivers with no text, and Edit >
Paste reads the clipboard's bitmap, or the first image file of a copied
file list, when there is no text or the text is only an address.
- The menu read waits at most 1.5 s on its own thread, with one read in
flight at a time.
- With a native menu, objects copied here still paste as objects until
the pasteboard's change count shows a newer copy.
- ui.paste takes {image} for the control channel.
Review fixes for #2304:
- Each pointer-less drop asks the system where the pointer is when its raw input arrives, and
converts it with that input's window rect and the UI scale, instead of one sample taken at the
later UI pass for the whole batch. Drops with pointer events keep their own pointer, and the
system is still only asked when a drop brought none.
- system_pointer is cfg'd off on wasm with its only caller; Services::pointer's docs say a drop
without a pointer lands in the middle of the view.
- pointer.rs: the AppKit flip is a pure function with a test, documenting why it flips against
the main display only (winit's window positions use the same origin).
- Test: a filled compound path takes a dropped image through its ring, not its hole.
Split out of #2073. Port of #1307's drops and #1666.
- Several images dropped together load the place cursor in the order they
came, each run of them where it comes among the other files, after the
images it already holds; click to place them one by one.
- One image dropped off a frame that takes it loads the place cursor instead
of being placed at once; on such a frame it still fills it.
- A drop is handled in its order, each file at its own pointer, and a dialog
(a multi-page PDF's Import Options, an alert) cancels the rest.
- On the web, files dropped together are read as one batch (none if one
can't be read), and a single dropped image loads the place cursor.
Split out of #2073. winit sends no pointer events during a drag from another
application on macOS, so a Finder drop had no pointer and never found the frame
under it. The host now gives the pointer's place on the screen
(`Services::pointer`, `PointerFn`: the system's points before the UI scale,
from `NSEvent.mouseLocation`), and `take_pending_drops` uses it for the files
that came without a pointer, divided by egui's zoom factor and made relative
to the window.
Split out of #2073. Port of #1307, #1392 (grid) and #1432 (thumbnail and count).
- File › Place takes several files; images load the place cursor in the
order chosen (`place.load` `files`, `append`), after the ones it holds.
A multi-page PDF or an alert stops the batch, and a file that can't be
placed returns its error to `app.placeDialog`.
- Each click places the next image; arrow keys while dragging lay out a
grid (`place.grid`) and are handled even at a limit; Escape unloads the
rest (`place.cancel`). Undo of a loaded image's asset cancels the queue.
- The cursor shows how many images are loaded.
- On the web, Place picks several files and the inbox loads consecutive
images for the same document as one batch.
The script command threw away the result of each export, so a PDF with
a drop shadow came out with nothing on stderr, while run --export
printed "warning: 1 object(s) with soft effects ... exported as images".
Each warning an export returns now goes to stderr as "warning: ...".
The JSON report on stdout is unchanged.
`validate_pdf` accepts `--standard x4|x1a`, and both its own usage string and the
module docs say so, but the line in the global `USAGE` left it off -- and that
line is exactly what `validate-pdf --help` slices out. So the option was
documented everywhere except the one place a user would look (noted in review).
`subcommand_help_names_the_options_that_subcommand_takes` asserts it, checks the
parser and the help agree by refusing an unknown standard, and does the same for
`run --cmd` and `mcp --automation-read-root` so this is about subcommand help
rather than one line.
`<sub> --help` answered about that subcommand without first asking whether the
subcommand was one, so `designcraft-cli typo --help` printed the whole usage and
succeeded. `typo` on its own was an error and `typo --help` was not, which is
backwards: a script checking the exit status carried straight past a misspelled
command (noted in review).
`is_subcommand` reads the names out of `USAGE` rather than listing them again,
so one added to the usage text cannot be missing here, and `usage_for` now uses
the same line parser instead of its own copy. An unknown name falls through to
the dispatch and fails there, as it already did without `--help`.
Measured over every name the usage lists -- run, commands, describe, script,
app, mcp, perf, bench, validate-pdf, links -- each still answers on stdout and
exits 0, while `typo` and `nonsense` exit 1. The test asserts both halves, so
the check cannot quietly become a block on subcommand help.
winit 0.30 gives an undecorated window WS_CAPTION and WS_BORDER; on some systems the compositor
reserves that frame, so the content is drawn offset (black bars at the top and left) while the
pointer keeps the client coordinates. A per-frame guard strips the styles again after every
winit flag change and keeps a maximized window clear of the taskbar. Fixes#1295.
egui-wgpu doubles its vertex buffer when a frame outgrows it, and wgpu's
default largest buffer is 256 MiB. Opening a 160-page InDesign catalogue
produced a frame with 137 MB of vertices; egui-wgpu asked for a 275 MB
buffer, the device refused it and the app stopped. The device now takes
the adapter's own largest buffer, as it already did for the texture side
(2047 MiB on DirectX 12 here), and the log says both limits.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
UPDATE_APP (native builds; craft-update is a native-only dependency) carries our 128 px icon and accent (#7bb51c, its colour in ArtCraft Launcher). The updater, the self-update
helper and craft-update's startup prompt all get them through crate::UPDATE_APP; the
prompt draws the icon, the accent and "by ArtCraft" (craft-update's default developer).
craft-update is pinned to storytold/craft-libs main at 1065653e7 (#434).
Clippy fixes for Rust 1.99 in untouched code (same logic):
- crates/engine/src/cmd/export/text_tests.rs
- crates/pdf/src/gradient_inks.rs
designcraft-cli thumbnail a.designcraft a.designcraft replaced the
document with PNG bytes. The output is now refused before anything is
read or written when it is the input by the same path, through a
symlink, or on Unix as a hard link (same device and inode).
Review caught a consequence of the previous commit. Standing the order check
aside so a missing value could be reported meant the value was reported
later -- after the exports before it had already been written. `run --export
first.png --scale --export second.png` wrote first.png and only then failed,
so an invocation that fails could overwrite a file that was already there.
`values_present` checks every option that takes a value before the order
check and before any export, so the line is refused as a whole. The test
writes a file at the export path first and asserts its bytes are unchanged.
* Show file and message dialogs without blocking the frame
A blocking rfd dialog inside the egui frame runs AppKit's modal loop; a
file dragged from Finder and held over the window then re-enters winit's
handler and aborts the app. Dialogs now go through craft-dialogs: a
command without a path asks with a continuation and returns, the host
shows the dialog at the end of the frame, and the continuation runs with
the answer on a later frame, in the document it was asked for. Commands
given a path stay synchronous. The replace-file question is a message
box from the same queue. Quit and Close wait for a Save As dialog's
answer. clippy.toml disallows rfd::FileDialog and rfd::MessageDialog.
* Raise the open file panel when File > Open is chosen again
* Repin craft-dialogs to the craft-libs PR head
* Queue dialogs asked by different code or documents; hold answers behind newer dialogs
Two asks for the same file dialog were treated as one, so Place for one
document and then Choose Image, or Place again for another document, ran
the first ask's action. An ask is now skipped (and the open panel
raised) only when the same code asked for the same dialog for the same
document. An answer that would replace an egui dialog opened since the
asking (an unsaved-changes question, Preferences) waits until it closes;
Quit counts it as pending.
* Repin craft-dialogs to the craft-libs PR head
* Allow the file dialogs' existence checks in the file guard
* Repin craft-dialogs to storytold/craft-libs main
- An option took the next token whatever it was, so `--export --scale` wrote a
file called `--scale` in the working directory. A token that cannot be a
value is refused, and where the value is a path the message offers the
shell's own way out (`./-name`). A negative number can still be a value, and
`-inf`/`-nan` still reach the check that reports them.
- An argument that is not UTF-8 panicked inside `std::env::args`. It is a
usage error now, named, since such a path cannot reach the engine anyway.
- `<sub> --help` was read as an unknown option by every parser but `script`'s.
It answers from the usage block, on stdout, and nothing else happens.
Rebased onto the post-split main, where the fix had to grow one part. Upstream
has since added a check that an export option sits before its `--export`, and
it consumed the following token whatever it was, so `--scale --export out.png`
was reported as the *order* of the options -- advice to move an option that is
already where it belongs -- when what is wrong is that `--scale` has no value.
That check now skips a value only where the next token can be one, and stands
aside entirely when a value is missing so the value error speaks. Its own test,
`run_export_options_come_before_their_export`, still passes.
The CLI's tests moved to tests/it/cli.rs, so the test additions went there.
The PDF exporter called Cache::get twice for every text frame it drew.
Each call rebuilds the cache signature of the whole story, which looks up
every frame of the story with Document::find (a linear walk over all
spreads), and the anchored-frame placements walk them again. For a story
threaded through many frames this is O(frames^2 x items) per export.
The document doesn't change during an export, so the exporter now keeps
the composition it got for each (story, page) and reuses it. The cache
still decides what to compose; the output is byte-identical.
Add examples/pdf_export.rs to designcraft-cli: File > Export PDF through
a headless session on the `designcraft-cli perf` stress document (200
pages, 1M characters in 40 threaded stories, 500 placed images). The
stress document generator moves unchanged from src/perf.rs to a small
library module (src/stress.rs) that the binary and the example share.
Ryzen 16 threads, Linux, 12 runs each, interleaved:
main median 3485 ms, min 3427 ms
patched median 2016 ms, min 1656 ms (-42 % median, -52 % min)
The exported PDF is byte-identical (12,075,744 bytes).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
aiongg
Dylan M. Taylor
dotCooCoo
texjer
aiongg
Hamza
Brandon Thomas
JonRC
FredApps
NetterSilverandClaude Opus 5.5
MarekSpodBiedry
r31linandClaude Opus 5.5
Marco Arnulfo