Registro de cambios

Historial de versiones

Historial de versiones de la biblioteca PDFlibPas. Las entradas se enumeran de la más reciente a la más antigua; cada versión sigue el versionado semántico conforme a la política de publicación del proyecto.

v3.56.42 2026-05-27

Se corrigió la ruta de descifrado AES-256 basada en búfer introducida en v3.56.41 para que los llamadores puedan asignar el resultado de descifrado al mismo AnsiString que proporcionó el búfer de texto cifrado sin provocar infracciones de acceso.
El flujo de la API normal LoadFromFile, Encrypt, SaveToFile, recarga, Decrypt y SaveToFile vuelve a completarse en PDFs grandes cargados, conservando la optimización de descifrado AES-CBC con menos copias.
Se añadió cobertura de regresión AES para los casos en que el búfer de entrada y el resultado comparten el mismo destino durante la restauración de streams cifrados al guardar, incluidos payloads grandes de 504 KB que antes exponían el fallo.

v3.56.41 2026-05-27

Se agregó TPDFlib.DACopyFile para flujos Direct Access que necesitan el recuento de páginas y una copia de archivo sin cambios sin construir el grafo completo de objetos normal.
Se optimizó el descifrado AES-256 agregando rutas AES-CBC basadas en búfer y usándolas al descifrar cadenas y streams cargados, lo que reduce copias adicionales de texto cifrado en streams cifrados grandes.
La demo Delphi HugeFileBenchmark ahora incluye una fila direct-copy y filtros --ops y --skip para ejecuciones enfocadas en archivos grandes.

v3.56.40 2026-05-26

Las demos HelloWorld de Delphi y C++Builder ahora crean un PDF inicial más completo con información del documento, salida con una fuente estándar seleccionada, un bloque de título con estilo, dibujo vectorial sencillo y orientación para los siguientes pasos, manteniendo el mismo flujo de compilación y ejecución.
Todas las notas de las demos de Delphi y C++Builder se han reemplazado por páginas Readme.html fáciles de leer en el navegador, incluidas las notas auxiliares de contraseñas, ficheros restringidos y resultados de firma; los índices de demos ahora dirigen a los usuarios a las notas HTML.

v3.56.39 2026-05-26

Las rutas de guardado de la API de ficheros directos ahora construyen tablas de búsqueda de referencias cruzadas de forma lineal, lo que hace que DASaveAsFile y las rutas de guardado directo relacionadas sean mucho más rápidas en PDFs con muchísimos objetos o árboles de páginas densos.
El escritor optimizado conserva la misma semántica de la cadena de objetos libres y evita escaneos repetidos de números de objeto durante la generación completa de xref, mejorando los flujos de guardado directo grandes sin cambiar la API pública ni el contrato de salida.

v3.56.38 2026-05-26

Se corrigió la salida de cifrado de la API normal para que Encrypt cree o conserve el identificador de trailer /ID antes de escribir los datos de seguridad AES-256, manteniendo los PDFs cifrados detectables al recargarlos mediante EncryptionStatus.
El flujo de la API normal LoadFromFile, Encrypt, SaveToFile, recarga, Decrypt y SaveToFile ahora conserva el estado cifrado antes del Decrypt explícito, igualando el comportamiento de la API de acceso directo a ficheros para PDFs heredados grandes.

v3.56.37 2026-05-26

Se anadio TPDFlib.ComparePreflightReports, un comparador linea por linea para informes de preflight en texto sin formato que ignora las lineas de marca temporal volatiles Generated: y devuelve una cadena vacia cuando el contenido estable del informe coincide.
La demo Delphi PreflightReport ahora admite --compare <file> en modo de fichero unico, escribe un informe UTF-8 .diff.txt y devuelve el codigo de salida 2 cuando el informe de texto generado difiere de la baseline.

v3.56.36 2026-05-26

La demo Delphi PreflightReport ahora admite ejecuciones por lotes de directorios con --input-dir, --output-dir y --recursive, escribiendo un informe por cada PDF como <basename>.preflight.<ext>.
El modo por lotes escribe un fichero UTF-8 preflight-summary.csv que registra cada PDF de origen, el estado pass/fail, el recuento de problemas y la ruta del informe generado, conservando el contrato de codigos de salida existente para automatizacion.

v3.56.35 2026-05-26

ReportFormat = 3 agrega salida CSV a TPDFlib.CreatePreflightReportEx y TPDFlib.SavePreflightReportEx, generando filas UTF-8 para los metadatos del informe, cada comprobacion de cumplimiento seleccionada, codigos y mensajes de problemas individuales, y el resumen final.
La demo Delphi PreflightReport ahora admite --format csv y --csv, de modo que las ejecuciones de preflight desde la linea de comandos puedan alimentar hojas de calculo o analizadores de CI simples sin posprocesar JSON ni extraer texto.

v3.56.34 2026-05-26

Se agregaron las API con formato TPDFlib.CreatePreflightReportEx y TPDFlib.SavePreflightReportEx para generar informes de preflight PDF/A y PDF/UA-1 como texto plano, JSON o HTML independiente, conservando las API existentes solo de texto.
La demo Delphi PreflightReport ahora admite --format text|json|html y los atajos --json y --html, por lo que el mismo flujo de línea de comandos puede producir informes legibles o artefactos de CI legibles por máquina.

v3.56.33 2026-05-26

Se agregaron TPDFlib.CreatePreflightReport y TPDFlib.SavePreflightReport para que las aplicaciones puedan generar informes de texto reutilizables desde las comprobaciones integradas de conformidad PDF/A y PDF/UA-1 sin enumerar manualmente los identificadores de listas de cadenas.
La demo Delphi PreflightReport ahora llama directamente a las API de informe de la biblioteca, manteniendo el ejemplo centrado en el flujo de línea de comandos, las comprobaciones seleccionadas, el modo de primer problema y los códigos de salida aptos para automatización.

v3.56.32 2026-05-26

Se agregó un nuevo ejemplo de consola Delphi PreflightReport que ejecuta comprobaciones PDF/A y PDF/UA-1 con CheckFileCompliance, enumera las listas de incidencias con GetStringListCount y GetStringListItem, y escribe un informe de preflight en texto plano.
El ejemplo admite las opciones --input, --output, --pdfa, --pdfua, --both y --first-issue, además de códigos de salida para resultados aptos para automatización: correcto, incidencias encontradas y error de ejecución.

v3.56.31 2026-05-25

GetCustomKeys(2) ahora oculta de forma consistente las entradas del sistema de catálogo gestionadas por la biblioteca, incluyendo /OutputIntents, /Extensions, /Requirements, /Collection y /NeedsRendering.
Los perfiles de salida PDF/A creados por SetPDFAMode ya no aparecen como claves personalizadas en el catálogo, manteniendo la enumeración de metadatos de la aplicación separada de las estructuras de cumplimiento de PDF.

v3.56.25 2026-05-23

El componente GetPDFUADiagnostics en el lado del escritor ahora tiene el mismo problema que MULTIPLE-H-CHILDREN:N, lo que lo alinea con el lector 10044 desde v3.56.24. ISO 14289-1 §7.4.4 prohíbe que un nodo de árbol de etiquetas tenga más de un hijo directo H; la verificación del lado del escritor se activa cada vez que el árbol FStructElems en memoria contiene una violación de este tipo.
Un nuevo componente CountMultipleHChildren auxiliar recorre el árbol en profundidad, contando los hijos H en cada nivel. La verificación se ejecuta junto con los recorridos existentes de LIST-STRUCT / LIST-NO-NUMBERING y comparte el mismo patrón de recorrido FStructElems.

v3.56.24 2026-05-23

La auditoría PDF/UA-1 ahora incluye una verificación de unicidad de etiquetas H ISO 14289-1 §7.4.4. 10044 informa sobre cualquier nodo de estructura que tenga más de un hijo H directo; —, según la especificación, esto está prohibido en documentos con estructura rígida, y la misma restricción se aplica a cualquier nodo de árbol de etiquetas, independientemente del modo de estructura general. La otra sección § 7.4.4 SHALL (un documento debe tener una estructura rígida o débil, pero no ambas) requiere heurísticas a nivel de documento y se excluye intencionalmente de esta auditoría.
Un nuevo recorrido de árbol de estructura en preorden (UAVisitStructNodeForHUniqueness / ScanStructTreeForHUniqueness) cuenta los hijos H directos por nodo y se recursa en profundidad. Reutiliza el mismo decodificador en forma de K que los recorridos existentes de encabezado, lista y nota.

v3.56.23 2026-05-23

La auditoría PDF/UA-1 ahora incluye dos verificaciones de programas de fuentes ISO 14289-1 §7.21.6 que las verificaciones de la capa de diccionario de v3.56.10 tenían que posponer hasta que estuviera disponible un analizador TrueType. 10034 informa sobre programas TrueType no simbólicos cuyos cmap incrustados SFNT contienen solo la entrada simbólica (platformID=3, encodingID=0) — §7.21.6 El primer párrafo requiere al menos una subtabla cmap no simbólica para que el programa pueda renderizar los puntos de código declarados por su /Encoding.. 10035 informa sobre arreglos TrueType no simbólicos /Encoding /Differences cuyas nombres de glifos no son miembros de la lista de glifos de Adobe (.notdef excluido). — §7.21.6 El tercer párrafo requiere que cada entrada de Diferencias se encuentre en AGL.
El nuevo Lib/PDFlibPDFUAFontInspect.pas implementa un analizador de directorio de tablas tolerante y un analizador de directorio de subtables cmap. La tabla Adobe Glyph List de 4281 nombres, que se agregó como estructura de soporte en el commit de infraestructura anterior, ahora está conectada a través de la verificación de Diferencias. Los programas que no se analizan como SFNT (fuente PFB / PFA, colección OpenType, basura arbitraria) se omiten silenciosamente; se prefieren los falsos negativos a los falsos positivos en la capa de auditoría.

v3.56.22 2026-05-23

La auditoría PDF/UA-1 ahora incluye verificaciones de datos de clip multimedia. 10042 informa sobre diccionarios de datos de clip multimedia (identificados por /S /MCD, opcionalmente /Type /MediaClip) que carecen de la entrada obligatoria de tipo de contenido /CT. 10043 informa sobre los mismos diccionarios que carecen del arreglo /Alt requerido. ISO 32000-1 La Tabla 274 enumera ambas claves como opcionales, pero ISO 14289-1 §7.18.6 las promueve a obligatorias para que los lectores de pantalla puedan anunciar una descripción significativa para los multimedia integrados.
Esta es la Fase 6 del plan de auditoría profunda PDF/UA (.superpowers/plans/2026-05-23-pdfua-deep-audit-plan.md). Se ejecuta sin ninguna dependencia del analizador de programas de fuentes ni del flujo de contenido, por lo que es la primera subclase posterior a la serie v3.56.0..v3.56.13.

v3.56.21 2026-05-23

El nuevo SetSignProcessCommitmentType emite el atributo firmado 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 del PAdES-B-B SignerInfo. Acepta códigos enteros del 1 al 6 que se mapean a los conocidos esquemas de compromiso ETSI id-cti-ets-proofOfOrigin a través de id-cti-ets-proofOfCreation; pase 0 para borrar. Los códigos fuera de rango son rechazados.
El nuevo SetSignProcessSignaturePolicy emite el atributo firmado CAdES signature-policy-identifier (OID 1.2.840.113549.1.9.16.2.15, §5.2.9). Toma la política en formato decimal punteado OID, el hash del documento de política como una cadena hexadecimal en mayúsculas y un código de algoritmo de resumen (1=SHA-1, 2=SHA-256, 3=SHA-384, 4=SHA-512, 0=auto/SHA-256). El atributo lleva la SignaturePolicyId SEQUENCE con sigPolicyId + sigPolicyHash (OtherHashAlgAndValue SEQUENCE).
Ambos atributos solo tienen efecto cuando el SubFilter es ETSI.CAdES.detached (la ruta PAdES-B-B); extienden el array rgAuthAttr existente junto con content-type y signing-certificate-v2. La fila d) de la PAdES Tabla 1 prohíbe combinar commitment-type-indication con la entrada del diccionario de firmas PDF /Reason; el llamador es responsable de no establecer ambos.

v3.56.20 2026-05-23

El nuevo AddPAdESDSSVRI adjunta una entrada de subdiccionario de Firma VRI al DSS que se está ensamblando, completando la estructura de Validación Relacionada con la cláusula 5.4.2.3 de ETSI EN 319 142-1 v1.2.1. La entrada se clavea con el SHA-1 en mayúsculas y hexadecimal de los bytes de la firma '; sus sub-arreglos Cert / CRL / OCSP se completan haciendo referencia a los flujos principales correspondientes mediante índices basados en 0 proporcionados como listas separadas por comas (por ejemplo, "0,2,5").
El TSmartPDFDocument.AddPAdESDSSWithVRI subyacente realiza un seguimiento de los números de objeto de flujo emitidos para cada certificado / CRL / OCSP y los utiliza para escribir los sub-arreglos VRI como referencias indirectas de nuevo a los mismos flujos a los que ya apuntan los arreglos principales DSS, cumpliendo con el requisito de la especificación de que las entradas de VRI compartan almacenamiento con el diccionario principal DSS. El punto de entrada AddPAdESDSS original sigue funcionando sin cambios para los clientes que no necesitan VRI.
Cada subdiccionario VRI por firma lleva el marcador opcional /Type /VRI, por lo que las herramientas que recorren el catálogo por etiquetas Type pueden reconocer la estructura sin volver a resolver la ruta principal.

v3.56.19 2026-05-23

Nuevo flujo de trabajo PAdES-B-T para adjuntar una firma y una marca de tiempo (id-aa-signatureTimeStampToken, OID 1.2.840.113549.1.9.16.2.14) a una firma PAdES-B-B existente. NewPAdESSignatureTimeStampProcessFromFile / FromStream / FromString abre un PDF firmado, SetPAdESSignatureTimeStampField nombra el campo, GetPAdESSignatureValueHashHex devuelve el hash SHA-256 (o 384 / 512) del identificador del firmante ' para su envío a un TSA, GetPAdESSignatureCMSBytes expone la carga útil existente CMS, SetPAdESSignatureCMSBytes acepta los bytes aumentados CMS que el llamador ensambla mediante su CMS biblioteca de elección, y EndPAdESSignatureTimeStampProcessToFile / ToStream / ToString une la nueva CMS en el marcador de posición original /Contents.
BuildPAdESSignatureTimeStampAttribute es un ayudante sin estado que envuelve un TimeStampToken emitido por TSA en el atributo CMS que SignerInfo.unsignedAttrs espera, por lo que los llamadores que ya tienen una biblioteca CMS a mano pueden omitir la parte de tuberías OID + SET.
El nuevo SetSignProcessReserveContentsBytes amplía el marcador de posición /Contents en el momento de la firma inicial para que el CMS aumentado posteriormente quepa sin desbordarse de la reserva original. Los atributos TimeStampTokens típicamente emitidos por 13 agregan de 2 a 6 KB al SignerInfo; pase 1024-8192 aquí para dejar espacio. Si no hay suficiente reserva, la llamada de aumento devuelve 13 (desbordamiento de salida).
La biblioteca no incluye un cliente TSA HTTP; el llamador recupera el TimeStampToken (típicamente 30-50 líneas de solicitud TSP + HTTP POST contra, por ejemplo, FreeTSA o DigiCert). En Windows, CMSG_CTRL_ADD_SIGNER_UNAUTH_ATTR CryptoAPI idealmente automatizaría la inyección CMS en la biblioteca, pero devuelve CRYPT_E_INVALID_INDEX (0x80091008) en la forma separada SignedData PAdES emitida, por lo que se utiliza la ruta de bytes suministrada por el llamador CMS.

v3.56.18 2026-05-23

El atributo PAdES signing-certificate-v2 ahora incrusta el campo opcional IssuerSerial definido por RFC 5035 (ESSCertIDv2). El nombre distinguido del emisor del certificado de firma se envuelve en un GeneralName [4] EXPLICIT directoryName CHOICE dentro de GeneralNames, seguido del número de serie del certificado como un ASN.1 INTEGER. Los bytes del número de serie llegan en orden de bytes little-endian desde Windows CryptoAPI (CRYPT_INTEGER_BLOB) y se invierten a big-endian con la adición del byte de relleno de entero positivo cuando se establece el bit más significativo, lo que coincide con la forma en que OpenSSL y BouncyCastle emiten el mismo campo.
Los verificadores que comprueban el nombre del emisor + el par de números de serie contra su conjunto de candidatos de construcción de rutas (específicamente EU DSS en modo estricto) ahora encuentran ambos identificadores en el atributo signing-cert-v2; la salida anterior v3.56.17 proporcionaba solo la referencia certHash.
Los nuevos ayudantes ASN.1 DER_IntegerFromLittleEndian (maneja el orden de bytes Win32 CRYPT_INTEGER_BLOB) y DER_ContextTagExplicit (envuelve una carga útil en una etiqueta contextual construida) completan el micro-codificador PDFlibASN1. Las nuevas declaraciones CERT_INFO / CRYPT_ALGORITHM_IDENTIFIER / CRYPT_INTEGER_BLOB / PCERT_CONTEXT en PDFlibCryptoAPI dan al camino de firma acceso a los campos del certificado analizados.

v3.56.17 2026-05-23

La ruta de firma incorporada ETSI.CAdES.detached ahora produce firmas PAdES-B-B estructuralmente conformes. La biblioteca construye por sí misma los atributos autenticados CMS — content-type (id-data) y signing-certificate-v2 de RFC 5035 / RFC 5816 con un hash SHA-256 del certificado de firma — y los entrega a CryptSignMessage a través de rgAuthAttr. Una vez que ese campo deja de ser NULL, la Windows CryptoAPI deja de auto-inyectar el atributo signing-time que PAdES (ETSI EN 319 142-1 v1.2.1 Table 1) prohíbe, por lo que el SignerInfo resultante porta los atributos requeridos y solo esos.
La nueva unidad PDFlibASN1 proporciona un microcodificador DER (X.690) enfocado — prefijo de longitud, OCTET STRING, SEQUENCE, SET, OBJECT IDENTIFIER — usado para construir el valor del atributo SigningCertificateV2. El codificador sigue las reglas estándar para arcos OID base-128 y omite el campo opcional hashAlgorithm cuando este solo repetiría el valor por defecto SHA-256, coincidiendo con lo que emiten OpenSSL y BouncyCastle.
ApplySignature ahora enruta ETSI.CAdES.detached por la vía raw-byte (la misma que usa adbe.pkcs7.detached) en lugar de alimentar un digest precalculado. La CryptoAPI computa ahora el atributo autenticado messageDigest sobre el contenido realmente firmado, que es lo que esperan los verificadores.
SHA-384 y SHA-512 también se respetan al construir el atributo signing-certificate-v2: el campo hashAlgorithm se emite con el AlgorithmIdentifier correspondiente en lugar de depender del valor por defecto. SHA-1 se promueve silenciosamente a SHA-256 en este contexto porque PAdES-B-B no autoriza SHA-1 (clause 6.2.1).

v3.56.16 2026-05-23

El nuevo SetSignProcessDigestAlgorithm selecciona el algoritmo de message-digest para la firma: 1 = SHA-1 (deprecated), 2 = SHA-256 (valor por defecto moderno), 3 = SHA-384, 4 = SHA-512, 0 = auto (SHA-256 para cada SubFilter excepto la ruta heredada adbe.pkcs7.sha1, que se mantiene en SHA-1 por compatibilidad binaria estable). ETSI EN 319 142-1 v1.2.1 §6.2.1 prohíbe MD5 y delega en ETSI TS 119 312 las suites criptográficas recomendadas, por lo que los firmantes PAdES deben elegir SHA-256 o más fuerte.
Se añaden los helpers de hash SHA256StreamRange, SHA384StreamRange y SHA512StreamRange junto al SHA1StreamRange existente; la ruta de firma los utiliza para resumir el ByteRange del PDF bajo el algoritmo seleccionado. Ahora se garantiza que el OID SignerInfo.digestAlgorithm de PKCS#7 y los bytes de hash escritos coincidan (el código previo siempre pasaba el digest SHA-1 sin importar el algoritmo negociado).
TPDFlibPFXFile.SignData ahora toma un parámetro DigestAlgorithm y elige el OID correcto para cada par (SubFilter, algoritmo): 2.16.840.1.101.3.4.2.1 / .2 / .3 para SHA-256/384/512 en SubFilters detached y custom (RFC 5754), y los OIDs de la familia sha256WithRSAEncryption correspondientes para la ruta heredada adbe.pkcs7.sha1.

v3.56.15 2026-05-23

El nuevo SetSignProcessDocTimeStamp cambia un sign process al modo PAdES Document Time-stamp según ETSI EN 319 142-1 v1.2.1 §5.4.3. El Signature Dictionary resultante lleva /Type /DocTimeStamp y /SubFilter /ETSI.RFC3161, omite las claves no permitidas /M, /Reason, /Location, /ContactInfo y /Name, y reserva un marcador hex de 8192 bytes (o del tamaño especificado por el llamador) en /Contents para un TimeStampToken RFC 3161 obtenido externamente.
El passthrough se activa automáticamente cuando se selecciona el modo DocTimeStamp porque el TimeStampToken procede de una TSA externa. Las llamadas a SetSignProcessInfo hechas tras cambiar al modo DocTimeStamp se ignoran silenciosamente para mantener el signature dictionary conforme a la especificación.
La auto-inyección PAdES /Extensions /ESIC existente añadida en v3.56.8 ya cubre DocTimeStamp porque su SubFilter comienza con ETSI., de modo que un PDF Document Time-stamp declara la extensión de catálogo requerida sin cableado adicional.

v3.56.14 2026-05-23

Nueva API de aumento PAdES Document Security Store (DSS). NewPAdESDSSProcessFromFile / NewPAdESDSSProcessFromStream / NewPAdESDSSProcessFromString abren un PDF previamente firmado, AddPAdESDSSCertificate / AddPAdESDSSCRL / AddPAdESDSSOCSP preparan material de validación codificado en DER, y EndPAdESDSSProcessToFile / EndPAdESDSSProcessToStream / EndPAdESDSSProcessToString escriben una actualización incremental que contiene un diccionario /DSS << /Type /DSS /Certs [...] /CRLs [...] /OCSPs [...] >> según especifica ETSI EN 319 142-1 v1.2.1 §5.4.2.2. Esta es la pieza base para promover una firma PAdES-B-B / B-T a una validación a largo plazo PAdES-B-LT.
El DSS process actualiza automáticamente la entrada /Extensions /ESIC del catálogo a al menos ExtensionLevel 1 al añadir material de validación, ajustándose al requisito de §5.6, y fusiona nuevos certificados, CRLs y respuestas OCSP en los arrays existentes /Certs / /CRLs / /OCSPs en invocaciones repetidas, de modo que las revisiones se acumulan en lugar de sobrescribirse.
GetPAdESDSSProcessResult / ReleasePAdESDSSProcess completan el ciclo de vida, reflejando la superficie existente de la API SignProcess.

v3.56.8 2026-05-23

Conformidad baseline PAdES: cuando se crea una firma con un SubFilter PAdES (ETSI.CAdES.detached o ETSI.RFC3161), el catálogo del documento recibe ahora automáticamente la entrada /Extensions /ESIC <</BaseVersion /1.7 /ExtensionLevel 2>> requerida por ETSI EN 319 142-1 v1.2.1 §5.6. La entrada se añade a través de la misma actualización incremental que lleva la firma, nunca rebaja un /ExtensionLevel superior existente, y sigue las referencias indirectas /Extensions o /ESIC cuando el PDF de origen ya las almacena como objetos separados.
El marcador de extensión equivalente de Adobe escrito por SetSignProcessCustomSubFilter para PDFs creados a través de TPDFlib es ahora /ADBE /BaseVersion /1.7 /ExtensionLevel 8 (antes ExtensionLevel 5), coincidiendo con la declaración alternativa que las firmas PAdES baseline pueden usar; el nivel 5 sólo cubría características de formularios / 3D / RichMedia de ISO 32000-2 y no identificaba en realidad las extensiones PAdES.

v3.56.13 2026-05-23

Cuando SetPDFUAMode está activo y el documento se guarda, todo elemento de estructura L (lista) que carezca de un atributo ListNumbering explícito recibe ahora automáticamente /O = List /ListNumbering = None. ISO 14289-1 §7.6 exige que toda etiqueta L declare su estilo de numeración; la nueva corrección en tiempo de guardado ApplyPDFUAListNumbering se une a la familia existente ApplyPDFUATabOrder / ApplyPDFUAFormFieldTU / ApplyPDFUAAnnotContents / ApplyPDFUAEmbeddedAFRelationship / ApplyPDFUAStripTrapNet.
Los autores que se preocupen por un estilo de lista específico deben seguir llamando a SetStructElemListNumbering antes de EndTag; la auto-corrección sólo se dispara cuando no hay atributo ListNumbering presente en tiempo de guardado, de modo que los valores explícitos se conservan.
El mensaje de diagnóstico del lado del escritor LIST-NO-NUMBERING:N ahora indica que la auto-corrección enmascarará el problema en tiempo de guardado, de modo que los usuarios entiendan tanto el atributo faltante como el comportamiento de reparación automática.

v3.56.12 2026-05-23

La auditoría PDF/UA-1 gana tres nuevas verificaciones ISO 14289-1. 10031 informa de anotaciones Link cuyo diccionario de acción URI lleva /IsMap = true (prohibido por §7.18.5 a menos que se proporcione funcionalidad equivalente en otro lugar del contenido; los autores con un caso de uso legítimo de IsMap pueden suprimir el diagnóstico por su cuenta). 10032 informa de elementos de estructura Note a los que les falta la entrada /ID — §7.9 exige que toda etiqueta Note declare un ID único. 10033 informa del recuento de pares duplicados cuando dos o más etiquetas Note comparten el mismo valor /ID.
La detección de colisión de IDs de Note se realiza recogiendo los IDs en una TStringList ordenada y recorriendo pares adyacentes, de modo que un grupo de tres Notes compartiendo un ID cuenta como dos pares duplicados.
La verificación de la acción URI recorre el array /Annots de cada página, filtra por /Subtype /Link, y luego inspecciona /A /S /URI y el booleano /IsMap. Las referencias indirectas se desreferencian en cada paso de modo que los diccionarios de acción separados se comportan igual que los inline.

v3.56.11 2026-05-23

ISO 14289-1 §7.6 exige que todo elemento de estructura L (lista) lleve un atributo ListNumbering explícito. 10030 (lado lector) y LIST-NO-NUMBERING:N (lado escritor) informan de las etiquetas L que lo omiten. El walker del lado lector decodifica ambas formas de /A (diccionario único de atributos, o un array de diccionarios mezclados con enteros de revisión) y busca la clave /ListNumbering independientemente del propietario. La verificación del lado escritor inspecciona TPDFStructElem.Attributes para el mismo nombre tanto en la lista de estructura finalizada como en la pila de etiquetas aún abierta.
Los valores válidos de ListNumbering según ISO 32000-1 Table 347 son None, Disc, Circle, Square, Decimal, UpperRoman, LowerRoman, UpperAlpha, LowerAlpha. La auditoría sólo verifica la presencia de la clave, no qué valor se elige — toda etiqueta L necesita uno de estos.

v3.56.10 2026-05-23

La auditoría PDF/UA-1 gana las reglas de codificación TrueType de ISO 14289-1 §7.21.6. 10028 informa de fuentes TrueType no simbólicas cuyo /Encoding (o el /BaseEncoding dentro de un diccionario Encoding) no es ni MacRomanEncoding ni WinAnsiEncoding. 10029 informa de fuentes TrueType simbólicas que llevan una entrada /Encoding en absoluto (prohibido por el cuarto párrafo de §7.21.6).
Simbólico vs. no simbólico se decide a partir del bit 3 (máscara 4) de los /Flags del FontDescriptor, reutilizando el helper existente UAFontDescriptorSymbolic de la subclase 4. El primer párrafo completo de §7.21.6 (el programa TrueType incrustado debe contener entradas cmap coincidentes) requiere analizar el programa de fuente TrueType y sigue pendiente; las reglas a nivel de diccionario anteriores son la capa práctica que esta auditoría puede verificar sin un parser TrueType.
Las reglas de array Differences de §7.21.6 (nombres de glifo sólo AGL, presencia de cmap Microsoft Unicode) quedan fuera de alcance por la misma razón — requieren la inspección del programa de fuente.

v3.56.9 2026-05-23

La auditoría PDF/UA-1 gana una verificación completa de ISO 14289-1 §7.18.4. 10027 informa de anotaciones Widget cuyo /StructParent resuelve a través del /ParentTree del árbol de estructura pero no aterriza en un elemento de estructura con /S = Form. La verificación parcial anterior de v3.56.7 (10026) sólo capturaba Widgets que carecían completamente de /StructParent; la nueva verificación completa la regla siguiendo el puntero del number-tree y verificando la etiqueta de destino.
Un nuevo helper NumberTreeLookup implementa la forma de number-tree de ISO 32000-1 §7.9.7 (raíz plana /Nums, /Kids intermedios delimitados por /Limits). Auditorías futuras que necesiten resolver entradas de página /StructParents o etiquetas /PageLabels pueden reutilizarlo.
La verificación de la etiqueta Form para la anotación Widget usa un modelo de dos niveles: un Widget sin /StructParent se informa como 10026; un Widget cuyo /StructParent existe pero no resuelve a /S = Form se informa como el más específico 10027. Esto evita el doble recuento de la misma violación bajo ambos códigos.

v3.56.7 2026-05-23

Cuando SetPDFUAMode está activo y el documento se guarda, todas las entradas de anotación TrapNet se eliminan ahora automáticamente del array /Annots de cada página. ISO 14289-1 §7.18.2 prohíbe las anotaciones TrapNet; la nueva corrección en tiempo de guardado ApplyPDFUAStripTrapNet se une a la familia existente ApplyPDFUATabOrder / ApplyPDFUAFormFieldTU / ApplyPDFUAAnnotContents / ApplyPDFUAEmbeddedAFRelationship de modo que los documentos en modo PDF/UA dejan de emitir silenciosamente restos de TrapNet.
La auditoría PDF/UA-1 gana una verificación parcial de §7.18.4. 10026 informa de anotaciones Widget a las que les falta /StructParent — un Widget sin /StructParent no puede alcanzarse desde el árbol de estructura y, por tanto, no puede estar anidado en una etiqueta de estructura Form. La verificación estructural completa (resolución de /StructParent a través del ParentTree y confirmación de que el /S padre es Form) se deja para una release de seguimiento.
GetPDFUADiagnostics del lado escritor gana el problema correspondiente WIDGET-NO-STRUCTPARENT:N. El mensaje TRAPNET-ANNOT existente ahora también indica que SetPDFUAMode auto-elimina éstos en tiempo de guardado.

v3.56.6 2026-05-23

La auditoría PDF/UA-1 gana dos verificaciones de jerarquía de encabezados de ISO 14289-1 §7.4.2. 10024 informa cuando el primer elemento de encabezado en orden de documento no es H1 (o H). 10025 informa del número de saltos de nivel de encabezado en una secuencia descendente (p. ej. H1 seguido de H3 sin H2). Ambas verificaciones comparten un único recorrido en preorden del árbol de estructura que decodifica las formas anidadas /K (StructElem único, array de StructElems / IndRefs / MCRs).
GetPDFUADiagnostics del lado escritor gana el problema correspondiente FIRST-HEADING-NOT-H1, en paridad con el lector 10024. La verificación del escritor HEADING-LEVEL-SKIP preexistente tiene ahora un compañero que también captura problemas del estilo "el primer encabezado fue H2".

v3.56.5 2026-05-23

Cuando SetPDFUAMode está activo y el documento se cifra más tarde, la clave de permisos de cifrado (/P en el diccionario de cifrado) tiene ahora automáticamente el bit 10 (máscara $200, "Extraer texto y gráficos en apoyo de la accesibilidad") establecido, incluso cuando el llamador no incluyó ppCanCopyAccess en los TPDFExtraPermissions pasados a Encrypt. ISO 14289-1 §7.16 exige que todo fichero cifrado conforme permita la extracción para accesibilidad, y el bit es por lo demás fácil de olvidar. El bit es siempre seguro de establecer — sólo concede acceso adicional a la tecnología de asistencia, no a otras rutas de extracción.
GetPDFUADiagnostics del lado escritor gana un nuevo problema ENCRYPT-NO-ACCESS que se dispara cuando PDFUAMode está activado y el bit 10 del /P del diccionario de cifrado está en cero. Esto captura el caso límite de orden de llamada en el que el usuario llamó a Encrypt() primero y a SetPDFUAMode sólo después — el diagnóstico le dice al usuario que llame a Encrypt() de nuevo para que el diccionario de cifrado se vuelva a emitir con el /P corregido.

v3.56.4 2026-05-23

GetPDFUADiagnostics del lado escritor gana cinco nuevas verificaciones ISO 14289-1 de modo que la auditoría del documento en memoria capture las mismas violaciones que la auditoría del lado lector CheckFileCompliance ComplianceTest=2. SUSPECTS-TRUE señala MarkInfo/Suspects=true (§7.1: los ficheros PDF/UA conformes requieren Suspects=false). ROLEMAP-STANDARD-REMAP:N señala llamadas a AddRoleMap que reasignarían una etiqueta de estructura estándar — §7.1 prohíbe reasignar etiquetas estándar. DC-TITLE-MISSING señala un dc:title XMP vacío (separado de DOCINFO-TITLE-MISSING, que verifica /Info /Title). TRAPNET-ANNOT:N señala anotaciones TrapNet (§7.18.2 las prohíbe). ANNOT-PAGE-NO-TABS-S:N señala páginas que llevan anotaciones cuyo diccionario de página /Tabs no es /S (§7.18.3 exige el orden de tabulación basado en el árbol de estructura en esas páginas).
Las auditorías PDF/UA-1 del lado escritor y del lado lector están ahora aproximadamente en paridad: todo problema que la auditoría del lado lector levanta en un fichero guardado es también alcanzable desde el diagnóstico en memoria, salvo las convenciones de formato de cada función (texto separado por saltos de línea vs. lista de cadenas con código NNNNN).

v3.56.3 2026-05-23

La auditoría PDF/UA-1 gana sus verificaciones de fuente de §7.21. 10020 informa de cualquier fuente no Standard-14 cuyo FontDescriptor carezca de FontFile/FontFile2/FontFile3 (§7.21.4.1: toda fuente renderizada debe incrustar su programa). 10021 informa de descendientes CIDFontType2 sin una entrada /CIDToGIDMap (§7.21.3.2). 10022 destaca las fuentes Standard 14 (Helvetica, Times, Courier, Symbol, ZapfDingbats y variantes negrita / oblicua) que se referencian sin un programa incrustado — §7.21.4 NOTE 5 deja claro que no hay exención de incrustación para estas fuentes. 10023 informa de fuentes que carecen de un CMap /ToUnicode y no coinciden con la lista de exención de §7.21.7 (codificaciones predefinidas MacRoman / MacExpert / WinAnsi, Type 0 con colecciones de caracteres Adobe-GB1 / CNS1 / Japan1 / Korea1, TrueType no simbólico).
Las fuentes compuestas Type 0 se inspeccionan en ambas capas: /ToUnicode en el propio diccionario padre Type 0, e incrustación / /CIDToGIDMap en el primer CIDFont descendiente. Las fuentes Type 3 omiten la verificación de incrustación (sus glifos son CharProcs inline) pero aún participan en la verificación /ToUnicode.
Los helpers PDFlibPDFA para trabajo de fuente similar no se compartieron intencionadamente — media docena de rutinas cortas (eliminación del prefijo de subset, tabla de nombres Standard-14, presencia de FontFile, flag Symbolic) se duplican localmente como helpers UA* de modo que la auditoría PDF/A pueda seguir evolucionando sin romper PDF/UA, y viceversa.

v3.56.2 2026-05-23

La auditoría PDF/UA-1 gana cinco verificaciones ISO 14289-1 más que cubren anotaciones, ficheros incrustados y contenido opcional. 10015 informa de anotaciones Link que carecen de una descripción alternativa /Contents no vacía (§7.18.5) para que los lectores de pantalla puedan anunciar los destinos del enlace. 10016 y 10017 señalan diccionarios FileSpec de fichero incrustado a los que les faltan las claves /F o /UF requeridas (§7.11). 10018 señala diccionarios de configuración de contenido opcional que omiten una cadena de texto /Name no vacía (§7.10). 10019 señala diccionarios de configuración de contenido opcional que contienen la clave prohibida /AS (§7.10).
El recorrido de anotaciones por página que ya impulsaba las verificaciones de TrapNet y /Tabs /S recoge ahora también los datos Link / /Contents en el mismo pase, manteniendo la auditoría O(N) respecto al recuento de objetos.

v3.56.1 2026-05-23

La auditoría PDF/UA-1 gana cinco nuevas verificaciones ISO 14289-1. 10010 verifica el permiso de extracción de accesibilidad (bit 10 de la clave /P de cifrado) en ficheros cifrados (§7.16). 10011 detecta formularios XFA dinámicos vía el elemento <dynamicRender>required</dynamicRender> dentro del paquete XFA XDP (§7.15). 10012 señala Form XObjects que llevan una entrada /Ref — los reference XObjects están prohibidos (§7.20). 10013 señala anotaciones TrapNet (§7.18.2). 10014 recorre cada página e informa de cualquier página que lleve anotaciones cuyo diccionario de página no establezca /Tabs /S (§7.18.3) para que el orden de tabulación siga el árbol de estructura.
Los cinco nuevos códigos fluyen a través del mismo par de handles CheckFileCompliance + GetStringListItem que añadió la release anterior — no hay nueva superficie pública de API.

v3.56.0 2026-05-23

La nueva auditoría del lado lector CheckCompliancePDFUA valida un PDF externo contra ISO 14289-1 (PDF/UA-1). Complementa la verificación existente del lado escritor GetPDFUADiagnostics aceptando cualquier PDF de entrada (salida propia, salida de escáner, contenido de terceros) y listando las violaciones PDF/UA-1 del mismo modo en que CheckFileCompliance ya informa de problemas PDF/A.
CheckFileCompliance acepta ahora ComplianceTest = 2 para ejecutar la nueva auditoría PDF/UA-1. El test PDF/A bajo ComplianceTest = 1 está sin cambios, y la lista de problemas sigue fluyendo a través del par de handles existente GetStringListCount / GetStringListItem.
El primer corte cubre las puertas de conformidad fundacionales de PDF/UA-1 de §5 (identificación XMP pdfuaid:part) y §7.1 (flujo /Metadata del catálogo, marcador tagged-PDF, árbol de estructura, preferencia de título del visor, idioma del documento, dc:title XMP, valor de /Suspects, y la prohibición de reasignar etiquetas de estructura estándar). Se emiten ocho códigos de diagnóstico — 10001 a 10009 — manteniendo el rango numérico visualmente separado de los códigos PDF/A 00xxx.
Las cláusulas PDF/UA-1 más profundas (seguridad, anotaciones, XObjects, subset de fuentes) están previstas para releases de parche de seguimiento sobre el mismo framework de auditoría.

v3.55.6 2026-05-22

Cada paquete XMP recién generado lleva ahora una propiedad xmpMM:InstanceID en el formato uuid:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX. El identificador se genera vía CoCreateGuid de Win32 y proporciona a cada documento producido una huella única e independiente de la versión, como recomienda ISO 19005-1 §6.7.2 (Cor2) y las guías de buenas prácticas PDF/A. Las builds no Windows (donde el paquete XMP permanece vacío) no se ven afectadas.
El espacio de nombres xmpMM (http://ns.adobe.com/xap/1.0/mm/) forma ahora parte de los SelectionNamespaces del paquete XMP; los nuevos helpers SetXMPMM y GenerateInstanceID sustentan la emisión de InstanceID y proporcionan la base para el soporte futuro de xmpMM:History / xmpMM:DerivedFrom.
El esquema de descripción PDF/A Extension Schema (pdfaExtension / pdfaSchema / pdfaProperty / pdfaType / pdfaField) no se añade en esta release. Crear un esquema de extensión personalizado requiere construcción multi-paso de propiedades bag / seq / estructuradas más allá de la forma actual de SetDublinCore / SetXMPBasic; el trabajo se prevé para una release futura. Los documentos que necesiten declarar propiedades XMP personalizadas siguen recurriendo a la ruta LoadFromString.

v3.55.5 2026-05-22

Los documentos PDF/A tienen ahora sus flags /F de anotación normalizados en tiempo de guardado. ISO 19005-1 §6.5.3 exige que el bit Print sea 1 y los bits Hidden / Invisible / NoView sean 0 en toda anotación; el escritor aplica ahora esa máscara en tiempo de guardado de modo que los llamadores no tengan que recordar el diseño de bits. El caso /Subtype /Popup está exento — los popups son hijos de otras anotaciones y tradicionalmente no se imprimen.
El flag AcroForm /NeedAppearances se fuerza ahora a false en tiempo de guardado cuando el documento está en cualquier modo PDF/A. ISO 19005-1 §6.9 exige que el flag esté ausente o sea false; previamente el escritor dejaba el valor que el llamador hubiera establecido, lo que producía documentos que pedían al visor que regenerara las apariencias en tiempo de apertura y violaban silenciosamente la especificación cuando el llamador lo había puesto a true. La corrección también se ejecuta para documentos a los que les faltaba previamente el flag — el escritor emite un /NeedAppearances false explícito para no dejar ambigüedad al validador.

v3.55.4 2026-05-22

AddStandardFont rechaza ahora las llamadas en modo PDF/A. ISO 19005-1 §6.3.4 revoca la exención "Standard 14 may be unembedded" de la referencia PDF: cada programa de fuente en un fichero conforme debe estar incrustado, y la biblioteca no incluye los outlines Standard 14. La fachada devuelve 0 silenciosamente; los llamadores deben cambiar a AddTrueTypeFont o AddType1Font con un fichero de fuente real.
AddTrueTypeFont promueve ahora silenciosamente Embed=0 (sin incrustación) a Embed=1 (incrustar fuente completa) cuando el modo PDF/A está activo. La ruta de referencia no incrustada producía PDF que dependía del fallback de fuente del visor a una instalación del sistema de Arial / Times / Courier, lo cual viola ISO 19005-1 §6.3.4. Los llamadores existentes que pidieron incrustación (Embed=1 o 2) no se ven afectados.
La verificación de conformidad de /Encoding TrueType no simbólico (ISO 19005-1 §6.3.7 Cor2 exige WinAnsi o MacRoman como el nombre de codificación o BaseEncoding, sin /Differences) no se añade en esta release porque la biblioteca ya emite /WinAnsiEncoding para subsets TrueType no simbólicos, y la aplicación más profunda requeriría rastrear el despacho simbólico-vs-no-simbólico a través de la ruta de subset. CheckCompliancePDFA 00034 / 00035 (añadidos en v3.51.0) señalan cualquier salida no conforme en tiempo de validación.

v3.55.3 2026-05-22

Los diccionarios de fuente CIDFontType2 respaldados por TrueType llevan ahora /CIDToGIDMap /Identity explícitamente. ISO 19005-1 §6.3.3.2 (Cor2) exige que la entrada esté presente en cada CIDFont Type 2 incrustado; la referencia PDF permite el predeterminado implícito Identity, pero PDF/A exige un valor explícito. El escritor estaba omitiendo previamente la clave por completo, haciendo que veraPDF (y CheckCompliancePDFA 00033 añadido en v3.51.0) señalara el fichero. El nombre /Identity coincide con el diseño GID-como-CID que el escritor ya estaba produciendo implícitamente, de modo que los documentos existentes se renderizan idénticamente.
FontDescriptor /CharSet (para subsets Type 1) y /CIDSet (para subsets CIDFont) siguen siendo TODO; el escritor necesitaría rastrear qué nombres de glifo / CIDs terminaron en el subset para rellenarlos con precisión. CheckCompliancePDFA 00031 y 00032 (también añadidos en v3.51.0) señalarán la ausencia para que los usuarios vean el problema en tiempo de validación.

v3.55.2 2026-05-22

AddImageDirectFromString rechaza ahora los filtros incompatibles con PDF/A en el punto de entrada. Pasar Filter = 'LZWDecode' es rechazado para cada parte PDF/A (ISO 19005-1 §6.1.10 más las reglas equivalentes ISO 19005-2 / -3). Pasar Filter = 'JBIG2Decode' o 'JPXDecode' es rechazado para PDF/A-1 (modos 1 y 2). PDF/A-2 y PDF/A-3 admiten JPXDecode bajo ISO 19005-2 §6.2.8.3 con restricciones de sub-especificación (recuento de canales de color, uniformidad de profundidad de bits, requisitos METH/APPROX) que la puerta del lado escritor no aplica — los llamadores en esos modos aún necesitan asegurarse de que el flujo JPEG 2000 sea conforme. La fachada devuelve 0 silenciosamente cuando se solicita un filtro prohibido.
Las entradas TIFF, PNG, JPEG y JPEG 2000 cargadas a través de AddImageFromFile / AddImageFromStream no se ven afectadas: el importador descomprime los bytes de origen y los recodifica con FlateDecode (o DCTDecode para cargas JPEG), de modo que la entrada LZW nunca se propaga a la cadena Filter de salida. El validador CheckCompliancePDFA añadido en v3.50.0 (00004) y v3.52.0 (00022, 00023) proporciona una segunda línea de defensa en tiempo de validación para cualquier ruta indirecta que aún deslice un filtro prohibido en la salida.

v3.55.1 2026-05-22

AddLinkToHideField rechaza ahora las llamadas en modo PDF/A. La release anterior dejaba un comentario afirmando que la acción era compatible con PDF/A, pero ISO 19005-1 Cor2 añadió /Hide a la lista de acciones prohibidas (§6.6.1), e ISO 19005-2 / -3 heredan la restricción. La fachada devuelve 0 silenciosamente cuando se llama en modo PDF/A, coincidiendo con AddLinkToJavaScript y AddLinkToImportData.
AddSWFAnnotationFromFile rechaza ahora las llamadas en modo PDF/A. Las anotaciones SWF / RichMedia envuelven medios Flash que están prohibidos por ISO 19005-1 §6.5.2 (sin subtypes Movie / Sound) y reforzados por ISO 19005-2 §6.3.1 (sin 3D / Sound / Screen / Movie). La fachada devuelve 0 silenciosamente.
AddEmbeddedFile y AddLinkToEmbeddedFile rechazan ahora las llamadas en modos PDF/A-1 y PDF/A-2. ISO 19005-1 §6.1.11 prohíbe /EF, e ISO 19005-2 §6.8 sólo admite ficheros PDF/A incrustados; en lugar de verificar la PDF/A-idad recursiva de la carga adjunta, el escritor simplemente rechaza la llamada en estos modos. PDF/A-3 (SetPDFAMode 5 o 6) sigue permitido — véase v3.55.0 para la inyección automática de /AFRelationship.
SetOpenActionMenu rechaza ahora los valores MenuItem fuera de la lista blanca {NextPage, PrevPage, FirstPage, LastPage} cuando el documento está en modo PDF/A. ISO 19005-1 §6.6.1 restringe las acciones nombradas a ese conjunto, de modo que previamente la API producía silenciosamente diccionarios Open-Action Find / Print / FullScreen no conformes que veraPDF rechazaría.
NewOptionalContentGroup rechaza ahora las llamadas en modos PDF/A-1 (SetPDFAMode 1 o 2). ISO 19005-1 §6.1.13 prohíbe la clave /OCProperties del catálogo. PDF/A-2 (modos 3/4) y PDF/A-3 (modos 5/6) admiten contenido opcional con las restricciones de su respectivo §6.9, de modo que la puerta sólo se dispara para PDF/A-1.

v3.55.0 2026-05-22

Los documentos PDF/A-3 reciben ahora automáticamente una entrada /AFRelationship en cada fichero incrustado. Previamente un fichero PDF/A-3 creado con la biblioteca podía fallar la validación porque ISO 19005-3 Anexo E, Tabla E.1 exige AFRelationship en cada especificación de fichero incrustado. El escritor inyecta ahora el valor predeterminado configurado ('Unspecified' por defecto) en cualquier diccionario FileSpec que carezca de la entrada en tiempo de guardado, reflejando la auto-inyección de AFRelationship PDF/UA introducida anteriormente. Sólo los modos PDF/A-3 (SetPDFAMode 5 = PDF/A-3b o 6 = PDF/A-3a) disparan la auto-inyección; PDF/A-1 y PDF/A-2 siguen rechazando ficheros incrustados directamente según ISO 19005-1 §6.1.11 e ISO 19005-2 §6.8.
SetPDFA3DefaultAFRelationship es una nueva API que sobrescribe el valor predeterminado escrito por el escritor cuando un fichero incrustado carece de una entrada /AFRelationship. Acepta los valores de la Tabla E.1 de ISO 19005-3 'Source' (el fichero incrustado es el material fuente que produjo el contenido PDF), 'Data' (el fichero son los datos estructurados que respaldan una tabla o gráfico visual), 'Alternative' (una representación alternativa como una versión de audio), 'Supplement' (una representación suplementaria como una forma MathML de una ecuación), 'Unspecified' (la relación no puede caracterizarse por lo anterior), o cualquier nombre de segunda clase registrado. La cadena vacía reinicia a 'Unspecified'. Las sobrescrituras por fichero siguen disponibles vía SetEmbeddedFileAFRelationship.
Las nuevas APIs están expuestas en la fachada Delphi como TPDFlib.SetPDFA3DefaultAFRelationship y vía la DLL como DLSetPDFA3DefaultAFRelationship (PWideChar) y DLSetPDFA3DefaultAFRelationshipA (PAnsiChar).

v3.54.0 2026-05-22

LoadOutputIntentProfile es una nueva API que reemplaza el perfil OutputIntent sRGB incluido con un perfil ICC externo cargado desde disco. Requerido al producir documentos PDF/A en espacios de color DeviceCMYK o DeviceGray, ya que la biblioteca sólo incluye un perfil sRGB. El uso típico es llamar a SetPDFAMode primero (que inicializa el esqueleto OutputIntent), y luego a LoadOutputIntentProfile('C:\\path\\to\\FOGRA39.icc', 'DeviceCMYK') para intercambiar los bytes del perfil y etiquetar el documento con el nuevo espacio de color. Devuelve 1 en éxito, 0 si no se encuentra el fichero o si el espacio de color es desconocido. Expuesto en la fachada Delphi como TPDFlib.LoadOutputIntentProfile y vía la DLL como DLLoadOutputIntentProfile (forma PWideChar) y DLLoadOutputIntentProfileA (forma PAnsiChar). ISO 19005-1 §6.2.2 permite cualquier perfil ICC registrado en el flujo DestOutputProfile.
SetFillColorCMYK, SetTextColorCMYK, SetTextHighlightColorCMYK, SetTextUnderlineColorCMYK, AddSeparationColor, SetFillColorSep, SetLineColorSep, SetTextHighlightColorSep y SetTextColorSep tienen ahora éxito en modo PDF/A cuando el perfil OutputIntent del documento es DeviceCMYK. Previamente estas APIs rechazaban cada llamada en modo PDF/A independientemente del OutputIntent, lo que impidía producir documentos CMYK conformes. La puerta es ahora PDFAMode = 0 OR OutputIntentColorSpace = 'DeviceCMYK', coincidiendo con la regla ISO 19005-1 §6.2.3.3 que permite DeviceCMYK cuando el OutputIntent usa un perfil CMYK, e ISO 19005-1 §6.2.3.4 que permite alternativas Separation cuyo espacio de color base también sea conforme.
SetTextShader tiene ahora éxito en modo PDF/A cuando el perfil OutputIntent es DeviceRGB o DeviceCMYK. Los shaders en sí no están prohibidos por PDF/A; el validador (lado lector) verifica que el espacio de color interno del shader coincida con el OutputIntent. El comportamiento anterior de rechazo estricto negaba el uso de shaders conformes.
El desbloqueo de CMYK / Separation / Shader depende de la etiqueta OutputIntentColorSpace establecida por AddOutputIntent y LoadOutputIntentProfile (introducidas en v3.53.0). Llamar a SetPDFAMode sin LoadOutputIntentProfile mantiene el espacio de color como DeviceRGB (el perfil sRGB incluido), de modo que las llamadas CMYK siguen rechazándose por defecto — el nuevo comportamiento es opt-in vía LoadOutputIntentProfile.

v3.53.0 2026-05-22

El diccionario OutputIntent lleva ahora los campos completos del esqueleto PDF/A recomendados por ISO 19005-1 §6.2.2 y la preflight de Adobe Acrobat: /OutputCondition (descripción legible por humanos de la condición de color), /Info (texto de identificación de forma larga), y /RegistryName (URL del registro, por defecto http://www.color.org). Los valores predeterminados son "sRGB IEC61966-2.1" / "sRGB IEC61966-2.1" / "http://www.color.org" para los puntos de llamada heredados de un solo argumento; la nueva sobrecarga de AddOutputIntent toma los cuatro campos personalizados directamente para que los llamadores puedan rellenarlos para sus propias condiciones de color.
AddOutputIntent gana una nueva sobrecarga de cinco argumentos: AddOutputIntent(ColorSpace, OutputConditionIdentifier, OutputCondition, Info, RegistryName). La forma heredada de un solo argumento sigue funcionando sin cambios; ahora delega en la nueva sobrecarga con los predeterminados sRGB. El argumento ColorSpace también selecciona el recuento de componentes /N escrito en el diccionario del perfil ICC incrustado (3 para DeviceRGB, 4 para DeviceCMYK, 1 para DeviceGray); el propio perfil incrustado sigue siendo el flujo sRGB incluido hasta que la próxima API LoadOutputIntentProfile se publique en v3.54.0.
TPDFDocument expone OutputIntentColorSpace como una propiedad de lectura/escritura que rastrea el espacio de color de la última llamada a AddOutputIntent. Ésta se convierte en la condición de puerta para las restricciones del lado escritor CMYK / Separation / Shader en v3.54.0, donde las APIs de color que hoy rechazan cada llamada en modo PDF/A rechazarán sólo cuando el espacio de color no coincida con el OutputIntent.

v3.52.0 2026-05-22

CheckCompliancePDFA audita ahora anotaciones, estado gráfico, acciones y form XObjects, completando la cobertura del validador del lado lector PDF/A de los capítulos 6.2-6.6 de ISO 19005-1 y las reglas diferenciales equivalentes PDF/A-2/-3. El validador informa de 14 nuevas clases de problemas (00050-00067): subtypes de anotación prohibidos (00050; ISO 19005-1 §6.5.2 prohíbe FileAttachment / Sound / Movie para PDF/A-1, e ISO 19005-2 §6.3.1 prohíbe 3D / Sound / Screen / Movie para PDF/A-2 y PDF/A-3), /CA de anotación distinto de 1.0 (00051; §6.5.3), /F de anotación ausente o con Print=0 / Hidden=1 / Invisible=1 / NoView=1 (00052; §6.5.3, con /Subtype /Popup exento), /AA de anotación (00054; §6.6.2), diccionario de apariencia de anotación con claves distintas de /N o valor /N no conforme (00055; §6.5.3 Cor2), anotación Widget con /A (00056; §6.9), ExtGState /TR (00058; §6.2.8), ExtGState /TR2 distinto de /Default (00059; §6.2.8), y sólo en PDF/A-1: ExtGState /SMask distinto de /None (00061; §6.4), /BM distinto de Normal o Compatible (00062; §6.4), /CA o /ca distinto de 1.0 (00063; §6.4).
La auditoría de acciones en cualquier lugar (00064, 00065) reemplaza la verificación sólo de OpenAction de v3.50.0 con un barrido completo que señala valores de acción /S prohibidos (Launch, Sound, Movie, ResetForm, ImportData, JavaScript, Hide, SetState, NOP, Trans, GoTo3DView, Rendition, SetOCGState) y acciones nombradas cuyo /N está fuera de {NextPage, PrevPage, FirstPage, LastPage} independientemente de dónde viva la acción (anotación /A, widget /A, esquema /A, catálogo /OpenAction, etc.). ISO 19005-1 §6.6.1.
La auditoría de XObject (00066, 00067) informa de PostScript y Reference XObjects, más claves prohibidas en 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 audita ahora la conformidad de fuente y espacio de color además de las verificaciones estructurales añadidas en v3.50.0. El validador informa de nueve nuevas clases de problemas: al menos un programa de fuente no está incrustado (00030; ISO 19005-1 §6.3.4 exige que cada programa de fuente, incluidas las sustituciones Standard 14, esté incrustado), subset Type 1 sin /CharSet en su FontDescriptor (00031; §6.3.5), subset CIDFont sin /CIDSet (00032; §6.3.5), CIDFontType2 sin /CIDToGIDMap (00033; §6.3.3.2 Cor2), TrueType no simbólico con un /Encoding no conforme (00034; §6.3.7 Cor2 exige WinAnsi/MacRoman directamente o como BaseEncoding, sin /Differences), TrueType simbólico que aún lleva /Encoding (00035; §6.3.7 Cor2), al menos una fuente sin /ToUnicode en documentos PDF/A-Na o PDF/A-Nu (00036; §6.3.8 con la exención de cuatro clases aplicada), espacio de color ICCBased que no incrusta su flujo de perfil (00037; §6.2.3.2), y un fichero que usa tanto DeviceRGB como DeviceCMYK (00038; §6.2.3.3 prohíbe la mezcla).
La verificación /ToUnicode (00036) está limitada a los niveles de conformidad A y U porque sólo esos niveles requieren mapeo Unicode según ISO 19005-1 §6.3.8 e ISO 19005-2 §6.2.11.7. Los ficheros de nivel B (PDF/A-1b, PDF/A-2b, PDF/A-3b) no se señalan. La exención de cuatro clases reconoce las codificaciones predefinidas (MacRomanEncoding, MacExpertEncoding, WinAnsiEncoding), las BaseFonts Standard 14 Type 1 como proxy de las fuentes con nombres de glifo Adobe Standard Latin / Symbol, y las fuentes Type 0 cuya CIDFont descendiente usa los registros Adobe-GB1, Adobe-CNS1, Adobe-Japan1 o Adobe-Korea1.
La auditoría de fuentes recorre cada diccionario Font, lo clasifica por Subtype (Type1, MMType1, TrueType, Type3, Type0 con su descendiente CIDFontType0 o CIDFontType2), y luego despacha las verificaciones relevantes. Las fuentes compuestas Type 0 delegan las verificaciones de incrustación y de subset a su CIDFont descendiente mientras mantienen /ToUnicode en el envoltorio Type 0. La detección de subset usa la convención estándar de prefijo de seis letras mayúsculas.

v3.50.0 2026-05-22

CheckCompliancePDFA informa ahora de 15 problemas adicionales de no conformidad PDF/A que el validador previamente pasaba por alto: array /ID del trailer ausente (00013), flujo /Metadata del Catálogo del Documento ausente (00014), /Filter aplicado al flujo /Metadata (00015), diccionarios de flujo que referencian ficheros externos vía /F, /FFilter o /FDecodeParms (00016), ficheros incrustados declarados vía /EF en cualquier diccionario file-specification o vía la entrada /EmbeddedFiles del árbol de nombres en documentos PDF/A-1 (00017, 00018), /OpenAction apuntando a un tipo de acción prohibido (00019), diccionarios additional-action /AA en el Catálogo del Documento o cualquier Página (00020, 00021), filtros JBIG2Decode o JPXDecode en documentos PDF/A-1 (00022, 00023), filtros Crypt cuyo /Name no es /Identity (00024), /Requirements en el Catálogo del Documento (00025), /Perms con claves distintas de /UR3 y /DocMDP (00026), y /AcroForm /NeedAppearances establecido en true (00027). El validador señala ahora los tipos de acción /OpenAction del Catálogo prohibidos (/Launch, /Sound, /Movie, /ResetForm, /ImportData, /JavaScript, /Hide, /SetState, /NOP, /Trans, /GoTo3DView, /Rendition, /SetOCGState) y los valores /N de acción nombrada fuera de la lista blanca {NextPage, PrevPage, FirstPage, LastPage} según ISO 19005-1 §6.6.1.
El parser PDFAID acepta el sufijo de conformidad U (PDF/A-2U, PDF/A-3U) junto con las variantes A y B existentes, de modo que CheckCompliancePDFA ya no levanta una advertencia espúrea "00005 PDFA Mark NOT Found or invalid" al escanear un fichero PDF/A-2U o PDF/A-3U producido por otra herramienta. Los niveles de conformidad de mapeo Unicode añadidos en ISO 19005-2:2011 son ahora reconocidos por el validador.
Las verificaciones específicas de filtro (JBIG2Decode, JPXDecode) y las verificaciones de fichero incrustado (/EF, /EmbeddedFiles) siguen limitadas a PDF/A-1 porque ISO 19005-2 §6.2.8.3 y §6.8 relajan explícitamente esas restricciones para PDF/A-2 y PDF/A-3. Las verificaciones de estructura del documento (/Metadata, /AcroForm /NeedAppearances, /OpenAction, /AA, /Requirements, /Perms) se aplican a cada parte PDF/A.

v3.49.0 2026-05-21

AddLinkToImportData crea una anotación Link cuya acción es una acción de importación de datos PDF (/S /ImportData) que rellena los campos AcroForm del documento desde un fichero FDF externo cuando el usuario hace clic en el enlace (ISO 32000-1 §12.6.4.8, Table 198). El parámetro FileName se referencia como un diccionario filespec, con las mismas reglas de normalización de rutas usadas por AddLinkToFile / AddLinkToFileEx (las barras invertidas se convierten en barras según ISO 32000-1 §7.11.2.1). El bit 0 de Options activa el borde visible y los bits 1–3 seleccionan el modo de resaltado del enlace (Invert, Outline, Push), coincidiendo con las convenciones existentes de AddLinkTo*. PDF 1.4 o posterior. NO permitido en PDF/A porque la acción referencia un recurso externo; la fachada devuelve silenciosamente 0 cuando se invoca en modo PDF/A. Expuesto en la biblioteca Delphi y en la interfaz DLL como DLAddLinkToImportData / DLAddLinkToImportDataA (formas PWideChar y PAnsiChar).

v3.48.0 2026-05-21

AddLinkToHideField crea una anotación Link cuya acción es una acción de ocultación PDF (/S /Hide) que alterna la visibilidad de uno o varios campos AcroForm cuando el usuario hace clic en el enlace (ISO 32000-1 §12.6.4.10, Table 196). FieldNames acepta uno o varios nombres de campo completamente cualificados separados por comas, puntos y comas o saltos de línea; un único nombre escribe /T como cadena de texto y dos o más nombres escriben /T como un array, ambas formas permitidas por la especificación. HideFlag selecciona la dirección de visibilidad: un valor distinto de cero oculta los campos listados (/H true) y cero los muestra (/H false). El bit 0 de Options activa el borde visible y los bits 1–3 seleccionan el modo de resaltado del enlace (Invert, Outline, Push), coincidiendo con AddLinkToWeb / AddLinkToNamedAction. PDF 1.2 o posterior. Compatible con PDF/A porque no se referencia ningún recurso externo. Expuesto en la biblioteca Delphi y en la interfaz DLL como DLAddLinkToHideField / DLAddLinkToHideFieldA (formas PWideChar y PAnsiChar).

v3.47.0 2026-05-21

AddLinkToNamedAction crea una anotación Link cuya acción es una acción nombrada PDF (/S /Named) que dispara uno de los cuatro comandos estándar de navegación del visor definidos en ISO 32000-1 §12.6.4.11, Table 194: NextPage, PrevPage, FirstPage y LastPage. El parámetro NamedActionType selecciona el comando (0=NextPage, 1=PrevPage, 2=FirstPage, 3=LastPage); los valores fuera de este rango caen de vuelta a NextPage para que el escritor siempre emita un nombre /N conforme a la especificación. El bit 0 de Options activa el borde visible y los bits 1–3 seleccionan el modo de resaltado del enlace (Invert, Outline, Push), coincidiendo con las convenciones existentes de AddLinkToWeb / AddLinkToPage. La anotación requiere PDF 1.1 o posterior y es compatible con PDF/A porque no se referencia ningún recurso externo. Disponible en la biblioteca Delphi y las interfaces DLL.

v3.46.1 2026-05-21

AddCaretAnnotation crea una anotación de marcado caret (PDF /Subtype /Caret) en el rectángulo dado, marcando una posición en la página donde se ha insertado u omitido texto o contenido, o donde se requiere de otro modo la atención del revisor. Soporta dos tipos de símbolo (None y Paragraph) vía SymbolType (0 / 1), color, opacidad, título, contenido y marcas de tiempo de creación/modificación configurables. Definido en ISO 32000-1 §12.5.6.11. PDF 1.5 o posterior. Disponible en la biblioteca Delphi y las interfaces DLL.
Esta entrada completa la incorporación de anotaciones geométricas que comenzó con v3.44.0 Square+Circle. PDFlibPas ahora crea anotaciones Text, Stamp, FreeText, TextMarkup (Highlight/Underline/Squiggly/StrikeOut), Square, Circle, Line, Polygon, PolyLine, Ink y Caret, además del soporte existente de Link, FileAttachment, SVG, U3D y SWF.

v3.46.0 2026-05-21

AddInkAnnotation crea una anotación de marcado de tinta (PDF /Subtype /Ink) que representa trazos manuscritos o marcas libres dibujadas en la página. Los trazos se proporcionan como una única cadena donde varios trazos se separan por '|' o salto de línea, y dentro de cada trazo los pares de coordenadas siguen el mismo formato de espacios/comas/puntos y comas/tabuladores que usa AddPolygonAnnotation. Por ejemplo "100 100 110 105 120 110 | 200 200 210 205" describe dos trazos separados. Soporta anchura de borde, color de tinta, opacidad, título, contenido y marcas de tiempo configurables. Definido en ISO 32000-1 §12.5.6.13. PDF 1.3 o posterior. Disponible en la biblioteca Delphi y las interfaces DLL.
Cada trazo debe contener un número par de valores (al menos cuatro); de lo contrario la llamada devuelve 0 y no se escribe ninguna anotación. El /Rect se calcula automáticamente a partir de la extensión combinada de todos los trazos más un pequeño relleno para que los trazos permanezcan dentro del cuadro delimitador de la anotación.

v3.45.0 2026-05-21

AddPolygonAnnotation crea una anotación de marcado de polígono cerrado (PDF /Subtype /Polygon) con vértices proporcionados como una cadena de pares de coordenadas separados por espacios, comas, puntos y comas o tabuladores (p. ej. "100 100 200 100 200 200 100 200"). Soporta anchura de borde, color de borde, color de relleno interior opcional, opacidad, título, contenido y marcas de tiempo configurables. Definido en ISO 32000-1 §12.5.6.9. PDF 1.5 o posterior. Disponible en la biblioteca Delphi y las interfaces DLL.
AddPolyLineAnnotation crea una anotación de marcado de polilínea abierta (PDF /Subtype /PolyLine) con el mismo formato de cadena de vértices y estilos de extremos configurables en cada terminal (None, Square, Circle, Diamond, OpenArrow, ClosedArrow, Butt, ROpenArrow, RClosedArrow, Slash). Definido en ISO 32000-1 §12.5.6.9. PDF 1.5 o posterior. Disponible en la biblioteca Delphi y las interfaces DLL.
Ambas anotaciones requieren al menos dos puntos de vértice (cuatro números) y un número total par de números; la llamada devuelve 0 si la cadena de vértices no puede analizarse en una lista válida de pares. El /Rect se calcula a partir de la extensión de los vértices más un relleno proporcional al ancho del borde para que las decoraciones de los extremos permanezcan visibles.
Ambas anotaciones elevan la versión del documento a PDF 1.5 cuando se emiten bajo un bloqueo de versión mínima inferior.

v3.44.1 2026-05-21

AddLineAnnotation crea una anotación de marcado de línea (PDF /Subtype /Line) entre dos puntos finales, con anchura de borde, color de línea, color de relleno interior opcional, estilos de extremo para ambos lados (None, Square, Circle, Diamond, OpenArrow, ClosedArrow, Butt, ROpenArrow, RClosedArrow, Slash), opacidad, título, contenido y marcas de tiempo de creación/modificación configurables. Definido en ISO 32000-1 §12.5.6.7. PDF 1.3 o posterior. Disponible en la biblioteca Delphi y las interfaces DLL.
El /Rect de la anotación se calcula a partir de los dos puntos finales más un relleno proporcional al ancho del borde para que las decoraciones de los extremos permanezcan dentro del cuadro delimitador de la anotación.

v3.44.0 2026-05-21

AddSquareAnnotation crea una anotación de marcado rectangular (PDF /Subtype /Square) en el rectángulo dado, con anchura de borde, color de borde, color de relleno interior opcional, opacidad, título, contenido y marcas de tiempo de creación/modificación configurables. Definido en ISO 32000-1 §12.5.6.8. PDF 1.3 o posterior. Disponible en la biblioteca Delphi y las interfaces DLL.
AddCircleAnnotation crea una anotación de marcado elíptica (PDF /Subtype /Circle) inscrita en el rectángulo dado, con el mismo borde, relleno, opacidad, título, contenido y marcas de tiempo configurables que AddSquareAnnotation. Definido en ISO 32000-1 §12.5.6.8. PDF 1.3 o posterior. Disponible en la biblioteca Delphi y las interfaces DLL.
Ambas nuevas anotaciones elevan automáticamente la versión del documento a PDF 1.3 cuando se emiten bajo un bloqueo de versión mínima inferior y emiten un conjunto estándar de campos de anotación de marcado (/Type /Subtype /Rect /C /IC /BS /Border /CA /F /M /CreationDate /NM /T /Contents /Subj /P) para que los flujos de revisión existentes en Acrobat, Foxit y Edge puedan editarlas tras su creación.

v3.43.0 2026-05-20

SetStructElemSpaceBefore y SetStructElemSpaceAfter establecen los atributos /SpaceBefore y /SpaceAfter (Layout owner) en el elemento de estructura actualmente abierto, expresando el espaciado antes y después de los elementos de nivel de bloque en puntos. Definido en ISO 32000-1 §14.8.5.4.2 Table 340. Disponible en la biblioteca Delphi, ActiveX (Dispids 73008051/73008052) y las interfaces DLL.
SetStructElemStartIndent y SetStructElemEndIndent establecen los atributos /StartIndent y /EndIndent (Layout owner), expresando la sangría desde los bordes de inicio y fin del rectángulo de contenido sensibles al modo de escritura, en puntos. Definido en ISO 32000-1 §14.8.5.4.2 Table 340. Disponible en la biblioteca Delphi, ActiveX (Dispids 73008053/73008054) y las interfaces DLL.
SetStructElemColor establece el atributo /Color (Layout owner) como un triplete RGB (cada componente 0.0-1.0), describiendo el color de primer plano del elemento para motores de reflujo y verificadores de contraste de color descendentes. Definido en ISO 32000-1 §14.8.5.4.2 Table 340. Disponible en la biblioteca Delphi, ActiveX (Dispid 73008055) y las interfaces DLL.
Corregido un error de serialización en BuildStructElemDictRef: los valores numéricos de atributo de token único (como SpaceBefore, SpaceAfter, StartIndent, EndIndent) se escribían como nombres PDF en lugar de números PDF. La corrección se aplica tanto a las ramas de atributos de propietario único como de múltiples propietarios.

v3.42.0 2026-05-20

CheckCompliancePDFA ahora valida correctamente los seis modos PDF/A (1a, 1b, 2a, 2b, 3a, 3b). La verificación PDFAID (código 00005) acepta cualquiera de los seis marcadores XMP válidos en lugar de sólo '1B'. La verificación del límite superior de versión (00002) aplica 1.4 para PDF/A-1 y 1.7 para PDF/A-2 y PDF/A-3.
La verificación OCProperties (código 00003) ahora es condicional: se aplica sólo a documentos PDF/A-1, donde el contenido opcional (capas) está prohibido. PDF/A-2 y PDF/A-3 permiten capas y ya no se marcan.
Se añaden tres nuevas verificaciones de conformidad: el código 00006 marca documentos cifrados (el cifrado está prohibido en todas las versiones PDF/A); el código 00007 marca documentos a los que les falta una entrada OutputIntents en el catálogo (requerida por todas las versiones PDF/A); los códigos 00011 y 00012 marcan documentos a los que les falta MarkInfo o StructTreeRoot cuando el nivel de conformidad es -a (accesibilidad).

v3.41.0 2026-05-20

El modo PDF/A ahora aplica las operaciones prohibidas a nivel de API. Cuando un modo PDF/A está activo (cualquiera de los modos 1-6), llamar a SetEncryption, AddSeparationColor, SetFillColorCMYK, SetTextColorCMYK o cualquier otra API CMYK/Separation/Shader devuelve 0 y no tiene efecto, en consonancia con el requisito de PDF/A de un único output intent sRGB.
La transparencia está prohibida en PDF/A-1 (modos 1 y 2): SetTransparency, SetBlendMode y SetPageTransparencyGroup devuelven 0 y son no-ops cuando el modo activo es 1 o 2. PDF/A-2 y PDF/A-3 (modos 3-6) permiten transparencia limitada y no están restringidos.
Las acciones JavaScript están prohibidas en todos los modos PDF/A (1-6): SetOpenActionJavaScript, PageJavaScriptAction, DocJavaScriptAction, AddGlobalJavaScript y AddLinkToJavaScript devuelven todas 0 y son no-ops cuando cualquier modo PDF/A está activo. ISO 19005-1 §6.6.1 prohíbe explícitamente JavaScript en documentos PDF/A.
Las API de adjuntar ficheros (EmbedFile, AddFileAttachment) están bloqueadas en los modos PDF/A-1 y PDF/A-2 (1-4). Permanecen funcionales en PDF/A-3 (modos 5 y 6), que permite explícitamente ficheros incrustados arbitrarios.

v3.40.0 2026-05-20

SetPDFAMode ahora soporta los niveles de conformidad PDF/A-2 y PDF/A-3. Pase NewMode=3 para PDF/A-2b, 4 para PDF/A-2a, 5 para PDF/A-3b o 6 para PDF/A-3a. PDF/A-2 apunta a PDF 1.7 y permite capas, formularios interactivos, imágenes JPEG2000 y transparencia limitada. PDF/A-3 extiende PDF/A-2 permitiendo ficheros incrustados arbitrarios (cualquier tipo MIME). Todas las variantes -a escriben automáticamente /MarkInfo y los marcadores de estructura tagged-PDF requeridos por el nivel de conformidad de accesibilidad.
Corregido: SetPDFAMode(1) (PDF/A-1a) era previamente un no-op debido a un error de enrutamiento interno introducido en v3.20.0. Ahora escribe correctamente /MarkInfo y /OutputIntents y establece XMP pdfaid:part=1/conformance=A.
GetInformation(201) devuelve '1' hasta '6' coincidiendo con el modo PDF/A activo, en consonancia con la nueva numeración de modos.

v3.39.0 2026-05-20

SetStructElemWritingMode establece el atributo /WritingMode (Layout owner) en el elemento de estructura actualmente abierto. Los valores válidos son LrTb (de izquierda a derecha, predeterminado para escrituras latinas), RlTb (de derecha a izquierda, para árabe y hebreo) y TbRl (de arriba abajo y de derecha a izquierda, para texto vertical CJK tradicional). Definido en ISO 32000-1 §14.8.5.4.2 Table 340. Disponible en la biblioteca Delphi, ActiveX (Dispid 73008049) y las interfaces DLL.
SetStructElemListNumbering establece el atributo /ListNumbering (List owner) en el elemento de estructura actualmente abierto. Los valores soportados incluyen None, Disc, Circle, Square (marcadores no ordenados) y Decimal, UpperRoman, LowerRoman, UpperAlpha, LowerAlpha (numeración ordenada). El atributo se establece en el elemento L (lista) y permite a la tecnología de asistencia anunciar correctamente el tipo de lista. Definido en ISO 32000-1 §14.8.5.3.2 Table 336. Disponible en la biblioteca Delphi, ActiveX (Dispid 73008050) y las interfaces DLL.

v3.38.0 2026-05-20

SetStructElemColSpan establece el atributo /ColSpan (Table owner) en el elemento de estructura actualmente abierto, indicando cuántas columnas abarca la celda. Definido en ISO 32000-1 §14.8.5.7.2 Table 337. Disponible en la biblioteca Delphi, ActiveX (Dispid 73008047) y las interfaces DLL.
SetStructElemRowSpan establece el atributo /RowSpan (Table owner) en el elemento de estructura actualmente abierto, indicando cuántas filas abarca la celda. Definido en ISO 32000-1 §14.8.5.7.2 Table 337. Disponible en la biblioteca Delphi, ActiveX (Dispid 73008048) y las interfaces DLL.
Ambas funciones son envoltorios de conveniencia equivalentes a llamar a AddTagAttribute con Owner='Table' y el nombre de atributo respectivo. Complementan a SetStructElemScope para celdas de tabla completamente descritas en tablas complejas o con cabeceras que abarcan varias columnas/filas.

v3.37.2 2026-05-20

GetPDFUADiagnostics ahora informa FORM-NO-TOOLTIP:N cuando a N campos de formulario interactivos (anotaciones Widget) les falta una entrada TU (tooltip / nombre accesible). ISO 14289-1 §7.18.4 exige que todos los campos de formulario interactivos lleven una entrada TU para que la tecnología de asistencia pueda anunciar el propósito del campo al usuario cuando el campo reciba el foco. /TU es el nombre accesible que los lectores de pantalla pronuncian en voz alta; es distinto de /T, que es el nombre parcial del campo usado para acceso programático y envío de formularios.

v3.37.1 2026-05-20

GetPDFUADiagnostics ahora informa LIST-STRUCT:N cuando N elementos de estructura LI o LBody aparecen fuera de su elemento padre requerido. ISO 32000-1 §14.8.4.4 exige que LI sea hijo directo de L (lista) y que LBody sea hijo directo de LI (elemento de lista). El anidamiento de listas mal formado impide que la tecnología de asistencia recorra y anuncie correctamente el contenido de la lista, y puede causar fallos de validación de la estructura del documento en validadores PDF/UA-1.

v3.37.0 2026-05-20

BeginTagEx2 es una nueva API que abre un elemento de estructura y establece todas las propiedades principales del elemento en una única llamada. Además de los parámetros TagType, AltText, ActualText y Lang de BeginTagEx, BeginTagEx2 acepta Title (/T, para el panel de navegación Tags), ElemID (/ID, identificador único del elemento) y Expansion (/E, texto completo de una abreviatura o acrónimo). Pasar una cadena vacía para cualquiera de estos tres parámetros adicionales equivale a omitir el setter correspondiente. BeginTagEx2 reduce el boilerplate para elementos bien descritos — en lugar de llamar a BeginTagEx seguido por SetStructElemTitle, SetStructElemID y SetStructElemExpansion por separado, las siete propiedades pueden establecerse en una sola llamada. La función está disponible en la biblioteca Delphi, ActiveX (Dispid 73008046) y las interfaces DLL.

v3.36.1 2026-05-20

GetPDFUADiagnostics ahora informa TABLE-TH-NO-SCOPE:N cuando a N elementos de estructura TH (celdas de cabecera de tabla) les falta un atributo Scope. ISO 32000-1 §14.8.4.3.4 Table 337 define Scope (Row, Column o Both) como el atributo que describe a qué celdas de datos se aplica una celda de cabecera. Sin él, los lectores de pantalla y otras tecnologías de asistencia no pueden asociar de forma fiable las celdas de cabecera con las celdas de datos en tablas complejas o con múltiples cabeceras, lo cual es requerido por ISO 14289-1 §7.5. Llame a SetStructElemAttr('Table','Scope', 'Column') (o 'Row' / 'Both') inmediatamente después de etiquetar cada elemento TH.

v3.36.0 2026-05-20

SetStructElemExpansion es una nueva API que establece la entrada /E (texto de expansión) en el elemento de estructura actualmente abierto (ISO 32000-1 §14.9.5). El texto de expansión es la forma completa deletreada de una abreviatura o acrónimo contenido en el elemento — p. ej. "World Wide Web" para un Span cuyo texto es "WWW". Los lectores de pantalla pronuncian la expansión en lugar de intentar pronunciar los caracteres abreviados, lo cual es crítico para la accesibilidad de contenido técnico y científico. PDF/UA-1 (ISO 14289-1 §7.2) exige que la lengua natural sea determinable de forma inequívoca; /E es el mecanismo estándar para abreviaturas y acrónimos. La función está disponible en la biblioteca Delphi, ActiveX y las interfaces DLL.

v3.35.1 2026-05-20

GetPDFUADiagnostics ahora informa DOCINFO-TITLE-MISSING cuando la entrada /Title del diccionario de información del documento está ausente o vacía. PDF/UA-1 (ISO 14289-1) exige un título de documento para que los lectores de pantalla puedan anunciarlo al abrir el documento. La verificación existente DISPLAYDOCTITLE-FALSE confirma que el título se muestra en la barra de título del visor; DOCINFO-TITLE-MISSING es complementaria — confirma que el valor del título en sí está establecido. Llame a SetDocumentInfo('Title', ...) para proporcionar el valor.

v3.35.0 2026-05-20

SetStructElemTitle es una nueva API que establece la entrada /T (título) en el elemento de estructura actualmente abierto (ISO 32000-1 §14.7.2 Table 324). El título es una etiqueta legible por humanos que identifica la instancia específica del elemento — por ejemplo "Chapter 1", "Summary Table" o "Figure 3: Quarterly Sales" — y se muestra en el panel de navegación Tags de los visores PDF y es usado por herramientas de remediación de accesibilidad. /T es distinto de /Alt (texto alternativo para usuarios con problemas de renderizado) y /ActualText (corrección de texto a nivel de glifo); resulta más útil en elementos contenedores no textuales como Table, Figure, Form, Sect y Div. Pase una cadena vacía para borrar un valor establecido previamente. La función está disponible en la biblioteca Delphi, ActiveX y las interfaces DLL.

v3.34.0 2026-05-20

SetStructElemAltText es una nueva API que establece la entrada /Alt en el elemento de estructura actualmente abierto (ISO 32000-1 §14.9.3). Es equivalente a pasar AltText a BeginTag, pero permite que la descripción de texto alternativo se establezca o se actualice después de haber abierto el elemento — útil cuando la descripción se calcula de forma separada del tipo de elemento. PDF/UA-1 (ISO 14289-1 §7.5) exige texto Alt en los elementos Figure y Formula; GetPDFUADiagnostics ya informa FIGURE-NO-ALT:N para los valores ausentes. La función está disponible en la biblioteca Delphi, ActiveX y las interfaces DLL.

v3.33.1 2026-05-20

GetPDFUADiagnostics ahora incluye una verificación ROLEMAP-UNMAPPED:N que detecta nombres de tipo de elemento de estructura personalizados usados en el documento que no tienen entrada en el diccionario /RoleMap. ISO 14289-1 §7.1 e ISO 32000-1 §14.7.3 exigen que cada tipo de estructura no estándar se asigne a un tipo PDF estándar (como P, Span o Figure) para que la tecnología de asistencia pueda determinar cómo manejar el elemento. Cuando se encuentran N tipos sin asignar, la descripción del problema incluye la lista de nombres de tipo para que los llamadores sepan qué entradas AddRoleMap se necesitan. Los 49 tipos de estructura estándar definidos en ISO 32000-1 Table 333 (PDF 1.7) son reconocidos y excluidos del informe.

v3.33.0 2026-05-20

SetStructElemLang es una nueva API que establece la entrada /Lang en el elemento de estructura actualmente abierto (ISO 32000-1 §14.9.2). La etiqueta de idioma sobrescribe el idioma a nivel de documento declarado por SetDocumentLanguage o SetPDFUAMode para el elemento y todos sus descendientes, permitiendo que los documentos multilingües marquen cada fragmento con su etiqueta de idioma BCP 47 correcta (p. ej. 'en-US', 'fr', 'zh-Hant-TW'). Los lectores de pantalla usan el /Lang a nivel de elemento para seleccionar el motor o la voz de síntesis de texto a voz apropiados al leer el documento en voz alta. La función está disponible en la biblioteca Delphi, ActiveX y las interfaces DLL.

v3.32.0 2026-05-20

SetStructElemActualText es una nueva API que establece la entrada /ActualText en el elemento de estructura actualmente abierto (ISO 32000-1 §14.9.4). Úsela para especificar el texto Unicode exacto que representa una secuencia de glifos cuando la extracción del flujo de contenido produciría resultados incorrectos — los casos más comunes son los glifos de ligaduras OpenType (U+FB00 ff, U+FB01 fi, U+FB02 fl) y las abreviaturas con expansiones no obvias. ActualText complementa, en lugar de reemplazar, el contenido renderizado; sobrescribe lo que la tecnología de asistencia y los extractores de texto leen para ese elemento sin suprimir el renderizado visual. La función está disponible en la biblioteca Delphi, ActiveX y las interfaces DLL.

v3.31.1 2026-05-20

GetPDFUADiagnostics ahora verifica los elementos de estructura Formula además de los elementos Figure al informar la falta de texto Alt (FIGURE-NO-ALT:N). ISO 32000-1 §14.9.3 exige descripciones alternativas tanto para las figuras gráficas como para las fórmulas matemáticas; previamente sólo se escaneaban los elementos Figure.
GetPDFUADiagnostics ahora informa PDF-VERSION-LOW cuando la versión PDF del documento está por debajo de 1.7. PDF/UA-1 (ISO 14289-1) se define frente a PDF 1.7 (ISO 32000-1:2008); los documentos en PDF 1.5 o 1.6 no satisfarían los requisitos de la especificación base. Llame a SetPDFUAMode para elevar automáticamente la versión a 1.7.

v3.31.0 2026-05-19

Ahora se soportan los IDs de elementos de estructura y la asociación de cabeceras de tabla. SetStructElemID asigna un identificador de cadena único (/ID) al elemento de estructura actualmente abierto; los IDs se recopilan en un árbol de nombres /IDTree en la raíz del árbol de estructura al guardar el documento, permitiendo que las herramientas de accesibilidad y las referencias cruzadas localicen elementos por ID (ISO 32000-1 §14.7.4). SetStructElemHeaders asocia la celda de tabla actual (TD o TH) con una o más celdas de cabecera vía una lista separada por comas de IDs asignados previamente, escribiendo el array /Headers en el diccionario del owner de atributo Table (ISO 32000-1 §14.8.5.7.2). Juntas, estas dos funciones soportan el marcado de tabla complejo para PDF/UA-1 (ISO 14289-1 §7.10) y WCAG 2.x SC 1.3.1. Ambas funciones están disponibles en la biblioteca Delphi, ActiveX y las interfaces DLL. AddTagAttribute también maneja ahora correctamente el atributo /Headers con valores delimitados por comas escritos como arrays de cadenas de texto PDF.

v3.30.1 2026-05-19

GetPDFUADiagnostics ahora incluye una verificación HEADING-LEVEL-SKIP:N que detecta saltos de nivel de encabezado en el orden del documento (p. ej. un H1 seguido inmediatamente por un H3 sin un H2 en medio). La verificación realiza un recorrido en preorden de todo el árbol de elementos de estructura y cuenta cada aparición donde el siguiente nivel de encabezado excede al anterior en más de uno. Los elementos H genéricos se tratan como H1. Volver a un nivel de encabezado superior (H3 → H1) no se cuenta como un salto. El Criterio de Éxito 1.3.1 de WCAG 2.x e ISO 14289-1 §7.1 exigen que los encabezados se aniden sin huecos.

v3.30.0 2026-05-19

Ahora se soportan los atributos de los elementos de estructura para PDF etiquetado y documentos PDF/UA. Tres nuevas funciones de API permiten adjuntar atributos al elemento de estructura que se está construyendo actualmente en la pila de etiquetas: AddTagAttribute (de propósito general, cualquier owner/nombre/valor), SetStructElemScope (envoltorio de conveniencia que establece el atributo /Scope bajo el owner Table, para celdas de cabecera TH — ISO 32000-1 §14.8.5.7.2) y SetStructElemBBox (envoltorio de conveniencia que establece el atributo /BBox bajo el owner Layout, para figuras y otros elementos posicionados visualmente — ISO 32000-1 §14.8.5.4). Al guardar el documento, los atributos se escriben como diccionarios de atributos /A en cada elemento de estructura; múltiples atributos del mismo owner se agrupan en un solo diccionario, y atributos de diferentes owners se escriben como un array de diccionarios. Las tres funciones están disponibles en la biblioteca Delphi, ActiveX y las interfaces DLL.

v3.29.1 2026-05-19

GetPDFUADiagnostics ahora incluye dos verificaciones adicionales: si a algún elemento de estructura Figure en el documento le falta un valor de texto Alt (informado como FIGURE-NO-ALT:N, según ISO 14289-1 §7.5 e ISO 32000-1 §14.9.3), y si algún elemento de estructura sigue abierto porque no se llamó a EndTag (informado como STRUCT-UNCLOSED:N). La verificación de figuras realiza un recorrido recursivo completo del árbol de elementos de estructura, cubriendo elementos en todas las profundidades de anidamiento.

v3.29.0 2026-05-19

GetPDFUADiagnostics es una nueva API de diagnóstico que verifica un documento en busca de posibles problemas de conformidad PDF/UA-1 (ISO 14289-1) y devuelve una lista de hallazgos separados por saltos de línea. Se realizan seis verificaciones: si MarkInfo/Marked está establecido (PDF etiquetado), si el catálogo del documento tiene una entrada /Lang, si ViewerPreferences/DisplayDocTitle es true, si los metadatos XMP contienen un identificador pdfuaid:part, el conteo de anotaciones no exentas que carecen de una entrada Contents, y el conteo de ficheros incrustados que carecen de una entrada AFRelationship. Cada hallazgo se identifica con un código corto (p. ej. LANG-MISSING, ANNOT-NO-CONTENTS:3) seguido por una descripción legible por humanos. Devuelve una cadena vacía cuando no se encuentran problemas. Disponible en la biblioteca Delphi, ActiveX y las interfaces DLL.

v3.28.5 2026-05-19

Mejora de accesibilidad de anotaciones PDF/UA-1: cuando una anotación FileAttachment no tiene una entrada Contents ni un campo /T, ahora se utiliza como descripción accesible alternativa el nombre del fichero procedente de la especificación de fichero incrustado de la anotación (/FS /UF o /F). Esto completa la cadena de respaldo del Contents de anotaciones: /T → URI de Link → nombre de Stamp → nombre de fichero FileAttachment. Los lectores de pantalla reciben el nombre del fichero adjunto en lugar de silencio, satisfaciendo ISO 14289-1 §7.18.1 para los tipos de anotación más comunes.

v3.28.4 2026-05-19

Mejora de accesibilidad de anotaciones PDF/UA-1: cuando una anotación Stamp no tiene una entrada Contents (o está vacía) ni un campo /T, ahora se utiliza como descripción accesible alternativa el nombre del tipo de sello procedente de la entrada /Name de la anotación (p. ej. "Approved", "Draft", "Confidential", "Final"). Esto extiende la cadena de respaldo del Contents de anotaciones introducida en v3.28.3 para cubrir las anotaciones Stamp, que son comunes en los flujos de trabajo que implican documentos revisados o aprobados y a menudo carecen de un valor Contents explícito.

v3.28.3 2026-05-19

Mejora de accesibilidad de anotaciones PDF/UA-1: cuando una anotación Link no tiene una entrada Contents (o está vacía) ni un campo /T, ahora se utiliza como descripción accesible alternativa el URI procedente de la acción URI de la anotación. Esto se aplica sólo durante el procesamiento de SetPDFUAMode y sólo a las anotaciones Link que llevan una acción /URI. Los lectores de pantalla reciben la URL como etiqueta de último recurso, satisfaciendo ISO 14289-1 §7.18.1 en el caso común en el que los autores crean hipervínculos sin proporcionar una descripción legible por humanos.

v3.28.2 2026-05-19

SetEmbeddedFileAFRelationship es una nueva API para establecer explícitamente el valor AFRelationship en el diccionario de especificación de fichero de un fichero incrustado. Requerido por ISO 14289-1 (PDF/UA-1) §7.11, esto permite a los llamadores especificar la relación semántica de un fichero incrustado con el contenido del documento eligiendo entre los cinco valores válidos: Source, Data, Alternative, Supplement o Unspecified. Cuando SetPDFUAMode está activo, cualquier fichero incrustado sin una clave AFRelationship recibe automáticamente Unspecified; use esta función para sobrescribir ese valor por defecto antes de guardar. Disponible en la biblioteca Delphi, ActiveX y las interfaces DLL.

v3.28.1 2026-05-19

Cuando se llama a SetPDFUAMode sobre un documento cuyos metadatos XMP llevan el título genérico por defecto de la biblioteca en lugar de uno específico del documento, el título se reemplaza ahora automáticamente con el valor de la entrada Title del /Info del documento (si está presente). Esto garantiza que el paquete XMP pdfuaid:part-1 refleje el título real del documento en lugar de un marcador de posición, satisfaciendo las expectativas de los verificadores PDF/UA-1.
El parser XMP (LoadFromString) ahora lee el valor dc:title de los metadatos XMP existentes cuando se carga un documento, de modo que el round-trip de un PDF que ya tiene dc:title preserva correctamente ese título en lugar de revertir al marcador de posición por defecto.

v3.28.0 2026-05-19

BeginArtifactEx(ArtifactType, ArtifactSubtype) es una nueva API de PDF etiquetado que extiende BeginArtifact para expresar tanto el /Type del artifact como el /Subtype de Pagination en una sola llamada. Cuando ambos parámetros son no vacíos, el operador escrito es /Artifact << /Type /T /Subtype /S >> BMC, permitiendo artifacts Pagination completamente especificados como cabeceras y pies de página según ISO 32000-1 §14.8.2.2.1. Si sólo un parámetro es no vacío, se usa la forma de clave única correspondiente. También se exportan los puntos de entrada DLL DLBeginArtifactEx y DLBeginArtifactExA.

v3.27.2 2026-05-19

BeginArtifact ahora distingue correctamente los tipos de artifact de los subtipos de paginación. Cuando el argumento es Pagination, Layout o Page (tipos de artifact según ISO 32000-1 §14.8.2.2.1 Table 330), el operador de contenido marcado escribe /Type en lugar de /Subtype. Otros valores como Header, Footer y Watermark se siguen escribiendo como /Subtype. Esto corrige la salida incorrecta anterior que escribiría /Subtype /Pagination cuando el llamador pretendía marcar un artifact de paginación.

v3.27.1 2026-05-19

Cuando el modo PDF/UA está activo y el documento contiene ficheros incrustados, cada diccionario de especificación de fichero que carece de una entrada AFRelationship recibe ahora una automáticamente al guardar. El valor escrito es /Unspecified, satisfaciendo el requisito ISO 14289-1 §7.11 de que cada fichero incrustado lleve una clave AFRelationship. Esto se aplica tanto a los ficheros añadidos vía EmbedFile como a los ficheros incrustados ya presentes en un documento cargado.

v3.27.0 2026-05-19

AddRoleMap(CustomType, StandardType) es una nueva API de PDF etiquetado que registra una asignación de un nombre de tipo de elemento de estructura personalizado (no estándar) a un tipo de estructura PDF estándar. Al guardar, las asignaciones se escriben en el diccionario RoleMap en la raíz del árbol de estructura, satisfaciendo el requisito ISO 14289-1 §7.1 para documentos que usan nombres de etiqueta específicos de la aplicación. Se pueden registrar múltiples asignaciones; las claves duplicadas se sobrescriben con la última llamada. También se exportan los puntos de entrada DLL DLAddRoleMap y DLAddRoleMapA.

v3.26.0 2026-05-19

BeginTagEx(TagType, AltText, ActualText, Lang) es una nueva API de PDF etiquetado que extiende BeginTag con un atributo explícito de lengua natural. Cuando Lang es no vacía se escribe en el atributo /Lang del elemento de estructura, permitiendo la anotación de idioma por elemento requerida por ISO 14289-1 §7.2 para documentos multilingües. Pase una cadena Lang vacía para que se comporte de manera idéntica a BeginTag. También se exportan los puntos de entrada DLL DLBeginTagEx y DLBeginTagExA.

v3.25.1 2026-05-19

Las fuentes TrueType no subset cargadas con la página de códigos predeterminada de Windows (WinAnsiEncoding) reciben ahora un flujo CMap ToUnicode, permitiendo una extracción fiable de texto Unicode y copiar/pegar para estas fuentes. Anteriormente sólo se escribía un flujo ToUnicode cuando estaba presente una sobreescritura explícita de página de códigos o un array Differences; la ruta común con codificación por defecto carecía de él.
La misma corrección se aplica a las fuentes TrueType cargadas con una página de códigos no predeterminada explícita pero sin array Differences, y a las fuentes cargadas mediante el formato de fuente empaquetado.

v3.25.0 2026-05-19

Cuando el modo PDF/UA está activo, las anotaciones no exentas (todos los tipos excepto Widget, PrinterMark y TrapNet) que carecen de una entrada Contents no vacía reciben ahora una automáticamente al guardar. Se usa como valor de respaldo el valor /T (título / autor) de la anotación, satisfaciendo ISO 14289-1 §7.18.1 para las anotaciones que llevan un título pero ninguna descripción accesible explícita.

v3.24.0 2026-05-19

Cuando el modo PDF/UA está activo, los campos de formulario interactivos que carecen de una entrada TU (tooltip / descripción alternativa) reciben ahora una automáticamente al guardar. Se usa como valor de respaldo el nombre parcial del campo (entrada /T), garantizando que los lectores de pantalla puedan identificar cada campo. Los botones de tipo push se excluyen correctamente de este requisito según ISO 14289-1 §7.18.4.

v3.23.1 2026-05-19

GetInformation(200) devuelve '1' cuando el modo PDF/UA-1 está activo en el documento seleccionado, permitiendo a los llamadores consultar el estado del modo de conformidad en tiempo de ejecución.
GetInformation(201) devuelve '1' para PDF/A-1a, '2' para PDF/A-1b, o una cadena vacía cuando el modo PDF/A está desactivado.
GetInformation(311) y GetInformation(312) devuelven ahora correctamente la cadena de requisito de versión y el nombre de función del conflicto más reciente de bloqueo de versión (anunciado anteriormente en la entrada de v3.20.3 pero aún no implementado).
GetInformation(313) devuelve la cadena de versión PDF en la que el objetivo de guardado está actualmente bloqueado, o una cadena vacía para documentos con versionado libre.

v3.23.0 2026-05-19

SetMarkInfo(Marked) es ahora una API pública, permitiendo que la bandera MarkInfo.Marked se establezca de forma independiente de la configuración completa de PDF/UA-1 realizada por SetPDFUAMode. Cuando Marked es 1, MarkInfo.Suspects también se establece a false como requiere ISO 14289-1 §7.18.6.
Cuando el modo PDF/UA está activo, todas las páginas reciben automáticamente una entrada /Tabs /S al guardar, satisfaciendo el requisito de orden de tabulación basado en estructura de ISO 14289-1 §7.18.4.
Se añade documentación de referencia HTML para SetPDFUAMode, SetDocumentLanguage, SetMarkInfo, BeginTag, EndTag, BeginArtifact y EndArtifact, con tablas de sintaxis completas y ejemplos de uso.

v3.22.0 2026-05-19

BeginTag(TagType, AltText, ActualText) abre un elemento de estructura de PDF etiquetado en el flujo de contenido actual, escribiendo un operador BDC con un MCID asignado automáticamente y registrando el elemento en el árbol de estructura del documento. TagType es cualquier tipo de estructura estándar PDF (P, H1, Figure, Table, etc.). AltText y ActualText son cadenas opcionales de accesibilidad codificadas como cadenas de texto PDF (UTF-16BE).
EndTag cierra el elemento de estructura abierto más recientemente, escribiendo el operador EMC correspondiente en el flujo de contenido.
BeginArtifact(SubType) marca una región de contenido como un artifact PDF (artifact de paginación, fondo, etc.), escribiendo un operador BMC. SubType es opcional; cuando se proporciona se escribe como /Artifact << /Subtype /SubType >>.
EndArtifact cierra la región del artifact con un operador EMC.
Al guardar, cuando se han registrado elementos de estructura etiquetados, la biblioteca construye automáticamente el StructTreeRoot completo, asigna claves StructParents a las páginas afectadas y escribe el árbol numérico ParentTree, satisfaciendo los requisitos de ISO 32000-1 §14.7 para PDF etiquetado.
Las fuentes Type 1 estándar (familias Helvetica, Times, Courier, Symbol) y las fuentes Type 1 incrustadas con codificación WinAnsi reciben ahora un flujo CMap ToUnicode, permitiendo una extracción fiable de texto Unicode y copiar/pegar para estos tipos de fuente.

v3.21.0 2026-05-19

SetPDFUAMode(Language) activa el modo de conformidad PDF/UA-1 (ISO 14289-1): eleva automáticamente el documento a PDF 1.7, escribe MarkInfo.Marked y MarkInfo.Suspects, habilita DisplayDocTitle en ViewerPreferences, establece Catalog.Lang cuando Language es no vacía, y escribe la entrada de espacio de nombres XMP pdfuaid:part = 1 requerida por ISO 14289-1 Section 6.7.11.
SetDocumentLanguage(Language) escribe la entrada Catalog /Lang directamente, permitiendo que el idioma del documento se declare de forma independiente del modo PDF/UA.
MarkInfo.Suspects se establece ahora a false siempre que MarkInfo.Marked se establece a true, satisfaciendo el requisito de estructura de PDF etiquetado de ISO 14289-1 (Section 7.18.6).
Encrypt fuerza ahora la bandera de permiso CanCopyAccess (copia de contenido para accesibilidad) cuando el documento está en modo PDF/UA, como requiere ISO 14289-1 Section 7.17.
Los campos de formulario Choice (desplegables) ya no llevan un valor de tooltip codificado sin sentido; TU se deja sin establecer para que el llamador pueda asignar una etiqueta significativa vía la API de propiedades de campo de formulario.

v3.20.3 2026-05-19

Encrypt y AddSWFAnnotationFromFile devuelven ahora 0 inmediatamente con LastErrorCode 602 cuando la versión de guardado está bloqueada por debajo del mínimo requerido por la fuerza de cifrado o tipo de anotación seleccionados, en lugar de proceder silenciosamente y fallar sólo al guardar.
GetInformation(311) y GetInformation(312) reflejan ahora el requisito de versión conflictivo en el momento de la escritura cuando una versión bloqueada impide funciones de nivel de extensión como AES-256 o anotaciones RichMedia.

v3.20.2 2026-05-19

AddU3DAnnotationFromFile eleva ahora automáticamente la versión del documento a PDF 1.6 cuando se añade una anotación 3D a un documento de versión inferior, en consonancia con el comportamiento de elevación automática de versión de todos los demás puntos de entrada de API PDF 1.6+.

v3.20.1 2026-05-17

Los objetivos de guardado PDF 1.2 se imponen ahora como contratos estrictos de PDF 1.2. Guardar objetos PDF 1.3+ como los datos de TrimBox de página bajo un objetivo PDF 1.2 falla antes de escribir la salida en lugar de emitir un fichero de versión mixta.
El cumplimiento del nivel de extensión Adobe de PDF 1.7 es ahora parte del preflight de guardado. AESV3, AES-256, RichMedia, Projection, los diccionarios geoespaciales y los subfiltros de firma ETSI se verifican contra el ExtensionLevel requerido.
El cifrado AES-256, las anotaciones RichMedia, los diccionarios geoespaciales y los subfiltros de firma ETSI declaran ahora la entrada Adobe Extensions correspondiente cuando PDFlib eleva automáticamente un documento al contenido de extensión PDF 1.7.
Los guardados Append usan ahora la misma puerta de cumplimiento de versión que los guardados completos.
Las DLLs opcionales de runtime PDFium incluidas se actualizaron para Win32 y Win64. GDI+ sigue siendo el renderizador por defecto; PDFium permanece opt-in vía SetPDFiumFileName y SelectRenderer(3).
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 207/207 cada una, y la suite GoogleTest C++Builder Win64x pasó 61 tests con 2 tests existentes dependientes de muestras omitidos.

v3.20.0 2026-05-17

Ocho puntos de entrada de escritura PDFlib más se enrutan ahora a través de Phase 3 EnsureMinVersion, de modo que la versión del documento se eleva automáticamente al mínimo requerido por la función que se emite: SetDocumentMetadata (PDF 1.4 - /Metadata XMP stream) SetPDFAMode(1 or 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 con el conjunto de v3.15.0 (SetTransparency, SetPageUserUnit, Encrypt, SetPageLayout) y el conjunto de v3.17.0 (ocho entradas de JavaScript / fichero incrustado / XFA / SWF), PDFlib eleva ahora automáticamente FVersion a través de veintiun puntos de entrada de escritura.
NewOptionalContentGroup elevaba previamente FVersion directamente; ahora pasa por EnsureMinVersion para que se respete LockSaveVersion y la elevación se registre en AutoBumpedFeatures.

v3.19.0 2026-05-17

El cumplimiento de versión PDF en tiempo de guardado y carga reconoce ahora también cuatro funciones previamente diferidas: Btn /Ff bit 15 NoToggleToOff (radio-button-only) -> PDF 1.4 DeviceN /Subtype /NChannel (color-space refinement) -> PDF 1.6 FontFile3 /Subtype /OpenType (font program type) -> PDF 1.6 Sig /SubFilter ETSI.CAdES.detached or ETSI.RFC3161 -> PDF 1.7
La regla NChannel coincide con la forma de array de espacio de color DeviceN [/DeviceN names alternateSpace tintTransform attributes] cuando el diccionario de atributos en el índice 4 lleva /Subtype /NChannel.
La regla OpenType FontFile3 se dispara sólo cuando el flujo se alcanza a través de una clave padre llamada 'FontFile3', de modo que los flujos no relacionados que casualmente llevan /Subtype /OpenType no se marcan.
La tabla PDFFeatureRules tiene ahora 103 reglas (99 + 4 nuevas).

v3.18.6 2026-05-17

El cumplimiento de versión PDF en tiempo de guardado y carga reconoce ahora /AA (acciones adicionales) con conciencia del tipo de contenedor: Catalog /AA (document-level triggers) -> PDF 1.4 Annot /AA (annotation triggers) -> PDF 1.4 Page /AA (page triggers) -> PDF 1.5
/AA de campo de formulario (PDF 1.2) sigue cubierto por el contrato de guardado PDF 1.3 existente; no se necesita ninguna regla.
La tabla PDFFeatureRules tiene ahora 99 reglas (96 + 3 nuevas).

v3.18.5 2026-05-17

El cumplimiento de versión PDF en tiempo de guardado y carga clasifica ahora correctamente Page /Tabs como una función PDF 1.5; antes estaba clasificada erróneamente como PDF 1.4. El documento de cambios de la especificación PDF 1.4 (Adobe TN #5409) no lista /Tabs, y la Table 8.10 de PDF 1.5 introduce "Tabs (Optional; PDF 1.5)".
Nueva regla: AcroForm /NeedAppearances se reconoce como una función PDF 1.5 según la Table 218 de PDF 1.5.
La tabla PDFFeatureRules tiene ahora 96 reglas (95 + 1 nueva).

v3.18.4 2026-05-13

PDFlibZLib usa ahora siempre el backend de objetos estáticos zlib-ng incluido en las builds normales de la biblioteca, eliminando la ruta de respaldo restante de System.ZLib.
La cobertura de regresión de zlib-ng incluye ahora cargas de tamaño límite, datos de línea de escaneo tipo PNG, flujos almacenados multi-bloque, y flujos zlib conocidos a través de los runners de test Delphi y C++Builder.
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 194/194 cada una, y la suite GoogleTest C++Builder Win64x pasó 58 tests con 2 tests existentes dependientes de muestras omitidos.

v3.18.3 2026-05-12

Las demos Delphi y C++Builder que generan salida PDF o de texto abren ahora el documento generado automáticamente después de un guardado exitoso.
El empaquetado del instalador mantiene ahora los artefactos de build fuera de las carpetas de demo y hace que las muestras C++Builder más los módulos DLL y ActiveX/OCX sean componentes opt-in; sus ficheros correspondientes se instalan sólo cuando se selecciona el componente.

v3.18.2 2026-05-12

Las demos EditFormField Delphi y C++Builder borran ahora /NeedAppearances antes de actualizar los valores de los campos, de modo que cada campo de texto editado obtiene un flujo de apariencia normal refrescado en el PDF guardado.
Esto mantiene el flujo /AP guardado en sincronía con el valor /V almacenado y evita diferencias dependientes del visor en las que enfocar el campo revela texto que faltaba en la apariencia estática del campo.

v3.18.1 2026-05-10

El cumplimiento de versión PDF en tiempo de guardado y carga reconoce ahora también las banderas /Ff de campo de formulario a nivel de bit y el bit AppendOnly de AcroForm /SigFlags: /Ff bit 21 (FileSelect, mask 1048576) -> PDF 1.4 /Ff bit 22 (MultiSelect, mask 2097152) -> PDF 1.4 /Ff bit 23 (DoNotSpellCheck, mask 4194304) -> PDF 1.4 /Ff bit 24 (DoNotScroll, mask 8388608) -> PDF 1.4 /Ff bit 25 (Comb, mask 16777216) -> PDF 1.5 /Ff bit 26 (RichText / RadiosInUnison, 33554432) -> PDF 1.5 /Ff bit 27 (CommitOnSelChange, mask 67108864) -> PDF 1.5 /SigFlags bit 2 (AppendOnly, mask 2) -> PDF 1.5
No se sigue la herencia /Parent: sólo los diccionarios que llevan explícitamente /Ff o /SigFlags disparan las reglas.
La tabla PDFFeatureRules tiene ahora 95 reglas (87 + 8 nuevas a nivel de bit).
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 191/191 cada una, y la suite GoogleTest C++Builder Win64x pasó 57/57.

v3.18.0 2026-05-10

El cumplimiento de versión PDF en tiempo de guardado y carga reconoce ahora también nueve funciones adicionales a nivel de subclave y bit: banderas de anotación a nivel de bit (máscara /F): Locked (128) -> PDF 1.4 ToggleNoView (256) -> PDF 1.5 LockedContents (512) -> PDF 1.7 subclaves distintivas de catálogo y página: /BoxColorInfo (page) -> PDF 1.4 /Permissions, /Legal, /PresSteps -> PDF 1.5 /VP (page geospatial viewport) -> PDF 1.6 /Collection (catalog portable collection) -> PDF 1.7
La tabla PDFFeatureRules tiene ahora 87 reglas (78 a nivel de capítulo + 9 a nivel de subclave / bit).
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 189/189 cada una, y la suite GoogleTest C++Builder Win64x pasó 57/57.

v3.17.0 2026-05-10

Ocho puntos de entrada de escritura PDFlib más se enrutan ahora a través de Phase 3 EnsureMinVersion, de modo que la versión del documento se eleva automáticamente al mínimo requerido por la función que se emite: AddLinkToJavaScript, SetOpenActionJavaScript, AddGlobalJavaScript, FormFieldJavaScriptAction (PDF 1.3 - JavaScript actions) AddEmbeddedFile, AddFileAttachment (PDF 1.3 - file attachments) SetXFAFromString (PDF 1.5 - XFA forms) AddSWFAnnotationFromFile (PDF 1.7 - RichMedia annotation)
Combinado con el conjunto de v3.15.0 (SetTransparency, SetPageUserUnit, Encrypt, SetPageLayout), PDFlib cubre ahora trece puntos de entrada de escritura de versión alta de extremo a extremo.
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 187/187 cada una, y la suite GoogleTest C++Builder Win64x pasó 57/57.

v3.16.3 2026-05-10

Nueva API PDFlib: LockSaveVersion(Version) ancla el documento en Version y detiene la elevación automática de Phase 3 EnsureMinVersion del lado del escritor por encima de ella. UnlockSaveVersion borra el bloqueo.
La puerta de tiempo de guardado está sin cambios: las funciones emitidas por el escritor por encima de la versión bloqueada siguen produciendo LastErrorCode 602 al guardar, en lugar de elevar silenciosamente el encabezado.
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 184/184 cada una, y la suite GoogleTest C++Builder Win64x pasó 57/57.

v3.16.2 2026-05-10

Los PDFs cargados exponen ahora una vista exclusiva de contribuidores de la detección de funciones en tiempo de carga a través de GetInformation(103) ("ContributorFeatures"). La lista contiene sólo las funciones cuya versión mínima requerida es estrictamente mayor que HeaderVersion (clave 100), de modo que responde directamente a "por qué la versión efectiva es mayor que el encabezado del fichero".
GetInformation(101) ("DetectedFeatures") está sin cambios y aún lista cada función coincidente independientemente de la contribución.
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 181/181 cada una, y la suite GoogleTest C++Builder Win64x pasó 57/57.

v3.16.1 2026-05-10

Cobertura ampliada de tests de detección del lado del cargador con seis fixtures sintéticos adicionales: ExtGState de transparencia en página (sin elevación de versión), Catalog /MarkInfo (PDF 1.3 -> PDF 1.4), /OCProperties + contenido OCG (PDF 1.4 -> PDF 1.5), /Type /3DStream (PDF 1.5 -> PDF 1.6), un fixture de combinación multi-función, y una verificación de estabilidad de snapshot.
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 179/179 cada una, y la suite GoogleTest C++Builder Win64x pasó 57/57.

v3.16.0 2026-05-10

Los documentos PDF cargados pasan ahora por un pase de detección de versión orientado al contenido: cada objeto indirecto se recorre a través de la tabla de función-a-versión mínima usada por la puerta de tiempo de guardado, y FVersion se eleva por encima del valor literal del encabezado %PDF-X.Y cuando el contenido realmente requiere una versión superior. Por ejemplo, una entrada de página /UserUnit eleva la versión efectiva a PDF 1.6 incluso cuando el encabezado del fichero dice PDF 1.4.
Nuevas claves GetInformation: 100 devuelve HeaderVersion (literal %PDF-X.Y), 101 devuelve DetectedFeatures (funciones coincidentes en la carga, delimitadas por CRLF), 102 devuelve AutoBumpedFeatures (funciones que dispararon EnsureMinVersion del lado del escritor, delimitadas por CRLF).
La puerta de tiempo de guardado no se ve afectada: los documentos cuya versión efectiva se elevó al cargar, y luego se rebajaron explícitamente con SetInformation(0, ...), siguen produciendo LastErrorCode 602 al guardar.
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 173/173 cada una, y la suite GoogleTest C++Builder Win64x pasó 57/57.

v3.15.0 2026-05-10

Los puntos de entrada de escritura que producen funciones que requieren una versión mínima PDF particular elevan ahora automáticamente la versión PDF del documento. Llamar a SetTransparency en un documento marcado como PDF 1.3 promueve ahora el encabezado a PDF 1.4 en lugar de fallar el guardado con LastErrorCode 602.
Conectada la misma elevación automática en SetPageUserUnit (>=1.6), Encrypt con Strength 1/2/3/4 (>=1.4/1.6/1.7/1.7 respectivamente), y las dos variantes de página de SetPageLayout (>=1.5).
Cambio de comportamiento frente a 3.14.x: las aplicaciones que antes dependían de la puerta "save target rejects writer-emitted features" de v3.12.6 tienen ahora éxito en la versión elevada. Los PDFs cargados que ya contienen funciones de versión superior siguen pasando por la puerta de tiempo de guardado existente, de modo que cargar un PDF etiquetado y seleccionar PDF 1.3 sigue fallando con LastErrorCode 602.
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 170/170 cada una, y la suite GoogleTest C++Builder Win64x pasó 57/57.

v3.14.3 2026-05-10

El cumplimiento de versión PDF en tiempo de guardado reconoce ahora también los tipos restantes de diccionario 3D PDF 1.6 (/Type /3DStream /3DRef /3DBackground /3DRenderMode /3DLightingScheme /3DCrossSection /3DNode) y los subtipos de anotación PDF 1.7 Redact, RichMedia y Projection, más los diccionarios complementarios /Type /Requirement y /ReqHandler.
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 168/168 cada una, y la suite GoogleTest C++Builder Win64x pasó 57/57.

v3.14.2 2026-05-10

El cumplimiento de versión PDF en tiempo de guardado reconoce ahora también funciones PDF 1.5: formularios /XFA, /AlternatePresentations, árbol de nombres /Renditions, los diccionarios multimedia /Type /Rendition /MediaCriteria /MediaPermissions /MediaPlayers, y el subtipo de anotación Screen.
Guardar como PDF 1.4 rechaza ahora los documentos que llevan estas funciones con LastErrorCode 602.
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 166/166 cada una, y la suite GoogleTest C++Builder Win64x pasó 57/57.

v3.14.1 2026-05-10

El cumplimiento de versión PDF en tiempo de guardado reconoce ahora también funciones PDF 1.4: diccionarios /StructTreeRoot /MarkInfo y StructElem de PDF etiquetado, las entradas /Lang del documento y /Tabs de página, los diccionarios /OutputIntents y /OutputIntent, la firma de derechos de uso /UR3, y los subtipos de anotación PDF 1.4 Polygon, PolyLine, Caret, Ink, Popup y Watermark.
Guardar como PDF 1.3 rechaza ahora los documentos que llevan estas funciones con LastErrorCode 602.
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 165/165 cada una, y la suite GoogleTest C++Builder Win64x pasó 57/57.

v3.14.0 2026-05-10

El cumplimiento de versión PDF en tiempo de guardado reconoce ahora también funciones PDF 1.3 como smooth shading, objetos de función, espacios de color ICCBased y DeviceN, entradas de página /TrimBox /BleedBox /ArtBox, CMaps /ToUnicode, anotaciones de fichero adjunto y /Sound y /Movie, diccionarios /Type /Filespec y /Type /EmbeddedFile, las claves /Group /EF /Alternates /Mask, y acciones JavaScript.
Los llamadores PDF 1.2 guardan ahora bajo el contrato PDF 1.3: se preserva el encabezado literal %PDF-1.2, pero la puerta acepta funciones PDF 1.3. Las funciones PDF 1.4 y posteriores siguen siendo rechazadas con LastErrorCode 602.
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 162/162 cada una, y la suite GoogleTest C++Builder Win64x pasó 57/57.

v3.13.0 2026-05-10

Refactorizada la puerta de cumplimiento de versión PDF que rechaza las funciones de versión posterior en tiempo de guardado a un módulo dedicado para que el conjunto de reglas pueda crecer sin agitar el núcleo del documento.
Sin cambio de comportamiento visible al usuario frente a v3.12.7: las mismas funciones fuera de versión siguen siendo rechazadas con LastErrorCode 602.
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 155/155 cada una, y la suite GoogleTest C++Builder Win64x pasó 57/57.

v3.12.7 2026-05-09

Cobertura ampliada de tests automatizados para el flujo de renderizado de acceso directo PdfToImage tanto en las suites Delphi DUnitX como C++Builder GoogleTest.
El runner de tests Delphi VCL GUI registra ahora los fixtures Syntax y XRef, igualando la cobertura del runner de consola.
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 147/147 cada una, y la suite GoogleTest C++Builder Win64x pasó 57/57.

v3.12.6 2026-05-09

Guardar como PDF 1.3, 1.4, 1.5, 1.6 o 1.7 hace cumplir ahora la versión seleccionada como el contrato completo de salida de guardado.
Los guardados completos eliminan las sobreescrituras de /Version del catálogo, eliminan las entradas de extensión de catálogo y metadatos no soportadas para objetivos inferiores, y suprimen los flujos de metadatos XMP PDF 1.4 al guardar como PDF 1.3.
SaveToFile, SaveToString y SaveToStream fallan ahora con LastErrorCode 602 cuando la versión objetivo PDF seleccionada es inferior a las funciones aún presentes en el documento, como transparencia, contenido opcional, JPX, UserUnit, 3D, o funciones de crypt-filter AES.

v3.12.5 2026-05-09

Mejorado el análisis de cadenas literales PDF 1.7 para que las secuencias de escape desconocidas ignoren la barra invertida como requiere el estándar.
Los escapes octales de cadenas literales consumen ahora sólo dígitos octales y preservan un siguiente dígito no octal como datos de cadena regulares.
Añadida cobertura de regresión para escapes literales desconocidos y secuencias de escape octales/no octales mezcladas.
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 141/141 cada una.

v3.12.4 2026-05-09

Mejorado el análisis léxico PDF 1.7 para que los objetos de nombre se detengan ahora correctamente en el delimitador de llave derecha.
Corregida la carga SmartAccess de entradas de objeto comprimido de flujo xref cuyo número de flujo de objeto es mayor que la longitud en bytes del PDF.
Añadida cobertura de regresión para delimitadores de nombre de llave derecha y entradas dispersas de flujo xref de objeto comprimido.
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 139/139 cada una.

v3.12.3 2026-05-08

Mejorada la compatibilidad PDF 1.7 con documentos cifrados para ficheros del manejador de seguridad estándar que usan StrF, StmF, EFF, Identity, None, o crypt filters nombrados estilo StdCF.
Los flujos de metadatos respetan ahora EncryptMetadata=false durante los flujos de descifrado, cifrado y copia/guardado en lugar de ser procesados como flujos ordinarios.
Los flujos de ficheros incrustados llevan ahora /Type /EmbeddedFile y usan la ruta de decisión de crypt-filter de fichero incrustado cuando se cargan o guardan documentos cifrados.
Los flujos de ficheros incrustados externos promueven ahora FDecodeParms a DecodeParms cuando FFilter se promueve a Filter, preservando los parámetros de decodificación del flujo.
Los nuevos PDFs cifrados con AES escriben ahora los valores Length de crypt-filter como longitudes de bits, coincidiendo con el contrato de diccionario crypt filter PDF 1.7.
Los valores Prev/XRefStm de flujo XRef y los grandes desplazamientos numéricos mantienen ahora precisión de 64 bits a través de las rutas del parser y SmartAccess.
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 137/137 cada una.

v3.12.2 2026-05-08

Mejorada la compatibilidad de decodificación de flujos PDF 1.7. La decodificación genérica de flujos respeta ahora /DP como alias de DecodeParms, resuelve entradas de array de parámetros de decodificación indirectas, y acepta las abreviaturas de filtro estándar /AHx y /LZW.
La salida PDF de fichero grande escribe ahora los desplazamientos xref, startxref, linearization y ByteRange de firma digital a través de rutas de formateo de 64 bits en lugar de estrechar esos valores a través de helpers de enteros de 32 bits.
Los documentos cargados tratan ahora una entrada /Version del catálogo como la versión PDF efectiva cuando es más nueva que la versión del encabezado del fichero.
Los trailers reescritos de flujo xref ya no retienen claves DecodeParms exclusivas de flujo cuando PDFlibPas los guarda como diccionarios trailer clásicos.
Validación: las suites DUnitX Delphi Win32 y Win64 pasaron 134/134 cada una.

v3.12.1 2026-05-06

Los PDFs generados se abren ahora con la primera página dimensionada a la altura disponible de la ventana del visor, de modo que toda la primera página es visible de arriba a abajo con el mayor zoom que cabe en la ventana. Configure una OpenAction personalizada (SetOpenActionDestination, SetOpenActionMenu, SetOpenActionJavaScript) en el documento para sobrescribir este predeterminado.

v3.12.0 2026-05-06

Los backends estáticos de Windows incluyen ahora objetos NASM SIMD de libjpeg-turbo para Win32 y Win64, más objetos de despacho SIMD x86 de zlib-ng para el conjunto zlib-ng Win64x.
Reelaborados los scripts de reconstrucción de zlib-ng de modo que Win64x bcc64x y las builds MSVC de diagnóstico compilen los ficheros fuente genéricos, SSE2, SSSE3, SSE4.1/SSE4.2, PCLMULQDQ y AVX2 con banderas de función por fichero en lugar de depender de un único interruptor global de compilador.
Añadidos stubs CRT malloc/calloc/realloc/free alineados a 32 bytes para las bibliotecas C estáticas y corregido TPDFJPEGImage.Compress para liberar los buffers jpeg_mem_dest a través de la misma ruta C free que los asignó.
Ampliadas las notas de validación públicas para destacar la cobertura automatizada estricta detrás de esta release: builds de biblioteca, viajes redondos de compresión, salida HelloWorld /FlateDecode, renderizado JPEG, flujos de imágenes, fuentes, formularios, seguridad, firma, impresión, y flujos derivados de demo C++Builder.

v3.11.0 2026-05-05

Cambiada la compresión y descompresión Flate de Windows a zlib-ng en modo zlib-compatible. Win32, Delphi Win64 y C++Builder Win64x enlazan ahora conjuntos de objetos estáticos zlib-ng con ABI coincidente desde Lib\thirdparty\Win32, Lib\thirdparty\Win64 y Lib\thirdparty\Win64x.
La ruta Win64 ya no se enruta a través de la unidad System.ZLib de Delphi, de modo que la compresión/descompresión de flujos PDF puede beneficiarse del backend zlib-ng igual que la build de 32 bits.
Añadido un pequeño objeto puente zlib-ng para las builds Win64 de modo que el código Pascal mantiene puntos de entrada zlib-compatible estables mientras Delphi y C++Builder consumen sus propios conjuntos de objetos compatibles con su enlazador.
Actualizados todos los proyectos demo C++Builder para definir PDFLIB_CPPBUILDER, igualando el runner GoogleTest y evitando que las demos Win64x enlacen los objetos zlib-ng Delphi Win64.

v3.10.3 2026-05-01

Ampliada la suite GoogleTest C++Builder para cubrir todas las demos bajo Demo\C++Builder. El layout de fase 1 de 7 fixtures creció a 15 fixtures / 52 casos GoogleTest, todos pasando en Win64x. Demos nuevamente cubiertas: 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

Añadido un runner GoogleTest C++Builder bajo Tests\C++Builder que ejercita Lib\PDFlibrary.pas a través de los mismos encabezados HPP emitidos por {$JPHNE} usados por las demos C++Builder. La primera fase refleja siete escenarios núcleo Delphi (HelloWorld, DrawShapes, CreateTable, PdfEncrypt, ExtractText, PdfSigning, PdfToImage rendering) como 17 casos GoogleTest, todos pasando en Win64x.
Ampliada la suite Delphi DUnitX con Tests.Print cubriendo las demos PrintPDF y ShowPrinterBins (enumeración de impresora predeterminada, configuración de impresora personalizada, opciones de impresión, trabajo de impresión redirigido a fichero) y un test de cambio de renderer en Tests.Render ejercitando la selección de motor GDI+ / PDFium / Cairo de la demo MultiFunction sobre el mismo PDF fuente.

v3.10.1 2026-05-01

Se añadieron 57 tamaños de página con nombre a SetPageSize para que también funcionen aquí los mismos nombres canónicos de tamaño de página: 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

Añadidas versiones C++Builder nativas para cada muestra Delphi bajo Demo. Las demos de creación PDF, manipulación de páginas, fuente, imagen, seguridad, firma, renderizado e impresión pueden ahora construirse y ejecutarse desde C++Builder sin ningún wrapper del lado Delphi.
Cada demo nueva vive en Demo\C++Builder\<Name>\ como un proyecto de consola que consume Lib\PDFlibrary.pas directamente y envía los ficheros de entrada necesarios para ejecutarse.
Añadido un Readme.txt en inglés breve para cada carpeta de demo Delphi describiendo lo que la demo muestra, la API en la que se centra, y cómo ejecutarla; una vista general HTML en Demo\Delphi\index.html enlaza a todas ellas agrupadas por tema.
Reflejado el mismo Readme.txt para cada demo C++Builder con una sección Run reescrita para el flujo de consola (argumentos argv en lugar de Open/SaveDialogs); un Demo\C++Builder\index.html correspondiente lista cada demo C++Builder con los mismos grupos de tema.
Corregida una fuga de memoria en la demo ImportEMF (la instancia TPDFlib se creaba pero nunca se liberaba).

v3.9.14 2026-04-30

Corregida la demo de copia de rango de páginas para que realmente copie páginas en lugar de siempre informar fallo.
Ordenadas las demos de texto envuelto y paginación HTML para que cada una se centre en su propia API y se ejecute desde un único botón.
Renombrados dos proyectos demo (EmbeddedFonts y PdfPermission) para que los ejecutables compilados coincidan con los nombres de las carpetas en lugar de nombres de prototipo más antiguos.

v3.9.13 2026-04-30

Corregido un bug de posición de flujo en el lector de buffer interno: las lecturas de palabra de dos bytes avanzaban el cursor de lectura cuatro bytes en lugar de dos. En buffers de más de dos bytes, las lecturas subsiguientes aterrizaban en el desplazamiento equivocado y devolvían silenciosamente datos incorrectos. El efecto era más visible al analizar estructuras de datos binarias que intercalan lecturas de byte y palabra.
Introducida una suite de tests automatizados DUnitX (runners de consola y VCL GUI) cubriendo unidades de utilidad — buffer, AES, ZLib, Unicode, y digest hashing — y flujos a nivel de biblioteca incluyendo creación de documento, guardado a fichero y a flujo, viajes redondos de carga, y cifrado AES-128/AES-256.

v3.9.12 2026-04-30

El renderizado de imágenes GDI+ pasa por defecto ahora a interpolación bicúbica suave y de alta calidad al escalar imágenes raster a resolución de pantalla o exportación. Anteriormente el predeterminado era el vecino más cercano, que producía artefactos visibles de escalera en imágenes pequeñas (logos, miniaturas) ampliadas para vista previa en pantalla o exportación de alta DPI. Los llamadores que prefieran el modo más nítido de vecino más cercano pueden restaurar el comportamiento antiguo vía SetGDIPlusOptions.

v3.9.11 2026-04-30

Corregido el renderizado Cairo de imágenes PDF que usan transparencia color-key (un array de rango de color /Mask en el diccionario de imagen). Previamente, cuando una página contenía una imagen con esta forma de transparencia, el renderer Cairo omitía la imagen por completo en lugar de componerla contra el fondo de la página. La corrección deriva un canal alfa por píxel de los rangos color-key declarados y renderiza el resultado como una imagen transparente, produciendo una salida visualmente consistente con el renderer GDI+.

v3.9.10 2026-04-30

Corregida una regresión de renderizado Cairo donde todo el contenido de la página que seguía a una secuencia de imagen recortada se confinaba incorrectamente al rectángulo de recorte de la imagen. Las páginas PDF que guardan el estado de gráficos, aplican una ruta de recorte, pintan una imagen, y luego restauran el estado — una técnica de layout común para imágenes enmarcadas o con borde — renderizaban todo el texto, formas y gráficos subsiguientes sólo dentro de la región recortada. Cairo save y restore mapean ahora correctamente a los operadores q/Q de PDF, de modo que la región de recorte se descarta después de dibujar la imagen.

v3.9.9 2026-04-29

Añadido un motor de renderizado PDF basado en Cairo como tercera opción de renderizado junto a GDI+ y PDFium. Llame a SelectRenderer(2) antes de renderizar para activarlo; el motor requiere cairo.dll de la carpeta DLL\Cairo incluida. El renderizado Cairo soporta los mismos modos de salida que GDI+: exportación a fichero y flujo de bitmap (BMP, JPEG, PNG, GIF, TIFF, G4 TIFF), renderizado a contexto de dispositivo, y salida directa a impresora.
La demo MultiFunction View/Print expone ahora un selector de renderer de tres vías para que los usuarios puedan comparar las salidas GDI+, PDFium y Cairo lado a lado sobre el mismo documento sin ningún cambio de código.

v3.9.8 2026-04-29

Suprimidos dos diagnósticos espurios del compilador en el shim del runtime C Win32 que aparecían en RAD Studio 13.1 y posteriores. Se generaba una advertencia de deprecación (W1000) porque una guarda de capacidad por versión del compilador no se propagaba a compiladores más nuevos que Delphi 2009, haciendo que compilaran contra una API de gestor de memoria obsoleta. Se generaba un aviso de variable no usada (H2164) para una variable interna de compatibilidad necesaria sólo para builds de Delphi 7; ahora está alcanzada al bloque condicional de esa versión. Ambos problemas eran sólo de diagnóstico sin impacto en runtime.

v3.9.7 2026-04-29

Añadido renderizado de página basado en PDFium opcional en Windows, incluyendo renderizado de flujo BMP, renderizado a contexto de dispositivo, renderizado a memoria, y salida a impresora.
Actualizada la demo Delphi MultiFunction View/Print con un selector de renderer para que los usuarios puedan cambiar entre el renderer GDI+ existente y PDFium.

v3.9.6 2026-04-29

Añadidos scripts Inno Setup separados para el paquete completo PDFlibPas y el paquete trial, con exclusiones enfocadas en release para metadatos de control de fuente, salidas de build, cachés de IDE, ficheros de agente locales, y árboles de fuente de terceros incluidos que no forman parte del paquete enviado.
El instalador trial construye y empaqueta ahora bibliotecas binarias trial para RAD Studio 11.3, 12.3 y 13.1, más las demos trial Delphi, antes de generar el ejecutable de setup.

v3.9.5 2026-04-29

Corregidas las builds de biblioteca Win32 bajo RAD Studio 9.0 / Delphi XE2. El script de build pasaba una bandera de directorio de salida DCU que sólo existe desde Delphi 2010 en adelante; el compilador de XE2 interpretaba la bandera de forma diferente, produciendo una ruta de salida ilegible y un error fatal antes de procesar ningún fichero fuente. El script selecciona ahora la bandera apropiada automáticamente según la versión del compilador objetivo.
Corregida una guarda de versión del compilador relacionada en la fuente de la biblioteca que llamaba a una función de runtime cualificada por nombre introducida en XE4 bajo una condición XE2+. Las builds que apuntan a XE2 y XE3 resuelven ahora correctamente la importación de compatibilidad apropiada.

v3.9.4 2026-04-29

Corregida la configuración de impresora para impresoras de red y compartidas en servidor aplicando bandeja de papel, medio, dúplex, calidad, y otros ajustes de impresión a través del handle DEVMODE de la impresora en lugar del handle del contexto de dispositivo de la impresora.

v3.9.3 2026-04-29

Actualizado el backend AES incluido a las fuentes AES de Brian Gladman de 2018 tanto en Win32 como Win64. Los scripts de build reproducibles permiten ahora reconstruir los objetos AES estáticos desde el código fuente en cualquier momento. Se descubrió y corrigió un defecto ABI en los bindings Pascal en el proceso: a las funciones AES-CBC encrypt y decrypt les faltaba su declaración de convención de llamada C, de modo que las builds Win32 pasaban silenciosamente los argumentos en el orden de registro incorrecto, produciendo potencialmente salida cifrada incorrecta. Las builds Win64 no se venían afectadas porque la plataforma impone una convención de llamada uniforme.
Endurecidos los scripts de reconstrucción de terceros para que los scripts basados en MSVC para zlib, JPEG y CRT-stub puedan lanzarse tanto desde la raíz del repositorio como desde el directorio thirdparty; antes requerían que el directorio de trabajo estuviera fijado a la carpeta thirdparty.

v3.9.2 2026-04-29

Actualizado el backend JPEG 2000 desde el OpenJPEG 1.5 heredado a OpenJPEG 2.5.4 tanto en Win32 como Win64. Ambas plataformas usan ahora enlace de objetos estáticos, de modo que la codificación y decodificación JPEG 2000 funcionan sin una DLL de runtime adicional. El códec moderno trae el manejo actual de encabezados JP2/J2K, una API de flujo dirigida por callbacks, y los bug y security fixes acumulados del proyecto upstream. La API pública TJpeg2000Bitmap está sin cambios.

v3.9.1 2026-04-29

Corregido el renderizado de página JPEG y la exportación de imágenes después de la actualización libjpeg-turbo, restaurando la conversión JPG de PdfToImage y la salida TPDFJPEGImage.SaveToStream en Win32 y Win64.
Corregidos los bindings ABI Win32 de libjpeg-turbo para que los callbacks, alineación de estructura, campos booleanos y destinos JPEG respaldados por memoria coincidan con libjpeg-turbo 3.1.90.
Corregida la descompresión de flujo FlateDecode Win32 con el backend zlib 1.3.2 incluido, restaurando la carga de flujos xref PDF para ficheros como el documento de muestra PdfToImage.

v3.9.0 2026-04-29

Actualizado el backend JPEG 2000 incluido desde el OpenJPEG 1.5 heredado a OpenJPEG 2.5.4. La carga y guardado JPEG 2000 usan ahora el códec moderno, API de flujo dirigida por callbacks, y manejo actual de encabezados JP2/J2K mientras preservan la API pública TJpeg2000Bitmap.
La salida JPEG 2000 selecciona ahora automáticamente un conteo válido de resolución OpenJPEG para imágenes pequeñas, y el backend estático Win32 ya no depende de exportaciones helper MSVCRT ausentes.

v3.8.1 2026-04-29

Eliminadas las 16 advertencias cosméticas del enlazador W1028 "Bad global symbol definition" en Win32 y Win64. Los renombrados a nivel fuente eliminan los duplicados redundantes del lado Pascal (jpeg_std_error y los stubs del allocator jmemnobs se resuelven ahora únicamente desde la capa obj); a los tres símbolos obj bcc32 / vc64 restantes (jpeg_natural_order, jpeg_aritab, jpeg_nbits_table) que deben permanecer resueltos por el enlazador contra datos del lado Pascal se les quita ahora sus nombres de símbolo COFF vía un pase de post-procesamiento ObjConv durante thirdparty\build-jpeg-vc64.bat. Sin cambio en API pública; salida limpia del enlazador tanto para builds Delphi Win32 como Win64.

v3.8.0 2026-04-29

Códec JPEG Win64 actualizado desde libjpeg estilo IJG a libjpeg-turbo 3.1.90, completando la migración JPEG iniciada en v3.7.0 (Win32). Las rutas Win32 y Win64 comparten ahora el mismo códec JPEG moderno, con los mismos bucles internos optimizados por SIMD y 30+ correcciones acumuladas de CVE / fuzz del upstream. API pública PDFlibPas sin cambios.

v3.7.0 2026-04-28

Códec JPEG Win32 actualizado desde IJG libjpeg-6b a libjpeg-turbo 3.1.90. Codificación/decodificación JPEG significativamente más rápida a través de bucles internos optimizados por SIMD, más las 30+ correcciones de CVE / fuzz acumuladas en el upstream de libjpeg-turbo. La API pública PDFlibPas (clase TPDFJPEGImage, funciones DumpJPEG) está sin cambios; las rutas de código PDF/JPEG existentes corren más rápido sin cambios de código fuente necesarios.

v3.6.0 2026-04-28

zlib Win32 actualizado de 1.2.x a 1.3.2. Incluye las 25+ correcciones estándar de CVE / fuzz acumuladas en el upstream desde 1.2.8, más los nuevos puntos de entrada inflateBack9 / inflateTree9 usados por flujos de ventana de 64 bits. La API pública PDFlibPas (DeflateStr / InflateStr / InflateStrParms) está sin cambios.
La ruta zlib Win64 está sin cambios en esta release - sigue usando la unidad System.ZLib incluida con Delphi.
Activado el shim CRT en tiempo de enlace Win64 PDFlibCLibs.pas (introducido en v3.5.0) para la ruta zlib Win32, proporcionando símbolos memcpy / memset / malloc / free que los nuevos ficheros obj de zlib 1.3.2 referencian.

v3.5.0 2026-04-28

Vendorizada infraestructura de build fresca para las bibliotecas C de imagen / compresión incluidas: zlib 1.3.2, libjpeg-turbo 3.1.90, libtiff 4.7.1. Los scripts de build tanto para Embarcadero bcc32 (Win32) como para MSVC cl.exe (Win64) viven en Lib/thirdparty/ junto a los árboles de fuente, de modo que cualquiera con RAD Studio + VS2022 puede reconstruir los ficheros obj estáticos desde la fuente limpia.
Añadida infraestructura de build para OpenJPEG 2.5.4. El árbol de fuente OpenJPEG en sí es obtenido independientemente por el usuario (git clone uclouvain/openjpeg en Lib/thirdparty/OpenJPEG/) para que pueda actualizarse sin tocar la configuración de build de PDFlibPas.
Se añadió Lib/PDFlibCLibs.pas, un shim CRT de enlace para Win64 usado por el backend Win64. Cubre la separación entre los ficheros obj de C compilados con MSVC y los enlazadores Win64 de Delphi (dcc64 / Win64x ld.lld / BCB ilink64), que no incorporan msvcrt.dll automáticamente.

v3.4.0 2026-04-28

Endurecida la generación de clave de cifrado, vector de inicialización AES y bloque de permisos Perms contra fuentes de números aleatorios predecibles. Los PDFs cifrados producidos en sistemas iniciados cerca del mismo tiempo wall-clock ya no son trivialmente correlacionables; los documentos AES-256 mantienen ahora su fuerza completa de clave.
Endurecido el análisis de diccionario de imagen contra PDFs malformados u hostiles que declaran conteos no razonables de Width, Height, BitsPerComponent o componentes DeviceN. Los valores fuera de rango se acotan antes de cualquier aritmética de buffer de píxeles, evitando crash al abrir tales ficheros.
Endurecido el recorrido de referencia cruzada y árbol de páginas contra documentos cuyas cadenas xref /Prev o enlaces de página /Parent forman un ciclo o son excesivamente profundas. El lector rechaza ahora las estructuras malformadas limpiamente en lugar de recurrir hasta agotar la pila.

v3.3.1 2026-04-27

Streamlined los scripts de build de Windows por componente. Las carpetas DLL/, OCX/ y Dylib/ ya no llevan variantes build12-* / build13-* separadas: cada plataforma tiene ahora un único script build-Win32 / build-Win64 que se ancla al último RAD Studio y acepta un argumento opcional "debug".
Añadidos comentarios de justificación en línea alrededor de las correcciones de renderizado de PDFlibRenderer.pas que ya estaban presentes en la línea base inicial de Git. Los comentarios documentan por qué SetPen escala los anchos de trazo por la transformación activa del canvas, y por qué los operadores d0/d1 de CharProc de fuente Type 3 deben consumir sus operandos. Sin cambio en el comportamiento de runtime.

v3.3.0 2026-04-26

Corregido el renderizado de trazos transformados en PDFlibRenderer.pas. SetPen aplica ahora la escala de la transformación actual del canvas a los anchos de línea PDF antes de llamar a Picasso, evitando trazos de tamaño excesivo o insuficiente en rutas cuyas coordenadas ya han sido transformadas. Esto corrige los contornos de glifo Type 3 que podían renderizarse como bloques gruesos e irregulares.
Corregido el manejo d0/d1 de CharProc de fuente Type 3 en el parser de flujo de contenido. d0 consume ahora sus dos operandos de ancho, y d1 consume sus seis operandos de ancho/bounding box antes de que se ejecuten los comandos de dibujo posteriores, evitando que operandos obsoletos corrompan la geometría de glifo o ruta.