Remplissage typé rich original des formulaires sous Windows

Les file jobs Windows et hpdf_document_execute_json_v1 acceptent des requêtes forms.fill contenant richTextRuns à côté de mises à jour ordinaires de texte, choice et boutons ; tous les champs partagent un PDF candidat authentifié unique

Les runs typés originaux parviennent directement au compositeur natif d’apparences ; la génération d’AP ne fait pas d’aller-retour par la représentation RV sérialisée des couleurs ; le V simple, le RV rich standard et l’AP réel sont préparés ensemble

Requête

{
  "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"}
  ]
}

Chaque champ fournit richTextRuns ou une valeur scalaire value ou values ; une value optionnelle à côté de richTextRuns doit correspondre exactement au texte simple dérivé natif, retours chariot entre paragraphes typés compris ; un richText sérialisé n’est pas une entrée de runs typés

Chaque run exige text et accepte fontStyle, fontSize, color, underline, strikeOut, paragraphBreakBefore et alignment ; fontStyle vaut regular, bold, italic ou boldItalic ; alignment vaut left, center ou right ; les composants RGB sont des nombres finis de zéro à un

Les tailles de runs doivent être positives et d’au plus 4096 points ; une taille manquante utilise le fontSize du champ ou 12 points ; le formatage numérique PDF natif s’applique toujours, tandis que le RV CSS standard sérialise les couleurs en composants huit bits

Les options d’apparences de champs incluent fontSize, padding, characterSpacing, wordSpacing et paintWhiteBackground ; la génération d’un vrai AP est requise, donc appearance=false est invalide

Vrais programmes de polices

Un tableau fontFamilies de champ remplace le tableau de l’opération ; les tableaux configurés contiennent de un à seize libellés de familles valides non vides ; la correspondance ignore la casse ASCII et compare exactement les autres caractères Unicode ; un fontFamily de run explicite doit correspondre à un libellé configuré, et un libellé de run manquant sélectionne la première famille

Sans fontFamilies, le chemin original à famille unique reste disponible ; le libellé du callback de police provient du fontFamily du champ, du fontFamily de l’opération ou de DejaVu Sans ; les runs originaux à famille unique omettent le fontFamily de run

Les file jobs ajoutent input, output et fonts ; fonts mappe chaque libellé de famille configuré vers des chemins de fichiers regular, bold, italic et boldItalic ; seuls les styles utilisés et la face regular nécessaire aux apparences scalaires sont chargés ; les chemins de fichiers ne doivent pas être des alias de la sortie

Les appelants C ABI versionnés utilisent l’extension hpdf_form_data_operation_v1 existante et renvoient des tables hpdf_io_v1 lisibles depuis son callback de police ; les libellés de familles sont en UTF-8 et les valeurs de style de 0 à 3 ; tous les vrais programmes sont copiés en octets possédés bornés avant la composition des apparences

Les symboles V1 originaux, les tailles de structures de base et les offsets d’extensions optionnels restent inchangés ; les ressources famille/style sont mises en cache au sein d’une requête et partagées entre champs sans facturer deux fois la même allocation possédée

Le fallback opt-in fallbackFontFamilies=true applique le fallback whole-graphème parmi les vraies familles fournies ; les runs typés peuvent conserver un tableau fontFamilyCandidates ordonné, les candidats déclarés étant considérés avant l’ordre configuré ; voir le fallback de polices rich Windows par familles fournies pour l’héritage de requête et le chargement de callbacks à quatre styles

Graphe courant et publication

Sans InputIO, le C ABI utilise sa révision chargée possédée et son graphe en attente réel ; un InputIO optionnel fournit un PDF de remplacement, copié et authentifié en privé avant tout callback de police ; ni une mutation de l’entrée empruntée ni un remplacement échoué ne peuvent altérer le contexte committé

OutputIO et ResultIO sont requis ; le PDF candidat réel et le JSON de résultat doivent tous deux se terminer avec succès, suivis du dernier checkpoint d’annulation, avant que le C ABI n’échange le document et la source

Un callback en échec peut avoir déjà reçu des octets du candidat ; les appelants doivent jeter ces octets quand le statut renvoyé est non nul ; le contexte de bibliothèque précédemment committé reste inchangé

Les file jobs mettent en scène le candidat complet et la réponse bornée avant le remplacement atomique de la sortie demandée ; une police manquante, un échec de politique, une annulation ou un échec de capacité préserve la cible existante

Politiques et résultat

L’intégrité des signatures existantes, DocMDP P1/P2/P3, les locks FieldMDP, les drapeaux lecture seule et les permissions de remplissage AES sont appliqués via le moteur natif authentifié ; signaturePolicy accepte les mêmes réglages explicites de confiance, d’horodatage et de révocation que les imports de formulaires Windows

Une mise à jour lecture seule à entrée identique ne réussit que si les opérateurs AP réels, polices, ressources et valeurs de champs sont équivalents ; les flux AP compressés et un RV équivalent non canonique sont pris en charge ; un vrai changement de style reste un changement même si sa couleur RV se quantifie vers la même valeur CSS

Une requête authentiquement inchangée publie les octets exacts de la révision courante préparée après authentification de la politique ; les éditions du graphe en attente sont matérialisées dans cette révision courante avant la comparaison

Les réponses réussies incluent typedRichText=true, typedRichProfile=original-typed-runs-v1, updated, fieldCount, fontBytes et fields issus du vrai candidat préparé ; formDataExchange.typedRichFill décrit ces points d’entrée implémentés

Chaque élément de fields conserve le name ordinaire, la valeur scalaire et le résumé fieldType ; un choice adossé à un tableau a une valeur scalaire vide dans ce résumé, tandis que sa sélection complète reste dans le PDF sauvegardé et l’export FDF/XFDF suivant

La façade de jobs ExecuteLoadedOperation directe et l’ancienne extension de callbacks handle/police HPDFDocRunJob restent des travaux séparés ; cette liaison n’ajoute pas d’échange d’annotations, de fichiers embarqués, d’actions ni de FDF incrémental

Sujets liés

FillTypedData, Transaction Windows, Mises à jour typées mixtes natives, Échange FDF/XFDF Windows