Native Linux C ABI rich form interchange

The existing forms.import operation accepts FDF RV and XFDF value-richtext through the caller's versioned InputIO callbacks and publishes a genuine updated PDF through OutputIO

The V1 ABI version, exported symbols and callback table layout remain unchanged; this binding targets native Linux x64

{"schemaVersion":1,"type":"forms.import","format":"xfdf","fontFamily":"DejaVu Sans","fontSize":12}

The destination PDF must already be loaded; InputIO supplies the actual form-data bytes rather than another PDF

The inline-xhtml-v1 profile preserves mixed Unicode text order, paragraph and explicit line breaks, inherited inline font sizes, RGB colours, weight, italic, underline, strikeout and paragraph alignment through the bounded native XHTML decoder

Optional named rich font families select configured programs with inherited CSS family lists; arbitrary CSS layout, external style sheets, tables, images and vertical alignment remain separate capabilities

fontFamily selects the native font provider's real regular, bold, italic and bold-italic programs; only styles required by the actual rich values are loaded, together with the regular program used by scalar fields

The deployment's Fontconfig configuration must supply the desired family and faces; normal provider fallback applies when a requested face is unavailable, and fontStyles describes the loaded style slots rather than certifying installed font faces

The font programs return to the caller inside the prepared PDF's embedded font streams and real appearances; no font file paths are exposed in the JSON response

When fontSize is zero, unstyled XHTML uses the decoder's 12-point default; explicit supported XHTML font sizes retain their own values

Result fieldMeaning
updatedChanged terminal field count, including supported style-only changes
richFieldCountNumber of rich fields in the decoded input, including equivalent unchanged values
fontStylesActually loaded font slots in regular, bold, italic, boldItalic order
richXMLProfileinline-xhtml-v1 or inline-xhtml-font-families-v1 when the decoded input contains rich fields
fontFamiliesConfigured family labels when the optional named-family array is supplied

Equivalent canonical and noncanonical rich markup is idempotent when its text and supported styles match; unchanged read-only fields preserve their source RV, whilst different supported styles enforce read-only protection

A zero-change import publishes the exact committed private PDF snapshot, including existing signed or encrypted revisions, without accumulating empty cross-reference revisions; changed caller input bytes or backing files do not replace that loaded snapshot

Import preserves authenticated AES security, actual signed revisions, DocMDP P1/P2/P3 decisions and FieldMDP locks through the native rich import transaction

The combined font programs are bounded to one quarter of limits.memoryBytes, in addition to the per-font native limit; existing form-data, glyph, object, output and result limits remain active

Callbacks execute synchronously on the calling thread; partial input and output callbacks are accepted, and cancellation remains active during parsing, font loading, appearance preparation and publication

The handle commits only after both PDF and JSON callbacks succeed; a callback error or cancellation preserves its previous state, whilst the caller discards any partial bytes already received by a sink

Capabilities advertise formData.richXML=true, the compatible default richXMLProfile=inline-xhtml-v1, both richXMLProfiles, optional named-family selection up to sixteen labels and the four supported fontStyles; annotation interchange remains false

Form-data callbacks and limits · Native Linux C ABI · Signature trust options

Internal style sheets apply bounded selectors, importance, specificity and source order to actual imported rich values and saved appearances; repeated equivalent imports and failed publication retain the existing transaction guarantees

richTextResources supplies linked and imported CSS text through the unchanged execute-json-v1 operation

Use FPC 3.3.1 or later with matching runtime units, and record the actual compiler build used for acceptance

JSON operation parsing preserves escaped NUL and Unicode object keys; a NUL in richTextResources is rejected before the document changes, rather than silently disappearing during JSON decoding

The reusable Tests/Linux/JSONOperationUnicode/Run.py gate checks the selected product parser, whilst the actual callback suite also checks the compiled shared library and PDF transaction