|
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
Delphi syntax: procedure AddXFAPacket(const PacketName: AnsiString; const XMLBytes: TBytes); procedure ClearXFAPackets; function XFAPacketCount: Integer;
Description Each call to
At
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.
AcroForm dictionary emission The AcroForm dict is emitted when either
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 |