Build an offline package recipients can actually use
An offline preview needs a clear boundary: which files are included, what supported device or drive is required, whether installation is needed, and what the reviewer must return or destroy. Packaging is an operational process, not only a conversion step.
A reviewer receives a USB package containing selected chapters, a rights note and viewing instructions. The package opens only from its original media on supported Windows devices. If those conditions are not explained and tested, the restriction can become a support failure rather than a useful control.
Run a verifiable release workflow
- 01Use only the rights-cleared, accepted media versions.
- 02Prepare a manifest with module identifiers, versions and expected file counts.
- 03Create the package on approved media using the documented product workflow.
- 04Open every item from the final physical package on a clean target device.
- 05Seal, identify and dispatch the package through a traceable process.
Leave a record another coordinator can follow
Record package ID, included versions, media identifier, creation tool/version, test device, tester, result, recipient, dispatch date and planned return or retirement.
Pause and review when
- The package contains masters or source assets not needed for review.
- Instructions promise support for devices or formats that were never tested.
- The only copy of the final preview exists on the distribution medium.
A technical restriction is not complete control
Do not promise screen-capture prevention, web DRM or support for every format/device. Test only the workflow you intend to claim, preserve unrestricted authorized masters separately, and pair technology with rights, custody, versioning and support.
Resolve these before release
Is copying to a USB drive the same as controlled packaging?
No. Control also requires rights, minimization, versioning, verified playback, custody and clear recipient instructions.
Can the package support every device?
No. State only the device, operating system, format and workflow combinations that were actually verified.
Retest the whole preview path
Repeat the documented test after any change to the judge screener, rights terms, PDF export, embedded media, Copy Protect release, Windows version, removable drive, reviewer device or delivery instructions. Use fictional pages and non-sensitive artwork during technical checks. Ask a second operator to follow the written procedure without verbal help, identify the approved revision, open every intended component, recognize unsupported behavior and locate the recovery owner. Record the date, operator, package identifier, device baseline, observed result and corrective action. Preserve the unrestricted authorized master separately so a failed restriction, damaged drive or forgotten password cannot become the only route to the publisher's work.
Sources for this decision
Links support the specific question on this page and do not imply endorsement. Copyright, contracts, platform policy and local law control the actual decision; seek qualified advice for legal conclusions.