Using PDF Studio

PDF Studio keeps the original file, analysis, safe preparation, evidence, and handoff in one workspace. After a PDF is accepted, its strip follows the selected workflow. Upload is the entry operation rather than a fixed strip step. Current areas are Check, Repair, Prepare for print, Impose, Save and Share with your printer. Some workflow steps show progress without opening another panel. Actions remain subject to their document, runtime and access requirements. See the first Studio guide for the current labels and tasks.

Links and saved context

New Studio links use journey and tool query keys. Existing mode=review, preflight, organize, imposition, compare, or proof links continue in the corresponding journey. The retired mode=pro link safely opens File and cannot grant additional access. Report, finding, session, and debug references in the same link are preserved during migration.

Start with a PDF

Before a document is accepted, Studio presents one primary Upload PDF action and the equivalent drag-and-drop target. Journey navigation, production status, side panels, and workflow controls stay out of the way until there is a valid document. The file picker is keyboard accessible and resets after every attempt, so you can select the same file again after correcting an error.

Studio validates the file before calculating its source digest or starting preview work. A file must be non-empty, use a .pdf extension, have a blank or application/pdf MIME value, and contain a valid PDF header near its start. The default browser limit is 200 MB and 500 pages; a larger eligible server path has separate admission and explicit consent, and individual operations can have smaller bounds. See limits and privacy. Non-PDF extensions, MIME mismatches, empty files and false PDF headers are rejected with a focused error message. Rejecting a replacement does not discard the current valid document.

Panels, keyboard and zoom

Use the visible panel controls when the canvas needs more room. Compact layouts use drawers; a panel being closed does not cancel or finish a PDF operation. Open the current step's settings when you need to change its inputs, and read the reason shown for an unavailable action.

Page-edit and imposition controls offer button-based paths as well as pointer interactions. With canvas focus, 0 fits the page, W fits width, arrows pan, PageUp/PageDown change pages and N/P select findings. Use browser zoom and the available panel controls for your screen; preview size does not change the PDF's physical dimensions.

Canvas findings and report actions

Canvas findings are available as an ordered keyboard list linked to the viewer and source page. Selecting a list item moves the same selection shown on the canvas; merely hovering over a marker does not announce or change the selection. Error, warning, and information levels use visible localized text and different marker patterns as well as colour. The selected page and finding expose their current state programmatically.

Preflight output controls appear progressively. Before a report exists, Studio explains the missing prerequisite instead of showing a wall of disabled downloads. When the report is ready, one primary report action is shown and secondary formats are available under More report actions. Passport and RFQ actions appear only when their evidence prerequisites are satisfied; otherwise Studio names what is still missing. Reduced-motion removes Studio animations and transitions, while forced-colour mode preserves visible focus and selection using system colours and non-colour cues.

Operator diagnostics

Operator diagnostics are an entitlement-controlled lens over the same workflow. They are not a separate customer journey. A URL parameter cannot enable the lens; the server must verify the user's role, entitlement, and feature disclosure. Users without that access see the same customer workflow and no raw operator diagnostics.

Local-first and evidence boundaries

PDF Studio prefers browser-local processing. A server lane requires the applicable product gate, an authenticated principal, and explicit consent. Before that consent, Studio does not POST the PDF bytes or its source hash to the preflight or rendering lanes. Preview pixels, analysis findings, output receipts, and production proof are distinct evidence types. The workspace names unavailable or preview-only evidence instead of silently promoting it.

Consent is bound to the current signed-in principal and the enabled server lanes. Switching accounts, changing the lane gates, or withdrawing consent revokes it immediately: active server requests are aborted, and queued preflight or render work rechecks permission before sending bytes. An already-open document continues through the browser-local renderer when that local path is available; the user does not have to upload it again merely because server consent changed.

PDF Studio does not automatically convert RGB to CMYK, flatten transparency, create trapping, outline fonts, or make other destructive prepress rewrites.

Cancel, retry, and recovery

Studio runs one job per stage. Repeated clicks do not start duplicate analysis, preparation, or output jobs. When you cancel a supported active job, Studio stops that job and keeps both the source PDF and the last stable preview, report, prepared artifact, or output. Retry and Resume stay disabled until the cancelled browser job has actually settled. This prevents a late result from the cancelled attempt from being attached to a new attempt.

When an operation cannot continue, the recovery notice explains:

• what happened;
• what happened to your file and last stable result;
• what you can do next.

Use only the recovery actions offered for that error. They may include retry, resume, a different PDF or Desktop Edge Hub. A deterministic layout refusal needs the named setting changed; the same engine may refuse the same settings on Desktop too. A retry receives a new job identity. If the engine or profile changed, the previous artifact remains in lineage but is marked stale instead of being presented as current evidence.

Retry repeats the exact failed attempt: its source artifact, page-operation manifest, imposition plan, mode, and settings do not silently change to values edited after the failure. To run the new values, start a new action instead of using Retry. A failed retry also keeps the last stable output and post-imposition evidence available.

Encrypted, damaged, unsupported, over-limit, offline, runtime-integrity, timeout, memory, and security-restricted cases are shown as different recovery states. Encryption takes precedence over secondary parser damage signals. Password text and raw parser or worker diagnostics are not shown or copied into Studio's public recovery state.

Offline local work is allowed only when the required runtime can be loaded from the content-addressed cache, passes its integrity checks, and reaches the ready state. If that runtime is missing, stale, corrupt, or unavailable, Studio stops safely and offers retry or the Desktop path instead of silently changing execution authority.

When the verified local runtime cannot run, Studio disables the affected check, organize, imposition, output, postflight, and Safe Repair actions and shows a localized recovery reason. Existing stable reports and downloads remain visible where they do not require a new runtime job. Report downloads use only the result accepted by the current Studio workflow, never a transient result left by a previous PDF.

Replacing a PDF and safe repair

Selecting a non-PDF or otherwise invalid replacement leaves the current valid PDF session intact. Once Studio accepts a valid replacement, it clears the previous document, evidence, plans, and outputs before loading the new file. If that load fails, Studio shows recovery for the new file; it does not keep the previous pages visible under the new session. A late hash, progress event, or job result from the previous file cannot replace the newer document.

After an accepted safe repair, Studio creates the prepared artifact and immediately runs preflight on that exact repaired output. It also retires imposition plans, outputs, and postflight evidence derived from the previous prepared source. Selecting another PDF cannot redirect the delayed repair check to the replacement document, and Studio does not show an Applied receipt unless the workflow accepted the repair.

Regenerating an organized PDF follows the same acceptance boundary. Only an accepted replacement retires the imposition plan, imposed output, and postflight evidence derived from the previous prepared bytes; a failed, cancelled, or superseded organize run preserves the last stable evidence.