THPDFHeadlessDocument.SaveRichTextFieldUpdatesToFile

function SaveRichTextFieldUpdatesToFile(const FileName: string;
  const Updates: THPDFHeadlessRichTextFieldUpdates;
  const Options: THPDFHeadlessFormDataOptions): Integer;

Bereitet ein unabhängiges PDF mit skalaren Text-, Choice- und Button-Updates zusammen mit originalen typisierten Rich-Text-Runs vor und veröffentlicht es atomar; liefert die Anzahl geänderter Felder und hält den geladenen Dokumentgraphen unverändert

Der aktuelle Graph wird serialisiert in eine private authentifizierte Revision, bevor Updates angewendet werden; bestehende ungespeicherte Seiten- und Feldbearbeitungen, AES-R5/R6-Credentials, Verschlüsselungsidentifikatoren und signierte Quellpräfixe bleiben dem Kandidaten verfügbar

Typisierte Runs erzeugen Appearances direkt, ohne einen Rich-XML-Encode/Decode-Roundtrip; /V und /RV beschreiben den authored Text und die Stile, während /AP die bestehende PDF-Numerikpräzision der Appearance-Engine für die originalen typisierten Größen und Farben bewahrt

Ein typisierter No-op verlangt äquivalente Plain- und Rich-Werte plus gleich erzeugte Appearance-Streams und aufgelöste Font-/Ressourcengraphen für jedes Widget; der Vergleich entschlüsselt bestehende Streams und normalisiert indirekte Objektreferenzen, statt allein quantisierten /RV-Farben zu vertrauen

Dies erlaubt wirklich unveränderte schreibgeschützte oder signaturgesperrte Felder; eine andere tatsächliche Paint-Farbe, Größe, gelieferte Schrift oder Widget-Appearance folgt den normalen Schreibschutz-, FieldMDP- und DocMDP-Beschränkungen, selbst wenn der serialisierte Rich-Wert zufällig identisch ist

Der Vergleich ist konservativ bei bestehenden Appearances: extern authored PDFs mit äquivalentem visuellem Ergebnis, aber anderer Operator- oder Ressourcendarstellung können eine gewöhnliche geschützte Aktualisierung erfordern; diese API verspricht kein byteidentisches No-op-Output

Wenn jedes angeforderte Feld unverändert ist und der geladene Graph keine ausstehenden Editierungen hat, ist das veröffentlichte PDF byteidentisch zur geladenen Quelle, einschließlich bestehender AES-Verschlüsselungsbytes und authentifizierter Signaturrevisionen; ein leeres Update-Array folgt derselben Regel vorbehaltlich der bestehenden Quell-Kompatibilitätsprüfungen

Ausstehende Editierungen im Aufrufergraphen werden genau einmal in den Kandidaten serialisiert, selbst wenn diese Methode null Feldänderungen zurückgibt; nicht zusammenhängende ungespeicherte Seiten- oder Feldänderungen bleiben erhalten, und der ursprüngliche geladene Graph bleibt unverändert

Die Veröffentlichung ohne Updates führt weiterhin Berechtigungs- und Signaturvalidierung, Quell-/Ziel-Alias-Prüfungen, Output-Budget-Prüfungen, Abbruch und atomaren Zielersatz durch; schreibgeschützte und gesperrte Felder verlangen echte Wert- und Appearance-Äquivalenz

Dieses byterhaltende Verhalten gilt für diese transaktionale Methode; die allgemeine SaveToFile-Methode und separate FDF/XFDF-Import-APIs behalten ihr bestehendes Speicherverhalten

Feldanzahl, doppelte Namen, Unicode, Wertgrößen und aggregierte Textkapazitäten nutzen Options; typisierte Run-Anzahl, aggregierte Glypheneinheiten, gelieferte Font-Bytes, Rich-Wert-Bytes, erzeugte Objekte und Appearance-Vergleichsbytes nutzen zusätzlich die geladenen Dokumentlimits

Ein gemeinsames managed Font-Byte-Array wird über Updates hinweg einmal gezählt; unterschiedliche Allokationen verbrauchen separate Input-Font-Kapazität, selbst wenn ihre Bytes übereinstimmen, während die erzeugten PDF-Objekt- und Output-Budgets weiterhin alle Appearances abdecken

Nutzen Sie das Abbruch-Token des Dokuments für Formular- und Appearance-Optionen; ungültige Felder, missgebildete Werte, Berechtigungen, fehlgeschlagene Signaturauthentifizierung, Abbruch oder Budget-Fehlschläge lassen das vorherige Ziel intakt, und Quell-/Zialiase werden zurückgewiesen

Die API deckt native gemischte Transaktionen ab; Windows-JSON-Typed-Rich-Filling, die ältere Job-Callback-Extension, Annotationsaustausch sowie eingebettete oder inkrementelle FDF-Daten sind separate Workflows

Update record and array · Rich FDF/XFDF import