read_smf_lenient keeps what comes before MAX_EVENTS events or MAX_TRACKS
tracks and only says so in a warning. Those warnings are words, and at
most MAX_WARNINGS of them are kept: when earlier damage has filled them,
nothing tells the caller that the file was cut.
LenientRead gets over_limit, set whenever either limit left something
out, full warnings or not. A caller that refuses over-limit files, as
read_smf does, can now do so after a lenient read. LenientRead is
non_exhaustive, so the new field breaks no caller.
SonarCloud S7688 counts the POSIX [ tests in the Opus vector fetcher. The
script already needs bash for arrays and ${!ranges[@]}, so the tests use
[[ ... ]], which neither word-splits nor globs its operands.
* image-codecs: list InkSet and ExtraSamples on TiffPage
* image-codecs: TiffPage InkSet and ExtraSamples as enums
* image-codecs: InkSet::InkNames, and Invalid for undefined tag values
Ported from storytold/lightcraft#3796. The Z 6 and Z 7 join the bodies whose
NikonNEFInfo distortion becomes an OpcodeList3 warp. Three Z 6 and three Z 7
CC0 raw.pixls.us files (NIKKOR Z 24-70mm f/4 S) were matched against the
camera's embedded JPEG: the corrected radial median error is 0.88-0.96 px on
the Z 6 and 1.37-1.46 px on the Z 7, from 83-84 px and 124-125 px uncorrected.
The method and results are in crates/raw/docs/nikon-lens-corrections.md.
DistortionInfo's mode byte must now be 1 (On, optional) or 3 (On, required).
Mode 2 (Off) and unknown modes give no warp, where before only 0 was skipped,
so mode-2 files from the Z 6II, Z 8 and Z f no longer get a warp.
* feat(ps): add craft-ps with an EPS reader (read feature)
The reading half of craft-ps (#115): a clean-room PostScript interpreter
that runs an EPS and returns what it paints as a one-page vector PDF of
its bounding box, colours kept, so apps can draw and export EPS as a
placed PDF. Moved from DesignCraft (storytold/designcraft, where it was
written for placed EPS), with its app-specific names made neutral.
Written from the PostScript Language Reference (3rd ed.), the EPS
specification, the Type 1 Font Format and Adobe TN 5012/5176/5177.
Covers the language, paths, clipping, strokepath, device/Separation/
DeviceN/Indexed/ICCBased/Lab colour, images with lazily decoded filters,
shadings 1-7 and patterns, and Type 1/3/42/CFF/CID text through CMaps,
horizontal and vertical.
Bounded: each operator charges work proportional to its operands
against the step limit as it goes, every byte read or decoded counts,
copies count against the memory cap; defaults 50 M steps / 1 GiB, and
20 M / 256 MiB on wasm32. No panics (deny lints, fuzzed in debug
builds). 34 tests, the Type 42 one on a TrueType font built in the
test. No new external crates: pdf-writer, miniz_oxide, weezl, skrifa
and kurbo are already locked at these versions.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* clippy(ps): document stateful decoder complexity
* fix(ps): bound huge arc angle normalization
* fix(ps): preserve EffectCraft EPS text and limits parity
* fix(ps): address interpreter review findings
* fix(ps): preserve composite glyph paint order
* fix(ps): address interpreter review findings
* fix(ps): bound filter buffers and preserve file aliases
* fix(ps): make predictor allocation fallible
---------
Co-authored-by: markus.doebele <markus.doebele@top21.sh>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
zune-jpeg also holds every coefficient beside its output when an 8-bit
sequential frame's first scan lacks some of its components: no row is
finished until the scans that bring the others. jpeg_info now reads the
first scan's component count and reports these as held_coefficients
(was progressive_coefficients). The #12473 map rewritten with one
component per scan was admitted at 12.6 GB without this, and
OOM-killed in a 14 GB cgroup.
Co-Authored-By: Νύξ (Nyx, AI) 🌑 <nyx@despotak.is>
zune-jpeg keeps every coefficient of an 8-bit progressive frame (SOF2)
beside its output: 2 bytes per sample, per component at its sampling.
That is 9.85 GB for a 48,000 x 34,200 4:4:4 file, more than the decoded
image. JpegInfo::progressive_coefficients reports them from the frame
header, so a caller can admit the decode against its real peak.
Co-Authored-By: Νύξ (Nyx, AI) 🌑 <nyx@despotak.is>
For storytold/photocraft#12473: PhotoCraft lifts its 2^30 px JPEG cap
only after admitting the decode against free memory, and for that it
needs the frame before decoding. jpeg_info reads it from the markers
alone: the stored size, the layout decode returns, and
whole_coefficients, set when decode hands the file to craft-jpeg
(arithmetic-coded, lossless or 12-bit frames), whose working set is
several times the decoded image. None without a frame of 1, 3 or 4
components.
This was part of storytold/photocraft#12604 until
storytold/photocraft#14236 moved the codecs here.
Co-Authored-By: Νύξ (Nyx, AI) 🌑 <nyx@despotak.is>