Échange de formulaires riches ABI C Linux native

L'opération forms.import existante accepte le RV FDF et le value-richtext XFDF via les callbacks InputIO versionnés de l'appelant et publie un PDF mis à jour authentique via OutputIO

La version V1 de l'ABI, les symboles exportés et le layout de la table de callbacks restent inchangés ; ce binding cible le Linux x64 natif

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

Le PDF de destination doit déjà être chargé ; InputIO fournit les véritables octets de form-data plutôt qu'un autre PDF

Le profil inline-xhtml-v1 préserve l'ordre du texte Unicode mixte, les sauts de paragraphes et de lignes explicites, les tailles de polices inline héritées, les couleurs RGB, la graisse, l'italique, le souligné, le barré et l'alignement de paragraphes via le décodeur XHTML natif borné

Les familles de polices riches nommées optionnelles sélectionnent les programmes configurés avec des listes de familles CSS héritées ; la mise en page CSS arbitraire, les feuilles de style externes, les tableaux, les images et l'alignement vertical restent des capacités séparées

fontFamily sélectionne les véritables programmes regular, bold, italic et bold-italic du provider de polices natif ; seuls les styles requis par les valeurs riches réelles sont chargés, avec le programme regular utilisé par les champs scalaires

La configuration Fontconfig du déploiement doit fournir la famille et les faces souhaitées ; le fallback normal du provider s'applique quand une face demandée est indisponible, et fontStyles décrit les slots de styles chargés plutôt que de certifier les faces de polices installées

Les programmes de polices reviennent à l'appelant dans les streams de polices embarqués du PDF préparé et les apparences réelles ; aucun chemin de fichiers de polices n'est exposé dans la réponse JSON

Quand fontSize vaut zéro, le XHTML sans style utilise la valeur par défaut de 12 points du décodeur ; les tailles de polices XHTML explicites prises en charge conservent leurs propres valeurs

Le markup riche canonique et non canonique équivalent est idempotent quand son texte et ses styles pris en charge correspondent ; les champs read-only inchangés préservent leur RV source, tandis que des styles pris en charge différents font respecter la protection read-only

Un import sans changement publie l'instantané PDF privé exact validé, y compris les révisions signées ou chiffrées existantes, sans accumuler de révisions de références croisées vides ; des octets d'entrée ou des fichiers sous-jacents modifiés de l'appelant ne remplacent pas cet instantané chargé

L'import préserve la sécurité AES authentifiée, les révisions signées réelles, les décisions DocMDP P1/P2/P3 et les verrous FieldMDP via la transaction d'import riche native

Les programmes de polices combinés sont bornés à un quart de limits.memoryBytes, en plus de la limite native par police ; les limites existantes de form-data, de glyphes, d'objets, de sortie et de résultats restent actives

Les callbacks s'exécutent de manière synchrone sur le thread appelant ; les callbacks d'entrée et de sortie partiels sont acceptés, et l'annulation reste active pendant le parsing, le chargement de polices, la préparation d'apparences et la publication

Le handle ne valide qu'après le succès des callbacks PDF et JSON ; une erreur de callback ou une annulation préserve son état précédent, tandis que l'appelant jette les octets partiels déjà reçus par un sink

Les capacités annoncent formData.richXML=true, le richXMLProfile=inline-xhtml-v1 par défaut compatible, les deux richXMLProfiles, la sélection optionnelle de familles nommées jusqu'à seize étiquettes et les quatre fontStyles pris en charge ; l'échange d'annotations reste false

Callbacks et limites de form-data · ABI C Linux native · Options de trust de signature

Les feuilles de style internes appliquent sélecteurs bornés, importance, spécificité et ordre source aux valeurs rich réellement importées et aux apparences sauvegardées ; les imports équivalents répétés et les publications en échec conservent les garanties transactionnelles existantes

richTextResources fournit le texte CSS lié et importé via l'opération execute-json-v1 inchangée

Utilisez FPC 3.3.1 ou plus récent avec les unités de runtime correspondantes, et consignez le build réel du compilateur utilisé pour l'acceptation

L'analyse des opérations JSON préserve les NUL échappés et les clés d'objets Unicode ; un NUL dans richTextResources est rejeté avant que le document ne change, au lieu de disparaître silencieusement pendant le décodage JSON

La porte réutilisable Tests/Linux/JSONOperationUnicode/Run.py contrôle le parseur produit sélectionné, tandis que la suite de callbacks réelle contrôle aussi la bibliothèque partagée compilée et la transaction PDF