THPDFHeadlessDocument.SaveRichTextFieldUpdatesToFile
function SaveRichTextFieldUpdatesToFile(const FileName: string;
const Updates: THPDFHeadlessRichTextFieldUpdates;
const Options: THPDFHeadlessFormDataOptions): Integer;Przygotowuje i atomowo publikuje jeden niezależny PDF zawierający aktualizacje tekstu skalarnego, choice i button razem z oryginalnymi typowanymi runami rich-text; zwraca liczbę zmienionych pól przy zachowaniu załadowanego grafu dokumentu niezmienionego
Bieżący graf jest serializowany do prywatnej uwierzytelnionej rewizji przed zastosowaniem aktualizacji; istniejące niezapisane edycje stron i pól, dane logowania AES R5/R6, identyfikatory szyfrowania i podpisane prefiksy źródła pozostają dostępne dla kandydata
Typowane runy generują wyglądy bezpośrednio, bez round tripu kodowania/dekodowania rich XML; /V i /RV opisują autorski tekst i style, podczas gdy /AP zachowuje istniejącą precyzję numeryczną PDF silnika wyglądów dla oryginalnych typowanych rozmiarów i kolorów
Typowany no-op wymaga równoważnych wartości plain i rich plus równych wygenerowanych strumieni wyglądów i rozpoznanych grafów fontów/zasobów dla każdego widgeta; porównanie deszyfruje istniejące strumienie i normalizuje referencje obiektów pośrednich, zamiast ufać samym kwantyzowanym kolorom /RV
To pozwala na rzeczywiście niezmienione pola read-only albo zablokowane podpisami; inny rzeczywisty kolor malowania, rozmiar, dostarczony font albo wygląd widgeta podlega normalnym ograniczeniom read-only, FieldMDP i DocMDP, nawet gdy zserializowana wartość rich akurat jest identyczna
Porównanie jest konserwatywne wobec istniejących wyglądów: zewnętrznie autorskie PDF-y o równoważnych wynikach wizualnych, ale innej reprezentacji operatorów albo zasobów, mogą wymagać zwykłej chronionej aktualizacji
Gdy każde żądane pole jest niezmienione, a załadowany graf nie ma oczekujących edycji, opublikowany PDF jest byte-for-byte identyczny z załadowanym źródłem, łącznie z istniejącymi bajtami szyfrowania AES i uwierzytelnionymi rewizjami podpisów; pusta tablica aktualizacji podąża za tą samą regułą, podlegając istniejącym sprawdzeniom kompatybilności źródła
Oczekujące edycje w grafie wywołującego są serializowane do kandydata raz, nawet gdy ta metoda zwraca zero zmian pól; niezwiązane niezapisane zmiany stron albo pól są zachowywane, a oryginalny załadowany graf pozostaje niezmieniony
Publikacja z zerem aktualizacji nadal wykonuje walidację uprawnień i podpisów, sprawdzenia aliasów źródła/celu, limity wyjścia, anulowanie i atomową zamianę celu; pola read-only i zablokowane wymagają prawdziwej równoważności wartości i wyglądu
To byte-preserving zachowanie dotyczy tej transakcyjnej metody; ogólna metoda SaveToFile i odrębne API importu FDF/XFDF zachowują istniejące zachowanie zapisu
Liczba pól, zduplikowane nazwy, Unicode, rozmiary wartości i zagregowane pojemności tekstu używają Options; liczba typowanych runów, zagregowane jednostki glifów, dostarczone bajty fontów, bajty wartości rich, wygenerowane obiekty i bajty porównania wyglądów też używają limitów załadowanego dokumentu
Współdzielona zarządzana tablica bajtów fontu jest liczona raz między aktualizacjami; odrębne alokacje konsumują osobną pojemność wejściową fontów nawet przy zgodnych bajtach, podczas gdy wygenerowane budżety obiektów i wyjścia PDF nadal pokrywają wszystkie wyglądy
Używaj tokenu anulowania dokumentu dla opcji formularzy i wyglądów; niepoprawne pola, wadliwe wartości, uprawnienia, nieudane uwierzytelnienie podpisów, anulowanie albo awarie budżetu pozostawiają poprzedni cel nienaruszony, a aliasy źródła/celu są odrzucane
API pokrywa natywne transakcje mieszane; Windows JSON typowane-rich wypełnianie, starsze rozszerzenie callbacków zadań, wymiana adnotacji i osadzone albo przyrostowe dane FDF to odrębne workflow