THPDFHeadlessDocument.SaveRichTextFieldUpdatesToFile
function SaveRichTextFieldUpdatesToFile(const FileName: string;
const Updates: THPDFHeadlessRichTextFieldUpdates;
const Options: THPDFHeadlessFormDataOptions): Integer;Prepara e publica atomicamente um PDF independente contendo atualizações de texto escalar, choice e botões junto de runs originais de rich-text tipados; retorna o número de campos alterados mantendo o grafo do documento carregado inalterado
O grafo atual é serializado numa revisão privada autenticada antes de as atualizações serem aplicadas; edições existentes não salvas de páginas e campos, credenciais AES R5/R6, identificadores de criptografia e prefixos assinados da origem permanecem disponíveis ao candidato
Runs tipados geram aparências diretamente, sem round trip de encode/decode de XML rich; /V e /RV descrevem o texto e os estilos autorados, enquanto /AP retém a precisão numérica PDF existente do engine de aparências para os tamanhos e cores tipados originais
Um no-op tipado exige valores plain e rich equivalentes mais streams de aparências geradas iguais e grafos resolvidos de fontes/recursos para cada widget; a comparação descriptografa streams existentes e normaliza referências de objetos indiretos, em vez de confiar apenas nas cores /RV quantizadas
Isso permite campos read-only ou travados por assinaturas genuinamente inalterados; uma cor de pintura, tamanho, fonte fornecida ou aparência de widget realmente diferente segue as restrições normais read-only, FieldMDP e DocMDP mesmo quando o valor rich serializado por acaso é idêntico
A comparação é conservadora quanto às aparências existentes: PDFs autorados externamente com resultados visuais equivalentes mas representação diferente de operadores ou recursos podem exigir uma atualização protegida comum
Quando todo campo solicitado está inalterado e o grafo carregado não tem edições pendentes, o PDF publicado é byte a byte idêntico à origem carregada, incluindo os bytes existentes de criptografia AES e revisões assinadas autenticadas; um array vazio de atualizações segue a mesma regra, sujeito às checagens existentes de compatibilidade da origem
Edições pendentes no grafo do chamador são serializadas no candidato uma vez, mesmo quando este método retorna zero mudanças de campos; mudanças não salvas não relacionadas de páginas ou campos são preservadas, e o grafo original carregado permanece inalterado
A publicação de zero atualizações ainda executa validação de permissões e assinaturas, checagens de alias origem/destino, checagens do orçamento de saída, cancelamento e substituição atômica do destino; campos read-only e travados exigem equivalência genuína de valor e aparência
Este comportamento de preservação de bytes se aplica a este método transacional; o método geral SaveToFile e as APIs separadas de import FDF/XFDF retêm seu comportamento existente de save
Contagem de campos, nomes duplicados, Unicode, tamanhos de valores e capacidades agregadas de texto usam Options; contagem de runs tipados, unidades agregadas de glyphs, bytes de fontes fornecidas, bytes de valores rich, objetos gerados e bytes de comparação de aparências também usam os limites do documento carregado
Um array gerenciado compartilhado de bytes de fontes é contado uma vez entre atualizações; alocações distintas consomem capacidade separada de fontes de entrada mesmo quando seus bytes coincidem, enquanto os orçamentos de objetos e saída PDF gerados ainda cobrem todas as aparências
Use o token de cancelamento do documento para as opções de formulários e aparências; campos inválidos, valores malformados, permissões, autenticação de assinaturas com falha, cancelamento ou falhas de orçamento deixam o destino anterior intacto, e aliases origem/destino são rejeitados
A API cobre transações nativas mistas; o preenchimento typed-rich JSON do Windows, a extensão mais antiga de callbacks de jobs, o interchange de anotações e dados FDF embutidos ou incrementais são workflows separados