THPDFHeadlessDocument.SaveRichTextFieldUpdatesToFile
function SaveRichTextFieldUpdatesToFile(const FileName: string;
const Updates: THPDFHeadlessRichTextFieldUpdates;
const Options: THPDFHeadlessFormDataOptions): Integer;Prepara e pubblica atomicamente un PDF indipendente contenente aggiornamenti di testo scalare, choice e pulsanti insieme ai veri run rich-text tipizzati; restituisce il numero di campi modificati mantenendo invariato il grafo documento caricato
Il grafo corrente è serializzato in una revisione privata autenticata prima di applicare gli aggiornamenti; modifiche pending esistenti di pagine e campi, credenziali AES R5/R6, identificatori di cifratura e prefissi firmati della sorgente restano disponibili per il candidato
I run tipizzati generano le appearance direttamente, senza un round trip di codifica/decodifica rich XML; /V e /RV descrivono il testo e gli stili autoriali, mentre /AP conserva la precisione numerica PDF del motore appearance esistente per le size e i colori tipizzati originali
Un no-op tipizzato richiede valori plain e rich equivalenti più stream appearance generati uguali e grafi font/risorsa risolti identici per ogni widget; il confronto decifra gli stream esistenti e normalizza i riferimenti a oggetti indiretti, invece di fidarsi dei soli colori /RV quantizzati
Questo consente campi read-only o bloccati da firma genuinamente invariati; un diverso colore di paint reale, size, font fornito o appearance del widget segue le normali restrizioni read-only, FieldMDP e DocMDP anche quando il valore rich serializzato per caso è identico
Il confronto è prudente sulle appearance esistenti: PDF autoriali esterni con risultati visivi equivalenti ma una rappresentazione diversa di operatori o risorse possono richiedere un ordinario aggiornamento protetto
Quando ogni campo richiesto è invariato e il grafo caricato non ha modifiche pending, il PDF pubblicato è byte per byte identico alla sorgente caricata, byte di cifratura AES esistenti e revisioni di firma autenticate inclusi; un array aggiornamenti vuoto segue la stessa regola, salvo i consueti controlli di compatibilità della sorgente
Le modifiche pending nel grafo del chiamante sono serializzate nel candidato una sola volta anche quando questo metodo restituisce zero modifiche ai campi; le modifiche non correlate e non salvate a pagine o campi sono preservate e il grafo caricato originale resta invariato
La pubblicazione senza aggiornamenti esegue comunque validazione di permessi e firme, controlli alias sorgente/destinazione, controlli del budget di output, cancellazione e sostituzione atomica della destinazione; i campi read-only e bloccati richiedono vera equivalenza di valore e appearance
Questo comportamento di conservazione dei byte si applica a questo metodo transazionale; il metodo generale SaveToFile e le API separate di import FDF/XFDF conservano il loro comportamento di salvataggio esistente
Conteggio campi, nomi duplicati, Unicode, dimensioni dei valori e capacità testuali aggregate usano Options; conteggio run tipizzati, unità glyph aggregate, byte font forniti, byte dei valori rich, oggetti generati e byte di confronto appearance usano anche i limiti del documento caricato
Un array di byte font gestito condiviso è contato una volta tra gli aggiornamenti; allocazioni distinte consumano capacità font di input separate anche quando i loro byte coincidono, mentre i budget di oggetti PDF generati e output coprono comunque tutte le appearance
Usa il cancellation token del documento per le opzioni modulo e appearance; campi non validi, valori malformati, permessi, autenticazione firma fallita, cancellazione o fallimenti di budget lasciano intatta la destinazione precedente, e gli alias sorgente/destinazione vengono rifiutati
L'API copre le transazioni miste native; il fill typed-rich JSON di Windows, la vecchia estensione callback dei job, l'interscambio di annotazioni e i dati FDF incorporati o incrementali sono workflow separati