Échange FDF/XFDF Windows

Les file jobs Windows et hpdf_document_execute_json_v1 implémentent forms.export et forms.import pour fdf et xfdf en utilisant les codecs natifs scalaire et XHTML/CSS rich borné

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 utilise input, output, format et password optionnel ; il n’exige ni formDataInput ni fonts ; les file jobs réservent un candidat exclusif à côté de la cible, le flushent et le ferment, valident le JSON de résultat borné, puis remplacent la cible atomiquement

Polices manquantes, entrée mal formée, échecs d’authentification ou de politique, limites épuisées et publication échouée préservent la cible complète existante ; la sortie ne doit pas être un alias du PDF ni de l’entrée de données de formulaire, hard link compris

Familles de polices nommées

forms.import accepte fontFamilies à la racine de l’opération comme tableau de un à seize libellés ; l’absence conserve le profil original à famille unique et le libellé de callback fontFamily

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

Pour les file jobs, fonts contient des objets indexés par les libellés configurés exacts ; sans fontFamilies, il conserve l’objet original à chemins de styles directs ; lisez seulement de vrais programmes famille/style, tous les octets de polices sélectionnées partageant le budget de l’opération

Pour les callbacks Windows V1, le callback de police existant reçoit chaque libellé configuré UTF-8 canonique réel et le style sélectionné ; deux familles utilisant les quatre styles produisent huit vraies demandes de programmes sans changer le record de callback

Les lettres ASCII des libellés se comparent sans casse tandis que les autres caractères Unicode se comparent exactement ; les libellés sont distincts, non vides et d’au plus 128 unités de code UTF-16, sans espaces englobants, caractères de contrôle, surrogates non appariés ni ponctuation de quotes/séparateurs CSS

La première famille configurée est le défaut pour le texte scalaire et les styles rich hérités ; par défaut, les listes CSS font-family utilisent la sélection première-connue du codec natif

Le fallback opt-in fallbackFontFamilies=true préserve les candidats CSS font-family inline ordonnés et charge de vrais programmes de faces/styles configurés pour le fallback whole-graphème ; voir le fallback de polices rich Windows par familles fournies pour les candidats typés, le chargement par callbacks et la portée rich-only

Le résultat appliqué rapporte richXMLProfile inline-xhtml-font-families-v1, le tableau fontFamilies configuré et de vrais objets fontFamilyStyles contenant family, style et bytes ; fontStyles garde son type original objet-tableau et résume les comptages d’octets par style ; fontBytes compte tous les vrais programmes

Sans le tableau, richXMLProfile vaut inline-xhtml-v1 ; le forms.fill mixte scalaire et typed-rich original utilise la liaison separate original-typed-runs-v1 décrite ci-dessous ; l’ancienne extension de callback de police des jobs reste un travail de suivi séparé

Callbacks C Windows versionnés

Incluez hotpdf_abi_form_data.h ; remplissez hpdf_form_data_operation_v1, définissez operation.struct_size à sa taille complète et passez son préfixe d’opération inchangé à hpdf_document_execute_json_v1

Le callback de police optionnel reçoit les octets UTF-8 de la famille et le style 0 regular, 1 bold, 2 italic ou 3 boldItalic, et renvoie une table de lecture hpdf_io_v1 complète pour le vrai programme de police ; fournissez les quatre programmes quand les données rich utilisent les quatre styles

Les données scalaires demandent le programme regular ; fontFamily vaut DejaVu Sans par défaut ; les callbacks IO de polices fournis et leurs données utilisateur doivent rester valides jusqu’au retour de l’opération ; les statuts de callbacks non nuls sont sticky et se propagent sans retry de fallback

Pour forms.import, InputIO fournit le FDF/XFDF et la destination doit déjà être chargée ; OutputIO reçoit le PDF candidat et ResultIO reçoit le JSON borné ; forms.export utilise le record V1 original et écrit le FDF/XFDF dans OutputIO

Le hpdf_document_load_from_io Windows copie l’entrée complète vers une source possédée immuable avant de revenir ; un remplacement ou un ajout par l’appelant ne peut changer la révision chargée active ni sa sortie de données de formulaire ultérieure

Les sources possédées utilisent un handle synchronisé séparé pour les lectures aléatoires en arrière-plan, si bien que le prefetch ne peut déplacer le curseur de publication séquentiel ; le document candidat libère ses lecteurs d’arrière-plan avant que sa source ne soit détruite

Le contexte actif ne change qu’après le succès des callbacks de sortie et de résultat et le passage du dernier checkpoint d’annulation ; un échec ou une annulation de callback jette le candidat et conserve le document précédent et la source possédée

Un callback peut avoir reçu des octets du candidat avant qu’un callback ultérieur n’échoue ; les appelants ne doivent commiter leur propre destination de sortie qu’après que la fonction execute a renvoyé HPDF_STATUS_OK

Les dispositions de records V1 originales et les symboles exportés sont inchangés ; cette extension Windows est séparée de l’extension de callbacks publiée du Linux natif

Les points d’entrée liés sont le processeur de file jobs et hpdf_document_execute_json_v1 ; l’ancien record de callback HPDFDocRunJob et le ExecuteLoadedOperation générique n’acquièrent pas d’extension de police à ce stade ; les appelants Pascal peuvent utiliser la classe de transaction explicite

Champs, texte rich et politique

Les valeurs prises en charge incluent les noms de texte Unicode imbriqués, les noms d’export checkbox et radio, les tableaux multiselect et les valeurs lecture seule inchangées ; /V, /RV et les vraies ressources AP sont sauvegardés ensemble ; champs inconnus et contraintes de champs requis font échouer la transaction

L’échange rich utilise le profil XHTML/CSS borné documenté et de vraies polices de style fournies ; il ne prétend pas prendre en charge le HTML arbitraire, tout le CSS ni le XML rich sans restriction

Les mises à jour signées AES R5/R6 conservent le préfixe original complet, les paramètres de chiffrement, l’identifiant de chiffrement permanent et la signature CMS existante ; les imports scalaires ou rich inchangés sont identiques à l’octet près à la révision committée courante

L’intégrité CMS existante et la liaison de signataires ESS sont authentifiées avant les mises à jour de formulaires signés ; le remplissage P2/P3 n’est permis que dans ses contraintes réelles ; P1, les locks FieldMDP et les champs lecture seule modifiés refusent la publication

signaturePolicy accepte les booléens requireCAdES, requireTimestamp, requireAdobeRevocationInfo et requireTimestampRevocation ; trustedCAFile, timestampCAFile, timestampCRLFile et revocationCAFile doivent être des chaînes sans NUL et sélectionnent une confiance explicite de l’appelant pour les vérifications demandées

Les options des callbacks C bornent aussi les preuves signées via maxEvidenceBytes et maxEvidenceObjects ; la validation de confiance est distincte de la vérification d’intégrité de signatures par défaut

formData peut abaisser maxBytes, maxFields, maxObjects, maxDepth, maxValues, maxValueCodeUnits et maxTotalCodeUnits ; ces entiers positifs exacts sont en outre clampés par la capacité de travail ; les budget objectCount et pageCount limitent les documents candidats

budget.timeMilliseconds fixe le deadline de l’opération ; les callbacks C Windows acceptent aussi elapsedMilliseconds comme borne additionnelle plus serrée ; l’annulation est sondée pendant la préparation du graphe courant, le décodage des formulaires, la lecture des polices, les vérifications CMS, le chargement du candidat et la publication

Les capacités rapportent les vrais formats, styles, entrée immuable et comportement transactionnel des callbacks ; l’échange d’annotations, les fichiers FDF embarqués, les actions et les documents FDF incrémentaux restent des capacités séparées non achevées

Sujets liés

Le remplissage mixte scalaire et typed rich original utilise le même cycle de vie de candidats Windows authentifié via file jobs et execute-json-v1

Classe de transaction, Préparation du graphe courant, Données de formulaires natives

Les feuilles de style internes appliquent sélecteurs bornés, importance, spécificité et ordre source aux valeurs riches réellement importées et aux apparences enregistrées ; les imports équivalents répétés et la publication en échec gardent les garanties transactionnelles existantes

richTextResources fournit le CSS lié et importé pour les jobs de fichiers Windows réels et les imports execute-json-v1, avec la transaction et la liaison de polices existantes