C ABI nativa do Linux

HotPDFLinuxABI.lpr compila uma shared library 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 rendering por CPU sem componente Windows, desktop ativo, PDF viewer nem processo Python em runtime; Python é usado pelos scripts de build e aceitação

Build 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 novo com FCL e paszlib, um compilador C, binutils, Fontconfig e fontes TrueType instaladas; o ambiente Python de aceitação também precisa de pypdf com o provider AES dele, PyMuPDF, Pillow e NumPy

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

O FPC normalmente grava um bloco anônimo de exports na resposta do linker ELF dele; o build nomeia aquele bloco usando o symbol map embarcado no repositório antes de linkar, porque adicionar um segundo version script nomeado conflitaria com o bloco anônimo

Interface pública

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

A biblioteca do Linux exporta descoberta de ABI, descoberta de capabilities, criação e destruição de documentos, loading e saving por callbacks, contagem de páginas, hpdf_document_execute_json_v1 e o entry point 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 do 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 de assinatura novos opcionais e aparências Unicode, e permissões de certificação; assinatura bem-sucedida substitui o contexto carregado pela revisão assinada preparada, enquanto assinatura ou publicação com falha preserva o contexto original

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

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

A operação render aceita usage: "view" ou usage: "print", com default view; descubra as escolhas pelo array de capability renderUsages, com records V1 inalterados de callbacks e operações

Flags de screen e impressão de anotações seguem o uso selecionado, e annotations: false suprime anotações em qualquer modo; omitir optionalContent retém a configuração default 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 pixels PNG reais para origens plain e AES R5/R6, conteúdo default-desligado, falhas de callbacks, orçamentos, cancelamento e recuperação de 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, export values ou arrays completos de seleções, estados explícitos de botões, configurações de fontes e limites transacionais de recursos

Callbacks de leitura e gravação podem retornar transfers parciais; transfers bem-sucedidos precisam fazer progresso positivo e não podem exceder a contagem solicitada

Todos os callbacks executam sincronamente na thread chamadora, incluindo checagens de cancelamento dentro de parsing de documentos, rendering e checkpoints criptográficos

A entrada de callbacks é copiada para um arquivo temporário privado criado exclusivamente com modo 0600, de modo que os callbacks de entrada do Linux e os user data deles só precisam permanecer válidos até a chamada de load ou execute retornar

Operações num handle compartilhado de documento se serializam internamente; cada chamada ativa mantém uma referência independente, então destruir um handle a partir de um callback de progresso invalida o lookup subsequente enquanto permite que a chamada atual termine com segurança

Não execute recursivamente outra operação no mesmo handle a partir do callback dele; mantenha a shared library carregada até que todas as chamadas tenham retornado e todo handle tenha sido destruído

Orçamentos e publicação

A entrada JSON é limitada a 4 MiB e 64 levels de aninhamento, e rejeita UTF-8 inválido, membros duplicados, limites numéricos malformados e truncamento de parameters de Int64 para Int32

UTF-8 raw e escapes Unicode carregam os mesmos valores de strings, incluindo caracteres suplementares representados por surrogate pairs UTF-16 válidos; escapes de surrogates não pareados falham antes da mutação do documento ou da publicação binária

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

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

Mutações bem-sucedidas de PDFs commitam a saída preparada como o documento atual e o snapshot privado de origem dele, de modo que um import FDF ou XFDF seguinte de mesmo valor retorna os bytes exatos commitados do PDF com updated=0, retendo fills anteriores de formulários, aparências rich tipadas, texto desenhado e páginas importadas

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

Evidências

O reparo opcional de fontes de arquivamento habilita substituição e embutimento delimitados pelo Ghostscript com validação genuína PDF/A-4 antes dos callbacks

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

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 da origem

A comparação nativa geral de documentos normaliza grafos de objetos e encoding de streams, compara pixels reais Cairo com thresholds explícitos, e preserva o estado dos documentos e os orçamentos de publicação por callbacks

O cliente de aceitação verifica layouts reais de headers C e lookup versionado de símbolos, callbacks parciais, 80 operações concorrentes de handles compartilhados, cancelamento, edições Unicode, rollback e assinatura criptografada

Readers independentes pypdf, MuPDF e OpenSSL verificam os PDFs reais, pixels PNG, senhas retidas, dicionários de segurança, document IDs, gaps exatos de ByteRange, assinaturas válidas e a rejeição de bytes assinados modificados

API de documentos headless · Rendering nativo · Plano de entrega restante