Imposition

Wire validators prove structural and digest integrity only; they do not grant issuer trust or production authority. The opaque Rust verifier chain is the authority boundary that consumes a cryptographically verified preflight capability and verifies the complete input, capability, and plan chain.

Phase 3 now implements the canonical Rust handoff from immutable PDF bytes through foundation facts, Rust preflight, and a verified signed decision into TrustedVerifiedImpositionInputV3. Rust alone may mint the short-lived verifiedInputRef; TypeScript can check its transport binding but cannot issue it or recreate Rust authority. Ref issuance uses the trusted current time, and its full validity window must stay inside the underlying verified-decision receipt.

Phase 4 canonical fixed-point Rust planner is as-built. Its single entrypoint accepts one typed ImpositionPlanningRequestV3, binding the opaque trusted input, intent, Rust-evaluated opaque capability decision, and execution budget before planning; it returns an opaque verified plan. Callers cannot author an Allowed decision or seal a raw plan as production authority. It binds the exact intent digest and uses checked micropoint/UserUnit math. Phase 4 established N-up; the current Phase 8 matrix also includes step-and-repeat, cut-and-stack, and the fixed 2-up saddle-booklet contract described below. TypeScript no longer changes placement rotations or transforms after planning.

Phase 5 canonical Rust composer is as-built in ntp-pdf-compose. It accepts only immutable source bytes, the opaque trusted input, and the opaque verified plan. It writes a fresh deterministic PDF, uses Form XObjects, preserves supported inherited/shared resources through a bounded graph clone, and never edits the source or recalculates placements. Its receipt binds source, input, plan, composer options, the exact browser WASM or native runtime build identity, output hash/length, and the page count verified after writing. The receipt explicitly has productionReleaseAllowed=false: the composer receipt alone is not production evidence. Before issuing that receipt, the composer reparses the output and verifies its page order and sheet boxes plus every non-blank cell's exact placement matrix, /Fm{sourcePageIndex} resource binding, Form BBox, identity matrix, decoded source-content SHA-256, and a bounded, object-number-independent digest of the complete reachable Form resource graph. The receipt binds the resulting semantic placement proof and its canonical placement/source-content/source-resource manifests. The web output-validation receipt carries the exact composer receipt, all three manifest digests, verification engine, build SHA-256, placement counts, and limitations so preflight and passport consumers can audit the same proof identity. This proves deterministic structural placement against the verified plan; it does not claim RIP equivalence or measured raster evidence. External Reference XObjects and optional-content/marked-content property graphs are not in the Phase 5 subset; those files fail closed instead of silently losing catalog-level layer semantics. PostScript XObjects and OPI dictionaries also fail closed. Output boxes keep exact integer- micropoint precision, and separate limits cap sides, placements, output objects, working memory, and final bytes before unsafe materialization. Browser imposition-output WASM and the desktop binding call this Rust composer/assurance authority and emit exact-source structural evidence. That evidence remains deliberately non-production: it does not unlock a public or production claim.

The App Hosting writer uses the explicit canonical-v1 process protocol. Signed preflight authority and trusted-key selection are resolved only by trusted server orchestration, never from the public export request. If that orchestration is unavailable, export stays unavailable and the native process is not started. App Hosting keeps server export disabled until this trusted resolver is connected and evidenced.

Phase 6 post-imposition assurance is now as-built in Rust. It rechecks the exact composer output hash and length, collects canonical print facts, and runs the fixed print-baseline profile in production policy. A blocked result remains visible evidence but cannot mint final assurance; there is no fallback to a weaker screening profile. Optional measured render evidence must come from native PDFium. The signed isolation V4 receipt proves the isolated execution only; it does not make caller-provided raster evidence trusted. A separate supervisor-signed evidence envelope binds the exact output, postflight/foundation/geometry, expected PDFium build, raster evidence digest, isolation receipt digest, time window, trusted identity, and nonce. Rust verifies both signatures and consumes replay state last. If native evidence is unavailable, constructor-only digest-bound measured_unavailable records unique bounded limitations; invalid evidence is never downgraded into that state. Browser/WASM/preview pixels cannot become measured evidence.

The final assurance also binds the digest of the complete signed render-proof envelope, its supervisor issuer/key/trust-store, proof nonce, and proof time window. Its Ed25519 payload includes the signed schema, full assurance envelope, algorithm, identity fields, and envelope digest, so a reused key cannot silently relabel the authority. Signature, identity, limitation, page, raster, and isolation-limit inputs are bounded before hashing or cloning.

The signed Phase 6 assurance receipt still has productionReleaseAllowed=false and publicProductionClaimAllowed=false.

Phase 7 extends the existing enterprise job/runtime with a durable imposition boundary; it does not create a second queue or TypeScript imposition engine. The Rust-signed verified-input lease is bound to tenant, user, source artifact/SHA, TTL, and nonce, and only the Rust verifier can rehydrate opaque authority. Source, lease, and intent are resolved as private immutable artifacts with exact class, SHA, and byte-length checks; signed download URLs are not execution inputs. A missing native Rust binding fails closed with imposition_native_unavailable. A job cannot succeed without digest-bound plan, imposed PDF, postflight, and assurance manifests. The durable job keeps the authenticated submitter identity; idempotency is tenant-and-subject scoped, and both identities reach the Rust lease verifier. Result classes must be unique and allowlisted, requested render evidence must match the proof mode, and evidenceId must identify the assurance receipt. Lease and intent controls are each capped at 2 MiB before private bytes are resolved, and result artifact IDs must exactly match the unique manifest entries. Lease replay state is atomically bound to the first durable job ID: retries of that same job are idempotent, while a different job cannot reuse the nonce.

The Phase 12 canonical Rust planner supports N-up, step-and-repeat, row/column-major cut-and-stack, fixed 2-up saddle booklets, bounded multi-booklets, and gathered signature books. Booklet and signature modes use front/back two-slot sheets, left or right binding, LTR or RTL reading, and 4–64 pages per section in multiples of four. The exact source-page, padded-page, and sheet ranges are digest-bound to their physical placements. Sheet, placement, signature, contract, and geometry-operation budgets are checked before allocation.

The implemented fold models are the nested half-fold folio (nestedHalfFoldFolios, the default) plus the CIP4 catalog schemes f8-1 and f16-1 in the gathered signature-book mode. Catalog schemes use real per-cell tables (2×2 or 2×4 grids, top row rotated 180°) and are constrained to left binding, left-to-right reading, row-major fill, and long-edge duplex; creep and bleed extension are refused by name with catalog schemes. Press fold templates beyond this catalog subset, perfect-binding execution, and finishing-machine instructions remain unsupported and cannot be inferred from the signature manifest.

The Phase 9 canonical Rust optimizer provides a rectangular ganging and press digital-twin recommendation from opaque verified-input geometry. It compares sheet count, waste, estimated cost, and duration with checked integer units, immutable engine ceilings, explicit coordinate-axis grain, and bounded deterministic search. All item/source-box facts, every candidate, objective, budget, policy, and engine version are input-digest-bound; the opaque sealed result is semantically and cryptographically reverified. Only items from one verified input are accepted: cross-document compatibility and composition fail closed until signed authority exists. This is not a global-optimum, true-shape-nesting, or production-release claim; productionReleaseAllowed=false remains explicit and TypeScript ganging remains migration debt.

Phase 10 adds a 2 MiB bounded recommendation envelope and a deterministic 96-case resilience corpus. Decoded wire data is structural-integrity-only: it cannot mint or rehydrate opaque Rust recommendation or production authority. Search work is digest-bound and checked as deterministic engine-reported work units with exact-count and N-1 budget tests; it is not independently replayable authority. Bounded byte mutation exercises fail-closed decoding rather than making a wall-clock speed promise. The native adapter/deployment, signed cross-document compatibility authority, multi-source composer, and independent external conformance corpus remain pending, so publicProductionClaimAllowed=false.

This productization contract is not public activation. The public local browser lane can create a Rust V3 plan and imposed PDF without uploading the source PDF. Durable server, SDK, and MCP planning remain typed-unavailable with IMPOSITION_V3_RUNTIME_REQUIRED until the R3 immutable-byte runtime boundary is delivered; there is no HTTP, native-sidecar, or TypeScript planning fallback. Authenticated Studio users may opt into separately gated server render or preflight processing, and that consented lane must not be described as local-only. productionReleaseAllowed=false and publicProductionClaimAllowed=false remain authoritative.

Imposition places PDF pages onto press sheets for cutting, folding, binding, and production handoff. A good plan improves sheet usage, preserves page order for finishing, and gives the supplier a shared technical reference.

The critical distinction

An imposition preview plan is not an imposed PDF output.

A plan shows where pages land on each sheet side, which page boxes are used, and what transforms apply. An imposed PDF output is a separate export artifact and must be validated with an output receipt.

• A preview plan is for on-screen review.
• Imposed PDF output requires real PDF bytes, SHA-256, a safe file name, page count, and engine identity.
• Measured render evidence is never claimed without native PDFium render evidence and signed production policy.
• Browser preview pixels are not measured raster evidence or proof.
• The former TypeScript planning fallback is retired. A missing or rejected Rust V3 module returns a typed unavailable result and cannot create a plan, digest, token, or canonical export.

Operator workflow cockpit

The strongest lesson from Fiery Impose/JobMaster and FreeFlow Core is that imposition is an operator workflow, not a magic production button. NowToPrint Studio therefore shows the imposition step as a recipe, template/preset, job ticket, sheet preview, and hold reason before any output claim.

• Workflow recipe: explains the selected product intent, imposition mode, sheet, and mark policy.
• Job ticket: carries plan id, source preflight state, plan hash, output receipt, evidence state, and limitations.
• Template / preset: identifies the built-in or user/org-scoped template version and audit boundary.
• Sheet preview: exposes front/back sides, page order, rotation, trim/bleed boxes, marks, utilization, and waste.
• Hold reason: keeps operator or supplier review visible until output receipt, post-imposition preflight, and required independent acceptance receipts are complete.

This cockpit is not automatic production approval. Choosing a recipe or preset does not unlock production proof; it only clarifies how the plan should be reviewed and which evidence gaps keep the job on hold.

Document editing boundary

Foundation v1 is not full content editing. NowToPrint does not rewrite arbitrary text, images, color, transparency, fonts, or source PDF object streams as part of imposition. Page-level document operations such as reorder, rotate, delete, split, and merge are adjacent manifest-backed APIs; they are not imposition math.

Adding bleed area, adding production marks, or removing detected legacy marks can become future guarded operations. They cannot unlock a production claim without operator approval, mutation policy, rollback receipt, post-operation preflight, and PDFium measured raster evidence. Measured raster evidence is visual review evidence only; it is not proof, RIP equivalence, separation authority, or an automated production acceptance.

Sheet viewer controls

Studio's sheet canvas can switch between sheet content and page-number view. Sheet content uses the PDFium preview rasters already generated for on-screen review; page-number view draws imposition placements and blank positions when content preview is not useful. Zooming out shows more sheet sides per row, while zooming in reserves more canvas space for inspection. This is preview UX only: it does not change output bytes, placement math, proof status, or production authority.

Selected sheet, effective sheet, and minimum sheet

The selected sheet is the sheet size chosen by the user. The effective sheet is the sheet size used by the current plan/preview. The minimum sheet is the smallest custom sheet NowToPrint can calculate for the current layout without silently scaling or overflowing pages.

If the selected sheet is too small, Studio may calculate a larger minimum sheet for preview. That is an adjusted plan, not an accepted output state. Export availability stays locked until the user accepts the minimum sheet or chooses a larger sheet, and the output path still needs the normal receipt/evidence chain.

If the output writer is unavailable in the current runtime, Studio keeps the download action disabled and shows the reason. A disabled export button should not call the endpoint. If the server returns a controlled unavailable/failure response, the UI should show the specific next action instead of raw 500/503 text.

Why page boxes matter

Imposition uses MediaBox, CropBox, TrimBox, and BleedBox from the ntp-pdf-core PageGeometryTruth model.

• TrimBox defines the finished product boundary.
• BleedBox describes the safe bleed extent after trimming.
• CropBox constrains the visible working area.
• Non-zero origin and rotation are handled explicitly so overlays do not drift.

Bleed content is not synthesized

If bleed is missing, NowToPrint does not paint, mirror, rasterize, or invent new artwork at the page edge. Missing bleed remains a finding, limitation, or customer action. If the artwork must change, upload a corrected PDF.

Foundation modes

Mode	Use case	Evidence language
N-up	Place multiple pages on one sheet	Placement, trim/bleed rectangles, utilization
Step-and-repeat	Repeat one source page across a grid	Repeat count, order, waste
Spine-to-spine	Duplex paired N-up sheets	Front/back pairing, spine alignment, utilization
Booklet	Fixed 2-up saddle-stitch planning	Front/back page pairing, blank padding; no creep
Cut-and-stack	Cut and stack production planning	Stack order, physical cell order, blank padding
Multi-booklet	Independent 4–64 page saddle sections	Exact section/page/sheet ranges and blank padding
Signature-book	Gathered 4–64 page signature sections	Exact manifest plus nested half-fold folio limitation

Phase 12 gives canonical Rust plan authority to N-up, step-and-repeat, cut-and-stack, booklet, bounded multi-booklet, and gathered signature-book contracts. Each signature manifest is domain-separated, budgeted, and post-write proof-bound. Spine-to-spine remains a legacy preview surface. Canonical planning does not by itself grant public production activation: mode-specific composed output, PDFium proof, postflight, and release evidence must still pass the signed assurance boundary. The release verifier rechecks the Rust proof graph, two independent output runs, and measured PDFium-to-preview visual parity for all six modes at the exact source commit; browser preview pixels alone never satisfy this requirement. Creep, press fold templates, perfect-binding execution, large-format tiling, packaging ganging, and true-shape nesting are not production-ready public claims.

Marks and guides

Crop marks, fold marks, registration marks, color bars, gray bars, bleed guides, safe-area guides, spine guides, job labels, and QR/barcode identity marks can be carried as plan evidence.

Generated barcode or QR marks are not scanner-certified. Scanner verification needs separate evidence.

What creep means

Creep is the page shift that appears in thicker saddle-stitch work. The canonical V3 planner models it as a source-window translation derived from paper caliper (thickness) per sheet, disabled by default; when enabled, the per-sheet shift is part of the digest-sealed plan intent and is reported explicitly. The legacy foundation's basic linear model remains for preview compatibility; advanced creep profiles remain limitations.

Free browser imposition tools

Two public tool pages run the canonical chain entirely in the visitor's browser:

• Booklet imposition — fixed 2-up saddle-stitch booklet planning and local composition, with optional paper-caliper creep compensation.
• N-up imposition — 2-up/4-up grid layout on one sheet.

The file is read on the device and never uploaded; no account is required and use is not metered. Every downloadable output carries a sealed composition receipt (output SHA-256) and the result of a measured local post-imposition check. These pages are diagnostic self-service: the receipt language never claims production authority, and signed production decisions remain exclusive to the server lane described above.

Checks before production

Even when an imposed PDF is downloadable, the production claim is not automatic. The sequence is:

1. Source PDF preflight completes.
2. ntp-pdf-imposition produces the plan.
3. The Phase 5 Rust composer creates a fresh deterministic derived PDF and structural receipt.
4. Phase 6 reruns fixed print-baseline postflight over the exact output bytes.
5. Native PDFium measured evidence is optional; unavailable is explicit and preview is not measured.
6. The external signature verifier binds the assurance chain but keeps release/public claims false.
7. Phase 7 connects durable server execution to that chain; browser and desktop remain on the same Rust composer authority while every production/public claim stays closed.

The output receipt is a structural validation receipt: it proves that the derived PDF bytes were produced and that header, hash, byte length, file name, and page count checks matched. It does not prove that the imposed PDF is production-safe. Measured imposed-output raster evidence may only set visual_evidence_available; production acceptance stays blocked until independent conformance, supplier, and policy receipts are complete.

NowToPrint does not convert RGB to CMYK, convert spot colors to process, flatten transparency, generate trapping, mutate overprint, or outline/substitute fonts. Design intent, color behavior, and late-binding integrity are preserved.

Supplier handoff

Send the supplier the plan summary, selected profile, source preflight report id, plan hash, output receipt status, limitations, and post-imposition preflight/render evidence state. Raw storage refs, local paths, and debug JSON stay out of customer and public views.

Previous: PDF requirements | Next: Crop marks