ABI C nativa para Linux

HotPDFLinuxABI.lpr compila uma biblioteca partilhada ELF nativa x86_64 chamada libhotpdf.so.1, com SONAME libhotpdf.so.1 e símbolos públicos atribuídos a HOTPDF_1.0

A biblioteca usa THPDFHeadlessDocument e renderização por CPU sem um componente de Windows, um desktop ativo, um leitor PDF nem um processo Python em runtime; o Python é usado pelos scripts de compilação e de aceitação

Compilação e aceitação

sh Tests/Linux/Build-LinuxABI.sh
sh Tests/Linux/Run-LinuxABIAcceptance.sh
FPC_EXE=/usr/local/bin/fpc HPDF_LINUX_OUTPUT=Tests/Linux/bin/linux-abi331 sh Tests/Linux/Run-LinuxABIAcceptance.sh

Use FPC nativo 3.2.2 ou mais recente com FCL e paszlib, um compilador C, binutils, Fontconfig e tipos de letra TrueType instalados; o ambiente Python de aceitação também precisa de pypdf com o fornecedor AES dele, PyMuPDF, Pillow e NumPy

FPC_EXE, HPDF_LINUX_OUTPUT e PYTHON_EXE selecionam localizações de ferramentas; o ambiente Python de aceitação por defeito é /opt/hotpdf-python/bin/python

O FPC escreve normalmente um bloco de exportações anónimo na resposta do linker ELF dele; a compilação nomeia esse bloco usando o mapa de símbolos incluído no repositório antes da ligação, porque acrescentar um segundo script de versões nomeado conflituaria com o bloco anónimo

Interface pública

Inclua Lib/hotpdf_abi.h para o layout partilhado de registos e as constantes de status; hpdf_abi_io_v1_size e hpdf_abi_operation_v1_size reportam os tamanhos nativos reais dos registos

A biblioteca de Linux exporta descoberta de ABI, descoberta de capacidades, criação e destruição de documentos, carregamento e gravação por callbacks, contagem de páginas, hpdf_document_execute_json_v1 e o ponto de entrada de comparação de dois documentos hpdf_document_compare_json_v1

Descubra as operações atuais através de hpdf_capabilities_json_to_io em vez de assumir o conjunto de operações de Windows

{"schemaVersion":1,"type":"render","page":0,"dpi":150,"usage":"print","annotations":false,
 "limits":{"memoryBytes":268435456,"outputBytes":268435456,"pixels":100000000}}

Os workflows nativos de assinatura aceitam uma identidade explícita PEM ou PFX Base64, campos novos de assinaturas opcionais e aparências Unicode, e permissões de certificação; a assinatura bem-sucedida substitui o contexto carregado pela revisão assinada preparada, enquanto assinatura ou publicação falhadas preservam o contexto original

As opções nativas de assinatura vinculam seleção real de SHA256, SHA384 ou SHA512, informação Unicode de assinaturas, atestados legais, bytes explícitos de confiança, evidência validada assinada de revogação, presets reais de aparências e proveniência afirmada pela aplicação de credenciais ou de transports de timestamps

O estado de leitor de optional content opcional fornece aplicações explícitas automáticas de uso View, Print ou Export, zoom, linguagem, contexto de utilizadores e seleções manuais locais da operação através de registos V1 inalterados

A operação render aceita usage: "view" ou usage: "print", com default view; descubra as escolhas através do array de capacidades renderUsages, com registos V1 de callbacks e de operações inalterados

As flags de screen e de impressão de anotações seguem a utilização selecionada, e annotations: false suprime anotações em ambos os modos; omitir optionalContent retém a configuração por defeito estática, enquanto um objeto explícito ativa as recomendações automáticas documentadas e seleções manuais locais da operação

Tests/Linux/Run-LinuxABIRenderUsage.sh verifica píxeis PNG reais para fontes plain e AES R5/R6, conteúdo desativado por defeito, falhas de callbacks, orçamentos, cancelamento e recuperação do mesmo handle; veja Tests/Linux/HeadlessRenderUsage.en-us.md para as dependências de fixtures e o diretório opcional de fixtures pré-geradas

Callbacks e tempo de vida

As opções de aparências de formulários aceitam texto Unicode, valores de exportação ou arrays completos de seleções, estados explícitos de botões, definições de tipos de letra e limites transacionais de recursos

Callbacks de leitura e de escrita podem devolver transferências parciais; transferências bem-sucedidas têm de fazer progresso positivo e não podem exceder a contagem pedida

Todos os callbacks executam sincronamente na thread chamadora, incluindo verificações de cancelamento dentro do parsing de documentos, da renderização e dos checkpoints criptográficos

A entrada de callbacks é copiada para um ficheiro temporário privado criado exclusivamente com modo 0600, pelo que os callbacks de entrada de Linux e os dados de utilizador deles só precisam de permanecer válidos até a chamada de load ou execute devolver

Operações sobre um handle partilhado de documentos serializam-se internamente; cada chamada ativa detém uma referência independente, pelo que destruir um handle a partir de um callback de progresso invalida consultas subsequentes ao mesmo tempo que permite que a chamada atual termine em segurança

Não execute recursivamente outra operação sobre o mesmo handle a partir do callback dele; mantenha a biblioteca partilhada carregada até todas as chamadas devolverem e todos os handles terem sido destruídos

Orçamentos e publicação

A entrada JSON é limitada a 4 MiB e 64 níveis de aninhamento, e rejeita UTF-8 inválido, membros duplicados, limites numéricos malformados e truncamento de parâmetros de Int64 para Int32

UTF-8 em bruto e escapes Unicode transportam os mesmos valores de strings, incluindo carateres suplementares representados por surrogate pairs UTF-16 válidos; escapes de surrogates emparelhados a incompleto falham antes de mutações de documentos ou publicação binária

Os limites de operações incluem memoryBytes, outputBytes, resultBytes e pixels; os limites de documentos também se aplicam a handles previamente carregados, enquanto a memória gerida e os limites de renderização não prometem um teto de RSS do processo

A saída PDF e PNG é completamente preparada e verificada antes de os callbacks de saída começarem; um callback de saída próprio de quem chama pode reter uma transferência parcial após a falha própria de I/O dele, mas a publicação binária ou de resultados falhada não confirma edições de formulários nem substitui um contexto previamente carregado

Mutações PDF bem-sucedidas confirmam a saída preparada tanto como documento atual como snapshot privado de fonte dele, pelo que uma importação FDF ou XFDF subsequente com o mesmo valor devolve os bytes PDF confirmados exatos com updated=0, mantendo preenchimentos anteriores de formulários, aparências rich tipadas, texto desenhado e páginas importadas

Os ficheiros privados de staging são removidos quando o contexto é substituído ou destruído; a saída incremental bem-sucedida de formulários e de assinaturas preserva o prefixo original da fonte e a política de encriptação

Evidência

A reparação opcional de tipos de letra para arquivo ativa substituição e embedding delimitadas de Ghostscript com validação genuína de PDF/A-4 antes dos callbacks

O PDF de revisão anotado nativo acrescenta à comparação semântica saída real de PDFs preparados, destaques Unicode e permissões autenticadas de anotações P3

A comparação nativa de contratos fornece comparação semântica delimitada de dois handles, HTML de revisão Unicode e geometria real de linhas de fontes

A comparação nativa geral de documentos normaliza grafos de objetos e encodings de streams, compara píxeis reais Cairo com limiares explícitos e preserva o estado de documentos e os orçamentos de publicação por callbacks

O cliente de aceitação verifica layouts reais de cabeçalhos C e consulta versionada de símbolos, callbacks parciais, 80 operações concorrentes de handles partilhados, cancelamento, edições Unicode, rollback e assinatura encriptada

Leitores independentes de pypdf, MuPDF e OpenSSL verificam os PDFs reais, os píxeis PNG, palavras-passe retidas, dicionários de segurança, IDs de documentos, intervalos exatos de ByteRange, assinaturas válidas e a rejeição de bytes assinados alterados

API de documentos headless · Renderização nativa · Plano de entregas restantes