Windows FDF/XFDF Exchange

Windows file jobs and hpdf_document_execute_json_v1 implement forms.export and forms.import for fdf and xfdf using the native scalar and bounded rich XHTML/CSS codecs

File jobs

{
  "schemaVersion": 1, "type": "forms.import", "format": "xfdf",
  "input": "source.pdf", "output": "filled.pdf", "password": "owner",
  "formDataInput": "values.xfdf",
  "fonts": {
    "regular": "DejaVuSans.ttf", "bold": "DejaVuSans-Bold.ttf",
    "italic": "DejaVuSans-Oblique.ttf", "boldItalic": "DejaVuSans-BoldOblique.ttf"
  },
  "budget": {"memoryBytes": 268435456, "outputBytes": 134217728,
    "timeMilliseconds": 60000, "resultBytes": 16777216}
}

forms.export uses input, output, format and optional password; it does not require formDataInput or fonts; file jobs reserve an exclusive candidate beside the target, flush and close it, validate bounded result JSON, then replace the target atomically

Missing fonts, malformed input, authentication or policy failures, exhausted limits and failed publication preserve the existing complete target; output must not alias the PDF or form-data input, including a hard link

Named font families

forms.import accepts fontFamilies at the operation root as an array of one through sixteen labels; absence retains the original single-family profile and fontFamily callback label

"fontFamilies": ["DejaVu Sans", "DejaVu Serif Condensed"],
"fonts": {
  "DejaVu Sans": {
    "regular": "DejaVuSans.ttf", "bold": "DejaVuSans-Bold.ttf",
    "italic": "DejaVuSans-Oblique.ttf", "boldItalic": "DejaVuSans-BoldOblique.ttf"
  },
  "DejaVu Serif Condensed": {
    "regular": "DejaVuSerifCondensed.ttf", "bold": "DejaVuSerifCondensed-Bold.ttf",
    "italic": "DejaVuSerifCondensed-Italic.ttf", "boldItalic": "DejaVuSerifCondensed-BoldItalic.ttf"
  }
}

For file jobs, fonts contains objects keyed by the exact configured labels; without fontFamilies it retains the original direct style-path object; read only actual family/style programs, with all selected font bytes sharing the operation budget

For Windows V1 callbacks, the existing font callback receives each actual canonical UTF-8 configured label and selected style; two families using all four styles make eight real program requests without changing the callback record

ASCII label letters compare without case while other Unicode characters compare exactly; labels are distinct, nonempty and at most 128 UTF-16 code units, with no surrounding whitespace, controls, unpaired surrogates or CSS quote/separator punctuation

The first configured family is the default for scalar text and inherited rich styles; by default, CSS font-family lists use the native codec's first-known-family selection

Opt-in fallbackFontFamilies=true preserves ordered inline CSS font-family candidates and loads actual configured face/style programs for whole-grapheme fallback; see Windows supplied-family rich font fallback for typed candidates, callback loading and the rich-only scope

The applied result reports richXMLProfile inline-xhtml-font-families-v1, the configured fontFamilies array and actual fontFamilyStyles objects containing family, style and bytes; fontStyles keeps its original object-array type and summarizes byte counts by style; fontBytes counts all actual programs

Without the array, richXMLProfile is inline-xhtml-v1; mixed scalar and original typed-rich forms.fill uses the separate original-typed-runs-v1 binding described below; the older job font callback extension remains separate follow-up work

Versioned Windows C callbacks

Include hotpdf_abi_form_data.h; fill hpdf_form_data_operation_v1, set operation.struct_size to its complete size, and pass its unchanged operation prefix to hpdf_document_execute_json_v1

The optional font callback receives UTF-8 family bytes and style 0 regular, 1 bold, 2 italic or 3 boldItalic, and returns a complete hpdf_io_v1 read table for the actual font program; provide all four programs when rich data uses all four styles

Scalar data requests the regular program; fontFamily defaults to DejaVu Sans; supplied font IO callbacks and user data must remain valid until the operation returns; nonzero callback statuses are sticky and are propagated without a fallback retry

For forms.import, InputIO supplies FDF/XFDF and the destination must already be loaded; OutputIO receives the candidate PDF and ResultIO receives bounded JSON; forms.export uses the original V1 record and writes FDF/XFDF to OutputIO

Windows hpdf_document_load_from_io copies the complete input to an immutable owned source before returning; caller replacement or appending cannot change the active loaded revision or its later form-data output

Owned sources use a separate synchronized handle for background random reads, so prefetch cannot move the sequential publication cursor; the candidate document releases its background readers before its source is destroyed

The active context changes only after both output and result callbacks succeed and the final cancellation checkpoint passes; callback failure or cancellation discards the candidate and retains the previous document and owned source

A callback may have received candidate bytes before a later callback fails; callers must commit their own output destination only after the execute function returns HPDF_STATUS_OK

The original V1 record layouts and exported symbols are unchanged; this Windows extension is separate from native Linux's published callback extension

The bound entry points are the file job processor and hpdf_document_execute_json_v1; the older HPDFDocRunJob callback record and generic ExecuteLoadedOperation do not acquire a font extension in this stage; Pascal callers can use the explicit transaction class

Fields, rich text and policy

Supported values include nested Unicode text names, checkbox and radio export names, multiselect arrays and unchanged read-only values; /V, /RV and genuine AP resources are saved together; unknown fields and required field constraints fail the transaction

Rich interchange uses the documented bounded XHTML/CSS profile and real supplied style fonts; it does not claim arbitrary HTML, all CSS or unrestricted rich XML support

Signed AES R5/R6 updates retain the complete original prefix, encryption parameters, permanent encryption identifier and existing CMS signature; unchanged scalar or rich imports are byte-identical to the current committed revision

Existing CMS integrity and ESS signer binding are authenticated before signed form updates; P2/P3 filling is permitted only within its actual constraints; P1, FieldMDP locks and changed read-only fields refuse publication

signaturePolicy accepts Boolean requireCAdES, requireTimestamp, requireAdobeRevocationInfo and requireTimestampRevocation; trustedCAFile, timestampCAFile, timestampCRLFile and revocationCAFile must be strings without NUL and select explicit caller trust for the requested checks

C callback options also bound signed evidence through maxEvidenceBytes and maxEvidenceObjects; trust validation is distinct from the default signature integrity check

formData can lower maxBytes, maxFields, maxObjects, maxDepth, maxValues, maxValueCodeUnits and maxTotalCodeUnits; these exact positive integers are additionally clamped by the working capacity; budget objectCount and pageCount limit candidate documents

budget.timeMilliseconds sets the operation deadline; Windows C callbacks also accept elapsedMilliseconds as an additional tighter bound; cancellation is polled during current graph preparation, form decoding, font reading, CMS checks, candidate loading and publication

Capabilities report actual formats, styles, immutable input and transactional callback behavior; mapped annotation XFDF exchange is implemented separately, while embedded FDF files, wider actions and incremental FDF documents remain unfinished

Windows FDF/XFDF Exchange

File jobs

Named font families

Versioned Windows C callbacks

Fields, rich text and policy

Related topics