Registro de alterações

Histórico de versões

Histórico de versões da biblioteca PDFlibPas. As entradas são listadas da mais recente para a mais antiga; cada versão segue o versionamento semântico conforme a política de lançamento do projeto.

v3.56.42 2026-05-27

Corrigido o caminho de descriptografia AES-256 baseado em buffer introduzido na v3.56.41, permitindo que os chamadores atribuam o resultado da descriptografia ao mesmo AnsiString que forneceu o buffer de texto cifrado sem violações de acesso.
O fluxo da API normal LoadFromFile, Encrypt, SaveToFile, recarregar, Decrypt e SaveToFile volta a concluir em PDFs grandes já carregados, mantendo a otimização de descriptografia AES-CBC com menos cópias.
Adicionada cobertura de regressão AES para casos em que o buffer de entrada e o destino do resultado são o mesmo durante a restauração de streams criptografados ao salvar, incluindo payloads grandes de 504 KB que antes expunham a falha.

v3.56.41 2026-05-27

Adicionado TPDFlib.DACopyFile para fluxos Direct Access que precisam de contagem de páginas e uma cópia de arquivo sem alterações sem construir o grafo completo de objetos normal.
O descriptografar AES-256 foi otimizado com caminhos AES-CBC baseados em buffer, usados ao descriptografar strings e streams carregados, reduzindo cópias extras de texto cifrado em streams criptografados grandes.
A demo Delphi HugeFileBenchmark agora inclui uma linha direct-copy e filtros --ops e --skip para execuções focadas em arquivos grandes.

v3.56.40 2026-05-26

As demos HelloWorld de Delphi e C++Builder agora criam um PDF inicial mais rico com informacoes do documento, saida em uma fonte padrao selecionada, bloco de titulo estilizado, desenho vetorial simples e orientacao para os proximos passos, mantendo o mesmo fluxo de compilar e executar.
Todas as notas das demos Delphi e C++Builder foram substituidas por paginas Readme.html amigaveis ao navegador, incluindo notas auxiliares sobre senhas, arquivos restritos e resultados de assinatura; os indices das demos agora levam os usuarios para as notas HTML.

v3.56.39 2026-05-26

Os caminhos de salvamento da API de arquivo direto agora constroem tabelas de consulta de referência cruzada de forma linear, tornando DASaveAsFile e os caminhos de salvamento direto relacionados muito mais rápidos em PDFs com contagens muito altas de objetos ou árvores de páginas densas.
O writer otimizado preserva a mesma semântica da cadeia de objetos livres e evita varreduras repetidas dos números de objeto durante a geração completa de xref, melhorando grandes fluxos de salvamento direto sem alterar a API pública nem o contrato de saída.

v3.56.38 2026-05-26

Corrigida a saída de criptografia da API normal para que Encrypt crie ou preserve o trailer /ID antes de gravar os dados de segurança AES-256, mantendo PDFs criptografados detectáveis ao recarregar por meio de EncryptionStatus.
O fluxo da API normal LoadFromFile, Encrypt, SaveToFile, recarregamento, Decrypt e SaveToFile agora preserva o estado criptografado antes do Decrypt explícito, igualando o comportamento da API de acesso direto a arquivos para PDFs legados grandes.

v3.56.37 2026-05-26

Foi adicionado TPDFlib.ComparePreflightReports, um comparador linha a linha para relatorios de preflight em texto simples que ignora linhas volateis de carimbo de data/hora Generated: e retorna uma string vazia quando o conteudo estavel do relatorio coincide.
A demo Delphi PreflightReport agora oferece suporte a --compare <file> no modo de arquivo unico, grava um relatorio UTF-8 .diff.txt e retorna o codigo de saida 2 quando o relatorio de texto gerado difere da baseline.

v3.56.36 2026-05-26

A demo Delphi PreflightReport agora oferece suporte a execucoes em lote de diretorios com --input-dir, --output-dir e --recursive, gravando um relatorio por PDF como <basename>.preflight.<ext>.
O modo em lote grava um arquivo UTF-8 preflight-summary.csv que registra cada PDF de origem, status pass/fail, contagem de problemas e caminho do relatorio gerado, mantendo o contrato de codigos de saida existente para automacao.

v3.56.35 2026-05-26

ReportFormat = 3 adiciona saida CSV a TPDFlib.CreatePreflightReportEx e TPDFlib.SavePreflightReportEx, gerando linhas UTF-8 para metadados do relatorio, cada verificacao de conformidade selecionada, codigos e mensagens de problemas individuais e o resumo final.
A demo Delphi PreflightReport agora oferece suporte a --format csv e --csv, permitindo que execucoes de preflight pela linha de comando alimentem planilhas ou parsers simples de CI sem pos-processar JSON nem extrair texto.

v3.56.34 2026-05-26

Adicionadas as APIs com seleção de formato TPDFlib.CreatePreflightReportEx e TPDFlib.SavePreflightReportEx para gerar relatórios de preflight PDF/A e PDF/UA-1 como texto simples, JSON ou HTML autônomo, preservando as APIs existentes somente de texto.
A demonstração Delphi PreflightReport agora oferece suporte a --format text|json|html e aos atalhos --json e --html, permitindo que o mesmo fluxo de linha de comando produza relatórios legíveis ou artefatos de CI legíveis por máquina.

v3.56.33 2026-05-26

Adicionados TPDFlib.CreatePreflightReport e TPDFlib.SavePreflightReport, permitindo que aplicativos gerem relatórios em texto reutilizáveis a partir das verificações integradas de conformidade PDF/A e PDF/UA-1 sem enumerar manualmente identificadores de listas de strings.
A demonstração Delphi PreflightReport agora chama diretamente as APIs de relatório da biblioteca, mantendo o exemplo focado no fluxo de linha de comando, nas verificações selecionadas, no modo de primeiro problema e nos códigos de saída adequados para automação.

v3.56.32 2026-05-26

Adicionado um novo exemplo de console Delphi PreflightReport, que executa verificações PDF/A e PDF/UA-1 com CheckFileCompliance, enumera as listas de problemas com GetStringListCount e GetStringListItem e grava um relatório de preflight em texto simples.
O exemplo oferece suporte às opções --input, --output, --pdfa, --pdfua, --both e --first-issue, além de códigos de saída adequados para automação para aprovação, problemas encontrados e erro de execução.

v3.56.31 2026-05-25

GetCustomKeys(2) agora oculta de forma consistente as entradas do sistema Catalog gerenciadas pela biblioteca, incluindo /OutputIntents, /Extensions, /Requirements, /Collection e /NeedsRendering.
As intenções de saída PDF/A criadas por SetPDFAMode não aparecem mais como chaves personalizadas no catálogo, mantendo a enumeração de metadados da aplicação separada das estruturas de conformidade do PDF.

v3.56.25 2026-05-23

O componente GetPDFUADiagnostics no lado do escritor agora possui o mesmo problema que MULTIPLE-H-CHILDREN:N, garantindo a compatibilidade com o leitor 10044 a partir da versão v3.56.24. ISO 14289-1 §7.4.4 impede que um nó de árvore de tags tenha mais de um filho H direto — a verificação no lado do escritor é executada sempre que a árvore FStructElems na memória contiver essa violação.
Um novo utilitário CountMultipleHChildren aninhado percorre a árvore em profundidade, contando os filhos H em cada nível. A verificação é executada junto com as caminhadas existentes LIST-STRUCT / LIST-NO-NUMBERING e compartilha o mesmo padrão de travessia FStructElems.

v3.56.24 2026-05-23

A auditoria PDF/UA-1 agora inclui uma verificação de unicidade de tag H ISO 14289-1 §7.4.4. 10044 relata qualquer nó de estrutura que contenha mais de um filho H direto —, pois a especificação proíbe isso em documentos fortemente estruturados, e a mesma restrição se aplica a qualquer nó de árvore de tags, independentemente do modo de estrutura geral. A outra seção § 7.4.4 SHALL (um documento deve ser ou fortemente ou fracamente estruturado, não ambos) requer heurísticas em todo o documento e foi intencionalmente omitida desta auditoria.
Um novo caminhante de árvore de estrutura em pré-ordem (UAVisitStructNodeForHUniqueness / ScanStructTreeForHUniqueness) conta os filhos H diretos por nó e recursa em profundidade. Reutiliza o mesmo decodificador em forma de K que os caminhantes existentes de cabeçalho / lista / nota.

v3.56.23 2026-05-23

A auditoria PDF/UA-1 agora inclui duas verificações de programa de fonte ISO 14289-1 §7.21.6 que as verificações da camada de dicionário de v3.56.10 tiveram que adiar até que um analisador TrueType estivesse disponível. 10034 relata programas TrueType não simbólicos cujas tabelas cmap embutidas SFNT contêm apenas a entrada simbólica (platformID=3, encodingID=0) — §. O primeiro parágrafo da versão 7.21.6 exige pelo menos uma sub-tabela cmap não simbólica para que o programa possa renderizar os pontos de código declarados por sua /Encoding.. 10035 relata arrays TrueType não simbólicos cujos nomes de glifos não são membros da lista de glifos Adobe (.notdef excluído). — §. O terceiro parágrafo da versão 7.21.6 exige que cada entrada de Diferenças seja incluída em AGL.
A nova versão Lib/PDFlibPDFUAFontInspect.pas implementa um analisador de diretório de tabela tolerante e um analisador de sub-tabela de diretório cmap. A tabela de lista de glifos Adobe com 4281 nomes, adicionada como estrutura na alteração de infraestrutura anterior, agora está conectada por meio da verificação de Diferenças. Programas que não são analisados como SFNT (programa de fonte PFB / PFA, OpenType coleção, lixo arbitrário) são ignorados silenciosamente. Falsos negativos são preferidos a falsos positivos na camada de auditoria.

v3.56.22 2026-05-23

A auditoria PDF/UA-1 agora inclui verificações de dados de clip de mídia. 10042 relata dicionários de dados de clip de mídia (identificados por /S /MCD, opcionalmente /Type /MediaClip) que não possuem a entrada obrigatória de tipo de conteúdo /CT. 10043 relata os mesmos dicionários que não possuem o array /Alt obrigatório. ISO 32000-1 A Tabela 274 lista ambas as chaves como opcionais, mas ISO 14289-1 §7.18.6 as promove para obrigatórias para que os leitores de tela possam anunciar uma descrição significativa para multimídia incorporada.
Esta é a Fase 6 do plano de auditoria profunda PDF/UA (.superpowers/plans/2026-05-23-pdfua-deep-audit-plan.md). Ela é executada sem nenhuma dependência de analisador de programa de fonte ou fluxo de conteúdo, portanto, é a primeira subclasse após a série v3.56.0..v3.56.13.

v3.56.21 2026-05-23

Novo SetSignProcessCommitmentType emite o atributo assinado CAdES commitment-type-indication (OID 1.2.840.113549.1.9.16.2.16, ETSI EN 319 122-1 v1.2.1 §5.2.3) dentro do caminho PAdES-B-B SignerInfo. Aceita códigos inteiros de 1 a 6, que mapeiam para os bem conhecidos esquemas de compromisso ETSI id-cti-ets-proofOfOrigin a id-cti-ets-proofOfCreation; passe 0 para limpar. Códigos fora da faixa são rejeitados.
Novo SetSignProcessSignaturePolicy emite o atributo assinado CAdES signature-policy-identifier (OID 1.2.840.113549.1.9.16.2.15, §5.2.9). Recebe a política no formato decimal pontilhado OID, o hash do documento de política como uma string hexadecimal em maiúsculas e um código de algoritmo de digestão (1=SHA-1, 2=SHA-256, 3=SHA-384, 4=SHA-512, 0=auto/SHA-256). O atributo carrega a SignaturePolicyId SEQUENCE com sigPolicyId + sigPolicyHash (OtherHashAlgAndValue SEQUENCE).
Ambos os atributos só entram em vigor quando o SubFilter está em ETSI.CAdES.detached (o caminho PAdES-B-B); eles estendem o array rgAuthAttr existente, juntamente com content-type e signing-certificate-v2. A linha d) da Tabela 1 proíbe a combinação de commitment-type-indication com a entrada do dicionário de assinatura PDF /Reason; o chamador é responsável por não definir ambos.

v3.56.20 2026-05-23

A nova funcionalidade AddPAdESDSSVRI adiciona uma entrada de subdicionário de Assinatura VRI ao DSS que está sendo montado, completando a estrutura ETSI EN 319 142-1 v1.2.1 da cláusula 5.4.2.3 Informações Relacionadas à Validação. A entrada é identificada pelo SHA-1 hexadecimal maiúsculo dos bytes da assinatura '; seus sub-arrays Cert / CRL / OCSP são preenchidos referenciando os streams pai correspondentes por meio de índices baseados em 0, fornecidos como listas separadas por vírgula (por exemplo, "0,2,5").
O TSmartPDFDocument.AddPAdESDSSWithVRI subjacente rastreia os números de objeto de stream emitidos para cada certificado / CRL / OCSP e os usa para escrever os sub-arrays VRI como referências indiretas de volta para os mesmos streams aos quais os arrays pai DSS já apontam, satisfazendo o requisito da especificação de que as entradas VRI compartilhem armazenamento com o dicionário pai DSS. O ponto de entrada AddPAdESDSS original continua a funcionar inalterado para os chamadores que não precisam de VRI.
Cada subdicionário de assinatura VRI carrega o marcador opcional /Type /VRI, para que as ferramentas que percorrem o catálogo por tags Type possam reconhecer a estrutura sem precisar reresolver o caminho pai.

v3.56.19 2026-05-23

Novo fluxo de trabalho PAdES-B-T para anexar uma assinatura de carimbo de tempo (id-aa-signatureTimeStampToken, OID 1.2.840.113549.1.9.16.2.14) a uma assinatura PAdES-B-B existente. NewPAdESSignatureTimeStampProcessFromFile / FromStream / FromString abre um PDF assinado, SetPAdESSignatureTimeStampField nomeia o campo, GetPAdESSignatureValueHashHex retorna o hash SHA-256 (ou 384 / 512) do identificador do signatário' para envio a um TSA, GetPAdESSignatureCMSBytes expõe o payload CMS existente, SetPAdESSignatureCMSBytes aceita os bytes aumentados CMS que o chamador monta usando sua biblioteca CMS de escolha, e EndPAdESSignatureTimeStampProcessToFile / ToStream / ToString insere o novo CMS no espaço reservado /Contents original.
BuildPAdESSignatureTimeStampAttribute é um auxiliar sem estado que envolve um TimeStampToken emitido por TSA no atributo CMS que SignerInfo.unsignedAttrs espera, então os chamadores que já possuem uma biblioteca CMS podem pular a parte de configuração. OID + SET.
O novo SetSignProcessReserveContentsBytes amplia o espaço reservado /Contents no momento da assinatura inicial para que o CMS aumentado posteriormente caiba sem transbordar a reserva original. Os atributos TimeStampTokens normalmente emitidos por 13 adicionam 2-6 KB ao SignerInfo; passe 1024-8192 para deixar espaço. Se não houver espaço suficiente, a chamada de aumento retorna 13 (transbordamento de saída).
A biblioteca não inclui um cliente TSA HTTP; o chamador busca o TimeStampToken (geralmente 30-50 linhas de solicitação TSP + HTTP POST contra, por exemplo, FreeTSA ou DigiCert). No Windows, CMSG_CTRL_ADD_SIGNER_UNAUTH_ATTR CryptoAPI poderia, em princípio, automatizar a injeção CMS na biblioteca, mas retorna CRYPT_E_INVALID_INDEX (0x80091008) na forma separada SignedData PAdES emitida, então os bytes CMS fornecidos pelo chamador são usados no lugar.

v3.56.18 2026-05-23

O atributo PAdES signing-certificate-v2 agora incorpora o campo opcional IssuerSerial definido por RFC 5035 (ESSCertIDv2). O nome distinto do emissor do certificado de assinatura é envolvido em um GeneralName [4] EXPLICIT directoryName CHOICE dentro de GeneralNames, seguido pelo número de série do certificado como um ASN.1 INTEGER. Os bytes do número de série chegam em ordem little-endian do Windows CryptoAPI (CRYPT_INTEGER_BLOB) e são invertidos para big-endian com o byte de preenchimento inteiro positivo adicionado quando o bit mais significativo está definido, correspondendo à forma como OpenSSL e BouncyCastle emitem o mesmo campo.
Os verificadores que comparam o nome do emissor + o par de números de série com seu conjunto de candidatos de construção de caminho (notavelmente EU DSS em modo estrito) agora encontram ambos os identificadores no atributo signing-cert-v2; a saída anterior v3.56.17 fornecia apenas a referência certHash.
Novos auxiliares ASN.1 DER_IntegerFromLittleEndian (lida com a ordem de bytes Win32 CRYPT_INTEGER_BLOB) e DER_ContextTagExplicit (envolve um payload em uma tag construída específica do contexto) complementam o micro-codificador PDFlibASN1. As novas declarações CERT_INFO / CRYPT_ALGORITHM_IDENTIFIER / CRYPT_INTEGER_BLOB / PCERT_CONTEXT em PDFlibCryptoAPI fornecem ao caminho de assinatura acesso aos campos do certificado analisados.

v3.56.17 2026-05-23

O caminho de assinatura nativo ETSI.CAdES.detached agora produz assinaturas PAdES-B-B estruturalmente conformes. A biblioteca constrói ela mesma os atributos autenticados CMS — content-type (id-data) e signing-certificate-v2 do RFC 5035 / RFC 5816 com um hash SHA-256 do certificado de assinatura — e os entrega ao CryptSignMessage via rgAuthAttr. Assim que esse campo deixa de ser NULL, a Windows CryptoAPI para de injetar automaticamente o atributo signing-time que o PAdES (ETSI EN 319 142-1 v1.2.1 Table 1) proíbe, de modo que o SignerInfo resultante carrega os atributos exigidos e apenas eles.
A nova unit PDFlibASN1 oferece um microcodificador DER (X.690) focado — prefixo de comprimento, OCTET STRING, SEQUENCE, SET, OBJECT IDENTIFIER — usado para montar o valor do atributo SigningCertificateV2. O codificador segue as regras padrão de arcos OID em base-128 e omite o campo opcional hashAlgorithm quando ele apenas repetiria o valor padrão SHA-256, alinhado com o que OpenSSL e BouncyCastle emitem.
ApplySignature agora encaminha ETSI.CAdES.detached pelo caminho raw-byte (o mesmo usado por adbe.pkcs7.detached) em vez de fornecer um digest pré-calculado. A CryptoAPI passa a calcular o atributo autenticado messageDigest sobre o conteúdo realmente assinado, que é o que os verificadores esperam.
SHA-384 e SHA-512 também são honrados ao montar o atributo signing-certificate-v2: o campo hashAlgorithm é emitido com o AlgorithmIdentifier correspondente em vez de depender do valor padrão. SHA-1 é promovido silenciosamente a SHA-256 nesse contexto porque o PAdES-B-B não autoriza SHA-1 (clause 6.2.1).

v3.56.16 2026-05-23

O novo SetSignProcessDigestAlgorithm seleciona o algoritmo de message-digest da assinatura: 1 = SHA-1 (deprecated), 2 = SHA-256 (padrão moderno), 3 = SHA-384, 4 = SHA-512, 0 = auto (SHA-256 para todo SubFilter exceto o caminho legado adbe.pkcs7.sha1, que permanece em SHA-1 para preservar compatibilidade binária estável). ETSI EN 319 142-1 v1.2.1 §6.2.1 proíbe MD5 e delega à ETSI TS 119 312 as suites criptográficas recomendadas, portanto signatários PAdES devem escolher SHA-256 ou mais forte.
Adicionados os helpers de hash SHA256StreamRange, SHA384StreamRange e SHA512StreamRange ao lado do SHA1StreamRange existente; o caminho de assinatura os utiliza para gerar o digest do ByteRange do PDF sob o algoritmo selecionado. O OID SignerInfo.digestAlgorithm do PKCS#7 e os bytes de hash efetivamente gravados agora são garantidamente coerentes (o código anterior sempre passava o digest SHA-1 independentemente do algoritmo negociado).
TPDFlibPFXFile.SignData agora recebe um parâmetro DigestAlgorithm e escolhe o OID correto para cada par (SubFilter, algoritmo): 2.16.840.1.101.3.4.2.1 / .2 / .3 para SHA-256/384/512 em SubFilters detached e custom (RFC 5754), e os OIDs da família sha256WithRSAEncryption correspondentes para o caminho legado adbe.pkcs7.sha1.

v3.56.15 2026-05-23

Novo SetSignProcessDocTimeStamp alterna um processo de assinatura para o modo PAdES Document Time-stamp conforme ETSI EN 319 142-1 v1.2.1 §5.4.3. O Signature Dictionary resultante carrega /Type /DocTimeStamp e /SubFilter /ETSI.RFC3161, omite as chaves proibidas /M, /Reason, /Location, /ContactInfo e /Name, e reserva um placeholder hex de 8192 bytes (ou dimensionado pelo chamador) em /Contents para um TimeStampToken RFC 3161 obtido externamente.
Passthrough é ativado automaticamente quando o modo DocTimeStamp é selecionado, pois o TimeStampToken vem de uma TSA externa. Chamadas a SetSignProcessInfo feitas após alternar para o modo DocTimeStamp são silenciosamente ignoradas para manter o dicionário de assinatura em conformidade com a especificação.
A auto-injeção existente de /Extensions /ESIC do PAdES adicionada em v3.56.8 já cobre DocTimeStamp porque seu SubFilter começa com ETSI., de modo que um PDF Document Time-stamp declara a extensão de catálogo exigida sem fiação adicional.

v3.56.14 2026-05-23

Nova API de aumento do PAdES Document Security Store (DSS). NewPAdESDSSProcessFromFile / NewPAdESDSSProcessFromStream / NewPAdESDSSProcessFromString abrem um PDF previamente assinado, AddPAdESDSSCertificate / AddPAdESDSSCRL / AddPAdESDSSOCSP preparam material de validação codificado em DER, e EndPAdESDSSProcessToFile / EndPAdESDSSProcessToStream / EndPAdESDSSProcessToString escrevem uma atualização incremental contendo um dicionário /DSS << /Type /DSS /Certs [...] /CRLs [...] /OCSPs [...] >> conforme especificado por ETSI EN 319 142-1 v1.2.1 §5.4.2.2. Este é o bloco de construção para promover uma assinatura PAdES-B-B / B-T para validação de longo prazo PAdES-B-LT.
O processo DSS auto-incrementa a entrada de catálogo /Extensions /ESIC para pelo menos ExtensionLevel 1 ao adicionar material de validação, correspondendo ao requisito em §5.6, e mescla novos certificados, CRLs e respostas OCSP nos arrays existentes /Certs / /CRLs / /OCSPs em invocações repetidas, de modo que as revisões acumulem em vez de sobrescrever.
GetPAdESDSSProcessResult / ReleasePAdESDSSProcess completam o ciclo de vida, espelhando a superfície de API SignProcess existente.

v3.56.8 2026-05-23

Conformidade baseline PAdES: quando uma assinatura é criada com um SubFilter PAdES (ETSI.CAdES.detached ou ETSI.RFC3161), o catálogo do documento agora recebe automaticamente a entrada /Extensions /ESIC <</BaseVersion /1.7 /ExtensionLevel 2>> exigida por ETSI EN 319 142-1 v1.2.1 §5.6. A entrada é adicionada por meio da mesma atualização incremental que carrega a assinatura, nunca rebaixa um /ExtensionLevel superior existente, e segue referências indiretas /Extensions ou /ESIC quando o PDF de origem já as armazena como objetos separados.
O marcador de extensão equivalente Adobe escrito por SetSignProcessCustomSubFilter para PDFs criados por meio de TPDFlib agora é /ADBE /BaseVersion /1.7 /ExtensionLevel 8 (era ExtensionLevel 5), correspondendo à declaração alternativa que as assinaturas baseline PAdES são permitidas a usar; o nível 5 cobria apenas recursos de formulários / 3D / RichMedia do ISO 32000-2 e não identificava realmente as extensões PAdES.

v3.56.13 2026-05-23

Quando SetPDFUAMode está ativo e o documento é salvo, qualquer elemento de estrutura L (lista) que não tenha um atributo ListNumbering explícito agora recebe automaticamente /O = List /ListNumbering = None. ISO 14289-1 §7.6 exige que toda tag L declare seu estilo de numeração; a nova correção em tempo de salvamento ApplyPDFUAListNumbering se junta à família existente ApplyPDFUATabOrder / ApplyPDFUAFormFieldTU / ApplyPDFUAAnnotContents / ApplyPDFUAEmbeddedAFRelationship / ApplyPDFUAStripTrapNet.
Autores que se importam com um estilo de lista específico ainda devem chamar SetStructElemListNumbering antes de EndTag; a auto-correção só dispara quando nenhum atributo ListNumbering está presente no momento do salvamento, de modo que valores explícitos são preservados.
A mensagem de diagnóstico writer-side LIST-NO-NUMBERING:N agora observa que a auto-correção mascarará o problema no momento do salvamento, de modo que os usuários entendem tanto o atributo ausente quanto o comportamento de reparo automático.

v3.56.12 2026-05-23

A auditoria PDF/UA-1 ganha três novas verificações ISO 14289-1. 10031 informa anotações Link cujo dicionário de ação URI carrega /IsMap = true (proibido por §7.18.5 a menos que funcionalidade equivalente seja fornecida em outro lugar no conteúdo; autores com um caso de uso legítimo de IsMap podem suprimir o diagnóstico por conta própria). 10032 informa elementos de estrutura Note sem a entrada /ID — §7.9 exige que toda tag Note declare um ID único. 10033 informa contagens de pares duplicados quando duas ou mais tags Note compartilham o mesmo valor /ID.
A detecção de colisão de ID de Note é feita coletando os IDs em uma TStringList ordenada e percorrendo pares adjacentes, de modo que um grupo de três Notes compartilhando um ID conta como dois pares duplicados.
A verificação de ação URI percorre o array /Annots de cada página, filtra por /Subtype /Link, então inspeciona /A /S /URI e o booleano /IsMap. Referências indiretas são desreferenciadas em cada etapa, de modo que dicionários de ação divididos se comportam da mesma forma que os inline.

v3.56.11 2026-05-23

ISO 14289-1 §7.6 exige que todo elemento de estrutura L (lista) carregue um atributo ListNumbering explícito. 10030 (reader-side) e LIST-NO-NUMBERING:N (writer-side) informam tags L que o omitem. O walker reader-side decodifica ambas as formas de /A (dicionário de atributo único ou um array de dicionários misturado com inteiros de revisão) e procura pela chave /ListNumbering independentemente do owner. A verificação writer-side inspeciona TPDFStructElem.Attributes pelo mesmo nome tanto na lista de estrutura finalizada quanto na pilha de tags ainda aberta.
Valores válidos de ListNumbering por ISO 32000-1 Tabela 347 são None, Disc, Circle, Square, Decimal, UpperRoman, LowerRoman, UpperAlpha, LowerAlpha. A auditoria só verifica a presença da chave, não qual valor é escolhido — toda tag L precisa de um destes.

v3.56.10 2026-05-23

A auditoria PDF/UA-1 ganha as regras de codificação TrueType de ISO 14289-1 §7.21.6. 10028 informa fontes TrueType não simbólicas cuja /Encoding (ou o /BaseEncoding dentro de um dicionário Encoding) não é nem MacRomanEncoding nem WinAnsiEncoding. 10029 informa fontes TrueType simbólicas que carregam uma entrada /Encoding (proibido por §7.21.6 quarto parágrafo).
Simbólico vs. não simbólico é decidido a partir do bit 3 (mascara 4) de /Flags do FontDescriptor, reutilizando o helper existente UAFontDescriptorSymbolic da sub-classe 4. O primeiro parágrafo completo de §7.21.6 (o programa TrueType incorporado deve conter entradas cmap correspondentes) requer parsing do programa de fonte TrueType e ainda está pendente; as regras no nível de dicionário acima são a camada prática que esta auditoria pode verificar sem um parser TrueType.
Regras de array Differences em §7.21.6 (nomes de glifos somente AGL, presença de cmap Microsoft Unicode) permanecem fora de escopo pela mesma razão — requerem inspeção do programa de fonte.

v3.56.9 2026-05-23

A auditoria PDF/UA-1 ganha uma verificação completa de ISO 14289-1 §7.18.4. 10027 informa anotações Widget cujo /StructParent resolve através do /ParentTree da árvore de estrutura, mas não aterrissa em um elemento de estrutura com /S = Form. A verificação parcial anterior de v3.56.7 (10026) apenas detectava Widgets que não têm /StructParent em absoluto; a nova verificação completa a regra seguindo o ponteiro number-tree e verificando a tag de destino.
Um novo helper NumberTreeLookup implementa a forma number-tree de ISO 32000-1 §7.9.7 (raiz plana /Nums, intermediários /Kids faixados por /Limits). Auditorias futuras que precisem resolver entradas de página /StructParents ou rótulos /PageLabels podem reutilizá-lo.
A verificação de tag Form para anotações Widget usa um modelo de duas camadas: um Widget sem /StructParent é informado como 10026; um Widget cujo /StructParent existe mas não resolve para /S = Form é informado como o mais específico 10027. Isso evita contar duas vezes a mesma violação sob ambos os códigos.

v3.56.7 2026-05-23

Quando SetPDFUAMode está ativo e o documento é salvo, quaisquer entradas de anotação TrapNet agora são automaticamente removidas do array /Annots de cada página. ISO 14289-1 §7.18.2 proíbe anotações TrapNet; a nova correção em tempo de salvamento ApplyPDFUAStripTrapNet se junta à família existente ApplyPDFUATabOrder / ApplyPDFUAFormFieldTU / ApplyPDFUAAnnotContents / ApplyPDFUAEmbeddedAFRelationship, de modo que documentos em modo PDF/UA param de emitir silenciosamente sobras de TrapNet.
A auditoria PDF/UA-1 ganha uma verificação parcial de §7.18.4. 10026 informa anotações Widget que não têm /StructParent — um Widget sem /StructParent não pode ser alcançado da árvore de estrutura e portanto não pode ser aninhado em uma tag de estrutura Form. A verificação estrutural completa (resolvendo /StructParent através do ParentTree e confirmando que o /S do pai é Form) fica para uma release de acompanhamento.
Writer-side GetPDFUADiagnostics ganha o problema correspondente WIDGET-NO-STRUCTPARENT:N. A mensagem TRAPNET-ANNOT existente agora também observa que SetPDFUAMode auto-remove estas no momento do salvamento.

v3.56.6 2026-05-23

A auditoria PDF/UA-1 ganha duas verificações de hierarquia de títulos de ISO 14289-1 §7.4.2. 10024 informa quando o primeiro elemento de título na ordem do documento não é H1 (ou H). 10025 informa o número de saltos de nível de título em uma sequência descendente (por exemplo, H1 seguido por H3 sem H2). Ambas as verificações compartilham uma única travessia em pré-ordem da árvore de estrutura que decodifica as formas /K aninhadas (StructElem único, array de StructElems / IndRefs / MCRs).
Writer-side GetPDFUADiagnostics ganha o problema correspondente FIRST-HEADING-NOT-H1, em paridade com o reader 10024. A verificação writer HEADING-LEVEL-SKIP previamente existente agora tem uma companheira que também detecta problemas do estilo "primeiro título foi H2".

v3.56.5 2026-05-23

Quando SetPDFUAMode está ativo e o documento é posteriormente criptografado, a chave de permissão de criptografia (/P no dicionário de criptografia) agora tem automaticamente o bit 10 (máscara $200, "Extrair texto e gráficos em apoio à acessibilidade") definido, mesmo quando o chamador não incluiu ppCanCopyAccess nas TPDFExtraPermissions passadas para Encrypt. ISO 14289-1 §7.16 exige que todo arquivo criptografado em conformidade permita extração para acessibilidade, e o bit é de outra forma fácil de esquecer. O bit é sempre seguro de definir — ele apenas concede acesso adicional à tecnologia assistiva, não a outros caminhos de extração.
Writer-side GetPDFUADiagnostics ganha um novo problema ENCRYPT-NO-ACCESS que dispara quando PDFUAMode está ativo e o bit 10 de /P do dicionário de criptografia está limpo. Isso captura o caso extremo de ordem de chamada em que o usuário chamou Encrypt() primeiro e SetPDFUAMode apenas depois — o diagnóstico diz ao usuário para chamar Encrypt() novamente para que o dict de criptografia seja reemitido com o /P corrigido.

v3.56.4 2026-05-23

Writer-side GetPDFUADiagnostics ganha cinco novas verificações ISO 14289-1 para que a auditoria de documento em memória detecte as mesmas violações que a auditoria reader-side CheckFileCompliance ComplianceTest=2. SUSPECTS-TRUE sinaliza MarkInfo/Suspects=true (§7.1: arquivos em conformidade PDF/UA exigem Suspects=false). ROLEMAP-STANDARD-REMAP:N sinaliza chamadas AddRoleMap que remapeariam uma tag de estrutura padrão — §7.1 proíbe remapear tags padrão. DC-TITLE-MISSING sinaliza um dc:title XMP vazio (separado de DOCINFO-TITLE-MISSING, que verifica /Info /Title). TRAPNET-ANNOT:N sinaliza anotações TrapNet (§7.18.2 as proíbe). ANNOT-PAGE-NO-TABS-S:N sinaliza páginas que carregam anotações cujo dicionário de página /Tabs não é /S (§7.18.3 exige ordem de tabulação de árvore de estrutura nessas páginas).
Auditorias PDF/UA-1 writer-side e reader-side agora estão aproximadamente em paridade: todo problema que a auditoria reader-side levanta em um arquivo salvo também é acessível do diagnóstico em memória, módulo as convenções de formato de cada função (texto separado por nova linha vs. lista de strings de código NNNNN).

v3.56.3 2026-05-23

A auditoria PDF/UA-1 ganha suas verificações de fonte de §7.21. 10020 informa qualquer fonte não-Standard-14 cujo FontDescriptor não tem FontFile/FontFile2/FontFile3 (§7.21.4.1: toda fonte renderizada deve incorporar seu programa). 10021 informa descendentes CIDFontType2 sem uma entrada /CIDToGIDMap (§7.21.3.2). 10022 sinaliza fontes Standard 14 (Helvetica, Times, Courier, Symbol, ZapfDingbats e variantes negrito / oblíquo) que são referenciadas sem um programa incorporado — §7.21.4 NOTA 5 deixa claro que não há isenção de incorporação para essas fontes. 10023 informa fontes que não têm um CMap /ToUnicode e não correspondem à lista de isenção §7.21.7 (codificações predefinidas MacRoman / MacExpert / WinAnsi, Type 0 com coleções de caracteres Adobe-GB1 / CNS1 / Japan1 / Korea1, TrueType não simbólico).
Fontes compostas Type 0 são inspecionadas em ambas as camadas: /ToUnicode no próprio dicionário pai Type 0, e incorporação / /CIDToGIDMap no primeiro CIDFont descendente. Fontes Type 3 pulam a verificação de incorporação (seus glifos são CharProcs inline), mas ainda participam da verificação /ToUnicode.
Os helpers PDFlibPDFA para trabalho de fonte semelhante intencionalmente não foram compartilhados — meia dúzia de rotinas curtas (remoção de prefixo de subset, tabela de nomes Standard-14, presença de FontFile, flag Symbolic) são duplicadas localmente como helpers UA* para que a auditoria PDF/A possa continuar evoluindo sem quebrar PDF/UA, e vice-versa.

v3.56.2 2026-05-23

A auditoria PDF/UA-1 ganha mais cinco verificações ISO 14289-1 cobrindo anotações, arquivos incorporados e conteúdo opcional. 10015 informa anotações Link que não têm uma descrição alternativa /Contents não vazia (§7.18.5) para que leitores de tela possam anunciar destinos de link. 10016 e 10017 sinalizam dicionários FileSpec de arquivo incorporado que estão sem as chaves de nome de arquivo /F ou /UF exigidas (§7.11). 10018 sinaliza dicionários de configuração de conteúdo opcional que omitem uma string de texto /Name não vazia (§7.10). 10019 sinaliza dicionários de configuração de conteúdo opcional que contêm a chave proibida /AS (§7.10).
A travessia de anotação por página que já alimentava as verificações de TrapNet e /Tabs /S agora também coleta dados de Link / /Contents na mesma passagem, mantendo a auditoria em O(N) na contagem de objetos.

v3.56.1 2026-05-23

A auditoria PDF/UA-1 ganha cinco novas verificações ISO 14289-1. 10010 verifica a permissão de extração para acessibilidade (bit 10 da chave de criptografia /P) em arquivos criptografados (§7.16). 10011 detecta formulários XFA dinâmicos através do elemento <dynamicRender>required</dynamicRender> dentro do pacote XFA XDP (§7.15). 10012 sinaliza Form XObjects que carregam uma entrada /Ref — XObjects de referência são proibidos (§7.20). 10013 sinaliza anotações TrapNet (§7.18.2). 10014 percorre cada página e informa qualquer página que carregue anotações cujo dicionário de página não defina /Tabs /S (§7.18.3) para que a ordem de tabulação siga a árvore de estrutura.
Todos os cinco novos códigos fluem através do mesmo par de handles CheckFileCompliance + GetStringListItem que a release anterior adicionou — não há nova superfície de API pública.

v3.56.0 2026-05-23

Nova auditoria reader-side CheckCompliancePDFUA valida um PDF externo contra ISO 14289-1 (PDF/UA-1). Complementa a verificação writer-side existente GetPDFUADiagnostics aceitando qualquer PDF de entrada (saída própria, saída de scanner, conteúdo de terceiros) e listando violações PDF/UA-1 da mesma forma que CheckFileCompliance já informa problemas PDF/A.
CheckFileCompliance agora aceita ComplianceTest = 2 para executar a nova auditoria PDF/UA-1. O teste PDF/A sob ComplianceTest = 1 não muda, e a lista de problemas ainda flui de volta através do par de handles existente GetStringListCount / GetStringListItem.
O primeiro corte cobre os portões fundacionais de conformidade PDF/UA-1 de §5 (identificação XMP pdfuaid:part) e §7.1 (fluxo Catalog /Metadata, marcador de PDF tagged, árvore de estrutura, preferência de título do visualizador, idioma do documento, XMP dc:title, valor /Suspects e a proibição de remapear tags de estrutura padrão). Oito códigos de diagnóstico são emitidos — 10001 até 10009 — mantendo a faixa numérica visualmente separada dos códigos PDF/A 00xxx.
Cláusulas PDF/UA-1 mais profundas (segurança, anotações, XObjects, subconjuntamento de fonte) são rastreadas para releases de patch de acompanhamento sobre o mesmo framework de auditoria.

v3.55.6 2026-05-22

Todo pacote XMP recém-gerado agora carrega uma propriedade xmpMM:InstanceID no formato uuid:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX. O identificador é gerado via Win32 CoCreateGuid e dá a cada documento produzido uma impressão digital única e independente de versão conforme recomendado por ISO 19005-1 §6.7.2 (Cor2) e guias de melhores práticas PDF/A. As compilações não-Windows (onde o pacote XMP permanece vazio) não são afetadas.
O namespace xmpMM (http://ns.adobe.com/xap/1.0/mm/) agora faz parte dos SelectionNamespaces do pacote XMP; novos helpers SetXMPMM e GenerateInstanceID sustentam a emissão de InstanceID e fornecem a base para suporte futuro a xmpMM:History / xmpMM:DerivedFrom.
O schema de descrição PDF/A Extension Schema (pdfaExtension / pdfaSchema / pdfaProperty / pdfaType / pdfaField) não é adicionado nesta release. Autorar um schema de extensão personalizado requer construção de propriedade estruturada / bag / seq em múltiplas etapas além do formato atual de SetDublinCore / SetXMPBasic; o trabalho está rastreado para uma release futura. Documentos que precisam declarar propriedades XMP personalizadas continuam a recorrer ao caminho LoadFromString.

v3.55.5 2026-05-22

Documentos PDF/A agora têm suas flags /F de anotação normalizadas no momento do salvamento. ISO 19005-1 §6.5.3 exige que o bit Print seja 1 e os bits Hidden / Invisible / NoView sejam 0 em toda anotação; o writer agora aplica essa máscara no momento do salvamento, de modo que os chamadores não precisem lembrar o layout de bits. O caso /Subtype /Popup é isento — popups são filhos de outras anotações e tradicionalmente não são impressos.
A flag /NeedAppearances do AcroForm agora é forçadamente definida como false no momento do salvamento quando o documento está em qualquer modo PDF/A. ISO 19005-1 §6.9 exige que a flag esteja ausente ou seja false; anteriormente o writer deixava qualquer valor que o chamador tivesse definido, o que produzia documentos que pediam ao visualizador para regenerar aparências no momento da abertura e violavam silenciosamente a especificação quando o chamador a tinha definido como true. A correção também roda para documentos que anteriormente tinham a flag ausente — o writer emite um /NeedAppearances false explícito para não deixar ambiguidade para o validador.

v3.55.4 2026-05-22

AddStandardFont agora rejeita chamadas no modo PDF/A. ISO 19005-1 §6.3.4 revoga a isenção da referência PDF "Standard 14 pode ser não incorporada": todo programa de fonte em um arquivo em conformidade deve ser incorporado, e a biblioteca não empacota os contornos das Standard 14. A fachada retorna 0 silenciosamente; os chamadores devem mudar para AddTrueTypeFont ou AddType1Font com um arquivo de fonte real.
AddTrueTypeFont agora promove silenciosamente Embed=0 (sem incorporação) para Embed=1 (incorporar fonte completa) quando o modo PDF/A está ativo. O caminho de referência não incorporada produzia PDF que dependia do fallback de fonte do visualizador para uma instalação de sistema Arial / Times / Courier, o que viola ISO 19005-1 §6.3.4. Chamadores existentes que pediram incorporação (Embed=1 ou 2) não são afetados.
A verificação de conformidade de /Encoding de TrueType não simbólico (ISO 19005-1 §6.3.7 Cor2 exige WinAnsi ou MacRoman como o nome de codificação ou BaseEncoding, sem /Differences) não é adicionada nesta release porque a biblioteca já emite /WinAnsiEncoding para subsets TrueType não simbólicos, e a aplicação mais profunda exigiria rastrear o despacho simbólico-vs-não-simbólico através do caminho de subset. CheckCompliancePDFA 00034 / 00035 (adicionados v3.51.0) sinalizam qualquer saída não conforme no momento da validação.

v3.55.3 2026-05-22

Dicionários de fonte CIDFontType2 baseados em TrueType agora carregam /CIDToGIDMap /Identity explicitamente. ISO 19005-1 §6.3.3.2 (Cor2) exige que a entrada esteja presente para todo Type 2 CIDFont incorporado; a referência PDF permite o padrão implícito Identity, mas PDF/A exige um valor explícito. O writer anteriormente omitia a chave inteiramente, fazendo com que veraPDF (e CheckCompliancePDFA 00033 adicionado em v3.51.0) sinalizassem o arquivo. O nome /Identity corresponde ao layout GID-as-CID que o writer já produzia implicitamente, de modo que documentos existentes renderizam identicamente.
FontDescriptor /CharSet (para subsets Type 1) e /CIDSet (para subsets CIDFont) permanecem TODO; o writer precisaria rastrear quais nomes de glifos / CIDs acabaram no subset para preenchê-los com precisão. CheckCompliancePDFA 00031 e 00032 (também adicionados em v3.51.0) sinalizarão a ausência para que os usuários vejam o problema no momento da validação.

v3.55.2 2026-05-22

AddImageDirectFromString agora rejeita filtros incompatíveis com PDF/A no ponto de entrada. Passar Filter = 'LZWDecode' é rejeitado para toda parte PDF/A (ISO 19005-1 §6.1.10 mais as regras equivalentes ISO 19005-2 / -3). Passar Filter = 'JBIG2Decode' ou 'JPXDecode' é rejeitado para PDF/A-1 (modos 1 e 2). PDF/A-2 e PDF/A-3 admitem JPXDecode sob ISO 19005-2 §6.2.8.3 com restrições de sub-especificação (contagem de canais de cor, uniformidade de profundidade de bits, requisitos METH/APPROX) que o portão writer-side não aplica — chamadores nesses modos ainda precisam garantir que o fluxo JPEG 2000 esteja em conformidade. A fachada retorna 0 silenciosamente quando um filtro proibido é solicitado.
Entradas TIFF, PNG, JPEG e JPEG 2000 carregadas através de AddImageFromFile / AddImageFromStream não são afetadas: o importador descomprime os bytes de origem e recodifica com FlateDecode (ou DCTDecode para payloads JPEG), de modo que entrada LZW nunca se propaga para a cadeia de Filter de saída. O validador CheckCompliancePDFA adicionado em v3.50.0 (00004) e v3.52.0 (00022, 00023) fornece uma segunda linha de defesa no momento da validação para qualquer caminho indireto que ainda inclua um filtro proibido na saída.

v3.55.1 2026-05-22

AddLinkToHideField agora rejeita chamadas no modo PDF/A. A release anterior deixou um comentário alegando que a ação era compatível com PDF/A, mas ISO 19005-1 Cor2 adicionou /Hide à lista de ações proibidas (§6.6.1), e ISO 19005-2 / -3 herdam a restrição. A fachada retorna 0 silenciosamente quando chamada no modo PDF/A, correspondendo a AddLinkToJavaScript e AddLinkToImportData.
AddSWFAnnotationFromFile agora rejeita chamadas no modo PDF/A. Anotações SWF / RichMedia envolvem mídia Flash, que é proibida por ISO 19005-1 §6.5.2 (sem subtipos Movie / Sound) e reforçada por ISO 19005-2 §6.3.1 (sem 3D / Sound / Screen / Movie). A fachada retorna 0 silenciosamente.
AddEmbeddedFile e AddLinkToEmbeddedFile agora rejeitam chamadas nos modos PDF/A-1 e PDF/A-2. ISO 19005-1 §6.1.11 proíbe /EF, e ISO 19005-2 §6.8 admite apenas arquivos PDF/A incorporados; em vez de verificar a PDF/A-idade recursiva do payload anexado, o writer simplesmente recusa a chamada nesses modos. PDF/A-3 (SetPDFAMode 5 ou 6) permanece permitido — veja v3.55.0 para a injeção automática de /AFRelationship.
SetOpenActionMenu agora rejeita valores de MenuItem fora da whitelist {NextPage, PrevPage, FirstPage, LastPage} quando o documento está no modo PDF/A. ISO 19005-1 §6.6.1 restringe ações nomeadas a esse conjunto, de modo que anteriormente a API produzia silenciosamente dicionários Open-Action não conformes Find / Print / FullScreen que veraPDF rejeitaria.
NewOptionalContentGroup agora rejeita chamadas nos modos PDF/A-1 (SetPDFAMode 1 ou 2). ISO 19005-1 §6.1.13 proíbe a chave Catalog /OCProperties. PDF/A-2 (modos 3/4) e PDF/A-3 (modos 5/6) admitem conteúdo opcional com as restrições em seu respectivo §6.9, de modo que o portão só dispara para PDF/A-1.

v3.55.0 2026-05-22

Documentos PDF/A-3 agora recebem automaticamente uma entrada /AFRelationship em todo arquivo incorporado. Anteriormente, um arquivo PDF/A-3 criado com a biblioteca poderia falhar na validação porque ISO 19005-3 Anexo E, Tabela E.1 exige AFRelationship em toda especificação de arquivo incorporado. O writer agora injeta o valor padrão configurado ('Unspecified' por padrão) em qualquer dicionário FileSpec que não tenha a entrada no momento do salvamento, espelhando a auto-injeção de AFRelationship PDF/UA introduzida anteriormente. Apenas os modos PDF/A-3 (SetPDFAMode 5 = PDF/A-3b ou 6 = PDF/A-3a) acionam a auto-injeção; PDF/A-1 e PDF/A-2 ainda rejeitam arquivos incorporados completamente por ISO 19005-1 §6.1.11 e ISO 19005-2 §6.8.
SetPDFA3DefaultAFRelationship é uma nova API que sobrescreve o valor padrão escrito pelo writer quando um arquivo incorporado não tem uma entrada /AFRelationship. Aceita os valores da Tabela E.1 de ISO 19005-3 'Source' (o arquivo incorporado é o material de origem que produziu o conteúdo do PDF), 'Data' (o arquivo é os dados estruturados que suportam uma tabela ou gráfico visual), 'Alternative' (uma renderização alternativa, como uma versão de áudio), 'Supplement' (uma representação suplementar, como uma forma MathML de uma equação), 'Unspecified' (relação não pode ser caracterizada pelos anteriores), ou qualquer nome de segunda classe registrado. String vazia redefine para 'Unspecified'. Sobreposições por arquivo permanecem disponíveis via SetEmbeddedFileAFRelationship.
As novas APIs são expostas na fachada Delphi como TPDFlib.SetPDFA3DefaultAFRelationship e via DLL como DLSetPDFA3DefaultAFRelationship (PWideChar) e DLSetPDFA3DefaultAFRelationshipA (PAnsiChar).

v3.54.0 2026-05-22

LoadOutputIntentProfile é uma nova API que substitui o perfil OutputIntent sRGB empacotado por um perfil ICC externo carregado do disco. Necessário ao produzir documentos PDF/A em espaços de cor DeviceCMYK ou DeviceGray, já que a biblioteca só envia um perfil sRGB. O uso típico é chamar SetPDFAMode primeiro (que inicializa o esqueleto OutputIntent), então LoadOutputIntentProfile('C:\\caminho\\para\\FOGRA39.icc', 'DeviceCMYK') para trocar os bytes do perfil e marcar o documento com o novo espaço de cor. Retorna 1 em sucesso, 0 em arquivo não encontrado ou espaço de cor desconhecido. Exposto na fachada Delphi como TPDFlib.LoadOutputIntentProfile e via DLL como DLLoadOutputIntentProfile (forma PWideChar) e DLLoadOutputIntentProfileA (forma PAnsiChar). ISO 19005-1 §6.2.2 permite qualquer perfil ICC registrado no fluxo DestOutputProfile.
SetFillColorCMYK, SetTextColorCMYK, SetTextHighlightColorCMYK, SetTextUnderlineColorCMYK, AddSeparationColor, SetFillColorSep, SetLineColorSep, SetTextHighlightColorSep e SetTextColorSep agora têm sucesso no modo PDF/A quando o perfil OutputIntent do documento é DeviceCMYK. Anteriormente, essas APIs rejeitavam toda chamada no modo PDF/A independentemente do OutputIntent, o que impedia que documentos CMYK em conformidade fossem produzidos. O portão agora é PDFAMode = 0 OU OutputIntentColorSpace = 'DeviceCMYK', correspondendo à regra ISO 19005-1 §6.2.3.3 de que DeviceCMYK é permitido quando o OutputIntent usa um perfil CMYK, e ISO 19005-1 §6.2.3.4 que permite alternativas Separation cujo espaço de cor base também está em conformidade.
SetTextShader agora tem sucesso no modo PDF/A quando o perfil OutputIntent é DeviceRGB ou DeviceCMYK. Shaders em si não são banidos por PDF/A; o validador (lado de leitura) verifica se o espaço de cor interno do shader corresponde ao OutputIntent. O comportamento anterior de rejeição estrita negava o uso de shader em conformidade.
O desbloqueio CMYK / Separation / Shader depende da tag OutputIntentColorSpace definida por AddOutputIntent e LoadOutputIntentProfile (introduzido em v3.53.0). Chamar SetPDFAMode sem LoadOutputIntentProfile mantém o espaço de cor como DeviceRGB (o perfil sRGB empacotado), de modo que chamadas CMYK ainda rejeitam por padrão — o novo comportamento é opt-in via LoadOutputIntentProfile.

v3.53.0 2026-05-22

O dicionário OutputIntent agora carrega os campos completos do esqueleto PDF/A recomendados por ISO 19005-1 §6.2.2 e Adobe Acrobat preflight: /OutputCondition (descrição legível por humanos da condição de cor), /Info (texto de identificação em forma longa) e /RegistryName (URL do registro, padrão http://www.color.org). Os valores assumem como padrão "sRGB IEC61966-2.1" / "sRGB IEC61966-2.1" / "http://www.color.org" para os pontos de chamada legados de argumento único; a nova sobrecarga de AddOutputIntent assume os quatro campos personalizados diretamente para que os chamadores possam preenchê-los para suas próprias condições de cor.
AddOutputIntent ganha uma nova sobrecarga de cinco argumentos: AddOutputIntent(ColorSpace, OutputConditionIdentifier, OutputCondition, Info, RegistryName). A forma legada de argumento único continua funcionando inalterada; agora ela delega para a nova sobrecarga com os padrões sRGB. O argumento ColorSpace também seleciona a contagem de componentes /N escrita no dicionário do perfil ICC incorporado (3 para DeviceRGB, 4 para DeviceCMYK, 1 para DeviceGray); o próprio perfil incorporado permanece o fluxo sRGB empacotado até que a API LoadOutputIntentProfile chegue em v3.54.0.
TPDFDocument expõe OutputIntentColorSpace como uma propriedade de leitura/escrita rastreando o espaço de cor da última chamada de AddOutputIntent. Isso se torna a condição de portão para as restrições writer-side CMYK / Separation / Shader em v3.54.0, onde APIs de cor que hoje rejeitam toda chamada no modo PDF/A rejeitarão apenas quando o espaço de cor estiver incompatível com o OutputIntent.

v3.52.0 2026-05-22

CheckCompliancePDFA agora audita anotações, graphics-state, ações e form XObjects, completando a cobertura do validador read-side PDF/A para ISO 19005-1 capítulos 6.2-6.6 e as regras diferenciais equivalentes PDF/A-2/-3. O validador informa 14 novas classes de problemas (00050-00067): subtipos de anotação proibidos (00050; ISO 19005-1 §6.5.2 proíbe FileAttachment / Sound / Movie para PDF/A-1, e ISO 19005-2 §6.3.1 proíbe 3D / Sound / Screen / Movie para PDF/A-2 e PDF/A-3), anotação /CA diferente de 1.0 (00051; §6.5.3), anotação /F ausente ou com Print=0 / Hidden=1 / Invisible=1 / NoView=1 (00052; §6.5.3, com /Subtype /Popup isento), anotação /AA (00054; §6.6.2), dict de aparência de anotação com chaves diferentes de /N ou valor /N não conforme (00055; §6.5.3 Cor2), anotação Widget com /A (00056; §6.9), ExtGState /TR (00058; §6.2.8), ExtGState /TR2 diferente de /Default (00059; §6.2.8), e somente em PDF/A-1: ExtGState /SMask diferente de /None (00061; §6.4), /BM diferente de Normal ou Compatible (00062; §6.4), /CA ou /ca diferente de 1.0 (00063; §6.4).
Auditoria de ação em qualquer lugar (00064, 00065) substitui a verificação apenas-OpenAction de v3.50.0 por uma varredura completa que sinaliza valores /S de ação proibidos (Launch, Sound, Movie, ResetForm, ImportData, JavaScript, Hide, SetState, NOP, Trans, GoTo3DView, Rendition, SetOCGState) e ações nomeadas cujo /N está fora de {NextPage, PrevPage, FirstPage, LastPage} independentemente de onde a ação vive (anotação /A, widget /A, outline /A, catalog /OpenAction, etc.). ISO 19005-1 §6.6.1.
Auditoria de XObject (00066, 00067) informa PostScript e Reference XObjects, mais chaves proibidas em Form XObjects (/OPI, /PS, /Subtype2 = /PS) e Image XObjects (/Alternates, /OPI, /Interpolate true). ISO 19005-1 §6.2.4 - §6.2.7.

v3.51.0 2026-05-22

CheckCompliancePDFA agora audita conformidade de fonte e espaço de cor além das verificações estruturais adicionadas em v3.50.0. O validador informa nove novas classes de problemas: pelo menos um programa de fonte não está incorporado (00030; ISO 19005-1 §6.3.4 exige que todo programa de fonte, incluindo as substituições Standard 14, seja incorporado), subset Type 1 sem /CharSet em seu FontDescriptor (00031; §6.3.5), subset CIDFont sem /CIDSet (00032; §6.3.5), CIDFontType2 sem /CIDToGIDMap (00033; §6.3.3.2 Cor2), TrueType não simbólico com /Encoding não conforme (00034; §6.3.7 Cor2 exige WinAnsi/MacRoman diretamente ou como BaseEncoding, sem /Differences), TrueType simbólico que ainda carrega /Encoding (00035; §6.3.7 Cor2), pelo menos uma fonte sem /ToUnicode em documentos PDF/A-Na ou PDF/A-Nu (00036; §6.3.8 com isenção de quatro classes aplicada), espaço de cor ICCBased que não incorpora seu fluxo de perfil (00037; §6.2.3.2), e um arquivo que usa tanto DeviceRGB quanto DeviceCMYK (00038; §6.2.3.3 proíbe a mistura).
A verificação /ToUnicode (00036) tem escopo nos níveis de conformidade A e U porque apenas esses níveis exigem mapeamento Unicode por ISO 19005-1 §6.3.8 e ISO 19005-2 §6.2.11.7. Arquivos de nível B (PDF/A-1b, PDF/A-2b, PDF/A-3b) não são sinalizados. A isenção de quatro classes reconhece codificações predefinidas (MacRomanEncoding, MacExpertEncoding, WinAnsiEncoding), BaseFonts Standard 14 Type 1 como um proxy para fontes Adobe Standard Latin / Symbol glyph-name, e fontes Type 0 cujo CIDFont descendente usa registros Adobe-GB1, Adobe-CNS1, Adobe-Japan1 ou Adobe-Korea1.
A auditoria de fonte percorre cada dicionário Font, classifica-o por Subtype (Type1, MMType1, TrueType, Type3, Type0 com seu descendente CIDFontType0 ou CIDFontType2), então despacha as verificações relevantes. Fontes compostas Type 0 delegam as verificações de incorporação e subset para seu CIDFont descendente, mantendo /ToUnicode no wrapper Type 0. A detecção de subset usa a convenção padrão de prefixo de seis letras maiúsculas.

v3.50.0 2026-05-22

CheckCompliancePDFA agora informa 15 problemas adicionais de não conformidade PDF/A que o validador anteriormente perdia: array /ID de trailer ausente (00013), fluxo /Metadata do Document Catalog ausente (00014), /Filter aplicado ao fluxo /Metadata (00015), dicionários de fluxo que referenciam arquivos externos via /F, /FFilter ou /FDecodeParms (00016), arquivos incorporados declarados via /EF em qualquer dicionário de especificação de arquivo ou via a entrada Name tree /EmbeddedFiles em documentos PDF/A-1 (00017, 00018), /OpenAction apontando para um tipo de ação proibido (00019), dicionários /AA de ação adicional no Document Catalog ou em qualquer Page (00020, 00021), filtros JBIG2Decode ou JPXDecode em documentos PDF/A-1 (00022, 00023), filtros Crypt cujo /Name não é /Identity (00024), /Requirements no Document Catalog (00025), /Perms com chaves diferentes de /UR3 e /DocMDP (00026), e /AcroForm /NeedAppearances definido como true (00027). O validador agora sinaliza tipos de ação /OpenAction do Catalog proibidos (/Launch, /Sound, /Movie, /ResetForm, /ImportData, /JavaScript, /Hide, /SetState, /NOP, /Trans, /GoTo3DView, /Rendition, /SetOCGState) e valores /N de ação nomeada fora da allowlist {NextPage, PrevPage, FirstPage, LastPage} por ISO 19005-1 §6.6.1.
O parser PDFAID aceita o sufixo de conformidade U (PDF/A-2U, PDF/A-3U) ao lado das variantes A e B existentes, de modo que CheckCompliancePDFA não levanta mais um aviso espúrio "00005 PDFA Mark NOT Found or invalid" ao escanear um arquivo PDF/A-2U ou PDF/A-3U produzido por outra ferramenta. Os níveis de conformidade de mapeamento Unicode adicionados em ISO 19005-2:2011 agora são reconhecidos pelo validador.
Verificações específicas de filtro (JBIG2Decode, JPXDecode) e verificações de arquivo incorporado (/EF, /EmbeddedFiles) permanecem com escopo em PDF/A-1 porque ISO 19005-2 §6.2.8.3 e §6.8 explicitamente relaxam essas restrições para PDF/A-2 e PDF/A-3. Verificações de estrutura de documento (/Metadata, /AcroForm /NeedAppearances, /OpenAction, /AA, /Requirements, /Perms) se aplicam a toda parte PDF/A.

v3.49.0 2026-05-21

AddLinkToImportData cria uma anotação Link cuja ação é uma ação PDF de importação de dados (/S /ImportData) que preenche os campos AcroForm do documento a partir de um arquivo FDF externo quando o usuário clica no link (ISO 32000-1 §12.6.4.8, Tabela 198). O parâmetro FileName é referenciado como um dicionário filespec, com as mesmas regras de normalização de caminho usadas por AddLinkToFile / AddLinkToFileEx (barras invertidas convertidas em barras normais conforme ISO 32000-1 §7.11.2.1). O bit 0 de Options alterna a borda visível, e os bits 1–3 selecionam o modo de destaque do link (Invert, Outline, Push), correspondendo às convenções existentes de AddLinkTo*. PDF 1.4 ou posterior. NÃO permitido em PDF/A porque a ação referencia um recurso externo; a fachada retorna silenciosamente 0 quando chamada no modo PDF/A. Exposto na biblioteca Delphi e na interface DLL como DLAddLinkToImportData / DLAddLinkToImportDataA (formas PWideChar e PAnsiChar).

v3.48.0 2026-05-21

AddLinkToHideField cria uma anotação Link cuja ação é uma ação PDF de ocultar (/S /Hide) que alterna a visibilidade de um ou mais campos AcroForm quando o usuário clica no link (ISO 32000-1 §12.6.4.10, Tabela 196). FieldNames aceita um ou mais nomes de campos totalmente qualificados separados por vírgulas, ponto e vírgulas ou quebras de linha; um único nome emite /T como uma string de texto e dois ou mais nomes emitem /T como um array, ambas as formas permitidas pela especificação. HideFlag seleciona a direção da visibilidade: um valor diferente de zero oculta os campos listados (/H true) e zero os exibe (/H false). O bit 0 de Options alterna a borda visível, e os bits 1–3 selecionam o modo de destaque do link (Invert, Outline, Push), correspondendo a AddLinkToWeb / AddLinkToNamedAction. PDF 1.2 ou posterior. Compatível com PDF/A porque nenhum recurso externo é referenciado. Exposto na biblioteca Delphi e na interface DLL como DLAddLinkToHideField / DLAddLinkToHideFieldA (formas PWideChar e PAnsiChar).

v3.47.0 2026-05-21

AddLinkToNamedAction cria uma anotação Link cuja ação é uma ação nomeada PDF (/S /Named) que aciona um dos quatro comandos padronizados de navegação do visualizador definidos em ISO 32000-1 §12.6.4.11, Tabela 194: NextPage, PrevPage, FirstPage e LastPage. O parâmetro NamedActionType seleciona o comando (0=NextPage, 1=PrevPage, 2=FirstPage, 3=LastPage); valores fora desse intervalo retornam para NextPage, de modo que o writer sempre emite um nome /N em conformidade com a especificação. O bit 0 de Options alterna a borda visível, e os bits 1–3 selecionam o modo de destaque do link (Invert, Outline, Push), correspondendo às convenções existentes de AddLinkToWeb / AddLinkToPage. A anotação exige PDF 1.1 ou posterior e é compatível com PDF/A porque nenhum recurso externo é referenciado. Disponível na biblioteca Delphi e nas interfaces DLL.

v3.46.1 2026-05-21

AddCaretAnnotation cria uma anotação de marcação caret (PDF /Subtype /Caret) no retângulo fornecido, marcando uma posição na página onde texto ou conteúdo foi inserido, omitido ou requer atenção do revisor. Suporta dois tipos de símbolo (None e Paragraph) via SymbolType (0 / 1), cor configurável, opacidade, título, conteúdo e timestamps de criação/modificação. Definido em ISO 32000-1 §12.5.6.11. PDF 1.5 ou posterior. Disponível na biblioteca Delphi e nas interfaces DLL.
Esta entrada conclui o preenchimento das anotações geométricas que começou com v3.44.0 Square+Circle. O PDFlibPas agora cria anotações Text, Stamp, FreeText, TextMarkup (Highlight/Underline/Squiggly/StrikeOut), Square, Circle, Line, Polygon, PolyLine, Ink e Caret, além do suporte existente para Link, FileAttachment, SVG, U3D e SWF.

v3.46.0 2026-05-21

AddInkAnnotation cria uma anotação de marcação tinta (PDF /Subtype /Ink) representando traços manuscritos ou marcas em forma livre desenhadas na página. Os traços são fornecidos como uma única string em que múltiplos traços são separados por '|' ou nova linha, e dentro de cada traço os pares de coordenadas seguem o mesmo formato espaço/vírgula/ponto e vírgula/tabulação usado por AddPolygonAnnotation. Por exemplo, "100 100 110 105 120 110 | 200 200 210 205" descreve dois traços separados. Suporta largura da borda, cor da tinta, opacidade, título, conteúdo e timestamps configuráveis. Definido em ISO 32000-1 §12.5.6.13. PDF 1.3 ou posterior. Disponível na biblioteca Delphi e nas interfaces DLL.
Cada traço deve conter um número par de valores (pelo menos quatro); caso contrário, a chamada retorna 0 sem que nenhuma anotação seja escrita. O /Rect é calculado automaticamente a partir da extensão combinada de todos os traços mais um pequeno preenchimento para que os traços permaneçam dentro da caixa delimitadora da anotação.

v3.45.0 2026-05-21

AddPolygonAnnotation cria uma anotação de marcação polígono fechado (PDF /Subtype /Polygon) com vértices fornecidos como uma string de pares de coordenadas separados por espaços, vírgulas, ponto e vírgulas ou tabulações (por exemplo, "100 100 200 100 200 200 100 200"). Suporta largura da borda, cor da borda, cor de preenchimento interior opcional, opacidade, título, conteúdo e timestamps configuráveis. Definido em ISO 32000-1 §12.5.6.9. PDF 1.5 ou posterior. Disponível na biblioteca Delphi e nas interfaces DLL.
AddPolyLineAnnotation cria uma anotação de marcação polilinha aberta (PDF /Subtype /PolyLine) com o mesmo formato de string de vértices e estilos configuráveis de linha terminal em cada extremidade (None, Square, Circle, Diamond, OpenArrow, ClosedArrow, Butt, ROpenArrow, RClosedArrow, Slash). Definido em ISO 32000-1 §12.5.6.9. PDF 1.5 ou posterior. Disponível na biblioteca Delphi e nas interfaces DLL.
Ambas as anotações exigem pelo menos dois vértices (quatro números) e uma quantidade total par de números; a chamada retorna 0 se a string de vértices não puder ser analisada em uma lista de pares válida. O /Rect é calculado a partir da extensão dos vértices mais um preenchimento proporcional à largura da borda para que as decorações das extremidades permaneçam visíveis.
Ambas as anotações elevam a versão do documento para PDF 1.5 quando emitidas sob uma trava de versão mínima inferior.

v3.44.1 2026-05-21

AddLineAnnotation cria uma anotação de marcação linha (PDF /Subtype /Line) entre dois pontos finais, com largura da borda, cor da linha, cor de preenchimento interior opcional, estilos de linha terminal para ambas as extremidades (None, Square, Circle, Diamond, OpenArrow, ClosedArrow, Butt, ROpenArrow, RClosedArrow, Slash), opacidade, título, conteúdo e timestamps de criação/modificação configuráveis. Definido em ISO 32000-1 §12.5.6.7. PDF 1.3 ou posterior. Disponível na biblioteca Delphi e nas interfaces DLL.
O /Rect da anotação é calculado a partir dos dois pontos finais mais um preenchimento proporcional à largura da borda para que as decorações das extremidades permaneçam dentro da caixa delimitadora da anotação.

v3.44.0 2026-05-21

AddSquareAnnotation cria uma anotação de marcação retângulo (PDF /Subtype /Square) no retângulo fornecido, com largura da borda, cor da borda, cor de preenchimento interior opcional, opacidade, título, conteúdo e timestamps de criação/modificação configuráveis. Definido em ISO 32000-1 §12.5.6.8. PDF 1.3 ou posterior. Disponível na biblioteca Delphi e nas interfaces DLL.
AddCircleAnnotation cria uma anotação de marcação elipse (PDF /Subtype /Circle) inscrita no retângulo fornecido, com a mesma configuração de borda, preenchimento, opacidade, título, conteúdo e timestamps de AddSquareAnnotation. Definido em ISO 32000-1 §12.5.6.8. PDF 1.3 ou posterior. Disponível na biblioteca Delphi e nas interfaces DLL.
Ambas as novas anotações elevam automaticamente a versão do documento para PDF 1.3 quando emitidas sob uma trava de versão mínima inferior e emitem um conjunto padrão de campos de anotação de marcação (/Type /Subtype /Rect /C /IC /BS /Border /CA /F /M /CreationDate /NM /T /Contents /Subj /P), de modo que os fluxos de trabalho de revisão existentes no Acrobat, Foxit e Edge podem editá-las após a criação.

v3.43.0 2026-05-20

SetStructElemSpaceBefore e SetStructElemSpaceAfter definem os atributos /SpaceBefore e /SpaceAfter (Layout owner) no elemento de estrutura atualmente aberto, expressando o espaçamento antes e depois de elementos de nível de bloco em pontos. Definido em ISO 32000-1 §14.8.5.4.2 Tabela 340. Disponível na biblioteca Delphi, ActiveX (Dispids 73008051/73008052) e interfaces DLL.
SetStructElemStartIndent e SetStructElemEndIndent definem os atributos /StartIndent e /EndIndent (Layout owner), expressando o recuo a partir das bordas inicial e final, conscientes do modo de escrita, do retângulo de conteúdo em pontos. Definido em ISO 32000-1 §14.8.5.4.2 Tabela 340. Disponível na biblioteca Delphi, ActiveX (Dispids 73008053/73008054) e interfaces DLL.
SetStructElemColor define o atributo /Color (Layout owner) como uma tripla RGB (cada componente 0.0-1.0), descrevendo a cor de primeiro plano do elemento para mecanismos de re-flow e verificadores de contraste de cor posteriores. Definido em ISO 32000-1 §14.8.5.4.2 Tabela 340. Disponível na biblioteca Delphi, ActiveX (Dispid 73008055) e interfaces DLL.
Corrigido um bug de serialização em BuildStructElemDictRef: valores numéricos de atributo de um único token (como SpaceBefore, SpaceAfter, StartIndent, EndIndent) estavam sendo escritos como nomes PDF em vez de números PDF. A correção se aplica tanto aos ramos de atributo de single-owner quanto de multi-owner.

v3.42.0 2026-05-20

CheckCompliancePDFA agora valida corretamente todos os seis modos PDF/A (1a, 1b, 2a, 2b, 3a, 3b). A verificação PDFAID (código 00005) aceita qualquer um dos seis marcadores XMP válidos em vez de apenas '1B'. A verificação de limite de versão (00002) aplica 1.4 para PDF/A-1 e 1.7 para PDF/A-2 e PDF/A-3.
A verificação OCProperties (código 00003) agora é condicional: aplica-se apenas a documentos PDF/A-1, onde o conteúdo opcional (camadas) é proibido. PDF/A-2 e PDF/A-3 permitem camadas e não são mais sinalizados.
Três novas verificações de conformidade adicionadas: código 00006 sinaliza documentos criptografados (criptografia é proibida em todas as versões PDF/A); código 00007 sinaliza documentos sem uma entrada OutputIntents no catálogo (exigida por todas as versões PDF/A); códigos 00011 e 00012 sinalizam documentos sem MarkInfo ou StructTreeRoot quando o nível de conformidade é -a (acessibilidade).

v3.41.0 2026-05-20

O modo PDF/A agora impõe operações proibidas no nível da API. Quando um modo PDF/A está ativo (qualquer um dos modos 1-6), chamadas a SetEncryption, AddSeparationColor, SetFillColorCMYK, SetTextColorCMYK ou qualquer outra API CMYK/Separation/Shader retornam 0 e não têm efeito, consistente com a exigência do PDF/A de uma única intenção de saída sRGB.
Transparência é proibida em PDF/A-1 (modos 1 e 2): SetTransparency, SetBlendMode e SetPageTransparencyGroup retornam 0 e são no-ops quando o modo ativo é 1 ou 2. PDF/A-2 e PDF/A-3 (modos 3-6) permitem transparência limitada e não são restritos.
Ações JavaScript são proibidas em todos os modos PDF/A (1-6): SetOpenActionJavaScript, PageJavaScriptAction, DocJavaScriptAction, AddGlobalJavaScript e AddLinkToJavaScript todos retornam 0 e são no-ops quando qualquer modo PDF/A está ativo. ISO 19005-1 §6.6.1 proíbe explicitamente JavaScript em documentos PDF/A.
APIs de anexo de arquivo (EmbedFile, AddFileAttachment) são bloqueadas nos modos PDF/A-1 e PDF/A-2 (1-4). Permanecem funcionais em PDF/A-3 (modos 5 e 6), que permite explicitamente arquivos incorporados arbitrários.

v3.40.0 2026-05-20

SetPDFAMode agora suporta os níveis de conformidade PDF/A-2 e PDF/A-3. Passe NewMode=3 para PDF/A-2b, 4 para PDF/A-2a, 5 para PDF/A-3b ou 6 para PDF/A-3a. PDF/A-2 tem como alvo PDF 1.7 e permite camadas, formulários interativos, imagens JPEG2000 e transparência limitada. PDF/A-3 estende PDF/A-2 permitindo arquivos incorporados arbitrários (qualquer tipo MIME). Todas as variantes -a escrevem automaticamente /MarkInfo e os marcadores de estrutura PDF marcados exigidos pelo nível de conformidade de acessibilidade.
Corrigido: SetPDFAMode(1) (PDF/A-1a) era anteriormente um no-op devido a um bug interno de roteamento introduzido em v3.20.0. Agora escreve corretamente /MarkInfo e /OutputIntents e define XMP pdfaid:part=1/conformance=A.
GetInformation(201) retorna '1' a '6' correspondendo ao modo PDF/A ativo, consistente com a nova numeração de modos.

v3.39.0 2026-05-20

SetStructElemWritingMode define o atributo /WritingMode (Layout owner) no elemento de estrutura atualmente aberto. Valores válidos são LrTb (da esquerda para a direita, padrão para scripts latinos), RlTb (da direita para a esquerda, para árabe e hebraico) e TbRl (de cima para baixo, da direita para a esquerda, para texto vertical CJK tradicional). Definido em ISO 32000-1 §14.8.5.4.2 Tabela 340. Disponível na biblioteca Delphi, ActiveX (Dispid 73008049) e interfaces DLL.
SetStructElemListNumbering define o atributo /ListNumbering (List owner) no elemento de estrutura atualmente aberto. Valores suportados incluem None, Disc, Circle, Square (marcadores não ordenados) e Decimal, UpperRoman, LowerRoman, UpperAlpha, LowerAlpha (numeração ordenada). O atributo é definido no elemento L (lista) e permite que a tecnologia assistiva anuncie o tipo de lista corretamente. Definido em ISO 32000-1 §14.8.5.3.2 Tabela 336. Disponível na biblioteca Delphi, ActiveX (Dispid 73008050) e interfaces DLL.

v3.38.0 2026-05-20

SetStructElemColSpan define o atributo /ColSpan (Table owner) no elemento de estrutura atualmente aberto, indicando por quantas colunas a célula se estende. Definido em ISO 32000-1 §14.8.5.7.2 Tabela 337. Disponível na biblioteca Delphi, ActiveX (Dispid 73008047) e interfaces DLL.
SetStructElemRowSpan define o atributo /RowSpan (Table owner) no elemento de estrutura atualmente aberto, indicando por quantas linhas a célula se estende. Definido em ISO 32000-1 §14.8.5.7.2 Tabela 337. Disponível na biblioteca Delphi, ActiveX (Dispid 73008048) e interfaces DLL.
Ambas as funções são wrappers de conveniência equivalentes a chamar AddTagAttribute com Owner='Table' e o respectivo nome de atributo. Complementam SetStructElemScope para células de tabela totalmente descritas em tabelas complexas ou com cabeçalhos abrangentes.

v3.37.2 2026-05-20

GetPDFUADiagnostics agora informa FORM-NO-TOOLTIP:N quando N campos de formulário interativos (anotações Widget) estão sem uma entrada TU (tooltip / nome acessível). ISO 14289-1 §7.18.4 exige que todos os campos de formulário interativos contenham uma entrada TU para que a tecnologia assistiva possa anunciar a finalidade do campo ao usuário quando o campo recebe foco. /TU é o nome acessível que os leitores de tela leem em voz alta; é distinto de /T, que é o nome parcial do campo usado para acesso programático e submissão de formulários.

v3.37.1 2026-05-20

GetPDFUADiagnostics agora informa LIST-STRUCT:N quando N elementos de estrutura LI ou LBody aparecem fora de seu elemento pai obrigatório. ISO 32000-1 §14.8.4.4 exige que LI seja filho direto de L (lista) e LBody seja filho direto de LI (item de lista). Aninhamento de lista malformado impede que a tecnologia assistiva percorra e anuncie corretamente o conteúdo da lista e pode causar falhas de validação de estrutura de documento em validadores PDF/UA-1.

v3.37.0 2026-05-20

BeginTagEx2 é uma nova API que abre um elemento de estrutura e define todas as propriedades principais do elemento em uma única chamada. Além dos parâmetros TagType, AltText, ActualText e Lang de BeginTagEx, BeginTagEx2 aceita Title (/T, para o painel de navegação Tags), ElemID (/ID, identificador exclusivo do elemento) e Expansion (/E, texto completo de uma abreviação ou acrônimo). Passar uma string vazia para qualquer um desses três parâmetros adicionais equivale a omitir o setter correspondente. BeginTagEx2 reduz o boilerplate para elementos bem descritos — em vez de chamar BeginTagEx seguido por SetStructElemTitle, SetStructElemID e SetStructElemExpansion separadamente, todas as sete propriedades podem ser definidas em uma única chamada. A função está disponível na biblioteca Delphi, ActiveX (Dispid 73008046) e interfaces DLL.

v3.36.1 2026-05-20

GetPDFUADiagnostics agora informa TABLE-TH-NO-SCOPE:N quando N elementos de estrutura TH (célula de cabeçalho de tabela) estão sem um atributo Scope. ISO 32000-1 §14.8.4.3.4 Tabela 337 define Scope (Row, Column ou Both) como o atributo que descreve a quais células de dados uma célula de cabeçalho se aplica. Sem ele, leitores de tela e outras tecnologias assistivas não conseguem associar de forma confiável células de cabeçalho a células de dados em tabelas complexas ou com múltiplos cabeçalhos, o que é exigido por ISO 14289-1 §7.5. Chame SetStructElemAttr('Table','Scope', 'Column') (ou 'Row' / 'Both') imediatamente após tagear cada elemento TH.

v3.36.0 2026-05-20

SetStructElemExpansion é uma nova API que define a entrada /E (texto de expansão) no elemento de estrutura atualmente aberto (ISO 32000-1 §14.9.5). O texto de expansão é a forma totalmente escrita de uma abreviação ou acrônimo contido no elemento — por exemplo, "World Wide Web" para um Span cujo texto é "WWW". Os leitores de tela falam a expansão em vez de tentar pronunciar os caracteres abreviados, o que é crítico para a acessibilidade de conteúdo técnico e científico. PDF/UA-1 (ISO 14289-1 §7.2) exige que o idioma natural seja inequivocamente determinável; /E é o mecanismo padrão para abreviações e acrônimos. A função está disponível na biblioteca Delphi, ActiveX e interfaces DLL.

v3.35.1 2026-05-20

GetPDFUADiagnostics agora informa DOCINFO-TITLE-MISSING quando a entrada /Title do dicionário de informações do documento está ausente ou vazia. PDF/UA-1 (ISO 14289-1) exige um título de documento para que os leitores de tela possam anunciá-lo quando o documento é aberto. A verificação DISPLAYDOCTITLE-FALSE existente confirma que o título é exibido na barra de título do visualizador; DOCINFO-TITLE-MISSING é complementar — confirma que o próprio valor do título está definido. Chame SetDocumentInfo('Title', ...) para fornecer o valor.

v3.35.0 2026-05-20

SetStructElemTitle é uma nova API que define a entrada /T (título) no elemento de estrutura atualmente aberto (ISO 32000-1 §14.7.2 Tabela 324). O título é um rótulo legível por humanos que identifica a instância específica do elemento — por exemplo, "Chapter 1", "Summary Table" ou "Figure 3: Quarterly Sales" — e é mostrado no painel de navegação Tags dos visualizadores PDF e usado por ferramentas de remediação de acessibilidade. /T é distinto de /Alt (texto alternativo para usuários com deficiência de renderização) e /ActualText (correção de texto no nível de glifo); é mais útil em elementos de contêiner não textuais, como Table, Figure, Form, Sect e Div. Passe uma string vazia para limpar um valor previamente definido. A função está disponível na biblioteca Delphi, ActiveX e interfaces DLL.

v3.34.0 2026-05-20

SetStructElemAltText é uma nova API que define a entrada /Alt no elemento de estrutura atualmente aberto (ISO 32000-1 §14.9.3). É equivalente a passar AltText para BeginTag, mas permite que a descrição de texto alternativo seja definida ou atualizada depois que o elemento foi aberto — útil quando a descrição é computada separadamente do tipo do elemento. PDF/UA-1 (ISO 14289-1 §7.5) exige texto Alt em elementos Figure e Formula; GetPDFUADiagnostics já informa FIGURE-NO-ALT:N para valores ausentes. A função está disponível na biblioteca Delphi, ActiveX e interfaces DLL.

v3.33.1 2026-05-20

GetPDFUADiagnostics agora inclui uma verificação ROLEMAP-UNMAPPED:N que detecta nomes de tipos de elementos de estrutura personalizados usados no documento que não têm entrada no dicionário /RoleMap. ISO 14289-1 §7.1 e ISO 32000-1 §14.7.3 exigem que todo tipo de estrutura não padrão seja mapeado para um tipo PDF padrão (como P, Span ou Figure) para que a tecnologia assistiva possa determinar como lidar com o elemento. Quando N tipos não mapeados são encontrados, a descrição do problema inclui a lista de nomes de tipos para que os chamadores saibam quais entradas AddRoleMap são necessárias. Todos os 49 tipos de estrutura padrão definidos em ISO 32000-1 Tabela 333 (PDF 1.7) são reconhecidos e excluídos do relatório.

v3.33.0 2026-05-20

SetStructElemLang é uma nova API que define a entrada /Lang no elemento de estrutura atualmente aberto (ISO 32000-1 §14.9.2). A tag de idioma sobrescreve o idioma no nível do documento declarado por SetDocumentLanguage ou SetPDFUAMode para o elemento e todos os seus descendentes, permitindo que documentos multilíngues marquem cada span com sua tag de idioma BCP 47 correta (por exemplo, 'en-US', 'fr', 'zh-Hant-TW'). Leitores de tela usam o /Lang no nível do elemento para selecionar o mecanismo de texto para fala ou a voz apropriada ao ler o documento em voz alta. A função está disponível na biblioteca Delphi, ActiveX e interfaces DLL.

v3.32.0 2026-05-20

SetStructElemActualText é uma nova API que define a entrada /ActualText no elemento de estrutura atualmente aberto (ISO 32000-1 §14.9.4). Use-a para especificar o texto Unicode exato que uma sequência de glifos representa quando a extração do fluxo de conteúdo produziria resultados incorretos — os casos mais comuns são glifos de ligaduras OpenType (U+FB00 ff, U+FB01 fi, U+FB02 fl) e abreviações com expansões não óbvias. ActualText complementa, em vez de substituir, o conteúdo renderizado; sobrescreve o que a tecnologia assistiva e os extratores de texto leem para aquele elemento sem suprimir a renderização visual. A função está disponível na biblioteca Delphi, ActiveX e interfaces DLL.

v3.31.1 2026-05-20

GetPDFUADiagnostics agora verifica elementos de estrutura Formula além de elementos Figure ao informar texto Alt ausente (FIGURE-NO-ALT:N). ISO 32000-1 §14.9.3 exige descrições alternativas para figuras gráficas e fórmulas matemáticas; anteriormente apenas elementos Figure eram verificados.
GetPDFUADiagnostics agora informa PDF-VERSION-LOW quando a versão PDF do documento está abaixo de 1.7. PDF/UA-1 (ISO 14289-1) é definido contra PDF 1.7 (ISO 32000-1:2008); documentos em PDF 1.5 ou 1.6 não satisfariam os requisitos da especificação base. Chame SetPDFUAMode para elevar automaticamente a versão para 1.7.

v3.31.0 2026-05-19

IDs de elementos de estrutura e associação de cabeçalhos de tabela agora são suportados. SetStructElemID atribui um identificador de string único (/ID) ao elemento de estrutura atualmente aberto; os IDs são coletados em uma name tree /IDTree na raiz da árvore de estrutura quando o documento é salvo, permitindo que ferramentas de acessibilidade e referências cruzadas localizem elementos por ID (ISO 32000-1 §14.7.4). SetStructElemHeaders associa a célula de tabela atual (TD ou TH) com uma ou mais células de cabeçalho por meio de uma lista separada por vírgulas de IDs previamente atribuídos, escrevendo o array /Headers no dicionário do owner Table attribute (ISO 32000-1 §14.8.5.7.2). Juntas, essas duas funções suportam a marcação complexa de tabelas para PDF/UA-1 (ISO 14289-1 §7.10) e WCAG 2.x SC 1.3.1. Ambas as funções estão disponíveis na biblioteca Delphi, ActiveX e interfaces DLL. AddTagAttribute agora também lida corretamente com o atributo /Headers, com valores delimitados por vírgulas escritos como arrays de strings de texto PDF.

v3.30.1 2026-05-19

GetPDFUADiagnostics agora inclui uma verificação HEADING-LEVEL-SKIP:N que detecta saltos no nível de título na ordem do documento (por exemplo, um H1 imediatamente seguido por um H3 sem um H2 no meio). A verificação realiza uma travessia em pré-ordem de toda a árvore de elementos de estrutura e conta cada ocorrência em que o próximo nível de título excede o anterior em mais de um. Elementos H genéricos são tratados como H1. Voltar para um título de nível superior (H3 → H1) não é contado como um salto. WCAG 2.x Critério de Sucesso 1.3.1 e ISO 14289-1 §7.1 exigem que os títulos sejam aninhados sem lacunas.

v3.30.0 2026-05-19

Atributos de elementos de estrutura agora são suportados para PDF tagged e documentos PDF/UA. Três novas funções de API permitem que atributos sejam anexados ao elemento de estrutura atualmente sendo construído na pilha de tags: AddTagAttribute (uso geral, qualquer owner/name/value), SetStructElemScope (wrapper de conveniência que define o atributo /Scope sob o owner Table, para células de cabeçalho TH — ISO 32000-1 §14.8.5.7.2) e SetStructElemBBox (wrapper de conveniência que define o atributo /BBox sob o owner Layout, para figuras e outros elementos posicionados visualmente — ISO 32000-1 §14.8.5.4). Quando o documento é salvo, os atributos são escritos como dicionários de atributos /A em cada elemento de estrutura; múltiplos atributos do mesmo owner são agrupados em um dict, e atributos de owners diferentes são escritos como um array de dicts. Todas as três funções estão disponíveis na biblioteca Delphi, ActiveX e interfaces DLL.

v3.29.1 2026-05-19

GetPDFUADiagnostics agora inclui duas verificações adicionais: se algum elemento de estrutura Figure no documento está sem um valor de texto Alt (informado como FIGURE-NO-ALT:N, por ISO 14289-1 §7.5 e ISO 32000-1 §14.9.3), e se algum elemento de estrutura ainda está aberto porque EndTag não foi chamado (informado como STRUCT-UNCLOSED:N). A verificação de figura realiza uma travessia recursiva completa da árvore de elementos de estrutura, cobrindo elementos em todas as profundidades de aninhamento.

v3.29.0 2026-05-19

GetPDFUADiagnostics é uma nova API de diagnóstico que verifica um documento quanto a possíveis problemas de conformidade com PDF/UA-1 (ISO 14289-1) e retorna uma lista de descobertas separadas por nova linha. Seis verificações são realizadas: se MarkInfo/Marked está definido (PDF tagged), se o catálogo do documento tem uma entrada /Lang, se ViewerPreferences/DisplayDocTitle é true, se os metadados XMP contêm um identificador pdfuaid:part, a contagem de anotações não isentas sem uma entrada Contents, e a contagem de arquivos incorporados sem uma entrada AFRelationship. Cada descoberta é identificada por um código curto (por exemplo, LANG-MISSING, ANNOT-NO-CONTENTS:3) seguido por uma descrição legível por humanos. Retorna uma string vazia quando nenhum problema é encontrado. Disponível na biblioteca Delphi, ActiveX e interfaces DLL.

v3.28.5 2026-05-19

Melhoria de acessibilidade de anotações PDF/UA-1: quando uma anotação FileAttachment não tem entrada Contents e nenhum campo /T, o nome do arquivo da especificação de arquivo incorporada da anotação (/FS /UF ou /F) agora é usado como descrição acessível de fallback. Isso completa a cadeia de fallback de Contents de anotação: /T → Link URI → nome de Stamp → nome do arquivo de FileAttachment. Os leitores de tela recebem o nome do arquivo anexado em vez de silêncio, satisfazendo ISO 14289-1 §7.18.1 para os tipos mais comuns de anotação.

v3.28.4 2026-05-19

Melhoria de acessibilidade de anotações PDF/UA-1: quando uma anotação Stamp não tem entrada Contents (ou está vazia) e nenhum campo /T, o nome do tipo de carimbo da entrada /Name da anotação agora é usado como descrição acessível de fallback (por exemplo, "Approved", "Draft", "Confidential", "Final"). Isso estende a cadeia de fallback de Contents de anotação introduzida em v3.28.3 para cobrir anotações de carimbo, que são comuns em fluxos de trabalho envolvendo documentos revisados ou aprovados e frequentemente não têm um valor explícito de Contents.

v3.28.3 2026-05-19

Melhoria de acessibilidade de anotações PDF/UA-1: quando uma anotação Link não tem entrada Contents (ou está vazia) e nenhum campo /T, o URI da ação URI da anotação agora é usado como descrição acessível de fallback. Isso se aplica apenas durante o processamento de SetPDFUAMode e apenas a anotações Link que carregam uma ação /URI. Os leitores de tela recebem a URL como rótulo de último recurso, satisfazendo ISO 14289-1 §7.18.1 no caso comum em que os autores criam hyperlinks sem fornecer uma descrição legível por humanos.

v3.28.2 2026-05-19

SetEmbeddedFileAFRelationship é uma nova API para definir explicitamente o valor AFRelationship no dicionário de especificação de arquivo de um arquivo incorporado. Exigido por ISO 14289-1 (PDF/UA-1) §7.11, isso permite que os chamadores especifiquem a relação semântica de um arquivo incorporado com o conteúdo do documento, escolhendo entre os cinco valores válidos: Source, Data, Alternative, Supplement ou Unspecified. Quando SetPDFUAMode está ativo, qualquer arquivo incorporado sem uma chave AFRelationship recebe automaticamente Unspecified; use esta função para substituir esse padrão antes de salvar. Disponível na biblioteca Delphi, ActiveX e interfaces DLL.

v3.28.1 2026-05-19

Quando SetPDFUAMode é chamado em um documento cujos metadados XMP carregam o título genérico padrão da biblioteca em vez de um específico do documento, o título agora é automaticamente substituído pelo valor da entrada Title de /Info do documento (se houver uma presente). Isso garante que o pacote XMP pdfuaid:part-1 reflita o título real do documento em vez de um placeholder, satisfazendo as expectativas do verificador PDF/UA-1.
O parser XMP (LoadFromString) agora lê o valor dc:title dos metadados XMP existentes quando um documento é carregado, de modo que o round-tripping de um PDF que já tem dc:title preserva corretamente esse título em vez de reverter para o placeholder padrão.

v3.28.0 2026-05-19

BeginArtifactEx(ArtifactType, ArtifactSubtype) é uma nova API de PDF tagged que estende BeginArtifact para expressar tanto o /Type do artifact quanto o /Subtype da Pagination em uma única chamada. Quando ambos os parâmetros não estão vazios, o operador escrito é /Artifact << /Type /T /Subtype /S >> BMC, permitindo artifacts de Pagination totalmente especificados, como cabeçalhos e rodapés, conforme ISO 32000-1 §14.8.2.2.1. Se apenas um parâmetro não está vazio, a forma correspondente de chave única é usada. Os pontos de entrada DLL DLBeginArtifactEx e DLBeginArtifactExA também são exportados.

v3.27.2 2026-05-19

BeginArtifact agora distingue corretamente os tipos de artifact dos subtipos de paginação. Quando o argumento é Pagination, Layout ou Page (tipos de artifact conforme ISO 32000-1 §14.8.2.2.1 Tabela 330), o operador marked-content escreve /Type em vez de /Subtype. Outros valores, como Header, Footer e Watermark, continuam sendo escritos como /Subtype. Isso corrige a saída anteriormente incorreta que escrevia /Subtype /Pagination quando o chamador pretendia marcar um artifact de paginação.

v3.27.1 2026-05-19

Quando o modo PDF/UA está ativo e o documento contém arquivos incorporados, cada dicionário de especificação de arquivo que não possui uma entrada AFRelationship agora recebe uma automaticamente no momento do salvamento. O valor escrito é /Unspecified, satisfazendo o requisito ISO 14289-1 §7.11 de que todo arquivo incorporado carregue uma chave AFRelationship. Isso se aplica tanto aos arquivos adicionados via EmbedFile quanto aos arquivos incorporados já presentes em um documento carregado.

v3.27.0 2026-05-19

AddRoleMap(CustomType, StandardType) é uma nova API de PDF tagged que registra um mapeamento de um nome de tipo de elemento de estrutura personalizado (não padrão) para um tipo de estrutura PDF padrão. Quando salvos, os mapeamentos são escritos no dicionário RoleMap na raiz da árvore de estrutura, satisfazendo o requisito ISO 14289-1 §7.1 para documentos que usam nomes de tag específicos de aplicação. Múltiplos mapeamentos podem ser registrados; chaves duplicadas são sobrescritas pela última chamada. Os pontos de entrada DLL DLAddRoleMap e DLAddRoleMapA também são exportados.

v3.26.0 2026-05-19

BeginTagEx(TagType, AltText, ActualText, Lang) é uma nova API de PDF tagged que estende BeginTag com um atributo explícito de idioma natural. Quando Lang não está vazio, é escrito no atributo /Lang do elemento de estrutura, permitindo anotação de idioma por elemento exigida por ISO 14289-1 §7.2 para documentos multilíngues. Passe uma string Lang vazia para se comportar de forma idêntica a BeginTag. Os pontos de entrada DLL DLBeginTagEx e DLBeginTagExA também são exportados.

v3.25.1 2026-05-19

Fontes TrueType não subconjuntadas carregadas com a code page padrão do Windows (WinAnsiEncoding) agora recebem um fluxo CMap ToUnicode, permitindo extração confiável de texto Unicode e copiar/colar para essas fontes. Anteriormente, um fluxo ToUnicode era escrito apenas quando uma substituição explícita de code page ou array de Differences estava presente; o caminho comum de codificação padrão não o possuía.
A mesma correção se aplica a fontes TrueType carregadas com uma code page não padrão explícita mas sem array de Differences, e a fontes carregadas via formato packaged-font.

v3.25.0 2026-05-19

Quando o modo PDF/UA está ativo, anotações não isentas (todos os tipos exceto Widget, PrinterMark e TrapNet) que não possuem uma entrada Contents não vazia agora recebem uma automaticamente no momento do salvamento. O valor /T (título / autor) da anotação é usado como fallback, satisfazendo ISO 14289-1 §7.18.1 para anotações que carregam um título mas nenhuma descrição acessível explícita.

v3.24.0 2026-05-19

Quando o modo PDF/UA está ativo, campos de formulário interativos que não possuem uma entrada TU (tooltip / descrição alternativa) agora recebem uma automaticamente no momento do salvamento. O nome parcial do campo (entrada /T) é usado como valor de fallback, garantindo que os leitores de tela possam identificar cada campo. Botões push são corretamente excluídos deste requisito conforme ISO 14289-1 §7.18.4.

v3.23.1 2026-05-19

GetInformation(200) retorna '1' quando o modo PDF/UA-1 está ativo no documento selecionado, permitindo que os chamadores consultem o status do modo de conformidade em tempo de execução.
GetInformation(201) retorna '1' para PDF/A-1a, '2' para PDF/A-1b ou uma string vazia quando o modo PDF/A está desativado.
GetInformation(311) e GetInformation(312) agora retornam corretamente a string de requisito de versão e o nome do recurso do conflito mais recente de version-lock (anteriormente anunciado na entrada v3.20.3, mas ainda não implementado).
GetInformation(313) retorna a string de versão PDF na qual o alvo de salvamento está atualmente travado, ou uma string vazia para documentos com versionamento livre.

v3.23.0 2026-05-19

SetMarkInfo(Marked) agora é uma API pública, permitindo que o flag MarkInfo.Marked seja definido independentemente da configuração completa de PDF/UA-1 realizada por SetPDFUAMode. Quando Marked é 1, MarkInfo.Suspects também é definido como false conforme exigido por ISO 14289-1 §7.18.6.
Quando o modo PDF/UA está ativo, todas as páginas recebem automaticamente uma entrada /Tabs /S no momento do salvamento, satisfazendo o requisito de ordem de tabulação baseada em estrutura de ISO 14289-1 §7.18.4.
Documentação de referência HTML adicionada para SetPDFUAMode, SetDocumentLanguage, SetMarkInfo, BeginTag, EndTag, BeginArtifact e EndArtifact, com tabelas completas de sintaxe e exemplos de uso.

v3.22.0 2026-05-19

BeginTag(TagType, AltText, ActualText) abre um elemento de estrutura de PDF tagged no fluxo de conteúdo atual, escrevendo um operador BDC com um MCID atribuído automaticamente e registrando o elemento na árvore de estrutura do documento. TagType é qualquer tipo de estrutura padrão PDF (P, H1, Figure, Table, etc.). AltText e ActualText são strings opcionais de acessibilidade codificadas como strings de texto PDF (UTF-16BE).
EndTag fecha o elemento de estrutura aberto mais recentemente, escrevendo o operador EMC correspondente no fluxo de conteúdo.
BeginArtifact(SubType) marca uma região de conteúdo como um artifact PDF (pagination artefact, plano de fundo, etc.), escrevendo um operador BMC. SubType é opcional; quando fornecido, é escrito como /Artifact << /Subtype /SubType >>.
EndArtifact fecha a região de artifact com um operador EMC.
No momento do salvamento, quando algum elemento de estrutura tagged foi registrado, a biblioteca constrói automaticamente o StructTreeRoot completo, atribui chaves StructParents às páginas afetadas e escreve a name tree ParentTree, satisfazendo os requisitos de ISO 32000-1 §14.7 para PDF tagged.
Fontes Type 1 padrão (Helvetica, Times, família Courier, Symbol) e fontes Type 1 incorporadas com codificação WinAnsi agora recebem um fluxo CMap ToUnicode, permitindo extração confiável de texto Unicode e copiar/colar para esses tipos de fonte.

v3.21.0 2026-05-19

SetPDFUAMode(Language) ativa o modo de conformidade PDF/UA-1 (ISO 14289-1): eleva automaticamente o documento para PDF 1.7, escreve MarkInfo.Marked e MarkInfo.Suspects, habilita DisplayDocTitle em ViewerPreferences, define Catalog.Lang quando Language não está vazio e escreve a entrada de namespace XMP pdfuaid:part = 1 exigida pela Seção 6.7.11 do ISO 14289-1.
SetDocumentLanguage(Language) escreve diretamente a entrada Catalog /Lang, permitindo que o idioma do documento seja declarado independentemente do modo PDF/UA.
MarkInfo.Suspects agora é definido como false sempre que MarkInfo.Marked é definido como true, satisfazendo o requisito de estrutura de PDF tagged do ISO 14289-1 (Seção 7.18.6).
Encrypt agora força o flag de permissão CanCopyAccess (cópia de conteúdo para acessibilidade) quando o documento está no modo PDF/UA, conforme exigido pela Seção 7.17 do ISO 14289-1.
Campos de formulário Choice (dropdown) não carregam mais um valor de tooltip codificado e sem sentido; TU é deixado sem definir para que o chamador possa atribuir um rótulo significativo via API de propriedade do campo de formulário.

v3.20.3 2026-05-19

Encrypt e AddSWFAnnotationFromFile agora retornam 0 imediatamente com LastErrorCode 602 quando a versão de salvamento está travada abaixo do mínimo exigido pela força de criptografia selecionada ou tipo de anotação, em vez de prosseguir silenciosamente e falhar apenas no momento do salvamento.
GetInformation(311) e GetInformation(312) agora refletem o requisito conflitante de versão no momento da escrita quando uma versão travada bloqueia recursos de extension-level, como AES-256 ou anotações RichMedia.

v3.20.2 2026-05-19

AddU3DAnnotationFromFile agora eleva automaticamente a versão do documento para PDF 1.6 quando uma anotação 3D é adicionada a um documento de versão inferior, consistente com o comportamento de auto-bump de versão de todos os outros pontos de entrada da API PDF 1.6+.

v3.20.1 2026-05-17

Alvos de salvamento PDF 1.2 agora são aplicados como contratos PDF 1.2 estritos. Salvar objetos PDF 1.3+ como dados TrimBox de página sob um alvo PDF 1.2 falha antes que a saída seja escrita em vez de emitir um arquivo de versão mista.
A conformidade de extension-level Adobe PDF 1.7 agora faz parte do save preflight. AESV3, AES-256, RichMedia, Projection, dicionários geoespaciais e subfilters de assinatura ETSI são verificados em relação ao ExtensionLevel exigido.
A criptografia AES-256, anotações RichMedia, dicionários geoespaciais e subfilters de assinatura ETSI agora declaram a entrada Adobe Extensions correspondente quando o PDFlib eleva automaticamente um documento para conteúdo de extensão PDF 1.7.
Salvamentos Append agora usam o mesmo gate de conformidade de versão que os salvamentos completos.
DLLs de runtime PDFium opcionais empacotadas foram atualizadas para Win32 e Win64. GDI+ continua sendo o renderizador padrão; PDFium permanece opcional via SetPDFiumFileName e SelectRenderer(3).
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 207/207 cada, e o GoogleTest C++Builder Win64x passou em 61 testes com 2 testes existentes dependentes de amostra ignorados.

v3.20.0 2026-05-17

Mais oito pontos de entrada do writer PDFlib agora são roteados através do EnsureMinVersion da Fase 3, de modo que a versão do documento é elevada automaticamente para o mínimo exigido pelo recurso emitido: SetDocumentMetadata (PDF 1.4 - fluxo XMP /Metadata) SetPDFAMode(1 ou 2) (PDF 1.4 - /MarkInfo + /OutputIntents) PageJavaScriptAction (PDF 1.5 - Page /AA + JavaScript) DocJavaScriptAction (PDF 1.4 - Catalog /AA + JavaScript) SetTabOrderMode (PDF 1.5 - Page /Tabs) NewOptionalContentGroup (PDF 1.5 - /Type /OCG) SetNeedAppearances (PDF 1.5 - AcroForm /NeedAppearances) NewFormField(ftSignature) (PDF 1.5 - AcroForm /SigFlags AppendOnly)
Combinado com o conjunto v3.15.0 (SetTransparency, SetPageUserUnit, Encrypt, SetPageLayout) e o conjunto v3.17.0 (oito entradas JavaScript / arquivo incorporado / XFA / SWF), o PDFlib agora eleva automaticamente FVersion em vinte e um pontos de entrada do writer.
NewOptionalContentGroup anteriormente elevava FVersion diretamente; agora passa por EnsureMinVersion para que LockSaveVersion seja respeitado e o bump seja registrado em AutoBumpedFeatures.

v3.19.0 2026-05-17

A conformidade de versão PDF no momento do salvamento e do carregamento agora também reconhece quatro recursos anteriormente adiados: Btn /Ff bit 15 NoToggleToOff (apenas radio-button) -> PDF 1.4 DeviceN /Subtype /NChannel (refinamento de espaço de cores) -> PDF 1.6 FontFile3 /Subtype /OpenType (tipo de programa de fonte) -> PDF 1.6 Sig /SubFilter ETSI.CAdES.detached ou ETSI.RFC3161 -> PDF 1.7
A regra NChannel corresponde à forma de array de espaço de cores DeviceN [/DeviceN names alternateSpace tintTransform attributes] quando o dicionário de attributes no índice 4 carrega /Subtype /NChannel.
A regra FontFile3 OpenType dispara apenas quando o fluxo é alcançado por meio de uma chave pai chamada 'FontFile3', de modo que fluxos não relacionados que por acaso carregam /Subtype /OpenType não são sinalizados.
A tabela PDFFeatureRules agora carrega 103 regras (99 + 4 novas).

v3.18.6 2026-05-17

A conformidade de versão PDF no momento do salvamento e do carregamento agora reconhece /AA (ações adicionais) com consciência de tipo de contêiner: Catalog /AA (gatilhos no nível do documento) -> PDF 1.4 Annot /AA (gatilhos de anotação) -> PDF 1.4 Page /AA (gatilhos de página) -> PDF 1.5
/AA de campo de formulário (PDF 1.2) permanece coberto pelo contrato de salvamento PDF 1.3 existente; nenhuma regra necessária.
A tabela PDFFeatureRules agora carrega 99 regras (96 + 3 novas).

v3.18.5 2026-05-17

A conformidade de versão PDF no momento do salvamento e do carregamento agora classifica corretamente Page /Tabs como um recurso PDF 1.5; anteriormente era classificado incorretamente como PDF 1.4. O documento de mudanças da especificação PDF 1.4 (Adobe TN #5409) não lista /Tabs, e a Tabela 8.10 do PDF 1.5 introduz "Tabs (Opcional; PDF 1.5)".
Nova regra: AcroForm /NeedAppearances é reconhecido como um recurso PDF 1.5 conforme Tabela 218 do PDF 1.5.
A tabela PDFFeatureRules agora carrega 96 regras (95 + 1 nova).

v3.18.4 2026-05-13

PDFlibZLib agora sempre usa o backend de objeto estático empacotado zlib-ng em compilações normais da biblioteca, removendo o caminho de fallback restante para System.ZLib.
A cobertura de regressão zlib-ng agora inclui payloads de tamanho de fronteira, dados de scanline semelhantes a PNG, fluxos armazenados multi-bloco e fluxos zlib conhecidos nos runners de teste Delphi e C++Builder.
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 194/194 cada, e o GoogleTest C++Builder Win64x passou em 58 testes com 2 testes existentes dependentes de amostra ignorados.

v3.18.3 2026-05-12

Demos Delphi e C++Builder que geram saída PDF ou texto agora abrem automaticamente o documento gerado após um salvamento bem-sucedido.
O empacotamento do instalador agora mantém artefatos de compilação fora das pastas de demo e torna as amostras C++Builder mais módulos DLL e ActiveX/OCX componentes opcionais; seus arquivos correspondentes são instalados apenas quando o componente é selecionado.

v3.18.2 2026-05-12

Os demos Delphi e C++Builder EditFormField agora limpam /NeedAppearances antes de atualizar os valores dos campos, de modo que cada campo de texto editado receba um fluxo de aparência normal atualizado no PDF salvo.
Isso mantém o fluxo /AP salvo em sincronia com o valor /V armazenado e evita diferenças dependentes do visualizador onde focar o campo revela texto que estava ausente da aparência estática do campo.

v3.18.1 2026-05-10

A conformidade de versão PDF no momento do salvamento e do carregamento agora também reconhece flags /Ff de campo de formulário no nível de bit e o bit AppendOnly de AcroForm /SigFlags: /Ff bit 21 (FileSelect, máscara 1048576) -> PDF 1.4 /Ff bit 22 (MultiSelect, máscara 2097152) -> PDF 1.4 /Ff bit 23 (DoNotSpellCheck, máscara 4194304) -> PDF 1.4 /Ff bit 24 (DoNotScroll, máscara 8388608) -> PDF 1.4 /Ff bit 25 (Comb, máscara 16777216) -> PDF 1.5 /Ff bit 26 (RichText / RadiosInUnison, 33554432) -> PDF 1.5 /Ff bit 27 (CommitOnSelChange, máscara 67108864) -> PDF 1.5 /SigFlags bit 2 (AppendOnly, máscara 2) -> PDF 1.5
A herança de /Parent não é seguida: apenas dicionários que carregam explicitamente /Ff ou /SigFlags acionam as regras.
A tabela PDFFeatureRules agora carrega 95 regras (87 + 8 novas no nível de bit).
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 191/191 cada, e o GoogleTest C++Builder Win64x passou em 57/57.

v3.18.0 2026-05-10

A conformidade de versão PDF no momento do salvamento e do carregamento agora também reconhece nove mais sub-chaves e recursos no nível de bit: flags de anotação no nível de bit (máscara /F): Locked (128) -> PDF 1.4 ToggleNoView (256) -> PDF 1.5 LockedContents (512) -> PDF 1.7 sub-chaves distintas de catálogo e página: /BoxColorInfo (página) -> PDF 1.4 /Permissions, /Legal, /PresSteps -> PDF 1.5 /VP (viewport geoespacial de página) -> PDF 1.6 /Collection (coleção portátil de catálogo) -> PDF 1.7
A tabela PDFFeatureRules agora carrega 87 regras (78 no nível de capítulo + 9 no nível de sub-chave / bit).
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 189/189 cada, e o GoogleTest C++Builder Win64x passou em 57/57.

v3.17.0 2026-05-10

Mais oito pontos de entrada do writer PDFlib agora são roteados através do EnsureMinVersion da Fase 3, de modo que a versão do documento é elevada automaticamente para o mínimo exigido pelo recurso emitido: AddLinkToJavaScript, SetOpenActionJavaScript, AddGlobalJavaScript, FormFieldJavaScriptAction (PDF 1.3 - ações JavaScript) AddEmbeddedFile, AddFileAttachment (PDF 1.3 - anexos de arquivo) SetXFAFromString (PDF 1.5 - formulários XFA) AddSWFAnnotationFromFile (PDF 1.7 - anotação RichMedia)
Combinado com o conjunto v3.15.0 (SetTransparency, SetPageUserUnit, Encrypt, SetPageLayout), o PDFlib agora cobre treze pontos de entrada do writer de alta versão de ponta a ponta.
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 187/187 cada, e o GoogleTest C++Builder Win64x passou em 57/57.

v3.16.3 2026-05-10

Nova API PDFlib: LockSaveVersion(Version) fixa o documento na Version e impede que o EnsureMinVersion do writer da Fase 3 faça o auto-bump para uma versão superior. UnlockSaveVersion limpa a trava.
O gate no momento do salvamento permanece inalterado: recursos emitidos pelo writer acima da versão travada ainda produzem LastErrorCode 602 no momento do salvamento, em vez de elevar silenciosamente o cabeçalho.
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 184/184 cada, e o GoogleTest C++Builder Win64x passou em 57/57.

v3.16.2 2026-05-10

PDFs carregados agora expõem uma visão apenas de contribuintes da detecção de recursos no momento do carregamento através de GetInformation(103) ("ContributorFeatures"). A lista contém apenas recursos cuja versão mínima exigida é estritamente maior que HeaderVersion (chave 100), de modo que responde diretamente a "por que a versão efetiva é maior que o cabeçalho do arquivo?".
GetInformation(101) ("DetectedFeatures") permanece inalterado e ainda lista todos os recursos correspondentes, independentemente da contribuição.
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 181/181 cada, e o GoogleTest C++Builder Win64x passou em 57/57.

v3.16.1 2026-05-10

Cobertura expandida de teste de detecção do lado do loader com seis fixtures sintéticas adicionais: transparência in-page ExtGState (sem version bump), Catalog /MarkInfo (PDF 1.3 -> PDF 1.4), /OCProperties + conteúdo OCG (PDF 1.4 -> PDF 1.5), /Type /3DStream (PDF 1.5 -> PDF 1.6), uma fixture de combinação de múltiplos recursos e uma verificação de estabilidade de snapshot.
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 179/179 cada, e o GoogleTest C++Builder Win64x passou em 57/57.

v3.16.0 2026-05-10

Documentos PDF carregados agora passam por uma passagem de detecção de versão orientada por conteúdo: cada objeto indireto é percorrido através da tabela de recurso-para-mínimo-versão usada pelo gate no momento do salvamento, e FVersion é elevado acima do valor literal do cabeçalho %PDF-X.Y quando o conteúdo realmente exige uma versão superior. Por exemplo, uma entrada de página /UserUnit eleva a versão efetiva para PDF 1.6 mesmo quando o cabeçalho do arquivo diz PDF 1.4.
Novas chaves GetInformation: 100 retorna HeaderVersion (literal %PDF-X.Y), 101 retorna DetectedFeatures (recursos correspondentes no carregamento, delimitados por CRLF), 102 retorna AutoBumpedFeatures (recursos delimitados por CRLF que acionaram o EnsureMinVersion do writer).
O gate no momento do salvamento não é afetado: documentos cuja versão efetiva foi elevada no carregamento e depois explicitamente rebaixada com SetInformation(0, ...) ainda produzem LastErrorCode 602 no momento do salvamento.
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 173/173 cada, e o GoogleTest C++Builder Win64x passou em 57/57.

v3.15.0 2026-05-10

Pontos de entrada do writer que produzem recursos exigindo uma versão mínima específica do PDF agora elevam automaticamente a versão PDF do documento. Chamar SetTransparency em um documento marcado como PDF 1.3 agora promove o cabeçalho para PDF 1.4 em vez de falhar no salvamento com LastErrorCode 602.
Mesmo auto-bump conectado em SetPageUserUnit (>=1.6), Encrypt com Strength 1/2/3/4 (>=1.4/1.6/1.7/1.7 respectivamente) e as variantes de duas páginas de SetPageLayout (>=1.5).
Mudança de comportamento em relação a 3.14.x: aplicações que anteriormente dependiam do gate "alvo de salvamento rejeita recursos emitidos pelo writer" do v3.12.6 agora têm sucesso na versão elevada. PDFs carregados que já contêm recursos de versão superior ainda passam pelo gate existente no momento do salvamento, de modo que carregar um PDF tagged e selecionar PDF 1.3 ainda falha com LastErrorCode 602.
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 170/170 cada, e o GoogleTest C++Builder Win64x passou em 57/57.

v3.14.3 2026-05-10

A conformidade de versão PDF no momento do salvamento agora também reconhece os tipos restantes de dicionário 3D PDF 1.6 (/Type /3DStream /3DRef /3DBackground /3DRenderMode /3DLightingScheme /3DCrossSection /3DNode) e os subtipos de anotação Redact, RichMedia e Projection PDF 1.7 mais os dicionários complementares /Type /Requirement e /ReqHandler.
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 168/168 cada, e o GoogleTest C++Builder Win64x passou em 57/57.

v3.14.2 2026-05-10

A conformidade de versão PDF no momento do salvamento agora também reconhece recursos PDF 1.5: formulários /XFA, /AlternatePresentations, name tree /Renditions, os dicionários multimídia /Type /Rendition /MediaCriteria /MediaPermissions /MediaPlayers e o subtipo de anotação Screen.
Salvar como PDF 1.4 agora rejeita documentos que carregam esses recursos com LastErrorCode 602.
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 166/166 cada, e o GoogleTest C++Builder Win64x passou em 57/57.

v3.14.1 2026-05-10

A conformidade de versão PDF no momento do salvamento agora também reconhece recursos PDF 1.4: dicionários de PDF tagged /StructTreeRoot /MarkInfo e StructElem, as entradas /Lang do documento e /Tabs da página, dicionários /OutputIntents e /OutputIntent, a assinatura de direitos de uso /UR3 e os subtipos de anotação PDF 1.4 Polygon, PolyLine, Caret, Ink, Popup e Watermark.
Salvar como PDF 1.3 agora rejeita documentos que carregam esses recursos com LastErrorCode 602.
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 165/165 cada, e o GoogleTest C++Builder Win64x passou em 57/57.

v3.14.0 2026-05-10

A conformidade de versão PDF no momento do salvamento agora também reconhece recursos PDF 1.3, como smooth shading, objetos de função, espaços de cores ICCBased e DeviceN, entradas de página /TrimBox /BleedBox /ArtBox, CMaps /ToUnicode, anexos de arquivo e anotações /Sound e /Movie, dicts /Type /Filespec e /Type /EmbeddedFile, as chaves /Group /EF /Alternates /Mask e ações JavaScript.
Chamadores PDF 1.2 agora salvam sob o contrato PDF 1.3: o cabeçalho literal %PDF-1.2 é preservado, mas o gate aceita recursos PDF 1.3. Recursos PDF 1.4 e posteriores ainda são rejeitados com LastErrorCode 602.
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 162/162 cada, e o GoogleTest C++Builder Win64x passou em 57/57.

v3.13.0 2026-05-10

Refatorado o gate de conformidade de versão PDF que rejeita recursos de versão posterior no momento do salvamento em um módulo dedicado, para que o conjunto de regras possa crescer sem agitar o núcleo do documento.
Nenhuma mudança de comportamento visível ao usuário em relação a v3.12.7: os mesmos recursos fora de versão ainda são rejeitados com LastErrorCode 602.
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 155/155 cada, e o GoogleTest C++Builder Win64x passou em 57/57.

v3.12.7 2026-05-09

Cobertura de teste automatizado expandida para o fluxo de trabalho de renderização de acesso direto PdfToImage tanto nas suítes DUnitX Delphi quanto nas suítes GoogleTest C++Builder.
O runner de teste GUI Delphi VCL agora registra as fixtures Syntax e XRef, correspondendo à cobertura do runner de console.
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 147/147 cada, e o GoogleTest C++Builder Win64x passou em 57/57.

v3.12.6 2026-05-09

Salvar como PDF 1.3, 1.4, 1.5, 1.6 ou 1.7 agora impõe a versão selecionada como o contrato de saída do salvamento completo.
Salvamentos completos removem substituições de catálogo /Version, removem entradas de extensão de catálogo e metadados não suportados para alvos inferiores e suprimem fluxos de metadados XMP PDF 1.4 quando se salva como PDF 1.3.
SaveToFile, SaveToString e SaveToStream agora falham com LastErrorCode 602 quando a versão do alvo PDF selecionada é inferior aos recursos ainda presentes no documento, como transparência, conteúdo opcional, JPX, UserUnit, 3D ou recursos de crypt-filter AES.

v3.12.5 2026-05-09

Melhorada a análise de strings literais PDF 1.7, de modo que sequências de escape desconhecidas ignorem a barra invertida conforme exigido pelo padrão.
Escapes octais de strings literais agora consomem apenas dígitos octais e preservam um dígito não octal seguinte como dados normais da string.
Cobertura de regressão adicionada para escapes desconhecidos de strings literais e sequências de escape octal/não octal mistas.
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 141/141 cada.

v3.12.4 2026-05-09

Melhorada a análise léxica PDF 1.7, de modo que objetos de nome agora param corretamente no delimitador chave-direita.
Corrigido o carregamento SmartAccess de entradas de objeto comprimido de fluxo xref cujo número de fluxo de objeto é maior que o comprimento de bytes do PDF.
Cobertura de regressão adicionada para delimitadores de nome de chave-direita e entradas esparsas de fluxo xref de objeto comprimido.
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 139/139 cada.

v3.12.3 2026-05-08

Compatibilidade aprimorada de documentos criptografados PDF 1.7 para arquivos de standard security handler que usam StrF, StmF, EFF, Identity, None ou crypt filters nomeados no estilo StdCF.
Fluxos de metadados agora respeitam EncryptMetadata=false durante fluxos de trabalho de descriptografia, criptografia e cópia/salvamento em vez de serem processados como fluxos comuns.
Fluxos de arquivo incorporado agora carregam /Type /EmbeddedFile e usam o caminho de decisão de crypt-filter de arquivo incorporado quando documentos criptografados são carregados ou salvos.
Fluxos de arquivo incorporado externo agora promovem FDecodeParms para DecodeParms quando FFilter é promovido para Filter, preservando os parâmetros de decodificação do fluxo.
Novos PDFs criptografados AES agora escrevem valores de Length de crypt-filter como comprimentos de bit, correspondendo ao contrato do dicionário de crypt filter PDF 1.7.
Valores Prev/XRefStm de fluxo XRef e grandes offsets numéricos agora mantêm precisão de 64 bits através dos caminhos do parser e do SmartAccess.
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 137/137 cada.

v3.12.2 2026-05-08

Compatibilidade aprimorada de decodificação de fluxo PDF 1.7. A decodificação genérica de fluxo agora respeita /DP como alias de DecodeParms, resolve entradas indiretas de array de parâmetros de decodificação e aceita as abreviações de filtro padrão /AHx e /LZW.
A saída PDF de arquivo grande agora escreve offsets xref, startxref, linearização e ByteRange de assinatura digital através de caminhos de formatação de 64 bits, em vez de estreitar esses valores através de helpers inteiros de 32 bits.
Documentos carregados agora tratam uma entrada de catálogo /Version como a versão PDF efetiva quando é mais recente que a versão do cabeçalho do arquivo.
Trailers de fluxo xref reescritos não retem mais chaves DecodeParms exclusivas do fluxo quando o PDFlibPas os salva como dicionários de trailer clássicos.
Validação: as suítes DUnitX Delphi Win32 e Win64 passaram em 134/134 cada.

v3.12.1 2026-05-06

PDFs gerados agora abrem com a primeira página dimensionada para a altura disponível da janela do visualizador, de modo que toda a primeira página é visível de cima para baixo no maior zoom que cabe na janela. Configure um OpenAction personalizado (SetOpenActionDestination, SetOpenActionMenu, SetOpenActionJavaScript) no documento para substituir este padrão.

v3.12.0 2026-05-06

Os backends estáticos do Windows agora incluem objetos NASM SIMD libjpeg-turbo para Win32 e Win64, mais objetos de despacho SIMD x86 zlib-ng para o conjunto zlib-ng Win64x.
Retrabalhados os scripts de reconstrução zlib-ng para que as compilações Win64x bcc64x e MSVC de diagnóstico compilem os arquivos de origem genérico, SSE2, SSSE3, SSE4.1/SSE4.2, PCLMULQDQ e AVX2 com flags de recurso por arquivo, em vez de depender de um único switch global do compilador.
Adicionados stubs CRT malloc/calloc/realloc/free alinhados em 32 bytes para as bibliotecas C estáticas e corrigido TPDFJPEGImage.Compress para liberar buffers jpeg_mem_dest através do mesmo caminho de free C que os alocou.
Expandidas as notas de validação públicas para destacar a cobertura automatizada rigorosa por trás deste release: compilações de biblioteca, round trips de compressão, saída HelloWorld /FlateDecode, renderização JPEG, fluxos de trabalho de imagem, fontes, formulários, segurança, assinatura, impressão e fluxos de trabalho derivados de demo C++Builder.

v3.11.0 2026-05-05

Alternada a compressão e descompressão Flate do Windows para zlib-ng no modo zlib-compatível. Win32, Delphi Win64 e C++Builder Win64x agora linkam conjuntos estáticos de objetos zlib-ng compatíveis com ABI de Lib\thirdparty\Win32, Lib\thirdparty\Win64 e Lib\thirdparty\Win64x.
O caminho Win64 não é mais roteado através da unidade System.ZLib do Delphi, de modo que a compressão/descompressão de fluxo PDF pode se beneficiar do backend zlib-ng assim como a compilação de 32 bits.
Adicionado um pequeno objeto bridge zlib-ng para compilações Win64, de modo que o código Pascal mantenha pontos de entrada zlib-compatíveis estáveis enquanto Delphi e C++Builder consomem seus próprios conjuntos de objetos compatíveis com o linker.
Atualizados todos os projetos de demo C++Builder para definir PDFLIB_CPPBUILDER, correspondendo ao runner GoogleTest e impedindo que demos Win64x linkem os objetos zlib-ng Delphi Win64.

v3.10.3 2026-05-01

Estendida a suíte GoogleTest C++Builder para cobrir todos os demos em Demo\C++Builder. O layout phase-1 de 7 fixtures cresceu para 15 fixtures / 52 casos GoogleTest, todos passando em Win64x. Demos recém-cobertos: AddFormattedTitle, AddTextImage, AddTrueTypeSubsettedFont, AddWebLink, CanvasText, CaptureToNewSize, CopyPageRanges, CreateWithImage, CreateWithImageToStream, DoInTheStream, DrawWrappedText, EditFormField, EmbeddedFonts, ExtractAnnotAttach, ExtractEmbeddedFonts, ExtractImage, ImageToPdf, ImportEMF, MultiFunction (renderer switch), PageOperations, PdfDecrypt, PdfPermission, PrintPDF, TextMeasure, TextPaging.

v3.10.2 2026-05-01

Adicionado um runner GoogleTest C++Builder em Tests\C++Builder que exercita Lib\PDFlibrary.pas através dos mesmos cabeçalhos HPP emitidos pelo {$JPHNE} usados pelos demos C++Builder. A primeira fase espelha sete cenários principais Delphi (HelloWorld, DrawShapes, CreateTable, PdfEncrypt, ExtractText, PdfSigning, renderização PdfToImage) como 17 casos GoogleTest, todos passando em Win64x.
Estendida a suíte DUnitX Delphi com Tests.Print cobrindo os demos PrintPDF e ShowPrinterBins (enumeração de impressora padrão, configuração de impressora personalizada, opções de impressão, redirecionar trabalho de impressão para arquivo) e um teste de troca de renderizador em Tests.Render exercitando a seleção de mecanismo GDI+ / PDFium / Cairo do demo MultiFunction no mesmo PDF de origem.

v3.10.1 2026-05-01

Adicionados 57 tamanhos de página nomeados ao SetPageSize, para que os mesmos nomes canônicos de tamanho de página também funcionem aqui: SIZE8X11, QUADA0, DOUBA0, B0PLUS, ENVB4/B5/C6/DL/MONARCH, ENV9/10/11, ANSIA/B/C/D/E, ARCHA/B/C/D/E1/E, SHIROKU, G1K, USBC/EUBC/ASBC, ID1/ID2/ID3, ONEINCH/TWOINCH/L2INCH/USVISA, P2R..P24R / S8R / P4D photo prints, plus the Chinese / Taiwanese octavo and sextodecimo sheet formats LARGE/STANDARD/CROWN/ROC 8K and the matching 16K halves.

v3.10.0 2026-04-30

Adicionadas versões C++Builder nativas para cada amostra Delphi em Demo. Os demos de criação de PDF, manipulação de página, fontes, imagens, segurança, assinatura, renderização e impressão agora podem ser compilados e executados a partir do C++Builder sem nenhum wrapper Delphi.
Cada novo demo reside em Demo\C++Builder\<Name>\ como um projeto de console que consome Lib\PDFlibrary.pas diretamente e inclui os arquivos de entrada necessários para execução.
Adicionado um Readme.txt breve em inglês para cada pasta de demo Delphi descrevendo o que o demo mostra, a API em que se concentra e como executá-lo; uma visão geral HTML em Demo\Delphi\index.html liga todos eles agrupados por tópico.
Espelhado o mesmo Readme.txt para cada demo C++Builder com uma seção Run reescrita para o fluxo de trabalho de console (argumentos argv em vez de Open/SaveDialogs); um Demo\C++Builder\index.html correspondente lista cada demo C++Builder com os mesmos grupos de tópico.
Corrigido um vazamento de memória no demo ImportEMF (a instância TPDFlib foi criada mas nunca liberada).

v3.9.14 2026-04-30

Corrigido o demo de cópia de intervalo de páginas para que ele realmente copie páginas em vez de sempre relatar falha.
Arrumados os demos de texto envolvido e paginação HTML para que cada um se concentre em sua própria API e seja executado a partir de um único botão.
Renomeados dois projetos de demo (EmbeddedFonts e PdfPermission) para que os executáveis compilados correspondam aos nomes das pastas em vez dos nomes de protótipo mais antigos.

v3.9.13 2026-04-30

Corrigido um bug de posição de fluxo no leitor de buffer interno: leituras de palavra de dois bytes estavam avançando o cursor de leitura em quatro bytes em vez de dois. Em buffers com mais de dois bytes, as leituras subsequentes caiam no offset errado e retornavam silenciosamente dados incorretos. O efeito era mais visível ao analisar estruturas de dados binários que intercalam leituras de byte e word.
Introduzida uma suíte de teste automatizada DUnitX (runners de console e VCL GUI) cobrindo unidades utilitárias — buffer, AES, ZLib, Unicode e digest hashing — e fluxos de trabalho no nível da biblioteca, incluindo criação de documento, salvamento em arquivo e em fluxo, round-trips de carregamento e criptografia AES-128/AES-256.

v3.9.12 2026-04-30

A renderização de imagens GDI+ agora é padronizada para interpolação bicúbica suave de alta qualidade ao dimensionar imagens raster para a resolução de tela ou exportação. Anteriormente o padrão era vizinho mais próximo (nearest-neighbour), que produzia artefatos visíveis em escada em pequenas imagens (logos, miniaturas) ampliadas para visualização em tela ou exportação em alta DPI. Chamadores que preferem o modo de vizinho mais próximo mais nítido podem restaurar o comportamento antigo via SetGDIPlusOptions.

v3.9.11 2026-04-30

Corrigida a renderização Cairo de imagens PDF que usam transparência color-key (um array color-range /Mask no dicionário de imagem). Anteriormente, quando uma página continha uma imagem com essa forma de transparência, o renderizador Cairo omitia a imagem inteiramente em vez de comporê-la sobre o fundo da página. A correção deriva um canal alpha por pixel a partir dos intervalos de color-key declarados e renderiza o resultado como uma imagem transparente, produzindo saída visualmente consistente com o renderizador GDI+.

v3.9.10 2026-04-30

Corrigida uma regressão de renderização Cairo onde todo o conteúdo da página após uma sequência de imagem clipada estava incorretamente confinado ao retângulo de clipping da imagem. Páginas PDF que salvam o estado gráfico, aplicam um caminho de clip, pintam uma imagem e então restauram o estado — uma técnica de layout comum para imagens emolduradas ou com bordas — renderizariam todo o texto, formas e gráficos subsequentes apenas dentro da região clipada. O salvamento e restauração de estado do Cairo agora mapeiam corretamente para os operadores q/Q do PDF, de modo que a região de clipping é descartada após o desenho da imagem.

v3.9.9 2026-04-29

Adicionado um mecanismo de renderização PDF baseado em Cairo como uma terceira opção de renderização junto a GDI+ e PDFium. Chame SelectRenderer(2) antes de renderizar para ativá-lo; o mecanismo requer cairo.dll da pasta DLL\Cairo empacotada. A renderização Cairo suporta os mesmos modos de saída do GDI+: exportação de arquivo bitmap e fluxo (BMP, JPEG, PNG, GIF, TIFF, G4 TIFF), renderização em device-context e saída direta para impressora.
O demo View/Print MultiFunction agora expõe um seletor de renderizador de três vias para que os usuários possam comparar a saída GDI+, PDFium e Cairo lado a lado no mesmo documento sem nenhuma mudança de código.

v3.9.8 2026-04-29

Suprimidos dois diagnósticos espúrios do compilador no shim C-runtime Win32 que apareceram no RAD Studio 13.1 e posteriores. Um aviso de descontinuação (W1000) foi levantado porque um guard de capacidade de versão do compilador não foi propagado para compiladores mais novos que o Delphi 2009, fazendo com que compilassem contra uma API descontinuada do gerenciador de memória. Uma dica de variável não utilizada (H2164) foi levantada para uma variável de compatibilidade interna necessária apenas para compilações Delphi 7; agora está com escopo no bloco condicional dessa versão. Ambos os problemas eram apenas diagnósticos sem impacto em tempo de execução.

v3.9.7 2026-04-29

Adicionada renderização de página opcional baseada em PDFium no Windows, incluindo renderização de fluxo BMP, renderização em device-context, renderização em memória e saída para impressora.
Atualizado o demo Delphi View/Print MultiFunction com um seletor de renderizador para que os usuários possam alternar entre o renderizador GDI+ existente e PDFium.

v3.9.6 2026-04-29

Adicionados scripts Inno Setup separados para o pacote PDFlibPas completo e o pacote de avaliação, com exclusões focadas no release para metadados de controle de origem, saídas de compilação, caches da IDE, arquivos de agente locais e árvores de origem de terceiros empacotadas que não fazem parte do pacote enviado.
O instalador de avaliação agora compila e empacota bibliotecas binárias de avaliação para RAD Studio 11.3, 12.3 e 13.1, mais os demos Delphi de avaliação, antes que o executável de configuração seja gerado.

v3.9.5 2026-04-29

Corrigidas as compilações de biblioteca Win32 no RAD Studio 9.0 / Delphi XE2. O script de compilação estava passando um flag de diretório de saída DCU que existe apenas a partir do Delphi 2010; o compilador do XE2 interpretava o flag de forma diferente, produzindo um caminho de saída confuso e um erro fatal antes que qualquer arquivo de origem fosse processado. O script agora seleciona o flag apropriado automaticamente com base na versão do compilador alvo.
Corrigido um guard de versão do compilador relacionado no código-fonte da biblioteca que estava chamando uma função de runtime qualificada por nome introduzida no XE4 sob uma condição XE2+. As compilações alvo de XE2 e XE3 agora resolvem corretamente a importação de compatibilidade.

v3.9.4 2026-04-29

Corrigida a configuração de impressora para impressoras de rede e compartilhadas em servidor aplicando as configurações de bandeja de papel, mídia, duplex, qualidade e outras configurações de impressão através do handle DEVMODE da impressora em vez do handle de device context da impressora.

v3.9.3 2026-04-29

Atualizado o backend AES empacotado para as fontes AES 2018 de Brian Gladman tanto em Win32 quanto em Win64. Scripts de compilação reproduzíveis agora permitem que os objetos AES estáticos sejam reconstruídos a partir da fonte a qualquer momento. Um defeito de ABI nas bindings Pascal foi descoberto e corrigido no processo: as funções de criptografia e descriptografia AES-CBC estavam sem sua declaração de convenção de chamada C, de modo que compilações Win32 passavam silenciosamente argumentos na ordem errada de registradores, potencialmente produzindo saída criptografada incorreta. Compilações Win64 não foram afetadas porque a plataforma impõe uma convenção de chamada uniforme.
Endurecidos os scripts de reconstrução de terceiros para que os scripts MSVC para zlib, JPEG e stubs CRT possam ser lançados da raiz do repositório assim como do diretório thirdparty; anteriormente exigiam que o diretório de trabalho fosse definido como a pasta thirdparty.

v3.9.2 2026-04-29

Atualizado o backend JPEG 2000 do legado OpenJPEG 1.5 para OpenJPEG 2.5.4 tanto em Win32 quanto em Win64. Ambas as plataformas agora usam linking de objetos estáticos, de modo que a codificação e decodificação JPEG 2000 funcionam sem uma DLL de runtime adicional. O codec moderno traz manipulação atual de cabeçalho JP2/J2K, uma API de fluxo orientada por callback e bugs acumulados e correções de segurança do projeto upstream. A API pública TJpeg2000Bitmap permanece inalterada.

v3.9.1 2026-04-29

Corrigida a renderização de página JPEG e a exportação de imagem após o upgrade do libjpeg-turbo, restaurando a conversão JPG PdfToImage e a saída TPDFJPEGImage.SaveToStream em Win32 e Win64.
Corrigidas as bindings ABI libjpeg-turbo Win32 para que callbacks, alinhamento de estrutura, campos booleanos e destinos JPEG em memória correspondam ao libjpeg-turbo 3.1.90.
Corrigida a descompressão de fluxo FlateDecode Win32 com o backend zlib 1.3.2 empacotado, restaurando o carregamento de fluxo xref PDF para arquivos como o documento de amostra PdfToImage.

v3.9.0 2026-04-29

Atualizado o backend JPEG 2000 empacotado do legado OpenJPEG 1.5 para OpenJPEG 2.5.4. O carregamento e salvamento JPEG 2000 agora usam o codec moderno, API de fluxo orientada por callback e manipulação atual de cabeçalho JP2/J2K, preservando a API pública TJpeg2000Bitmap.
A saída JPEG 2000 agora seleciona automaticamente uma contagem de resolução OpenJPEG válida para pequenas imagens, e o backend estático Win32 não depende mais de exports auxiliares MSVCRT ausentes.

v3.8.1 2026-04-29

Eliminados todos os 16 avisos cosméticos do linker W1028 "Bad global symbol definition" em Win32 e Win64. Renomeações no nível da fonte removem as duplicatas redundantes do lado Pascal (jpeg_std_error e os stubs alocadores jmemnobs agora resolvem unicamente pela camada obj); os três símbolos obj bcc32 / vc64 restantes (jpeg_natural_order, jpeg_aritab, jpeg_nbits_table) que devem permanecer resolvidos por link contra dados do lado Pascal agora têm seus nomes de símbolo COFF removidos por meio de uma passagem de pós-processamento ObjConv durante thirdparty\build-jpeg-vc64.bat. Nenhuma mudança na API pública; saída limpa do linker para compilações Delphi Win32 e Win64.

v3.8.0 2026-04-29

Codec JPEG Win64 atualizado do libjpeg de estilo IJG para libjpeg-turbo 3.1.90, completando a migração JPEG iniciada em v3.7.0 (Win32). Os caminhos Win32 e Win64 agora compartilham o mesmo codec JPEG moderno, com os mesmos laços internos otimizados por SIMD e 30+ correções CVE / fuzz acumuladas do upstream. API pública PDFlibPas inalterada.

v3.7.0 2026-04-28

Codec JPEG Win32 atualizado do IJG libjpeg-6b para libjpeg-turbo 3.1.90. Encode/decode JPEG significativamente mais rápido por meio de laços internos otimizados por SIMD, mais as 30+ correções CVE / fuzz acumuladas no upstream do libjpeg-turbo. A API pública do PDFlibPas (classe TPDFJPEGImage, funções DumpJPEG) permanece inalterada; caminhos de código PDF/JPEG existentes executam mais rápido sem necessidade de mudanças de fonte.

v3.6.0 2026-04-28

Zlib Win32 atualizada de 1.2.x para 1.3.2. Inclui as 25+ correções CVE / fuzz padrão acumuladas no upstream desde 1.2.8, mais os novos pontos de entrada inflateBack9 / inflateTree9 usados por fluxos de janela de 64 bits. A API pública do PDFlibPas (DeflateStr / InflateStr / InflateStrParms) permanece inalterada.
O caminho zlib Win64 permanece inalterado neste release - continua a usar a unidade System.ZLib empacotada pelo Delphi.
Ativado o shim CRT de tempo de link Win64 PDFlibCLibs.pas (introduzido em v3.5.0) para o caminho zlib Win32, fornecendo os símbolos memcpy / memset / malloc / free que os novos arquivos obj zlib 1.3.2 referenciam.

v3.5.0 2026-04-28

Vendorizada infraestrutura de compilação nova para as bibliotecas C de imagem / compressão empacotadas: zlib 1.3.2, libjpeg-turbo 3.1.90, libtiff 4.7.1. Scripts de compilação tanto para Embarcadero bcc32 (Win32) quanto para MSVC cl.exe (Win64) residem em Lib/thirdparty/ junto com as árvores de origem, de modo que qualquer pessoa com RAD Studio + VS2022 possa reconstruir os arquivos obj estáticos a partir da fonte limpa.
Adicionada infraestrutura de compilação para OpenJPEG 2.5.4. A própria árvore de origem OpenJPEG é obtida independentemente pelo usuário (git clone uclouvain/openjpeg em Lib/thirdparty/OpenJPEG/) para que possa ser atualizada sem tocar na configuração de compilação do PDFlibPas.
Adicionado Lib/PDFlibCLibs.pas, um shim CRT de link para Win64 usado pelo backend Win64. Ele cobre a lacuna entre os arquivos obj C compilados com MSVC e os linkers Win64 do Delphi (dcc64 / Win64x ld.lld / BCB ilink64), que não vinculam msvcrt.dll automaticamente.

v3.4.0 2026-04-28

Endurecida a geração de chave de criptografia, vetor de inicialização AES e bloco de permissões Perms contra fontes de números aleatórios previsíveis. PDFs criptografados produzidos em sistemas iniciados perto do mesmo wall-clock time não são mais trivialmente correlacionáveis; documentos AES-256 agora mantêm sua força de chave total.
Endurecida a análise de dicionário de imagem contra PDFs malformados ou hostis que declaram contagens irrazoáveis de componentes Width, Height, BitsPerComponent ou DeviceN. Valores fora de intervalo são truncados antes de qualquer aritmética de buffer de pixels, prevenindo travamentos ao abrir tais arquivos.
Endurecida a travessia de cross-reference e page-tree contra documentos cujas cadeias xref /Prev ou links de página /Parent formam um ciclo ou são excessivamente profundos. O leitor agora rejeita estruturas malformadas de forma limpa, em vez de recursar até ficar sem stack.

v3.3.1 2026-04-27

Simplificados os scripts de compilação Windows por componente. As pastas DLL/, OCX/ e Dylib/ não carregam mais variantes separadas build12-* / build13-*: cada plataforma agora tem um único script build-Win32 / build-Win64 que se fixa no RAD Studio mais recente e aceita um argumento opcional "debug".
Adicionados comentários inline de racional em torno das correções de renderização PDFlibRenderer.pas que já estavam presentes no baseline Git inicial. Os comentários documentam por que SetPen escala as larguras de traço pela transformação ativa do canvas, e por que os operadores d0/d1 do CharProc de fonte Type 3 devem consumir seus operandos. Nenhum comportamento de tempo de execução mudou.

v3.3.0 2026-04-26

Corrigida a renderização de traços transformados em PDFlibRenderer.pas. SetPen agora aplica a escala da transformação atual do canvas às larguras de linha PDF antes de chamar Picasso, prevenindo traços superdimensionados ou subdimensionados em caminhos cujas coordenadas já foram transformadas. Isso corrige contornos de glifos Type 3 que poderiam renderizar como blocos espessos e irregulares.
Corrigida a manipulação d0/d1 do CharProc de fonte Type 3 no parser de fluxo de conteúdo. d0 agora consome seus dois operandos de largura, e d1 consome seus seis operandos de largura/bounding box antes que comandos de desenho posteriores sejam executados, prevenindo que operandos obsoletos corrompam a geometria de glifo ou caminho.