Renderer Cairo nativo de Linux
HPDFHeadlessCairoDevice renderiza una página de PDF cargada a un PNG RGB usando superficies de imagen de Cairo y FreeType, sin servidor de display ni lector de PDF
Suministra una vista prestada serial desde THPDFHeadlessDocument.GetRenderAccess(PageIndex) y mantén ese documento cargado e intacto hasta que el rendering devuelva
Document := THPDFHeadlessDocument.Create;
try
Document.LoadFromFile('input.pdf');
Options := THPDFHeadlessRenderOptions.Default;
Info := HPDFRenderHeadlessPagePNGFile(
Document.GetRenderAccess(0), 'page.png', Options);
finally
Document.Free;
end;Dependencias de runtime
El Linux nativo usa libcairo.so.2, libfreetype.so.6 y la dependencia Fontconfig del proveedor de fuentes estándar; instala fuentes adecuadas para la sustitución de Helvetica, Times y Courier
HOTPDF_CAIRO_LIBRARY y HOTPDF_FREETYPE_LIBRARY pueden seleccionar rutas de biblioteca compatibles explícitas antes del primer render; los módulos con éxito permanecen cargados porque las cachés nativas de fuentes pueden retener callbacks de destrucción
El host debe mantener su ejecutable, DLL o paquete de HotPDF cargado mientras esas cachés nativas puedan retener callbacks de destrucción de fuentes de HotPDF; descargar un módulo del host con independencia de la vida de la caché queda fuera de este perfil
Windows usa libcairo-2.dll y libfreetype-6.dll compatibles a través del mismo bridge; los binarios de runtime y su licencia los aporta la aplicación
Los colores ICCBased cargan además liblcms2.so.2; JPEG usa libturbojpeg.so.0 y JPEG 2000 una libopenjp2.so.7 compatible con OpenJPEG 2.5; estas dependencias solo se cargan para las entradas correspondientes
HOTPDF_LCMS_LIBRARY, HOTPDF_TURBOJPEG_LIBRARY y HOTPDF_OPENJPEG_LIBRARY sobrescriben esas rutas; los valores por defecto de Windows son lcms2.dll, turbojpeg.dll y openjp2.dll
Perfil de rendering
El contenido soportado incluye construcción y pintado de trazados, reglas de relleno nonzero y even-odd, clipping, estado gráfico anidado, transformaciones CTM, estilo de línea, colores DeviceGray/RGB/CMYK, alpha normal y Form XObjects repetidos con sus propios recursos, Matrix y BBox
Las anchuras de línea pueden ser cero: las hairlines del PDF solicitadas con 0 w o con ExtGState LW=0 usan un trazo de un píxel en espacio de dispositivo; las anchuras negativas se rechazan
ExtGState D y el operador d del stream de contenido comparten una validación acotada de dashes: los patrones vacíos sólidos, las repeticiones de longitud impar, las entradas de longitud cero, las longitudes fraccionarias y las fases con signo están soportadas
Un patrón de dash admite como máximo 256 longitudes finas no negativas de hasta 1e9, con al menos una longitud positiva cuando no está vacío y una fase fina de valor absoluto de hasta 1e9; cada elemento consume trabajo de operación y el almacenamiento temporal participa en la admisión de bytes de trabajo
Los arrays de operandos aceptan comentarios del PDF, incluidos los arrays numéricos de dash y los arrays de texto TJ; los valores léxicos malformados y los corchetes de cierre ausentes los retiene el scanner compartido y los rechaza el renderer en lugar de desaparecer silenciosamente
El texto horizontal usa el intérprete de glifos compartido para las matrices de texto, las anchuras explícitas del PDF, los avances canónicos de Helvetica/Times/Courier, el espaciado de caracteres y de palabras, la escala horizontal y los ajustes de TJ
Los programas de fuentes incrustadas soportadas usan FreeType con IDs de glifo resueltos; los mapeos Unicode ToUnicode siguen disponibles a través de la API de texto del documento, mientras que las formas raster de fuentes estándar dependen de los sustitutos instalados
El texto compuesto soporta Identity-H, Identity-V, streams CMap de codificación incrustada explícita y los mapeos horizontales y verticales integrados UniJIS, UniGB, UniCNS y UniKS UCS2/UTF16; no se exigen recursos CMap instalados por separado
El pintado vertical de glifos honra los vectores de posicionamiento por defecto y explícitos DW2/W2, el text rise, la escala horizontal, las matrices de texto y gráficos y el desplazamiento de TJ; los mapeos UTF-16 aceptan códigos de caracteres suplementarios
Los ocho modos de rendering de texto están soportados, incluidos los contornos verticales fill/stroke/invisible acumulados en el clip en ET; los streams CMap de codificación incrustada retienen su WMode y sus mapeos CID no identidad
Las operaciones transparentes combinadas de fill y stroke usan composición knockout de objeto para que el relleno solapado no se filtre a través del trazo; los procedimientos de glifo Type3 ejecutan sus propios recursos acotados y matrices de fuente
Las imágenes aceptan muestras de 1/2/4/8/16 bits y arrays Decode, stencil, máscaras explícitas, de color-key y suaves, máscaras de distinto tamaño y recuperación Matte; un Interpolate ausente usa muestreo de vecino más cercano y true selecciona muestreo bilineal
Los codestreams JPX aceptan componentes de origen con o sin signo de hasta 26 bits, incluida la precisión mixta, el subsampling y la opacidad explícita, y los normalizan a muestras acotadas de 8 o 16 bits; el BitsPerComponent del diccionario de imagen y las entradas Decode no stencil se ignoran para imágenes JPX, tal como exige el perfil de imágenes del PDF
Las paletas indexadas y las transformaciones validadas de perfil ICCBased a sRGB están soportadas para imágenes y colores de trazados; DeviceCMYK sin perfil conserva la conversión simple de dispositivo
Las transformaciones ICCBased aceptan firmas de perfil Gray, RGB, CMYK, Lab y XYZ y validan estrictamente el recuento de componentes declarado y los rangos de componentes
Los operandos de perfil Lab usan coordenadas físicas L a b con los rangos por defecto [0 100 -128 127 -128 127]; los operandos XYZ usan coordenadas físicas X Y Z con un rango por defecto sin signo de 1,15 [0 65535/32768] por componente
Las entradas de perfiles XYZ son una extensión nativa de compatibilidad y no implican conformidad PDF de archivado; los perfiles de origen Lab y XYZ no seleccionan un espacio de blending de transparencia soportado
El Range de un stream ICC exige dos valores finos ordenados por componente y acota los operandos de color; los valores por defecto de Decode de imágenes brutas y los valores de búsqueda indexada usan esos rangos de componentes
CalGray, CalRGB y Lab soportan trazados, texto, imágenes y bases de paletas indexadas; los parámetros se validan estrictamente, las entradas Matrix de CalRGB siguen el orden de columnas del PDF, y los componentes Lab y los valores por defecto de Decode de imágenes usan los rangos declarados
Los colores CIE usan adaptación cromática Bradford y salida sRGB relativa; los metadatos BlackPoint se validan, mientras que la compensación adicional de punto negro y las políticas de estado de rendering intent siguen siendo extensiones separadas
Los colores compuestos Separation y DeviceN retienen de uno a treinta y dos componentes de tinta para trazados, texto, bases indexadas e imágenes empaquetadas; los colores alternativos de dispositivo o CIE usan funciones de tinta muestreadas, exponenciales, de stitching o de cálculo acotadas
Las fuentes de color alternativas ICCBased Lab/XYZ y CalGray/CalRGB/Lab retienen sus coordenadas físicas a través de la transformación de tinta antes de convertir a un grupo de transparencia soportado
Las funciones de tinta muestreadas multidimensionales soportan interpolación lineal y cúbica, Domain, Encode, Decode, Range de salida y profundidades de muestras empaquetadas de hasta 32 bits; la evaluación cúbica extiende la convención escalar existente de cuatro nudos mediante productos tensoriales, con fallback lineal para dimensiones cortas y trabajo y cancelación acotados
Consulta funciones nativas de color muestreadas para las convenciones de interpolación y la evidencia separada de fórmulas y lectores
Separation None y los espacios DeviceN que contienen solo colorantes None no aportan ni color ni forma de knockout; los componentes None mixtos todavía llegan a la transformación de tinta alternativa
Separation All aplica su tinta a todos los colorantes de salida disponibles, usando salida de página RGB neutra y preservando cada componente de proceso dentro de los grupos CMYK
Los grupos CMYK reciben los valores de tinta alternativos originales de cuatro componentes antes del blending; las placas spot de Separation, la selección de proceso/colorante NChannel y la simulación de mixing hints siguen siendo extensiones separadas
El callback de imagen terminal preserva el descifrado del documento y los filtros de stream precedentes antes de la decodificación nativa de JPEG, JPEG 2000, CCITT o JBIG2; JBIG2 soporta texto aritmético y Huffman, MMR y diccionarios globales compartidos
JPEG 2000 soporta componentes con subsampling y con signo, declaraciones de color y muestras inferidas, perfiles ICC incrustados, overrides explícitos de espacio de color y opacidad separada o asociada mediante SMaskInData; sus valores de componente se normalizan a ocho o dieciséis bits y su array Decode de imagen se ignora
Los perfiles ICC Lab/XYZ incrustados o explícitos usan rangos físicos de componentes; la opacidad asociada se elimina de las muestras almacenadas normalizadas antes de aplicar el mapeo de coordenadas físicas, preservando los canales de offset Lab
El SMask de estado gráfico soporta grupos Alpha y Luminosity, colores de backdrop, matrices de Form, restauración de estado guardado y funciones de transferencia muestreadas, exponenciales, de stitching y de cálculo acotadas; el soft mask propio de una imagen sobrescribe el soft mask del estado gráfico
Los dieciséis modos de blending estándar del PDF están soportados; los grupos de Form y de página soportan composición aislada y no aislada, knockout de objeto y espacios de blending DeviceGray, DeviceRGB, DeviceCMYK, CalGray, CalRGB o ICCBased de uno, tres y cuatro componentes
Los grupos calibrados retienen los valores nativos de componentes hasta un borde de grupo y aceptan colores de origen de dispositivo o Lab mediante transformaciones calibradas inversas; Lab en sí no es un espacio de blending válido
Las máscaras Luminosity calibradas retienen las coordenadas de su grupo y evalúan el CIE XYZ-Y, incluidas la opacidad del grupo y los colores de backdrop, antes de aplicar la función de transferencia
La composición knockout mantiene la forma geométrica del objeto separada de la opacidad del soft mask; los agujeros de stencil preservan los objetos precedentes mientras que un trazado enmascarado los reemplaza en toda su geometría pintada
Los grupos knockout anidados retienen la unión de las formas geométricas de sus hijos, incluidos los objetos de opacidad cero; los grupos hijos no aislados usan el backdrop inicial del grupo knockout que los envuelve
Los grupos CMYK preservan los componentes complementarios CMY y negro en planos de imagen acotados separados y convierten el resultado combinado en los bordes de grupo; los modos de blending no separables retienen o reemplazan el negro según el modo seleccionado
Los grupos no aislados renderizan una pasada adicional acotada de opacidad, eliminan la contribución del backdrop inicial y aplican una sola vez el alpha entrante del grupo y su modo de blending; los grupos de transparencia de página usan una superficie aislada antes de componer sobre el fondo de página
Un Form no aislado hereda el espacio de blending que lo envuelve; una entrada CS de grupo explícita no conmuta el backdrop inicial a otro espacio
Las apariencias normales existentes de anotaciones se ajustan desde su BBox transformado al Rect; RenderAnnotations=false omite las apariencias en cualquiera de los dos usos
Usage vale hruView por defecto, que se salta las anotaciones Hidden y NoView y los tipos de anotación desconocidos con Invisible activo; los tipos de anotación estándar de ISO 32000, incluidos RichMedia y Projection de PDF 2.0, con apariencias normales soportadas permanecen visibles cuando solo está activo Invisible
La aceptación de RichMedia y Projection cubre apariencias normales estáticas existentes con recursos de medios válidos o una vista 3D por defecto asociada; la reproducción de medios y la activación 3D interactiva quedan fuera de esta ruta raster
hruPrint pinta solo las anotaciones con Print activo y Hidden inactivo; Invisible suprime los tipos de anotación desconocidos en ambos usos, NoView no suprime la impresión y NoZoom no cambia el tamaño de apariencia impreso
Las anotaciones visibles exigen un stream de apariencia normal existente y soportado; el renderer no sintetiza apariencias a partir de metadatos de anotaciones ni de valores de campos
Para la salida de vista, NoZoom de la anotación elimina la escala de render del tamaño de apariencia mientras preserva UserUnit; NoRotate mantiene la apariencia ajustada en vertical ante la rotación de página en ambos usos, y ambos preservan el ancla Rect transformada superior-izquierda y el clip de página
Las anotaciones de texto con apariencias normales existentes se comportan como NoZoom y NoRotate en la salida de vista con independencia de sus flags explícitos; la salida de impresión retiene su comportamiento NoRotate mientras ignora NoZoom
Usage controla la visibilidad raster estática y la geometría de anotaciones; los flags de solo interacción no crean comportamiento de hover ni de edición, y el callback existente de permiso de extracción sigue siendo obligatorio sin conceder permiso de impresión
Optional content en salida estática
El rendering consume la configuración por defecto OCProperties/D del catálogo, inicializa los estados de grupo desde BaseState, aplica los overrides ON y OFF y usa los valores Intent coincidentes al determinar la visibilidad
Los diccionarios de membresía soportan AnyOn, AllOn, AnyOff y AllOff; las expresiones recursivas VE soportan And, Or y Not de un operando, con VE teniendo precedencia sobre la política más simple
Las referencias de grupo null, no disponibles u obsoletas no tienen efecto de membresía; los grupos fuera de los intents de la configuración no controlan la visibilidad, y una membresía o expresión sin grupos aplicables deja el contenido visible
El marcado de contenido /OC anidado, las imágenes y los Form XObjects y las anotaciones respetan el estado resultante; las secciones marcadas ocultas todavía actualizan colores, matrices, clipping y posición de texto, mientras que los XObjects completos ocultos y las anotaciones pueden saltarse
Los diccionarios ordinarios de propiedades de marcado de contenido siguen siendo utilizables, incluidos los valores inline anidados; los arrays de contenido preservan el estado de marcado de contenido a través de sus streams componente, y los streams hijos mantienen su propio anidamiento de marcado
La rasterización independiente de forma final usa la configuración por defecto en los modos view y print sin aplicar automáticamente las recomendaciones interactivas de uso AS, según especifica la sección 8.11.4.5 de ISO 32000-1:2008; el ViewerState explícito habilita las recomendaciones View, Print, Export, Zoom, Language y User con selección manual persistente y estado temporal de eventos
Las propiedades de optional content ausentes o un catálogo prestado nil dejan las estructuras de optional content sin efecto de visibilidad; las membresías vivas malformadas, los ciclos de expresiones y los límites configurados de trabajo, memoria o recursión fallan antes de la publicación del PNG
Las matrices de apariencia afines y los orígenes de BBox distintos de cero retienen su ajuste normal bajo estos flags; una escala de render extremadamente pequeña puede seguir haciendo que la matriz inicial de página de Cairo sea numéricamente no invertible
La página renderizada usa la intersección MediaBox/CropBox, las cajas de página heredadas y el Rotate de cuarto de vuelta, y el UserUnit de la página; la escala 1 produce un píxel por punto efectivo de página, con las dimensiones de la superficie redondeadas hacia arriba
El operador sh pinta shadings de función, axiales y radiales (ShadingTypes 1–3), con dominios de dos entradas, matrices de shading, selección de círculo radial, extremos Extend, BBox y clips de trazado existentes
Las funciones de color soportadas y los arrays de funciones escalares convierten a través de colores de origen de dispositivo, calibrados, ICC Lab/XYZ y Separation/DeviceN; la opacidad de relleno actual, los modos de blending, los soft masks de estado gráfico y el knockout de grupos de transparencia aplican al shading resultante
El trazado y el color actuales se preservan; el Background del shading lo ignora sh, y AntiAlias es una pista de dispositivo con muestreo de color en el centro del píxel
Las entradas ExtGState no soportadas y los operadores de contenido no soportados quedan fuera de este perfil
Shadings de malla triangular
ShadingTypes 4 y 5 pintan mallas Gouraud de triángulos free-form y lattice con reutilización de aristas, geometría de lattice arbitraria, registros de vértices alineados a bytes, precisión de coordenadas de hasta 32 bits y precisión de componentes de hasta 16 bits
Los componentes de vértice se interpolan en los centros de píxel del dispositivo antes de la conversión de color; una función opcional de una entrada o un array de funciones de componente evalúa el parámetro interpolado, incluidos los espacios de color calibrados, ICC y especiales
Los orígenes indexados redondean los índices interpolados a la entrada de paleta más cercana; las cadenas de búsqueda hexadecimales se decodifican una vez con espacios en blanco, dígitos en mayúsculas y minúsculas y relleno del nibble final impar, mientras que las cadenas de búsqueda literales retienen sus bytes decodificados
Las transformaciones actuales, el clipping, el BBox, la opacidad de relleno, el modo de blending, los soft masks, los colorantes que no pintan y el knockout de grupo aplican a la malla completada; los bytes de stream retenidos, la superficie temporal de página y dos filas de lattice se unen a la admisión de memoria de trabajo
El análisis de vértices, la rasterización de triángulos y las funciones comparten operaciones agregadas y sondeo de cancelación; los registros malformados o truncados y las filas de lattice incompletas fallan antes de la publicación de la salida
La aceptación enfocada comprueba ecuaciones baricéntricas cerradas y salida separada de MuPDF y Poppler; los registros de prueba mantienen separados los fallos de los lectores de origen para el padding de vértices, los bits de flag no usados y la transparencia de mallas, y usan ecuaciones alternativas explícitas de lectores para colores que no pintan y valores indexados normalizados
Mallas de parches Coons y tensoriales
ShadingTypes 6 y 7 pintan fronteras cúbicas de Coons y redes de control tensoriales, con reutilización de aristas precedentes, registros alineados a bytes, semántica de flags de dos bits bajos y las mismas precisiones de coordenadas y componentes que las mallas triangulares
Los componentes de esquina se interpolan bilinealmente en los parámetros del parche antes de las funciones opcionales y la conversión de color; las fronteras de Coons se elevan a una red de Bernstein bicúbica equivalente, cuyos bounds de segunda derivada seleccionan las subdivisiones con un error geométrico de como máximo 0,125 píxeles de salida
La inversión polinómica refina los parámetros de píxel; la cobertura plegada elige el mayor parámetro v y después el mayor parámetro u para un mismo v, mientras que los parches posteriores reemplazan los colores anteriores antes de que el shading completado reciba la transparencia del objeto
El compositor de mallas compartido aplica clipping, BBox, patrones de shading, colorantes que no pintan, opacidad, blending, soft masks y knockout de grupo; dos filas de subdivisión y los arrays de parámetro y orden por píxel se unen a la admisión activa de bytes de trabajo
El análisis de puntos de control, la subdivisión, la rasterización y las funciones de color comparten límites de operación y cancelación; la aceptación enfocada usa ecuaciones independientes de Coons y tensoriales y raíces cúbicas para los parches plegados, con los fallos de lectores de origen registrados por separado de la verificación ordinaria de páginas de ecuaciones RGB
Estado de texto heredado
Los streams hijos de Form, Type3 y patrón heredan el objeto de fuente aplicable, el tamaño de fuente, el espaciado de caracteres y de palabras, la escala horizontal, el leading, el modo de rendering y el rise de su estado gráfico inicial; un recurso hijo con el mismo nombre de fuente no reemplaza una fuente heredada hasta que un Tf local la selecciona
El estado gráfico guardado restaura los parámetros de texto, y los operadores TD y comilla doble retienen sus cambios de leading y espaciado para los streams hijos posteriores; cada hijo empieza con sus propias matrices de texto
Las apariencias de anotaciones independientes parten de los parámetros de texto por defecto sin retener el estado final de texto del contenido de página
El texto Type3 en modo de rendering 3 no aporta gráficos de glifos visibles; la prueba enfocada de texto anidado Type3 retiene por separado la desviación de parámetros por defecto de MuPDF respecto de las ecuaciones de estado heredado, mientras que Poppler sigue los parámetros heredados en esos fixtures
Patrones de tiling y shading
Los espacios de color de patrón soportan patrones de tiling con y sin color, TilingType 1–3, patrones de shading, PatternMatrix, BBox de celda, espaciado positivo o negativo, selección de patrón, restauración de estado guardado y pintado de relleno o trazo
Los patrones sin color obtienen sus componentes de un espacio de color base soportado y pueden pintar stencils de imagen; los cambios de color explícitos, las imágenes con color y los shadings directos dentro de una definición sin color son contenido PDF inválido y se rechazan también a través de Forms anidados y procedimientos Type3
Los patrones seleccionados retienen el espacio de coordenadas por defecto del stream de contenido que resolvió su definición; las operaciones cm posteriores y un patrón heredado usado dentro de un Form no reemplazan ese origen
Las definiciones parten del estado gráfico inicial soportado del padre y de los parámetros de transparencia por defecto; las definiciones de tiling forman un grupo no aislado y sin knockout, mientras que las definiciones de shading usan knockout de objeto
Las celdas de tiling transparentes y solapadas se evalúan contra el backdrop actual; el alpha y el modo de blending entrantes del objeto aplican una sola vez al pintar el patrón completado, incluidos los patrones anidados, el texto, los trazos y las máscaras de imagen
El ExtGState de patrones de shading aumenta los parámetros de shading soportados, incluidos la opacidad y los soft masks; Background se pinta antes del shading, BBox recorta ambas contribuciones y los colores None que no pintan no aportan ni color ni forma
La evaluación de patrones admite dos superficies de página y contenido de celda decodificado, acota la enumeración de celdas visibles al clip actual y sondea la cancelación mientras renderiza celdas y elimina la contribución del backdrop
Los fixtures enfocados comparan ecuaciones cerradas de coordenadas, color y composición con píxeles nativos y salida de lectores independientes; los ficheros de prueba retienen las diferencias de lectores para los orígenes de patrones de Form heredados, la opacidad ExtGState de patrones de shading y los colores None que no pintan, con páginas de ecuaciones vectoriales ordinarias separadas para esos casos
Fuentes CFF con clave CID
Las fuentes CIDFontType0 incrustadas resuelven CIDs reales de CFF en contenedores standalone y OpenType, incluidos los mapeos no identidad, el CID 65535, los CMaps Encoding incrustados, los orígenes verticales W2, los contornos transformados y el clipping de texto
Las caras CFF standalone cargan por CID y las caras envueltas en SFNT cargan por índice compacto de glifo; el bridge usa el layout correcto de caras FreeType para Linux LP64 y Windows LLP64
Un código de carácter sin mapear o un CID solicitado ausente consulta notdefchar y notdefrange para el código original y después usa el glifo obligatorio CID 0 si el reemplazo está ausente; los rangos tienen destinos CID constantes y las entradas de caracteres tienen precedencia, mientras que los glifos presentes retienen su CID solicitado
La aceptación enfocada usa contornos poligonales declarados y ecuaciones de origen para 28 orígenes válidos, con comparaciones separadas de MuPDF y Poppler y páginas ordinarias de ecuaciones RGB
Los ficheros de prueba retienen las diferencias de lectores de origen para la selección de glifos OpenType con clave CID y las sustituciones notdef omitidas; la alternativa de omisión se mide por separado y no reemplaza la ecuación nativa de origen obligatoria
Límites y cancelación
Las codificaciones Type0 integradas exactas cubren los 200 nombres de codificación incluidos: Identity-H e Identity-V, dieciséis mapeos UCS2 y UTF16, y 182 mapas adicionales heredados y Unicode con overrides verticales de caracteres aplanados
Los operandos mixtos de uno a cuatro bytes usan bounds de codespace por byte y recuperación de códigos inválidos de prefijo más largo; la decodificación UTF8 y UTF32 y la codificación inversa preservan los escalares suplementarios y los bytes de cero a la izquierda significativos
Los streams Encoding y ToUnicode resuelven los nombres o streams usecmap del cuerpo y UseCMap del diccionario, con precedencia del diccionario y overrides locales de caracteres, rangos, secuencias Unicode y notdef
Cada CMap hijo mantiene su propio modo de escritura, con el horizontal por defecto cuando se omite WMode; el modo vertical explícito selecciona los mapeos heredados y las métricas verticales de la fuente
La herencia de CMaps usa límites locales de hilo de profundidad anidada sin cambiar el layout de THPDFCMapBounds; los ciclos, los padres malformados y la profundidad excesiva fallan antes de la publicación de la salida, y los bloques finally restauran los límites tras la cancelación o las excepciones
La prueba enfocada retiene los fallos de origen UTF8 y UTF32 con nombre en un lector independiente sin esas tablas integradas, verifica compañeros separados de mapas incrustados y registra las diferencias de texto de origen cuando varios códigos seleccionan el mismo CID
Tests/Linux/Run-HeadlessLegacyCMapAcceptance.sh construye y prueba intervalos de codificación exactos, PDFs de origen de anchura mixta, rendering anidado, aislamiento de hilos y recuperación de cancelación en Linux nativo
Tests/Linux/Run-HeadlessLegacyCMapWindowsAcceptance.py ejecuta ejecutables nativos de Windows coincidentes, registra hashes de origen, binarios, PNG y diagnósticos y después transfiere capturas fijas al almacenamiento de Linux nativo para comprobaciones separadas de MuPDF y Poppler
Los mapas empaquetados preservan sus hashes de recursos y avisos completos de redistribución; mantén la licencia de datos CMap junto a las distribuciones de origen y binarias
Los escapes hexadecimales en valores de nombres PDF y operandos de nombres de contenido se decodifican una vez antes de resolver fuentes, espacios de color, modos de blending y recursos; un hash literal producido por la decodificación pasa a formar parte del nombre semántico
El decodificador de fuentes compartido aplica estas semánticas a los valores de diccionarios de fuentes, codificaciones con nombre, nombres de glifos Differences y CIDToGIDMap, sin modificar objetos prestados ni decodificar valores de cadena
Los nombres de renderer escapados usan decodificación lineal, admisión temporal de bytes de trabajo, límites agregados de operaciones y sondeo de cancelación; la aceptación enfocada compara bytes PNG nativos equivalentes y texto, más salida independiente de MuPDF y Poppler
El trabajo raster de shadings y las funciones de color comparten límites agregados de operaciones y sondeo de cancelación; la superficie temporal y una caché de coordenadas exactas de como máximo 8192 colores convertidos se unen a la admisión activa de bytes de trabajo
La aceptación enfocada de shadings usa ecuaciones cerradas de geometría/función/color y páginas vectoriales de ecuaciones separadas, reteniendo las diferencias de lectores de origen para el clipping de BBox, la geometría degenerada, la conversión de color, los nombres de colorantes especiales y la teselación knockout
Options acota los píxeles de superficie, los buffers gestionados activos, los bytes decodificados acumulados, los bytes PNG codificados, el trabajo de tokens y operadores y la profundidad recursiva y de estado gráfico
La decodificación de fuentes usa márgenes de admisión conservadores: 32 MiB de capacidad transitoria, 64 veces el tamaño decodificado del stream de fuente, 128 veces los slots de array comprobados recursivamente y dos veces la estimación del decodificador retenido en el agregado activo
Las tablas CID admiten 65 536 entradas retenidas; la enumeración acota los charstrings reales, y los arrays notdef se unen al deep-copy del decodificador y al cómputo de bytes retenidos
El análisis de CMaps y la búsqueda notdef comparten límites locales de hilo de entradas anidadas y sondeo de trabajo; los ámbitos del renderer comparten límites agregados de tokens y operaciones, y los escaneos léxicos largos sondean como máximo cada 256 bytes
El intérprete reserva además capacidad de secuencias Unicode por glifo a partir de los bytes de operandos de entrada y del mapeo ToUnicode más largo antes de crear los registros de glifos, de modo que los mapeos largos repetidos no puedan burlar la admisión de memoria de trabajo
Un presupuesto pequeño de memoria de trabajo puede rechazar una fuente simple aunque su asignación final cabría; estas comprobaciones cubren los buffers gestionados y las superficies de imagen de CPU, mientras que las cachés de Cairo, Fontconfig y FreeType y el RSS total del proceso quedan fuera del cómputo
Las superficies de transparencia, soft mask, backdrop, opacidad y knockout de objeto se unen al presupuesto activo de superficies; las funciones de transferencia comparten el presupuesto agregado de operaciones, los códecs ICC y de imagen usan admisión conservadora y el decodificador nativo JBIG2 acota de forma acumulativa la asignación de bitmaps/contextos y sondea la cancelación durante la decodificación
Los recorridos complementarios de CMY, negro y forma geométrica comparten los límites agregados de operaciones, decodificación y cancelación; los perfiles que usan el mismo stream resuelto comparten una transformación validada y una reserva activa de admisión hasta que el rendering de la página termine
Los streams de funciones retenidos, la evaluación de funciones y los registros de estado gráfico se unen a la admisión de bytes de trabajo; las funciones de tinta recursivas, la interpolación multidimensional y las instrucciones de cálculo comparten límites de operación y de cancelación
El token de cancelación prestado se sondea durante la decodificación acotada, la tokenización, los operadores, las llamadas al resolver de glifos, las filas de imagen, la recursión, la codificación PNG y antes de la publicación; su ciclo de vida es del llamador
El renderer comprueba el permiso de extracción mediante la política prestada del documento y retiene los valores de objetos de origen y los bytes de origen
Propiedad de la salida
HPDFRenderHeadlessPagePNG completa el rendering y la codificación PNG en privado antes de escribir en un stream propio del llamador; un fallo final de I/O del stream puede retener los bytes ya aceptados
HPDFRenderHeadlessPagePNGFile comprueba la identidad del origen, crea exclusivamente un fichero de staging en el directorio objetivo, lo vuelca, vuelve a comprobar identidad y cancelación y reemplaza atómicamente el destino
La publicación de Windows usa como máximo ocho intentos de reemplazo atómico y siete esperas de 1, 2, 4, 8, 16, 16 y 16 milisegundos, reintentando solo los errores de acceso denegado, violación de uso compartido y violación de bloqueo; la cancelación se comprueba antes de cada intento y a ambos lados de cada espera
Una publicación de Windows fallida informa del código de error final capturado de Windows mediante EHPDFHeadlessRenderError; la cancelación retiene el diagnóstico de cancelación del renderer, y ninguna de las dos rutas elimina el destino existente ni hace fallback a una copia no atómica
Los fallos de rendering, presupuesto, cancelación y staging preservan un destino existente y eliminan los ficheros de staging propios no publicados; los alias de ruta de origen y de hardlink se rechazan
Aceptación
La aceptación de runtime de Windows usa ejecutables nativos de consola coincidentes y una closure de import portátil de DLL aislada y fijada por SHA256; un proceso WSL separado ejecuta comprobaciones independientes de píxeles, ecuaciones y geometría de MuPDF y Poppler contra los ficheros PNG producidos por Windows
Los sustitutos de fuentes estándar de Windows usan caras GDI explícitas de Cairo para texto Unicode y contornos reales, incluidos el clipping y los modos fill-and-stroke; las fuentes incrustadas retienen su mapeo de glifos FreeType
Las llamadas a OpenJPEG usan el ABI stdcall de Windows y los exports decorados de Win32, mientras que los callbacks de stream y de mensajes retienen la convención de callbacks de C
Tests/Linux/Run-HeadlessCairoAcceptance.sh realiza builds ELF nativos frescos, limpia DISPLAY y WAYLAND_DISPLAY, rechaza las bibliotecas de escritorio enlazadas directamente y ejecuta oráculos independientes de pypdf/MuPDF
Los fixtures ejercitan las fuentes estándar, TrueType Unicode, Type3, todos los modos de rendering de texto y de blending, alpha y knockout, grupos de transparencia RGB, profundidades de muestras y Decode, máscaras de imagen y Matte, colores indexados e ICC, códecs terminales, cadenas de filtros cifradas con AES, geometría de página, transformaciones de anotaciones, presupuestos, cancelación, preservación del origen y salida atómica
Consulta THPDFHeadlessRenderResult para los contadores y EHPDFHeadlessRenderError para el manejo de errores