Criteri di LoadDocument e output riparato

Gli overload tradizionali usano la modalità compatible e preservano il comportamento esistente pubblicando allo stesso tempo la validità xref nativa e lo stato di recovery tramite LastLoadReport. L'overload senza argomenti legge dal percorso memorizzato in FileName. Gli overload Pointer, TBytes e TMemoryStream caricano direttamente da dati in memoria, aggirando il file system. L'overload a intervallo di byte seleziona un PDF incorporato da un contenitore più grande, da una frame di protocollo o da un buffer di ricezione riutilizzabile senza creare una porzione temporanea di TBytes

Quando Buffered è True (predefinito), TPdf copia i byte forniti nel proprio buffer trattenuto. Quando False, il buffer del chiamante deve restare valido e invariato fino a UnloadDocument o Active := False — questo evita una copia supplementare ma richiede un'attenta gestione della durata

L'overload a intervallo di byte rifiuta valori negativi, un Index oltre la lunghezza dei dati o un Count che eccede i byte rimanenti. L'overload a puntatore rifiuta nil quando Size è diverso da zero; l'overload TMemoryStream rifiuta uno stream nil prima che qualsiasi stato del documento venga modificato

In caso di successo, Active diventa True e tutte le proprietà di pagina riflettono la prima pagina (PageNumber = 1). In caso di fallimento viene sollevata un'eccezione EPdfError

TPdfLoadOptions.Default fornisce valori predefiniti delimitati per byte della sorgente, problemi, sezioni xref, voci xref e numeri di oggetto. PDFium resta il parser semantico in ogni modalità; la verifica del wrapper esiste perché l'ABI pubblico di PDFium riporta la validità xref ma non espone un'opzione che disabiliti il recovery del parser

• plmCompatible accetta il recovery di PDFium e registra il risultato senza modificare il comportamento di caricamento tradizionale
• plmStrict rifiuta una sorgente quando PDFium ha ricostruito il suo xref o la verifica delimitata trova errori strutturali
• plmRecovery accetta esplicitamente un caricamento recuperato e ne restituisce il percorso diagnostico e l'evidenza

La verifica segue le tabelle xref classiche, gli xref stream, le revisioni ibride e le catene /Prev. Riporta sezioni malformate, cicli, voci in conflitto, offset di oggetto danneggiati, marker terminali mancanti, filtri di stream non supportati, esaurimento del budget e recovery nativo. Il superamento di un budget di verifica configurato imposta AuditComplete a False e produce un avviso; di per sé non afferma che i byte non verificati siano invalidi

InspectAvailability resta la sonda nativa leggera di disponibilità per la linearizzazione e il caricamento page-first; non sostituisce il report strutturale di caricamento

TPdfLoadReport include Status, CrossReferenceTableValid, UsedRecovery, RecoveryRoute, offset della sorgente e strutturali, contatori di sezioni e voci, contatori di conflitti e danni, totali dei problemi, stato di troncamento e un array tipizzato Issues. Lo stesso report è memorizzato in LastLoadReport

TPdfRepairReport registra se la sorgente ha usato il recovery, la dimensione dell'output e il numero di pagine, la validità xref dell'output, il testo dell'errore terminale e il report completo della verifica indipendente con caricamento strict

SaveAsRepaired chiede a PDFium di scrivere una copia completa non incrementale, quindi apre quell'output in un TPdf isolato con plmStrict. Il metodo consegna i byte solo dopo il superamento della validità xref e della coerenza del numero di pagine. L'overload su file scrive tramite un file temporaneo nella stessa directory e sostituisce atomicamente la destinazione

Una riscrittura completa rimuove la cronologia incrementale precedente e invalida gli intervalli di byte delle firme esistenti. I documenti firmati vengono rifiutati a meno che AllowSignedDocument non sia esplicitamente True. Il metodo ripara le strutture che PDFium può caricare e riscrivere con successo; non garantisce il recupero di contenuti danneggiati arbitrari né la preservazione delle firme digitali