THotPDF.AddXFAPacket / ClearXFAPackets / XFAPacketCount

THotPDF XFA forms container (v2.119.51)

 

RegisterAcroFormFont  AcroForm Support

Registers a named XFA (XML Forms Architecture) packet for emission inside the document's AcroForm /XFA entry. PDF 1.7 §12.7.6 + §12.7.8 lets an AcroForm carry an /XFA array alongside (or instead of) the static /Fields array, enabling hybrid AcroForm + XFA workflows or pure dynamic XFA forms.

 

Delphi syntax:

procedure AddXFAPacket(const PacketName: AnsiString; const XMLBytes: TBytes);

procedure ClearXFAPackets;

function XFAPacketCount: Integer;

 

Description

Each call to AddXFAPacket registers one named packet. Typical names (per the XFA 3.3 specification and PDF 1.7 §12.7.8 Table 234):

 

template - form layout + scripts (the largest packet in most XFA documents).

datasets - data binding (the XML payload the template renders against).

config - viewer configuration.

connectionSet - external data connections.

localeSet - locale-specific formatting rules.

stylesheet - XSLT or CSS styling.

xfdf - XFDF form data overlay.

xmpmeta - XMP metadata.

signature - signature-related XFA data.

sourceSet - source-side data definitions.

 

At EndDoc each registered packet becomes one indirect FlateDecode-compressed stream object, and the AcroForm /XFA array alternates packet-name PDF strings with stream references in registration order, so the layout is byte-deterministic. ClearXFAPackets removes all registered packets (useful for reusing a THotPDF instance across multiple documents). XFAPacketCount returns the current count.

 

Container-level support only

HotPDF does not parse the XFA XML, does not implement the XFA dynamic-layout engine, does not execute FormCalc or JavaScript inside the XFA template, and does not validate template structure. The caller authors the XFA XML themselves (typically via Adobe LiveCycle Designer or hand-rolling against the XFA 3.3 specification) and HotPDF emits the bytes verbatim.

 

Consumer readers with an XFA engine (older Acrobat / Reader, FormsCentral, some kiosk products) render the form; readers without an XFA engine (Adobe Reader DC from 2017 onward, most open-source readers) display the fallback AcroForm fields if the document is a hybrid AcroForm + XFA workflow.

 

PDF/A and PDF/X compliance gates

ISO 19005-1 §6.4.2 / ISO 19005-2 §6.4.2 / ISO 19005-3 §6.4.2 all explicitly disallow XFA forms (the dynamic-layout engine is not deterministically archivable). ISO 15930 prepress workflows reject interactive forms entirely. AddXFAPacket raises immediately under any non-empty PDFACompliance or PDFXCompliance with the relevant spec reference. Duplicate packet names raise. Empty PacketName or empty XMLBytes raise. RequirePDFVersion(pdf15) auto-bumps the document version.

 

AcroForm dictionary emission

The AcroForm dict is emitted when either /Fields has at least one entry or at least one XFA packet has been registered. Pre-v2.119.51 callers that register no packets keep byte-identical /AcroForm output.

 

Typical workflow (pure XFA dynamic form)

 

PDF.BeginDoc;

TemplateBytes := TFile.ReadAllBytes('form-template.xml');

DataBytes     := TFile.ReadAllBytes('form-data.xml');

PDF.AddXFAPacket('template', TemplateBytes);

PDF.AddXFAPacket('datasets', DataBytes);

PDF.EndDoc;

 

See also: AcroForm Support, THotPDF.RegisterAcroFormFont, THPDFPage.AddTextField