Using PDF Studio
Use the five PDF Studio journeys, understand local-first processing, and distinguish preview, evidence, and operator diagnostics.
Using PDF Studio
PDF Studio keeps the original file, analysis, safe preparation, evidence, and handoff in one workspace. Its primary navigation has five customer journeys:
| Journey | Purpose |
|---|---|
| Inspect | Upload the PDF and review its pages and file summary. |
| Explain | Run available print checks and understand findings and evidence limits. |
| Prepare | Organize pages or create an imposition plan without silent color, font, trapping, or transparency changes. |
| Prove | Compare artifacts and review the available evidence level. A preview is not certified production proof. |
| Route | Prepare an evidence-bound RFQ or supplier handoff when the required document and evidence are available. |
Prepare and Prove contain focused sub-tools. Changing a sub-tool does not create a separate product or permission boundary.
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 Inspect 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, no larger than 200 MB, use the exact .pdf extension, have a blank or
application/pdf MIME value, and begin with the PDF %PDF- signature. Renamed files, double
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.
Responsive workspace and zoom
Studio adapts the same task state from 320 through 2560 CSS pixels; changing the viewport does not create another session or discard the current PDF. On mobile widths below 768 px, the production cockpit starts as a compact collapsed control and both side panels start closed. The left and right panel controls open one drawer at a time so the workspace is never covered by two panels. Upload or the current journey's primary action remains in the first viewport.
From 768 through 1023 px, Studio uses the canvas plus one applicable side panel. At 1024 px and above, both applicable panels can remain visible around the fluid canvas. At 200% and 400% browser zoom equivalents, the page reflows in document order, primary actions remain reachable, and wide journey or workflow controls scroll inside their own bounded region instead of widening the page.
Keyboard, touch, and non-drag operation
On compact widths, each side-panel button identifies and announces whether its panel is open. Opening a panel moves keyboard focus into it; Escape closes that compact panel and returns focus to the button that opened it. Persistent desktop panels remain ordinary complementary regions rather than modal focus traps. Scrollable drawers contain their own scroll chain.
Below 768 px, Studio buttons, visible form controls, and checkbox or radio labels expose at least a 44 by 44 CSS pixel hit area while browser zoom remains available. Native checkbox and radio glyphs are not enlarged. Organize and imposition do not require dragging: visible buttons provide move up/down, rotate, insert blank, split, delete/confirm, undo, merge, create, and download paths.
The engineering accessibility lane scans 12 explicit Studio states with enabled axe rules tagged through WCAG 2.2 AA, explicitly enables axe's 24 px target-size rule, and separately guards the 44 px product policy in source. It fails on critical or serious findings and on duplicate or nested main landmarks while attaching every axe violation to a JSON state report. That automated gate is not a WCAG certification or a substitute for current browser and assistive-technology testing.
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 sixth 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.
Depending on the safe error category, you can retry, resume from the last stable result, choose a different PDF, or continue with the Desktop Edge Hub. 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.
Was this article helpful?
Related articles
Last updated on
Preflight Check
Preflight is the final quality-control step before a PDF goes to print. Learn what NowToPrint checks, how browser and server analysis work together, and how to fix common issues.
Reading the Trust Passport
Learn how to read the NowToPrint PDF Tools report: readiness decision, evidence levels, Studio overlays, customer actions, and supplier notes.