Fill form rich tipizzato originale su Windows

I file job Windows e hpdf_document_execute_json_v1 accettano richieste forms.fill contenenti richTextRuns accanto ad aggiornamenti ordinari di testo, choice e button; tutti i campi condividono un unico PDF candidato autenticato

I run tipizzati originali arrivano direttamente al composer nativo degli appearance; la generazione AP non fa un round-trip attraverso la rappresentazione RV serializzata dei colori; V semplice, RV rich standard e AP reale vengono preparati insieme

Richiesta

{
  "schemaVersion": 1,
  "type": "forms.fill",
  "fontFamilies": ["DejaVu Sans", "DejaVu Serif Condensed"],
  "fields": [
    {"name": "Input", "richTextRuns": [
      {"text": "Original typed precision", "fontFamily": "DejaVu Sans",
       "fontStyle": "regular", "fontSize": 12.123456,
       "color": [0.123456, 0.234567, 0.345678]},
      {"text": "Another paragraph", "fontFamily": "DejaVu Serif Condensed",
       "fontStyle": "boldItalic", "fontSize": 14.125,
       "paragraphBreakBefore": true, "alignment": "center",
       "underline": true, "strikeOut": false}
    ]},
    {"name": "Plain", "value": "Changed scalar"},
    {"name": "Choice", "values": ["B", "C"]},
    {"name": "Check", "value": "Yes"}
  ]
}

Ogni campo fornisce richTextRuns oppure un valore scalare o values; un value opzionale accanto a richTextRuns deve corrispondere esattamente al testo semplice derivato nativo, inclusi i carriage return tra paragrafi tipizzati; il richText serializzato non è un input di run tipizzati

Ogni run richiede text e accetta fontStyle, fontSize, color, underline, strikeOut, paragraphBreakBefore e alignment; fontStyle è regular, bold, italic o boldItalic; alignment è left, center o right; le componenti RGB sono numeri finiti da zero a uno

Le dimensioni dei run devono essere positive e al massimo 4096 punti; una dimensione mancante usa il fontSize del campo o 12 punti; la formattazione numerica nativa PDF si applica comunque, mentre il RV CSS standard serializza i colori su componenti a otto bit

Le opzioni appearance dei campi includono fontSize, padding, characterSpacing, wordSpacing e paintWhiteBackground; la generazione AP genuina è obbligatoria, quindi appearance=false non è valido

Programmi font reali

Un array fontFamilies di campo sovrascrive quello dell'operazione; gli array configurati contengono da una a sedici etichette famiglia non vuote e valide; il matching piega il case ASCII e confronta esattamente gli altri Unicode; un fontFamily esplicito di run deve corrispondere a un'etichetta configurata, e un'etichetta run mancante seleziona la prima famiglia

Senza fontFamilies, l'originale percorso a famiglia singola resta disponibile; l'etichetta del callback font viene da fontFamily del campo, fontFamily dell'operazione o DejaVu Sans; i run originali a famiglia singola omettono il fontFamily del run

I file job aggiungono input, output e fonts; fonts mappa ogni etichetta famiglia configurata ai percorsi file regular, bold, italic e boldItalic; vengono caricati solo gli stili usati e la face regular necessaria agli appearance scalari; i percorsi file non devono essere alias dell'output

I chiamanti C ABI versionati usano l'esistente estensione hpdf_form_data_operation_v1 e restituiscono tabelle hpdf_io_v1 leggibili dal suo callback font; le etichette famiglia sono UTF-8 e i valori di stile vanno da 0 a 3; tutti i programmi reali vengono copiati in byte owned limitati prima di comporre gli appearance

I simboli V1 originali, le dimensioni delle strutture base e gli offset dell'estensione opzionale restano invariati; gli asset famiglia/stile vengono messi in cache entro una richiesta e condivisi tra campi senza addebitare la stessa allocazione owned più volte

fallbackFontFamilies=true opt-in applica il fallback whole-grapheme tra le famiglie fornite reali; i run tipizzati possono trattenere un array fontFamilyCandidates ordinato, con i candidati dichiarati considerati prima dell'ordine configurato; vedere Windows supplied-family rich font fallback per l'ereditarietà della richiesta e il caricamento callback a quattro stili

Grafo corrente e pubblicazione

Senza InputIO, la C ABI usa la propria revisione caricata owned e il grafo pending reale; un InputIO opzionale fornisce un PDF di rimpiazzo, copiato e autenticato privatamente prima di qualunque callback font; né la mutazione dell'input borrowed né un rimpiazzo fallito possono alterare il contesto committato

OutputIO e ResultIO sono obbligatori; il PDF candidato reale e il result JSON devono entrambi completarsi con successo, seguiti dal checkpoint finale di cancellazione, prima che la C ABI scambi documento e sorgente

Un callback fallito può aver già ricevuto byte candidato; i chiamanti devono scartare quei byte quando lo stato restituito è diverso da zero; il contesto della libreria committato in precedenza resta invariato

I file job mettono in staging il candidato completo e la risposta limitata prima della sostituzione atomica dell'output richiesto; un font mancante, un fallimento di policy, la cancellazione o un fallimento di capacità preservano il target esistente

Policy e risultato

L'integrità delle firme esistenti, DocMDP P1/P2/P3, i lock FieldMDP, i flag read-only e i permessi di form-fill AES vengono applicati attraverso l'engine nativo autenticato; signaturePolicy accetta le stesse impostazioni esplicite di trust, timestamp e revoca degli import form Windows

Un aggiornamento read-only con lo stesso input riesce solo quando operatori AP reali, font, risorse e valori dei campi sono equivalenti; gli stream AP compressi e un RV equivalente non canonico sono supportati; un vero cambiamento di stile resta un cambiamento anche se il suo colore RV quantizza allo stesso valore CSS

Una richiesta genuinamente invariata pubblica gli esatti byte della revisione corrente preparata dopo l'autenticazione della policy; le modifiche pending del grafo vengono materializzate in quella revisione corrente prima del confronto

Le risposte riuscite includono typedRichText=true, typedRichProfile=original-typed-runs-v1, updated, fieldCount, fontBytes e fields dal candidato preparato reale; formDataExchange.typedRichFill descrive questi punti di ingresso implementati

Ogni item fields conserva il nome ordinario, il valore scalare e il riassunto fieldType; una choice supportata da un array ha un valore scalare vuoto in questo riassunto, mentre la sua selezione completa resta nel PDF salvato e nel successivo export FDF/XFDF

La facciata job ExecuteLoadedOperation diretta e la più vecchia estensione callback handle/font HPDFDocRunJob restano lavoro separato; questo binding non aggiunge interchange di annotazioni, file incorporati, azioni o FDF incrementale

Argomenti correlati

FillTypedData, Transazione Windows, Aggiornamenti tipizzati misti nativi, Interchange FDF/XFDF Windows