Windows supplied-family rich font fallback

Windows file jobs and hpdf_document_execute_json_v1 support opt-in fallback among caller-supplied font families for rich FDF/XFDF imports and original typed rich runs; fallback selects a family that covers the entire grapheme, including parts crossing rich style boundaries

The default remains strict: fallbackFontFamilies is false and a missing required glyph fails normally; supplying a list does not silently select installed system fonts

Typed request

{
  "schemaVersion": 1,
  "type": "forms.fill",
  "fontFamilies": ["Primary", "Sans", "Serif"],
  "fallbackFontFamilies": true,
  "fields": [{"name": "Input", "richTextRuns": [
    {"text": "A\u03a9a\u0301", "fontStyle": "regular",
     "fontFamilyCandidates": ["Unavailable", "Primary", "Serif", "Sans"]}
  ]}]
}

fontFamilies contains one through sixteen distinct configured labels; ASCII letters compare without case and other Unicode code points compare exactly; field-level fontFamilies and fallbackFontFamilies override their operation defaults for forms.fill

A typed run may specify one through sixteen ordered fontFamilyCandidates when configured-family fallback is enabled; unknown names remain in authored metadata and are skipped during supplied-program resolution; if fontFamily is absent, the first configured declared candidate becomes the run family

A declared candidate list controls preference before configured-family order; in this example, a Primary font missing Omega selects Serif before Sans when both supplied alternatives cover the entire grapheme

Rich XML import

For forms.import, use the operation-level fontFamilies and fallbackFontFamilies properties; the bounded XHTML decoder preserves each inline CSS font-family list and the real appearance composer applies that order to the supplied font programs

<span style="font-family:Primary,Serif,Sans;font-weight:bold">AΩá</span>

Both FDF RV strings and XFDF value-richtext use this path; the existing inline-xhtml-font-families-v1 profile remains unchanged, while actual fallback behavior is reported separately

Real font bytes

The existing THPDFCABIFormDataOperationV1 font callback receives each canonical configured family label and regular, bold, italic or boldItalic style identifier; it returns the original bounded read-IO table and its bytes are copied into owned storage

File jobs read the same family/style programs from their existing fonts object; for each used rich style, the binding loads configured candidate programs before preparing the transaction; matching assets are shared across typed fields

The V1 IO and operation layouts and existing exported symbols remain unchanged; aggregate asset, font-byte, memory, field, object, result and output budgets remain enforced; callback failures remain sticky and cancellation checkpoints cover parsing, loading, preparation and publication

Transactions and limits

AES authentication, signed revision preservation, DocMDP, field locks and read-only checks use the existing authenticated transaction; same-input rich values, styles, fonts and appearance semantics can produce a byte-identical no-op, including read-only fields

PDF and JSON callbacks must both succeed before the current context changes; discard emitted candidate bytes after any nonzero status; file jobs prepare the complete candidate before replacing the target

formDataExchange.suppliedFamilyFallback reports default=false, richOnly=false, scalarText=true, choiceLabels=true, checkAndRadioMarks=true, comb=true, passwordMask=true, wholeGrapheme=true, fontFamilyCandidates=true, maxCandidates=16 and candidateOrder=declared-before-configured

Supplied-family scalar fallback also covers ordinary text, choice labels and checkbox or radio marks through Windows jobs and versioned callbacks; native pushbutton-caption setters use their documented family-aware appearance APIs

Direct loaded-job rich filling, the older job handle/font callback extension, arbitrary CSS layout, external style sheets and further FDF/XFDF annotation, file, action or incremental interchange remain separate work

Related topics

Original typed rich filling, Windows form-data exchange, Versioned font transport, Native supplied families