THPDFHeadlessDocument.SaveRichTextFieldUpdatesToFile
function SaveRichTextFieldUpdatesToFile(const FileName: string;
const Updates: THPDFHeadlessRichTextFieldUpdates;
const Options: THPDFHeadlessFormDataOptions): Integer;Prépare et publie atomiquement un PDF indépendant contenant les mises à jour de texte scalaire, choice et bouton avec les runs rich text typés d'origine ; retourne le nombre de champs modifiés tout en gardant le graphe du document chargé inchangé
Le graphe courant est sérialisé dans une révision privée authentifiée avant l'application des mises à jour ; les éditions de pages et champs non sauvegardées existantes, identifiants AES R5/R6, identifiants de chiffrement et préfixes signés de la source restent disponibles pour le candidat
Les runs typés génèrent les apparences directement, sans aller-retour d'encodage/décodage XML rich ; /V et /RV décrivent le texte et les styles rédigés, tandis que /AP conserve la précision numérique PDF du moteur d'apparences existant pour les tailles et couleurs typées d'origine
Un no-op typé exige des valeurs plain et rich équivalentes plus des streams d'apparence générés identiques et des graphes de polices/ressources résolus identiques pour chaque widget ; la comparaison déchiffre les streams existants et normalise les références d'objets indirectes, au lieu de se fier aux seules couleurs /RV quantifiées
Cela permet des champs réellement inchangés en lecture seule ou verrouillés par signature ; une couleur de peinture réelle, taille, police fournie ou apparence de widget différente suit les restrictions normales de lecture seule, FieldMDP et DocMDP même quand la valeur rich sérialisée se trouve être identique
La comparaison est prudente sur les apparences existantes : des PDF rédigés de l'extérieur avec des résultats visuels équivalents mais une représentation d'opérateurs ou de ressources différente peuvent exiger une mise à jour protégée ordinaire ; cette API ne promet pas une sortie no-op à l'octet identique
Quand chaque champ demandé est inchangé et que le graphe chargé n'a pas d'éditions en attente, le PDF publié est identique octet pour octet au source chargé, octets de chiffrement AES existants et révisions de signature authentifiées compris ; un tableau de mises à jour vide suit la même règle, sous réserve des contrôles de compatibilité source existants
Les éditions en attente du graphe appelant sont sérialisées dans la candidate une seule fois même quand cette méthode ne renvoie aucun changement de champ ; les changements de pages ou de champs non liés et non sauvegardés sont préservés, et le graphe chargé d'origine reste inchangé
La publication sans mise à jour effectue quand même la validation des permissions et signatures, les contrôles d'alias source/destination, les contrôles de budget de sortie, l'annulation et le remplacement atomique de la destination ; les champs en lecture seule et verrouillés exigent une équivalence réelle de valeur et d'apparence
Ce comportement de préservation d'octets s'applique à cette méthode transactionnelle ; la méthode SaveToFile générale et les API séparées d'import FDF/XFDF conservent leur comportement de sauvegarde existant
Le nombre de champs, noms dupliqués, Unicode, tailles de valeurs et capacités de texte cumulées utilisent Options ; le nombre de runs typés, unités de glyphes cumulées, octets de polices fournis, octets de valeurs rich, objets générés et octets de comparaison d'apparences utilisent aussi les limites du document chargé
Un tableau d'octets de police managé partagé est compté une fois à travers les mises à jour ; des allocations distinctes consomment une capacité de polices d'entrée séparée même quand leurs octets coïncident, tandis que les budgets d'objets PDF générés et de sortie couvrent toujours toutes les apparences
Utilisez le cancellation token du document pour les options de formulaires et d'apparences ; champs invalides, valeurs malformées, permissions, authentification de signature échouée, annulation ou échecs de budget laissent la destination précédente intacte, et les alias source/destination sont rejetés
L'API couvre les transactions mixtes natives ; le remplissage typed-rich JSON Windows, l'extension de callbacks de jobs plus ancienne, l'échange d'annotations et les données FDF embarquées ou incrémentales sont des workflows séparés