Merges main through #3283 (Smart Filters: distinct editors, shared
disclosure and stable alpha).
filter_dialog.rs: main's split of the preview into is_smart_edit,
smart_preview_factor and scale_preview_params is kept. The plug-in branch
from #7524 (plugin_cmds::scale_for_preview scales only declared pixel
lengths) moved into scale_preview_params, so it applies to a plug-in run
on its own and to a plug-in recorded as a smart filter.
smart_ui.rs open_editor: main's smart_filter_dialog::target flow and the
shared adjust/filter dialog opening are kept; the Liquify re-open with
recorded strokes (r4) stays ahead of it. The old per-adjustment
edit_filter call is dropped with main's rewrite.
dialogs.rs: main's Displace-map prompt runs before the fallible confirm_command. filter_dialog.rs: main's ask_displace_map uses the new confirm_command signature; SMART_FILTER_SET_PARAMS stays for main's uses; a smart-filter edit without a "layer" param previews the active layer, as the command runs it (main's smart_displace_preview_uses_the_map_document).
Conflicts:
- filter_dialog.rs: preview_document_for_target keeps our proxy scaling
and `p` clone; main's Bitmap rule (the preview drops Output resolution,
#5559) is applied to the same `p`.
- hu/sr/tr/vi catalogs: both sides appended rows at the end; kept both, no
duplicate keys.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- swatches.import with bytes only (no path or format): an .act whose first
colour is 0, 1, x or 0, 2, x still went to the .aco reader, which ignores
trailing bytes and returned a handful of junk swatches. At the two .act
lengths (768/772) an .aco header now counts only when its sections span
the whole file (new `aco::sections_len`); a Photoshop .aco of exactly
768 bytes is still an .aco. Test: act_that_starts_like_an_aco_is_still_an_act.
- The .atn corpus tests (psd and engine) skipped unreadable folders and
entries silently; they now fail with the path.
- act::write doc: the trailer is written when `count` or `transparent` is given.
Co-authored-by: Abdul karim mia <97598943+abdul-karim-mia@users.noreply.github.com>
Co-authored-by: Fabio Lissi <fabio.lissi@gmail.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
fill_to (Paint Bucket export): keep main's `source` alias and explicit
colour (`Usng` = `Clr ` plus `Clr `, #7199) together with the PR's
optional `Tlrn`/`AntA`.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
type.create stored the font field as a family name, so an exact
PostScript face such as Arial-Black warned and fell back. Resolve
only an exact PostScript match and keep that face's family, weight,
slant, and name. Unknown families still warn.
Fixes#8063
Signed-off-by: Gabrieljr42 <gabrieljunior42566@gmail.com>
Found while testing crates/engine/src/file_cmds.rs:690 (xml_unescape), used by li_values, find_attr and read_file_info
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The warp places pixels within +-2^20 px (WARP_REACH) and clamps the rest
away. The byte budget admitted results wider than that (a 2,000,002 px
strip fits 8192 MB), and a plain move past it already emptied the layer
without an error. `warp_output_clipped` says when the result would be cut,
and the budget check refuses it: "would reach past +-1048576 px, the
farthest a transform places pixels". Docstrings for the touched functions.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The fixed 2^30 px cap refused any transform of a stitched layer past about
1 GP, on any machine. A result is now priced in bytes at its pixel format
(with the alpha the warp adds) against Preferences > Performance > Memory
Usage (default 8192 MB), which Session::apply_prefs sets. The report's
37708 x 35259 px 8-bit result (5072 MB) now transforms: 10.7 s, 6.1 GB on
top of the source. Past the allowance the message names it:
"... (10144 MB), more than the 8192 MB Memory Usage allows (Preferences >
Performance)".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A Gradient Overlay (and gradient strokes, linked patterns, linked bevel
textures) is laid out over the layer's bounds. Painting grows those
bounds, but the stroke commands reported only the stroke as damage, and
the canvas's committed-stroke path repainted only what the live stroke
had not shown. The canvas therefore kept the old gradient around earlier
strokes: one gradient per stroke instead of one over the whole layer.
Session dispatch now grows a command's reported damage by
photocraft_compose::relayout_damage(before, after): the whole composite
of any visible layer whose effects span its frame, when that frame moved.
The canvas adds the same area to a committed live stroke. Strokes inside
the existing bounds and frame-independent effects keep tight damage.
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Conflicts and how they were resolved:
- crates/ui-egui/src/canvas.rs (ensure_filter_preview): kept our edit_command(), which
also covers the Blending Options dialog and checks the target guard; main's
smart_ui::confirm_command(fields, cmd, params) form (#6324) is the same preview
(setParams on the proxy) without the guard.
- crates/ui-egui/src/filter_dialog.rs (preview_document_for_target): kept our scaling
of the smart filters' lengths and the mask feather on the proxy (proxy_document
already scales cache, placement and mask, so nothing is scaled twice); dropped
main's run-at-full-size branch for setParams and its now unused
SMART_FILTER_SET_PARAMS constant.
- crates/ui-egui/src/smart_ui.rs (open_editor): kept our open_editor (target guard,
adjust_dialog then filter_dialog with reset_fields, then __smartFilter and the
stored params) over main's edit_filter helper; adjustment edits keep their live
preview (adjust_preview skips the layer path for __smartFilter), so main's
__preview removal for __adjust is not needed.
Adapted to main's API: smart_ui::preview_command (main, #6324) now also returns the
Blending Options command for our blending dialog, so the preview window matches its
key.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CodeRabbit counts the functions around the lines a PR changes, not only the
changed ones, so the PR's docstring coverage stays low (59.49%, threshold 80%)
unless the untouched neighbours are documented too. Comments only; no code
changes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CodeRabbit measured the docstring coverage of the PR at 59.49%, under its 80%
threshold. Add short doc comments saying what each helper does and which
behaviour each test pins. Comments only; no code changes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
aiongg