Renderer Cairo nativo do Linux

HPDFHeadlessCairoDevice renderiza uma página carregada de PDF para um PNG RGB usando superfícies de imagem Cairo e FreeType, sem servidor de exibição nem PDF reader

Forneça uma view emprestada serial de THPDFHeadlessDocument.GetRenderAccess(PageIndex) e mantenha aquele documento carregado e inalterado até o rendering retornar

Document := THPDFHeadlessDocument.Create;
try
  Document.LoadFromFile('input.pdf');
  Options := THPDFHeadlessRenderOptions.Default;
  Info := HPDFRenderHeadlessPagePNGFile(
    Document.GetRenderAccess(0), 'page.png', Options);
finally
  Document.Free;
end;

Dependências de runtime

O Linux nativo usa libcairo.so.2, libfreetype.so.6 e a dependência Fontconfig do provider de fontes padrão; instale fontes adequadas para substituição de Helvetica, Times e Courier

HOTPDF_CAIRO_LIBRARY e HOTPDF_FREETYPE_LIBRARY podem selecionar paths explícitos de bibliotecas compatíveis antes do primeiro render; módulos bem-sucedidos permanecem carregados porque os caches nativos de fontes podem reter callbacks de destruição

O host precisa manter o executável, a DLL ou o código de pacote HotPDF dele carregado enquanto aqueles caches nativos puderem reter callbacks de destruição de fontes do HotPDF; descarregar um módulo do host independentemente do tempo de vida do cache fica fora deste perfil

O Windows usa libcairo-2.dll e libfreetype-6.dll compatíveis através da mesma ponte; os binários de runtime e o licensing deles são fornecidos pela aplicação

Cores ICCBased carregam adicionalmente liblcms2.so.2; JPEG usa libturbojpeg.so.0, e JPEG 2000 usa um libopenjp2.so.7 compatível com OpenJPEG 2.5; essas dependências são carregadas apenas para as entradas correspondentes

HOTPDF_LCMS_LIBRARY, HOTPDF_TURBOJPEG_LIBRARY e HOTPDF_OPENJPEG_LIBRARY sobrepõem aqueles paths; os defaults do Windows são lcms2.dll, turbojpeg.dll e openjp2.dll

Perfil de rendering

O conteúdo suportado inclui construção e pintura de paths, regras de fill nonzero e even-odd, clipping, graphics state aninhado, transforms CTM, estilo de linhas, cores DeviceGray/RGB/CMYK, alfa normal e Form XObjects repetidos com recursos, Matrix e BBox próprios

Larguras de linhas podem ser zero: hairlines PDF solicitadas por 0 w ou ExtGState LW=0 usam um stroke de um pixel em device space; larguras negativas são rejeitadas

ExtGState D e o operador d de content streams compartilham a validação delimitada de dashes: patterns vazios sólidos, repetição de comprimento ímpar, entradas de comprimento zero, comprimentos fracionários e fases com sinal são suportados

Um dash pattern admite no máximo 256 comprimentos finitos não negativos até 1e9, com pelo menos um comprimento positivo quando não vazio e uma fase finita de valor absoluto de no máximo 1e9; cada elemento consome trabalho de operações e o armazenamento temporário entra na admissão de working bytes

Arrays de operands aceitam comentários PDF, incluindo arrays numéricos de dashes e arrays de texto TJ; valores lexicais malformados e colchetes de fechamento ausentes são retidos pelo scanner compartilhado e rejeitados pelo renderer, em vez de desaparecerem silenciosamente

Texto horizontal usa o interpretador compartilhado de glyphs para text matrices, widths explícitos do PDF, advances canônicos de Helvetica/Times/Courier, character e word spacing, escala horizontal e ajustes TJ

Programs de fontes embutidas suportadas usam FreeType com glyph IDs resolvidos; os mapeamentos ToUnicode Unicode permanecem disponíveis pela API de texto do documento, enquanto as formas raster de fontes padrão dependem de substitutos instalados

Texto composto suporta Identity-H, Identity-V, streams CMap explícitos de encodings embutidos e os mapeamentos horizontais e verticais internos UniJIS, UniGB, UniCNS e UniKS UCS2/UTF16; recursos CMap instalados separadamente não são exigidos

A pintura vertical de glyphs honra os vetores de posicionamento default e explícitos DW2/W2, text rise, escala horizontal, matrizes de texto e gráficos, e o deslocamento TJ; mapeamentos UTF-16 aceitam códigos de caracteres suplementares

Todos os oito rendering modes de texto são suportados, incluindo contornos verticais fill/stroke/invisível acumulados no clip em ET; streams CMap de encodings embutidos retêm o WMode deles e os mapeamentos não identidade de CIDs

Operações transparentes combinadas de fill e stroke usam composição knockout por objeto, de modo que o fill sobreposto não vaze através do stroke; procedures de glyphs Type3 executam os recursos e matrizes de fontes delimitados delas

Imagens aceitam samples de 1/2/4/8/16 bits e arrays Decode, stencil, máscaras explícitas, color-key e soft, máscaras de tamanhos diferentes e recuperação de Matte; Interpolate ausente usa amostragem nearest-neighbor e true seleciona amostragem bilinear

Codestreams JPX aceitam componentes de origem com ou sem sinal até 26 bits, incluindo precisão mista, subsampling e opacidade explícita, e normalizam em samples delimitadas de 8 ou 16 bits; o BitsPerComponent do dicionário da imagem e entradas Decode não stencil são ignorados para imagens JPX, como exigido pelo perfil de imagens do PDF

Palettes Indexed e transforms validadas de profiles ICCBased para sRGB são suportadas para imagens e cores de paths; DeviceCMYK sem profile retém a conversão simples de dispositivo

Transforms ICCBased aceitam assinaturas de profiles Gray, RGB, CMYK, Lab e XYZ e validam estritamente a contagem declarada de componentes e as faixas de componentes

Operands de profiles Lab usam coordenadas físicas L a b com faixas default [0 100 -128 127 -128 127]; operands XYZ usam coordenadas físicas X Y Z com uma faixa default sem sinal de 1.15 [0 65535/32768] por componente

Entradas de profiles XYZ são uma extensão nativa de compatibilidade e não implicam conformidade de PDFs de arquivamento; profiles de origem Lab e XYZ não selecionam um blending space suportado de transparências

O Range de um stream ICC exige dois valores finitos ordenados por componente e delimita os operands de cores; os defaults Decode de imagens raw e os valores de lookup Indexed usam aquelas faixas de componentes

CalGray, CalRGB e Lab suportam paths, texto, imagens e bases Indexed; parameters são estritamente validados, entradas da Matrix CalRGB seguem a ordenação de colunas do PDF, e componentes Lab e os defaults Decode de imagens usam as faixas declaradas

Cores CIE usam adaptação cromática Bradford e saída sRGB relativa; metadados BlackPoint são validados, enquanto compensação adicional de black point e políticas de estado de rendering intents permanecem extensões separadas

Cores compostas Separation e DeviceN retêm um a trinta e dois componentes de tint para paths, texto, bases Indexed e imagens empacotadas; cores alternativas de dispositivo ou CIE usam funções delimitadas de tint sampled, exponencial, stitching ou calculator

Origens alternativas de cores ICCBased Lab/XYZ e CalGray/CalRGB/Lab retêm as coordenadas físicas delas através do transform de tint antes da conversão para um transparency group suportado

Funções de tint amostradas multidimensionais suportam interpolação linear e cúbica, Domain, Encode, Decode, Range de saída e profundidades empacotadas de samples até 32 bits; a avaliação cúbica estende a convenção existente escalar de quatro nós por produtos tensoriais, com fallback linear para dimensões curtas e trabalho e cancelamento delimitados

Veja Funções de cores amostradas nativas para as convenções de interpolação e as evidências separadas de fórmulas e readers

Espaços Separation None e DeviceN contendo apenas colorants None não contribuem com cor nem forma de knockout; componentes None mistos ainda chegam ao transform alternativo de tint

Separation All aplica o tint dele a todo colorant de saída disponível, usando saída de páginas RGB neutra e preservando cada componente de processo dentro de grupos CMYK

Grupos CMYK recebem os valores alternativos originais de tint de quatro componentes antes do blending; plates de spot separations, seleção NChannel de process/colorants e simulação de mixing hints permanecem extensões separadas

O callback terminal de imagens preserva a descriptografia do documento e os filters precedentes de streams antes da decodificação nativa de JPEG, JPEG 2000, CCITT ou JBIG2; JBIG2 suporta texto aritmético e Huffman, MMR e dicionários globais compartilhados

JPEG 2000 suporta componentes subsampled e com sinal, declarações inferidas de cores e samples, profiles ICC embutidos, overrides explícitos de color spaces e opacidade separada ou associada através de SMaskInData; os valores dos componentes dele são normalizados para oito ou dezesseis bits e o array Decode da imagem dele é ignorado

Profiles Lab/XYZ ICC embutidos ou explícitos usam faixas físicas de componentes; a opacidade associada é removida das samples armazenadas normalizadas antes de aplicar o mapeamento de coordenadas físicas, preservando os canais de offset do Lab

Graphics state SMask suporta grupos Alpha e Luminosity, cores de backdrop, matrizes de Forms, restauração de estados salvos e funções de transferência delimitadas sampled, exponencial, stitching e calculator; a soft mask própria de uma imagem sobrepõe a soft mask do graphics state

Todos os dezesseis blend modes padrão do PDF são suportados; grupos de Forms e páginas suportam composição isolated e nonisolated, knockout por objeto, e blending spaces DeviceGray, DeviceRGB, DeviceCMYK, CalGray, CalRGB ou ICCBased de um, três e quatro componentes

Grupos calibrados retêm os valores nativos de componentes até uma fronteira de grupo e aceitam cores de origem de dispositivo ou Lab através de transforms calibrados inversos; o Lab em si não é um blending space válido

Máscaras Luminosity calibradas retêm as coordenadas do grupo delas e avaliam CIE XYZ-Y, incluindo a opacidade do grupo e as cores de backdrop, antes de aplicar a função de transferência

A composição knockout mantém a forma geométrica do objeto separada da opacidade da soft mask; buracos de stencils preservam os objetos precedentes, enquanto um path mascarado os substitui por toda a geometria pintada dele

Grupos knockout aninhados retêm a união das formas geométricas dos filhos deles, incluindo objetos de opacidade zero; grupos filhos nonisolated usam o backdrop inicial do grupo knockout que os contém

Grupos CMYK preservam os componentes complementares CMY e preto em planos de imagens delimitados separados e convertem o resultado combinado nas fronteiras do grupo; blend modes não separáveis retêm ou substituem o preto conforme o modo selecionado

Grupos nonisolated renderizam uma passada adicional delimitada de opacidade, removem a contribuição do backdrop inicial e aplicam o alfa e o blend mode do grupo de entrada uma vez; transparency groups de páginas usam uma superfície isolada antes de compor sobre o fundo da página

Um Form nonisolated herda o blending space que o contém; uma entrada CS explícita de grupo não troca o backdrop inicial para outro espaço

Aparências normais existentes de anotações são ajustadas do BBox transformado delas para o Rect; RenderAnnotations=false omite aparências em qualquer uso

Usage tem default hruView, que pula anotações Hidden e NoView e tipos desconhecidos de anotações com Invisible definido; tipos padrão ISO 32000 de anotações, incluindo RichMedia e Projection do PDF 2.0, com aparências normais suportadas permanecem visíveis quando apenas Invisible está definido

A aceitação de RichMedia e Projection cobre aparências normais estáticas existentes com assets de mídia válidos ou uma view 3D default associada; reprodução de mídia e ativação 3D interativa ficam fora deste path raster

hruPrint pinta apenas anotações com Print definido e Hidden limpo; Invisible suprime tipos desconhecidos de anotações em qualquer uso, NoView não suprime a impressão, e NoZoom não muda o tamanho de aparências impressas

Quando uma aparência normal está ausente, os metadados suportados de anotações são renderizados através de uma aparência temporária; veja o fallback nativo de anotações para geometria, FreeText Unicode, ícones estáticos e fronteiras restantes

Para saída de view, o NoZoom de anotações remove a escala de render do tamanho das aparências preservando UserUnit; NoRotate mantém a aparência ajustada na posição vertical através da rotação de páginas em qualquer uso, e ambos preservam a âncora transformada Rect de canto superior esquerdo e o clip da página

Text annotations com aparências normais existentes se comportam como NoZoom e NoRotate na saída de view, independentemente das flags explícitas delas; a saída de print retém o comportamento NoRotate delas ignorando NoZoom

Usage controla a visibilidade estática do raster e a geometria de anotações; flags apenas de interação não criam comportamento de hover nem edição, e o callback existente de permissão de extração permanece exigido sem conceder permissão de impressão

Optional content na saída estática

O rendering consome a configuração default OCProperties/D do catalog, inicializa os estados dos grupos a partir de BaseState, aplica os overrides ON e OFF, e usa valores correspondentes de Intent ao determinar a visibilidade

Dicionários de participação suportam AnyOn, AllOn, AnyOff e AllOff; expressões VE recursivas suportam And, Or e Not de operando único, com VE tendo precedência sobre a política mais simples

Referências de grupos null, indisponíveis e velhas não têm efeito de participação; grupos fora dos intents da configuração não controlam a visibilidade, e uma participação ou expressão sem grupos aplicáveis deixa o conteúdo visível

Marked content aninhado /OC, image e Form XObjects e anotações respeitam o estado resultante; seções marcadas ocultas ainda atualizam cores, matrizes, clipping e posição de texto, enquanto XObjects e anotações totalmente ocultos podem ser pulados

Dicionários comuns de propriedades de marked content permanecem utilizáveis, incluindo valores inline aninhados; arrays de conteúdo preservam o estado de marked content entre os streams componentes deles, e streams filhos mantêm o aninhamento próprio de marked content deles

Rasterização standalone de final-form usa a configuração default nos modos view e print sem aplicar automaticamente as recomendações interativas de uso AS, conforme a seção 8.11.4.5 da ISO 32000-1:2008; o ViewerState explícito habilita recomendações View, Print, Export, Zoom, Language e User, com seleção manual persistente e estado temporário de eventos

Propriedades ausentes de optional content ou um catalog emprestado nil deixam as estruturas de optional content sem efeito de visibilidade; participações vivas malformadas, ciclos de expressões e os limites configurados de trabalho, memória ou recursão falham antes da publicação do PNG

Matrizes afins de aparências e origens BBox não nulas retêm o ajuste normal delas sob essas flags; uma escala de render extremamente pequena ainda pode tornar a matriz inicial de páginas do Cairo numericamente não invertível

A página renderizada usa a interseção MediaBox/CropBox, page boxes herdados e Rotate de quarto de volta, e o UserUnit da página; escala 1 produz um pixel por ponto efetivo de página, com dimensões da superfície arredondadas para cima

O operador sh pinta shadings baseados em funções, axiais e radiais (ShadingTypes 1–3), com domínios de duas entradas, matrizes de shadings, seleção de círculos radiais, endpoints Extend, BBox e clips de paths existentes

Funções de cores suportadas e arrays de funções escalares convertem através de cores de origem de dispositivo, calibradas, ICC Lab/XYZ e Separation/DeviceN; a opacidade atual de fills, blend modes, soft masks do graphics state e knockout de transparency groups se aplicam ao shading resultante

O path e a cor atuais são preservados; o Background de shadings é ignorado por sh, e AntiAlias é uma dica de dispositivo com amostragem de cor no centro de pixels

Entradas não suportadas de ExtGState e operadores de conteúdo não suportados permanecem fora deste perfil

Shadings de mesh de triângulos

ShadingTypes 4 e 5 pintam meshes de triângulos Gouraud free-form e lattice com reutilização de edges, geometria arbitrária de lattice, records de vértices alinhados a bytes, precisão de coordenadas até 32 bits e precisão de componentes até 16 bits

Componentes de vértices interpolam nos centros de pixels do dispositivo antes da conversão de cores; uma função opcional de uma entrada ou array de funções de componentes avalia o parameter interpolado, incluindo color spaces calibrados, ICC e especiais

Origens Indexed arredondam os índices interpolados para a entrada de paleta mais próxima; strings de lookup hexadecimais decodificam uma vez com whitespace, dígitos de capitalização mista e padding de nibble final ímpar, enquanto strings de lookup literais retêm os bytes decodificados delas

Transforms atuais, clipping, BBox, opacidade de fills, blend mode, soft masks, colorants não pintantes e knockout de grupos se aplicam ao mesh concluído; bytes retidos de streams, a superfície temporária de páginas e duas linhas de lattice entram na admissão de memória de trabalho

Parsing de vértices, rasterização de triângulos e funções compartilham operações agregadas e polling de cancelamento; records malformados ou truncados e linhas de lattice incompletas falham antes da publicação da saída

A aceitação focada checa equações fechadas de coordenadas baricêntricas e saídas separadas de MuPDF e Poppler; records de provas mantêm as falhas de readers da origem separadas para padding de vértices, bits de flags não usados e transparência de meshes, e usam equações alternativas explícitas de readers para cores não pintantes e valores Indexed normalizados

Meshes de patches Coons e tensoriais

ShadingTypes 6 e 7 pintam fronteiras cúbicas Coons e control nets tensoriais, com reutilização de edges precedentes, records alinhados a bytes, semântica de flags de dois bits baixos e as mesmas precisões de coordenadas e componentes dos meshes de triângulos

Componentes de corners interpolam bilinearmente nos parameters de patches antes das funções opcionais e da conversão de cores; fronteiras Coons são elevadas a uma Bernstein net bicúbica equivalente, cujos bounds de derivadas segundas selecionam subdivisões com erro geométrico de no máximo 0.125 pixel de saída

A inversão polinomial refina os parameters de pixels; a cobertura dobrada escolhe o maior parameter v e depois o maior u para v iguais, enquanto patches posteriores substituem cores anteriores antes de o shading concluído receber a transparência do objeto

O compositor compartilhado de meshes aplica clipping, BBox, shading patterns, colorants não pintantes, opacidade, blending, soft masks e knockout de grupos; duas linhas de subdivisão e arrays por pixel de parameters e ordem entram na admissão ativa de working bytes

Parsing de control points, subdivisão, rasterização e funções de cores compartilham limites de operações e cancelamento; a aceitação focada usa equações independentes de Coons e tensoriais e raízes cúbicas para patches dobrados, com falhas de readers da origem registradas separadamente da verificação comum de páginas de equações RGB

Estado de texto herdado

Streams filhos de Forms, Type3 e patterns herdam o objeto de fonte aplicável, tamanho da fonte, character spacing, word spacing, escala horizontal, leading, rendering mode e rise do graphics state inicial deles; um recurso filho com o mesmo nome de fonte não substitui uma fonte herdada até um Tf local selecioná-la

Graphics state salvo restaura os parameters de texto, e os operadores TD e aspas duplas retêm as mudanças deles de leading e spacing para streams filhos subsequentes; cada filho começa com as próprias text matrices dele

Aparências independentes de anotações começam de parameters default de texto sem reter o estado final de texto do conteúdo da página

Texto Type3 no rendering mode 3 não contribui com gráficos visíveis de glyphs; a prova focada de texto Type3 aninhado retém separadamente o desvio de parameters default do MuPDF em relação às equações de estado herdado, enquanto o Poppler segue os parameters herdados naqueles fixtures

Patterns de tiling e shadings

Color spaces de patterns suportam tiling patterns colored e uncolored, TilingType 1–3, shading patterns, PatternMatrix, BBox de células, espaçamento positivo ou negativo, seleção de patterns, restauração de estados salvos e pintura de fill ou stroke

Patterns uncolored obtêm os componentes deles de um color space base suportado e podem pintar stencils de imagens; mudanças explícitas de cores, imagens colored e shadings diretos dentro de uma definição uncolored são conteúdo PDF inválido e são rejeitados também através de Forms aninhadas e procedures Type3

Patterns selecionados retêm o coordinate space default do content stream que resolveu a definição deles; operações cm posteriores e um pattern herdado usado dentro de uma Form não substituem aquela origem

Definições começam com o graphics state inicial suportado do pai e os parameters default de transparências; definições de tiling formam um grupo nonisolated não knockout, enquanto definições de shadings usam knockout por objeto

Células de tiling transparentes e sobrepostas são avaliadas contra o backdrop atual; o alfa e o blend mode de objetos de entrada se aplicam uma vez ao pintar o pattern concluído, incluindo patterns aninhados, texto, strokes e image masks

O ExtGState de shading patterns aumenta os parameters suportados de shadings, incluindo opacidade e soft masks; Background é pintado antes do shading, BBox clipa ambas as contribuições, e cores None não pintantes não contribuem com cor nem forma

A avaliação de patterns admite duas superfícies de páginas e o conteúdo decodificado de células, delimita a enumeração de células visíveis ao clip atual, e faz polling do cancelamento enquanto renderiza células e remove a contribuição do backdrop

Fixtures focados comparam equações fechadas de coordenadas, cores e composição com pixels nativos e saída de readers independentes; arquivos de provas retêm as diferenças de readers para origens herdadas de patterns de Forms, opacidade de ExtGState de shading patterns e cores None não pintantes, com páginas separadas comuns de equações vetoriais para aqueles casos

Fontes CFF indexadas por CID

Fontes CIDFontType0 embutidas resolvem CIDs CFF reais em containers standalone e OpenType, incluindo mapeamentos não identidade, CID 65535, CMaps Encoding embutidos, origens W2 verticais, contornos transformados e clipping de texto

Faces CFF standalone carregam por CID, e faces embrulhadas em SFNT carregam por índice compacto de glyphs; a ponte usa o layout correto de faces FreeType para Linux LP64 e Windows LLP64

Um código de caractere não mapeado ou um CID solicitado ausente consulta notdefchar e notdefrange para o código original, e depois usa o glyph obrigatório CID 0 se a substituição estiver ausente; faixas têm alvos constantes de CIDs, entradas de caracteres têm precedência, e glyphs presentes retêm o CID solicitado deles

A aceitação focada usa contornos declarados de polígonos e equações de origens para 28 origens válidas, com comparações separadas de MuPDF e Poppler e páginas comuns de equações RGB

Arquivos de provas retêm as diferenças de readers da origem para seleção de glyphs OpenType indexados por CID e substituições notdef omitidas; a alternativa de omissão é medida separadamente e não substitui a equação nativa exigida de origens

Limites e cancelamento

Encodings internos exatos Type0 cobrem todos os 200 nomes de encodings embarcados: Identity-H e Identity-V, dezesseis mapeamentos UCS2 e UTF16, e 182 mapas adicionais legados e Unicode com overrides verticais achatados de caracteres

Operands mistos de um a quatro bytes usam bounds de codespace por byte e recuperação de códigos inválidos de prefixo mais longo; a decodificação UTF8 e UTF32 e a codificação reversa preservam scalars suplementares e bytes de zeros iniciais significativos

Streams de Encoding e ToUnicode resolvem nomes ou streams de usecmap de corpo e UseCMap de dicionários, com precedência de dicionários e overrides locais de caracteres, faixas, sequências Unicode e notdef

Cada CMap filho mantém o próprio writing mode dele, com default horizontal quando WMode é omitido; o modo vertical explícito seleciona mapeamentos herdados e as métricas verticais da fonte

A herança de CMaps usa limites locais à thread de profundidade aninhada sem mudar o layout de THPDFCMapBounds; ciclos, pais malformados e profundidade excessiva falham antes da publicação da saída, e blocos finally restauram os limites após cancelamento ou exceções

A prova focada retém as falhas de origem nomeadas UTF8 e UTF32 num reader independente sem aquelas tabelas built-in, verifica companions separados de mapas embutidos, e registra diferenças de texto da origem quando múltiplos códigos selecionam o mesmo CID

Tests/Linux/Run-HeadlessLegacyCMapAcceptance.sh compila e testa intervalos exatos de encodings, PDFs de origem de larguras mistas, rendering aninhado, isolamento de threads e recuperação de cancelamento no Linux nativo

Tests/Linux/Run-HeadlessLegacyCMapWindowsAcceptance.py executa executáveis nativos correspondentes do Windows, registra hashes de origem, binários, PNGs e diagnósticos, e depois transfere capturas fixas para o armazenamento do Linux nativo para checagens separadas de MuPDF e Poppler

Os mapas empacotados preservam os hashes de recursos e os avisos completos de redistribuição deles; mantenha a licença dos dados CMap junto das distribuições de código-fonte e binárias

Escapes hexadecimais em valores de PDF names e operands de nomes de conteúdo decodificam uma vez antes de resolver fontes, color spaces, blend modes e recursos; um hash literal produzido pela decodificação permanece parte do nome semântico

O decoder compartilhado de fontes aplica essas semânticas a valores de dicionários de fontes, encodings nomeados, nomes de glyphs Differences e CIDToGIDMap, sem modificar objetos emprestados nem decodificar valores de strings

Nomes escapados de renderers usam decodificação linear, admissão temporária de working bytes, limites agregados de operações e polling de cancelamento; a aceitação focada compara bytes equivalentes nativos de PNGs e texto mais a saída independente de MuPDF e Poppler

O trabalho raster de shadings e as funções de cores compartilham limites agregados de operações e polling de cancelamento; a superfície temporária e um cache de coordenadas exatas de no máximo 8.192 cores convertidas entram na admissão ativa de working bytes

A aceitação focada de shadings usa equações fechadas de geometria/funções/cores e páginas separadas de equações vetoriais, retendo as diferenças de readers da origem para clipping de BBox, geometria degenerada, conversão de cores, nomes especiais de colorants e tesselação de knockouts

Opções delimitam pixels da superfície, buffers gerenciados ativos, bytes decodificados cumulativos, bytes PNG codificados, trabalho de tokens e operadores, e profundidade recursiva ou de graphics state

A decodificação de fontes usa cotas conservadoras de admissão: 32 MiB de capacidade transitória, 64 vezes o tamanho do stream de fonte decodificado, 128 vezes os slots de arrays checados recursivamente, e o dobro da estimativa retida pelo decoder no agregado ativo

Tabelas CID admitem 65.536 entradas retidas; a enumeração delimita os charstrings reais, e arrays notdef entram na contabilidade de deep-copy do decoder e de bytes retidos

O parsing de CMaps e o lookup notdef compartilham bounds locais à thread e aninhados de entradas e polling de trabalho; escopos de renderers compartilham limites agregados de tokens e operações, e scans lexicais longos fazem polling no máximo a cada 256 bytes

O interpretador também reserva capacidade de sequências Unicode por glyph a partir dos bytes de operands de entrada e do mapeamento ToUnicode mais longo antes de criar records de glyphs, de modo que mapeamentos longos repetidos não consigam burlar a admissão de memória de trabalho

Um orçamento pequeno de memória de trabalho pode rejeitar uma fonte simples mesmo quando a alocação eventual dela caberia; essas checagens cobrem buffers gerenciados e superfícies de imagens por CPU, enquanto os caches Cairo, Fontconfig e FreeType e o RSS total do processo ficam fora da contabilidade

Superfícies de transparências, soft masks, backdrops, opacidade e knockout por objeto entram no orçamento ativo de superfícies; funções de transferência compartilham o orçamento agregado de operações, codecs ICC e de imagens usam admissão conservadora, e o decoder nativo JBIG2 delimita cumulativamente a alocação de bitmaps/contextos e faz polling do cancelamento durante a decodificação

Traversals complementares de CMY, preto e formas geométricas compartilham os limites agregados de operações, decodificação e cancelamento; profiles usando o mesmo stream resolvido compartilham um transform validado e uma reserva ativa de admissão até o rendering da página terminar

Streams retidos de funções, avaliação de funções e records de graphics state entram na admissão de working bytes; funções de tint recursivas, interpolação multidimensional e instruções calculator compartilham os limites de operações e cancelamento

O token de cancelamento emprestado é polled durante decodificação delimitada, tokenização, operadores, chamadas de resolvers de glyphs, linhas de imagens, recursão, encoding PNG e antes da publicação; o chamador é dono do tempo de vida dele

O renderer checa a permissão de extração pela política emprestada do documento e retém os valores dos objetos da origem e os bytes da origem

Posse da saída

HPDFRenderHeadlessPagePNG conclui o rendering e o encoding PNG privadamente antes de gravar num stream de posse do chamador; uma falha final de I/O no stream pode reter bytes já aceitos

HPDFRenderHeadlessPagePNGFile checa a identidade da origem, cria exclusivamente um arquivo de staging no diretório alvo, faz flush dele, checa de novo a identidade e o cancelamento, e substitui atomicamente o destino

A publicação no Windows usa no máximo oito tentativas de substituição atômica e sete esperas de 1, 2, 4, 8, 16, 16 e 16 milissegundos, retentando apenas erros de access denied, sharing violation e lock violation; o cancelamento é checado antes de cada tentativa e nos dois lados de cada espera

Publicação no Windows com falha reporta o código final capturado de erro Windows através de EHPDFHeadlessRenderError; o cancelamento retém o diagnóstico de cancelamento do renderer, e nenhum dos caminhos apaga o destino existente nem cai para cópia não atômica

Falhas de rendering, orçamento, cancelamento e staging preservam um destino existente e removem arquivos de staging próprios não publicados; aliases de paths da origem e de hardlinks são rejeitados

Aceitação

A aceitação de runtime do Windows usa executáveis nativos correspondentes de console e uma closure de imports de DLLs portáteis isolada e fixada por SHA256; um processo WSL separado roda checagens independentes de pixels, equações e geometria de MuPDF e Poppler contra os arquivos PNG produzidos no Windows

Substitutos de fontes padrão no Windows usam faces GDI explícitas Cairo para texto Unicode e contornos reais, incluindo clipping e modos fill-and-stroke; fontes embutidas retêm o mapeamento de glyphs FreeType delas

Chamadas OpenJPEG usam a ABI stdcall do Windows e exports decorados Win32, enquanto callbacks de streams e mensagens retêm a convenção C de callbacks

Tests/Linux/Run-HeadlessCairoAcceptance.sh executa builds ELF nativos frescos, limpa DISPLAY e WAYLAND_DISPLAY, rejeita bibliotecas de desktop diretamente linkadas, e roda oráculos independentes pypdf/MuPDF

Os fixtures exercitam fontes padrão, TrueType Unicode, Type3, todos os rendering modes e blend modes de texto, alfa e knockout, transparency groups RGB, profundidades de samples e Decode, image masks e Matte, cores Indexed e ICC, codecs terminais, cadeias de filters AES-criptografadas, geometria de páginas, transforms de anotações, orçamentos, cancelamento, preservação da origem e saída atômica

Veja THPDFHeadlessRenderResult para os contadores e EHPDFHeadlessRenderError para o tratamento de erros