Document E-Filing

At a glance

NextPDF Enterprise optimizes a PDF into a delivery artifact suitable for e-court / government filing as configured by a jurisdiction profile, and splits it into size-bounded segments when a profile size limit is exceeded. It prepares formats for filing as configured; it does not guarantee that any document is accepted by a court or registry.

Availability & licensing

This capability ships in NextPDF Enterprise (nextpdf/enterprise) and activates with an Enterprise-tier license envelope. A deployment without that entitlement does not load the capability’s classes. Compare editions and get a license.

Install

composer require nextpdf/enterprise:^3

Conceptual overview

EFilingOptimizer runs a fixed pipeline against an input PDF:

1. Sanitization. Active content (JavaScript and actions) is removed through the content-disarm-and-reconstruction engine.
2. Linearization. The document is linearized for fast web view.
3. Size check and split. If the result exceeds the profile size limit, SizeAwareSplitter divides it into segments that each fit, using a binary search over page count to choose split points.

A jurisdiction profile (EFilingProfile) carries the constraints: maximum file size per segment, JPEG recompression quality, form flattening, JavaScript removal, linearization, and object-stream compression. Built-in profiles include US PACER (25 MiB cap), EU e-Justice (10 MiB cap), and Taiwan Judicial Yuan (10 MiB cap). The result (EFilingResult) reports the segments, the original and optimized sizes, the optimizations applied, and any warnings.

E-filing output is a delivery artifact, not a document-lifecycle state. An optimized or split PDF is final for transmission and must not re-enter a signing or archival pipeline, because re-processing would break hash chains and evidentiary integrity.

What this module does and does not claim

This module prepares formats for e-court / government filing as configured. It does not guarantee acceptance by any court, registry, or filing portal. Portal rules, accepted formats, size caps, and procedural requirements vary by jurisdiction and change over time. The built-in profiles encode commonly published constraints as a convenience; verify them against the current rules of the destination registry before filing.

Why it works this way

The pipeline runs in one fixed order — sanitize, linearize, size-check — because each stage consumes the previous stage’s output. Content disarm and reconstruction runs first, because filing inputs arrive from untrusted parties and must be disarmed before rewriting. Linearization precedes the size check because it changes the byte layout, and therefore the size the splitter must respect. splitByMaxSize() then verifies every produced segment against the profile’s maxFileSizeBytes cap rather than trusting an average-page estimate. A single page that still exceeds the cap is indivisible, so it surfaces as a warning rather than being dropped. The delivery artifact is excluded from re-signing and re-archival, because re-processing filed bytes would break evidentiary hash chains.

Design background: Sanitizing untrusted PDFs: content disarm and reconstruction.

API surface

Class	Responsibility
EFilingOptimizer	Run the sanitize → linearize → size-split pipeline.
EFilingProfile	Jurisdiction constraint profile (pacer(), euJustice(), taiwan(), or custom).
SizeAwareSplitter	Split a PDF into segments under a byte limit.
EFilingSegment	One output segment: bytes, page range, size, index.
EFilingResult	Aggregate: segments, sizes, optimizations, warnings.

Code sample — Quick start

use NextPDF\Enterprise\Document\EFiling\EFilingOptimizer;
use NextPDF\Enterprise\Document\EFiling\EFilingProfile;

$result = (new EFilingOptimizer())->optimize($pdfBytes, EFilingProfile::pacer());

Code sample — Production

$result = (new EFilingOptimizer())->optimize($pdfBytes, EFilingProfile::euJustice());

foreach ($result->warnings as $warning) {
    $logger->warning('efiling.warning', ['message' => $warning]);
}

foreach ($result->segments as $segment) {
    $store->put("filing/{$segment->segmentIndex}.pdf", $segment->pdfData);
}
// Confirm the destination registry's current rules before submitting.

Edge cases & gotchas

• A document already under the profile limit returns a single segment, unchanged in size terms.
• A single page that exceeds the limit cannot be split further; it is returned as one over-limit segment with a warning. Reduce image quality in a custom profile or pre-process the page.
• If sanitization rejects the input, a warning is recorded and the original bytes are kept; inspect warnings before filing.
• Built-in profile caps reflect commonly published values, not a live feed from each portal. Treat them as defaults to confirm.

Performance

Cost scales with document size and page count. Splitting performs a binary search over page count, so the number of split attempts is logarithmic in page count. Linearization and recompression dominate wall time for large image-heavy documents.

Security notes

Active content is removed before delivery through content disarm and reconstruction. Treat input PDFs from untrusted parties as hostile; the sanitization step is a mitigation, not a guarantee of safety for downstream systems.

Data residency & PII mitigations

Filed documents frequently contain personal and case data. Processing is in-process and local; the module performs no outbound network calls. Apply your own retention controls to segments and to the original.

Safe telemetry & log scrubbing

Warnings and optimization records describe pipeline actions, not document content. Avoid logging file paths or case identifiers from your surrounding code at shared sinks.

Conformance

Behavior	Reference	Status
Associated-file relationship semantics	ISO 19005-3:2012 §6.7.8	Honored where carriers apply
Embedded-file carrier requirements	ISO 19005-4:2020 Annex A	Honored where carriers apply

This table records specifications the surrounding PDF/A handling is built against. It is not a statement of acceptance by any court or registry.

FIPS-mode behavior

This module performs no cryptographic operations.

Threat model

Untrusted input PDFs carrying active content are the primary input. Mitigation: content disarm and reconstruction before linearization and delivery; the delivery artifact is excluded from re-signing and re-archival to protect evidentiary integrity.

Behavior contract

• EFilingOptimizer runs a fixed pipeline: content disarm and reconstruction, linearization, then a size check with binary-search splitting when a profile cap is exceeded.
• A document already under the profile limit returns a single unchanged-size segment.
• A single page over the limit is returned as one over-limit segment with a warning; it cannot be split further.
• An e-filing artifact is final for transmission and must not re-enter a signing or archival pipeline; re-processing would break hash chains and evidentiary integrity.

Publication boundary

This page documents externally observable behavior and the supported public API surface only. Internal namespace paths, helper classes, mechanism tables, runbook filenames, and ticket prefixes are out of scope.

Core fallback

NextPDF Core has no jurisdiction-profile e-filing optimizer, no CDR sanitization stage, and no size-aware splitter. A Core-only deployment must build any filing-preparation pipeline itself.

Pro fallback

NextPDF Pro does not provide the jurisdiction-profile e-filing optimizer, the built-in PACER / EU e-Justice / Taiwan Judicial Yuan profiles, the CDR sanitization stage, or the size-aware splitter. A configuration that requests profile-driven e-filing optimization in a Pro-only deployment has no Enterprise component to satisfy it. See the Enterprise overview for the Enterprise surface.

Enterprise boundary note

Internal mechanism detail stays in the source repository’s internal documentation and is out of scope for this manual.

Deployment boundary

Built-in profile caps encode commonly published constraints as a convenience, not a live feed from each portal; confirming them against the destination registry’s current rules before filing is the filer’s responsibility. Processing is in-process and local; the module makes no outbound network calls. Transport to a court, registry, or filing portal is external to this module.

Legal-compliance boundary

NextPDF prepares formats for e-court / government filing as configured by a jurisdiction profile. It does not guarantee that a document will be accepted by any court, registry, tribunal, or filing portal, and does not provide legal advice. Filing rules, accepted formats, size limits, signature requirements, and procedural deadlines are set by the relevant authority, vary by jurisdiction, and change. Verifying and meeting those rules is the filer’s responsibility. Consult counsel and the destination registry’s current guidance.

See also

• Document E-Filing reference — full public API surface for this module.
• Invoice — structured invoice generation.
• Enterprise overview
• Core vs Pro vs Enterprise feature matrix