Open and Place read Affinity documents natively (.af from Affinity 3,
.afdesign/.afphoto/.afpub from Affinity 1 and 2): layers and sublayers,
groups, artboards with their names and backgrounds, Publisher pages side
by side, curves with live corners, parametric shapes, compound shapes,
clipping by nesting, vector and pixel masks, solid and gradient fills,
strokes, fill layers, artistic and frame text, placed images (their
original JPEG/PNG), pixel layers, embedded documents as their cached
picture, opacity, visibility, locking and blend modes, at the document's
resolution in points. Unsupported content (effects, adjustments, brushes,
master pages, special shapes, Affinity-only blend modes...) is listed in
the import warning, one line per kind. A file whose native data can't be
read opens as its embedded preview with the reason, and that preview
cannot be placed or used as a template or library. Save never writes back
over the Affinity file and there is no Affinity export.
The document semantics were fitted to the thumbnails Affinity embeds in
176 public documents. `cargo xtask corpus --affinity` fetches 22 public
CC0/MIT/Apache-2.0 documents at pinned commits, sha256-verified; the new
engine test renders each and compares it with Affinity's own thumbnail
(0-4.4 of 255 mean difference, per-file ceilings). import_fuzz mutates a
synthetic native document's stream and container through open, render
and export; the fuzz crate gains a stream target.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GQPh8UDgMyARR5Hat9UchC
Read only the indexed PNG thumbnail observed in version-12 Affinity containers. Bound and validate the PNG before decoding, warn about omitted native content, clear the source save target, and reject auxiliary imports that cannot display that warning. Add malformed-input, lifecycle, property and optional native-oracle tests plus a fuzz target. Editable native layers and Affinity export remain unsupported.
Finder, Open With, a drop on the Dock icon and `open -a` failed with "VectorCraft cannot open
files in the PDF document format":
- The release Info.plist declared no document types, so Launch Services refused the files before
the app saw them. Info.plist.in now declares every format File › Open reads (the engine's
OPEN_EXTS; a test keeps them in step): VectorCraft owns its own documents and templates and is an
alternate for the others, so it takes over no other app's files. `cargo xtask bundle` now fills
in the same template instead of its own, shorter plist.
- macOS delivers such files as open-document events, not arguments. winit 0.30's application
delegate has no `application:openURLs:`, so AppKit fell back to NSDocumentController, which
refuses every file of a non-NSDocument app (the error in both issues). The new
`open_documents` module adds that method to the delegate's class when the app is about to finish
launching (before AppKit delivers launch files), queues the paths and wakes the UI, which opens
them with `io::open_path` like command-line files; errors go to the status bar too.
New direct macOS dependencies `objc2-foundation` 0.3 and `block2` 0.6 were already in Cargo.lock
(through winit, muda and rfd). The module allows `unsafe_code` for the Objective-C runtime call.
Fixes#354
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Drop the file types and wording carried over from the sibling raster
editor: the macOS exported type now declares .vectorcraft/.drawcraft
(was .pcraft) and the raster imported types (large raster documents, QOI)
are gone; the dev bundle's PDF type is "PDF Document"; Linux categories and
keywords say vector graphics (no trademark keyword), the AppStream
description and screenshot show VectorCraft, and the deb/rpm, MSI and web
embedding descriptions say vector illustration app. File associations stay
as they are. An xtask test rejects raster-editor wording in packaging/.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
