The PDF importer renders each page with PDFium at the import DPI (default 300), lays the
pages out side by side and wraps each in an artboard, so a 2-page PDF opens as 2 artboards
and saves back as a 2-page PDF (one page per artboard, page-sized, labelled). The import
caps at 16 pages for now.
The PDF writer now takes a list of pages: shared font/ICC/selection objects, one image per
page, and the existing one-page export is the single-page case. Artboards with vector/text
layers are rasterised in this path.
Tested: artboards_export_as_one_page_each; convert sample.pdf app-multi.pdf (2 pages),
rendered back with the probe.
File > Open, drag-and-drop and photocraft-cli now accept PDF files. The first page is
rendered with PDFium at 300 dpi (ImportOptions.pdf_dpi), built through the flat
importer, and the document resolution keeps the page's print size. The page count is
reported; multi-page import is the next step (#2541 / FILE-215-10).
- crates/io: pdf_import module, native-only pdfium-render + image deps, import and
preflight dispatch (.ai keeps its existing path).
- PDFium loads from the executable's folder or PDFIUM_DIR.
The Linux runner has no GPU, so the GPU tests ran on Mesa llvmpipe over
GL, which can't render Rgba32Float: 57 GPU checks (50 GPU parity, 3
canvas, 2 adjustment preview parity, 2 effect-map recovery) returned
early and passed without comparing anything. A new step after Test
installs mesa-vulkan-drivers and runs the nextest `gpu` group on
lavapipe (Vulkan), reusing Test's build, and fails unless the parity
tests report the Vulkan backend and no test printed a skip.
No code change: photocraft's tests take whatever adapter wgpu returns,
software adapters included. Follows the CI half of lightcraft#1148.
Co-authored-by: FredApps <FredApps@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Add an opt-in WinTab backend for pen pressure on Windows
Windows Ink stays the default. Preferences > Tools > Pen Tablet has a Tablet
input dropdown (Windows Ink (default) / WinTab). WinTab opens a WinTab 1.4
system context on PhotoCraft's window and polls pressure and the eraser end
(tilt on devices that report orientation axes; rotation only with a pen and
driver that report twist) into the stylus feed. The row says to turn Windows
Ink off in the tablet's software utility; the choice applies at next launch.
- crates/tablet: Windows-only wintab/wintab-sys backend. Devices with
orientation axes use the orientation packet; pressure-only devices open a
packet without it and report neutral tilt. Leaving is the driver's hardware
proximity message (WT_PROXIMITY) and the packet's out-of-context status, with
a long fallback for drivers that never report either. Overlap priority
follows window focus, and the message hook requests a frame for each WinTab
message so pressure-only strokes update without cursor movement.
- apps/photocraft: install the backend when the preference is on; poll it at
the start of each frame; the installed wake repaints the UI.
- ui-egui: TabletPollFn service; the Windows-only Pen Tablet row with the
Tablet input dropdown and the note.
- engine: tools.tabletInput (windowsInk/winTab), default windowsInk.
- docs: hardware-parity WinTab gap entry, qualifying tilt to orientation axes
and rotation to twist-reporting pens.
Tested locally on a Wacom tablet with Windows Ink off: pressure, tilt and the
eraser end reach the brush (rotation where the pen reports twist); the default
path is unchanged.
* WinTab: a message that finds the state borrowed is skipped, not a panic in the hook
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WinTab: rustfmt
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Scorecard: count the Tablet input setting
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: FredApps <153173854+FredApps@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Present the live scratch state as current configuration rather than the cause of a file's refusal. Explain that configured scratch capacity cannot override caller/build limits or replace non-spillable memory. Keep the typed error and admission policy unchanged, and add wording regressions.
Formatting and whitespace checks passed. No local build or test execution; validation awaits hosted CI.
Visit at most four output tiles per closing work unit and honor the caller's deadline between batches. Sparse images with distant opaque corners otherwise make one final poll scan the whole resized surface.
Add a sparse-output regression at 8, 16 and 32-bit requiring multiple closing polls, identical pixels, and removal of the same empty tiles. Formatting and whitespace checks passed; compilation and test execution await hosted CI.
* PSD write recipes: keep every exported candidate and pin the base file
A case that failed after export dropped out of manifest.json, losing the
file a reference-editor check most needs. The CLI also reopened the corpus
path after the hash was taken.
- Keep the candidate and its hash once export succeeds.
- Run the CLI on a copy of the hashed bytes, so it never opens the corpus.
- Compare numbers by value, so 17 equals 17.0.
- tracking-split also checks runs 0 and 2 and all three run lengths.
Part of #6130.
* PSD write recipes: compare large integers exactly, reject case-only id clashes
Converting to f64 made 9007199254740993 equal 9007199254740992. Ids that
differ only by letter case name one output directory on a case-insensitive
filesystem, so they are now rejected as duplicates.
* PSD write recipes: test that the CLI receives the hashed bytes
* PSD write recipes: reject the contour library commands
Their path param can read or write any file, including the pinned base and
the corpus, and they edit no document.
A stuck close no longer holds up the files queued behind it (up to four
closer threads), and a query identifies the current file by the configured
folder. Tests don't read the room and the status across a late answer, and
the growth-check step proves its query is stalled.
The whole folder change now waits 2 s at most, old files close on one
background thread, the cap counts query threads until they finish, and
writes during a query aren't counted twice. Capacity is refused if a sweep
paused spilling meanwhile, a query opens a file unless this folder has one,
and on macOS an unrelated dead mount only costs the purgeable figure.
Converting a document (layer copy to another mode/profile, Image > Mode,
Convert to Profile with or without dither, Duotone inks) converted run colours
but not the colours set by character/paragraph styles and Basic Paragraph, so
converted runs showed a false local override and stopped following later
style edits. Duplicate Layer > New Document dropped the source's Basic
Paragraph, giving inheriting type false overrides.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Opening and measuring the folder ran under the config lock, which the UI
takes every frame, and could run on the UI thread itself. They now run on
a short-lived thread, one per folder and question and 16 overall; callers
wait at most 2 s, and a late answer applies if the folder is still current.
No answer counts as unmeasured, or pauses spilling if nothing is open yet.
With 1 GiB or less of free RAM, or 512 MiB or less of commit headroom, the
hard limit was exactly 0, so even a small file was refused with a message that
didn't say memory was low.
The reserve now shrinks with the measurement: up to a quarter of free RAM opens
automatically, the rest goes to approval, and an approved import always leaves
at least 256 MiB free. Limits are unchanged for automatic opening above 4/3 GiB
free and for approval from 4 GiB free. A refusal set by measured memory now
gives the free amount and says to close other apps and try again, and the
approval prompt warns when little memory would be left.
An unreadable cgroup still measures Some(0) and stays refused.
A guard that is a temporary in an if condition drops before the body runs, so a configuration change
could still land between the two.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Triwarr
David Mann
Khawar Zamman Wani