Renderer Cairo nativo para Linux

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

Forneça uma vista emprestada em série de THPDFHeadlessDocument.GetRenderAccess(PageIndex) e mantenha esse documento carregado e inalterado até a renderização devolver

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

Linux nativo usa libcairo.so.2, libfreetype.so.6 e a dependência Fontconfig do fornecedor de tipos de letra standard; instale tipos de letra adequados para a substituição de Helvetica, Times e Courier

HOTPDF_CAIRO_LIBRARY e HOTPDF_FREETYPE_LIBRARY podem selecionar caminhos explícitos compatíveis de bibliotecas antes da primeira renderização; módulos bem-sucedidos permanecem carregados porque as caches nativas de tipos de letra podem reter callbacks de destruição

O host tem de manter o executável, a DLL ou o código de pacote HotPDF dele carregado enquanto essas caches nativas puderem reter callbacks de destruição de tipos de letra do HotPDF; descarregar um módulo do host independentemente do tempo de vida da cache está fora deste perfil

Windows usa libcairo-2.dll e libfreetype-6.dll compatíveis através da mesma ponte; os binários de runtime e as licenças 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; estas dependências são carregadas apenas para entradas correspondentes

HOTPDF_LCMS_LIBRARY, HOTPDF_TURBOJPEG_LIBRARY e HOTPDF_OPENJPEG_LIBRARY sobrepõem esses caminhos; os defaults de Windows são lcms2.dll, turbojpeg.dll e openjp2.dll

Perfil de renderização

O conteúdo suportado inclui construção e pintura de caminhos, regras de preenchimento nonzero e even-odd, clipping, estado de gráficos aninhado, transforms CTM, estilo de linhas, cores DeviceGray/RGB/CMYK, alfa normal e Form XObjects repetidos com os recursos, Matrix e BBox próprios deles

As larguras de linhas podem ser zero: hairlines PDF pedidas por 0 w ou por ExtGState LW=0 usam um stroke de um píxel em espaço de dispositivo; larguras negativas são rejeitadas

ExtGState D e o operador d de streams de conteúdo partilham validação delimitada de traços: padrões vazios sólidos, repetição de comprimento ímpar, entradas de comprimento zero, comprimentos fracionários e fases com sinal são suportados

Um padrão de traços 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 no máximo 1e9; cada elemento consome trabalho de operações e o armazenamento temporário participa na admissão de bytes de trabalho

Arrays de operandos aceitam comentários PDF, incluindo arrays numéricos de traços e arrays de texto TJ; valores lexicais malformados e parênteses retos de fecho em falta são retidos pelo scanner partilhado e rejeitados pelo renderer em vez de desaparecerem em silêncio

Texto horizontal usa o intérprete partilhado de glyphs para matrizes de texto, larguras PDF explícitas, avanços canónicos de Helvetica/Times/Courier, espaçamento de carateres e de palavras, escala horizontal e ajustes TJ

Programas suportados incorporados de tipos de letra usam FreeType com IDs de glyphs resolvidos; os mapeamentos ToUnicode Unicode permanecem disponíveis através da API de texto de documentos, enquanto as formas raster de tipos de letra standard dependem de substitutos instalados

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

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

Todos os oito modos de renderização de texto são suportados, incluindo contornos verticais fill/stroke/invisíveis acumulados no clip em ET; streams CMap de encodings incorporados mantêm o WMode delas e os mapeamentos não identidade de CIDs delas

Operações transparentes combinadas de fill e stroke usam composição knockout de objetos para que o fill sobreposto não atravesse o stroke; procedimentos de glyphs Type3 executam os recursos e matrizes de tipos de letra delimitados próprios deles

Imagens aceitam amostras de 1/2/4/8/16 bits e arrays Decode, stencil, máscaras explícitas, de color-key e soft, máscaras de tamanhos diferentes e recuperação de Matte; um Interpolate em falta usa amostragem de vizinho mais próximo e true seleciona amostragem bilinear

Codestreams JPX aceitam componentes de fontes com sinal ou sem sinal até 26 bits, incluindo precisão mista, subsampling e opacidade explícita, e normalizam para amostras delimitadas de 8 ou 16 bits; o BitsPerComponent do dicionário de imagens e as entradas Decode que não sejam de stencil são ignorados para imagens JPX, como exige o perfil de imagens PDF

Paletas Indexed e transforms validadas de perfis ICCBased para sRGB são suportadas para imagens e cores de caminhos; DeviceCMYK sem perfil mantém a conversão simples de dispositivos

Transforms ICCBased aceitam assinaturas de perfis Gray, RGB, CMYK, Lab e XYZ e validam estritamente a contagem declarada de componentes e os intervalos de componentes

Operandos de perfis Lab usam coordenadas físicas L a b com intervalos por defeito [0 100 -128 127 -128 127]; operandos XYZ usam coordenadas físicas X Y Z com um intervalo por defeito sem sinal de 1.15 [0 65535/32768] por componente

Entradas de perfis XYZ são uma extensão nativa de compatibilidade e não implicam conformidade de PDFs de arquivo; perfis fonte Lab e XYZ não selecionam um espaço de mistura de transparências suportado

O Range de uma stream ICC exige dois valores finitos ordenados por componente e delimita operandos de cores; os defaults de Decode de imagens em bruto e os valores de consulta Indexed usam esses intervalos de componentes

CalGray, CalRGB e Lab suportam caminhos, texto, imagens e bases de paletas Indexed; os parâmetros são estritamente validados, as entradas de Matrix de CalRGB seguem a ordenação de colunas PDF, e as componentes Lab e os defaults de Decode de imagens usam os intervalos declarados

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

Cores compostas Separation e DeviceN retêm entre uma e trinta e duas componentes de tint para caminhos, texto, bases Indexed e imagens empacotadas; cores alternantes de dispositivos ou CIE usam funções de tint delimitadas amostradas, exponenciais, de costura ou de calculadora

Fontes alternantes de cores ICCBased Lab/XYZ e CalGray/CalRGB/Lab mantê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 multidimensionais amostradas suportam interpolação linear e cúbica, Domain, Encode, Decode, Range de saída e profundidades empacotadas de amostras 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 as funções nativas de cor amostrada para as convenções de interpolação e a evidência separada de fórmulas e de leitores

Espaços Separation None e DeviceN contendo apenas colorantes None não contribuem com cor nem com forma de knockout; componentes None mistas ainda alcançam o transform alternante de tint

Separation All aplica o tint dele a todas as colorantes de saída disponíveis, usando saída de páginas RGB neutra e preservando todas as componentes de processo dentro de grupos CMYK

Grupos CMYK recebem valores alternantes originais de tint de quatro componentes antes da mistura; chapas de separações spot, seleção de processos/colorantes NChannel e simulação de mixing hints continuam a ser extensões separadas

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

JPEG 2000 suporta componentes com subsampling e com sinal, declarações inferidas de cores e de amostras, perfis ICC incorporados, overrides explícitos de espaços de cor e opacidade separada ou associada através de SMaskInData; os valores das componentes dele são normalizados para oito ou dezasseis bits e o array Decode da imagem dele é ignorado

Perfis Lab/XYZ ICC incorporados ou explícitos usam intervalos físicos de componentes; a opacidade associada é removida das amostras guardadas normalizadas antes de aplicar o mapeamento físico de coordenadas, preservando os canais de offset Lab

O SMask de estado de gráficos suporta grupos Alpha e Luminosity, cores de fundo, matrizes de Forms, restauração de estados guardados e funções de transferência amostradas, exponenciais, de costura e de calculadora delimitadas; a soft mask própria de uma imagem sobrepõe-se à soft mask do estado de gráficos

Todos os dezasseis modos de mistura standard PDF são suportados; grupos de Forms e de páginas suportam composição isolada e não isolada, knockout de objetos e espaços de mistura DeviceGray, DeviceRGB, DeviceCMYK, CalGray, CalRGB ou ICCBased de uma, três e quatro componentes

Grupos calibrados retêm valores nativos de componentes até uma fronteira de grupo e aceitam cores fonte de dispositivos ou Lab através de transforms calibrados inversos; o Lab em si não é um espaço de mistura válido

Máscaras calibradas de Luminosity mantêm as coordenadas do grupo delas e avaliam CIE XYZ-Y, incluindo opacidade do grupo e cores de fundo, 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 stencil preservam objetos precedentes enquanto um caminho mascarado os substitui ao longo da geometria pintada dele

Grupos knockout aninhados mantêm a união das formas geométricas dos filhos deles, incluindo objetos de opacidade zero; grupos filhos não isolados usam o fundo inicial do grupo knockout envolvente

Grupos CMYK preservam componentes complementares de CMY e de preto em planos de imagens separados e delimitados e convertem o resultado combinado nas fronteiras de grupos; modos de mistura não separáveis retêm ou substituem o preto de acordo com o modo selecionado

Grupos não isolados renderizam uma passagem adicional delimitada de opacidade, removem a contribuição do fundo inicial e aplicam o alfa e o modo de mistura do grupo de entrada uma vez; grupos de transparência de páginas usam uma superfície isolada antes de compor sobre o fundo da página

Um Form não isolado herda o espaço de mistura envolvente; uma entrada explícita de CS de grupos não muda o fundo 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 um dos usos

O uso tem por defeito hruView, que salta anotações Hidden e NoView e tipos de anotações desconhecidos com Invisible definido; tipos standard de anotações da ISO 32000, 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 recursos de media válidos ou uma vista 3D default associada; reprodução de media e ativação 3D interativa estão fora deste caminho raster

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

Quando falta uma aparência normal, 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 as restantes fronteiras

Para saída de visualização, o NoZoom de anotações remove a escala de renderização do tamanho da aparência mantendo UserUnit; NoRotate mantém a aparência ajustada na vertical através da rotação de páginas em qualquer um dos usos, e ambos preservam a âncora transformada Rect do canto superior esquerdo e o clip da página

Anotações de texto com aparências normais existentes comportam-se como NoZoom e NoRotate na saída de visualização independentemente das flags explícitas delas; a saída de impressão mantém o comportamento NoRotate delas enquanto ignora NoZoom

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

Optional content em saída estática

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

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

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

Conteúdo marcado /OC aninhado, XObjects de imagens e de Forms e anotações respeitam o estado resultante; secções marcadas ocultas ainda atualizam cores, matrizes, clipping e posição de texto, enquanto XObjects e anotações inteiras ocultas podem ser ignoradas

Dicionários ordinários de propriedades de marked content permanecem utilizáveis, incluindo valores inline aninhados; arrays de conteúdo preservam o estado de marked content através das streams componentes deles, e streams filhas mantêm o aninhamento próprio de marked content delas

A rasterização standalone de forma final usa a configuração por defeito em ambos os modos de visualização e de impressão sem aplicar automaticamente recomendações interativas de uso AS, conforme especifica a secção 8.11.4.5 da ISO 32000-1:2008; um ViewerState explícito ativa recomendações View, Print, Export, Zoom, Language e User com seleção manual persistente e estado temporário de eventos

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

Matrizes afins de aparências e origens de BBox diferentes de zero mantêm o ajuste normal delas sob estas flags; uma escala de renderização 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 de MediaBox/CropBox, page boxes herdadas e Rotate de quarto de volta, e o UserUnit da página; a escala 1 produz um píxel por ponto efetivo de página, com as dimensões da superfície arredondadas por excesso

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

Funções de cores suportadas e arrays de funções escalares convertem através de cores fonte de dispositivos, calibradas, ICC Lab/XYZ e Separation/DeviceN; opacidade atual de fills, modos de mistura, soft masks de estado de gráficos e knockout de grupos de transparência aplicam-se ao shading resultante

O caminho e a cor atuais são preservados; o Background de shadings é ignorado por sh, e AntiAlias é uma dica de dispositivo com amostragem de cor nos centros de píxeis

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

Shadings de malhas de triângulos

ShadingTypes 4 e 5 pintam malhas Gouraud de triângulos de forma livre e de grelha com reutilização de bordas, geometria arbitrária de grelhas, registos de vértices alinhados a bytes, precisão de coordenadas até 32 bits e precisão de componentes até 16 bits

As componentes de vértices interpolam nos centros de píxeis do dispositivo antes da conversão de cores; uma função opcional de uma entrada ou um array de funções de componentes avalia o parâmetro interpolado, incluindo espaços de cor calibrados, ICC e especiais

Fontes Indexed arredondam índices interpolados para a entrada de paleta mais próxima; strings de consulta hexadecimais descodificam-se uma vez com whitespace, dígitos em maiúsculas e minúsculas e padding do nibble final ímpar, enquanto strings de consulta literais mantêm os bytes descodificados delas

Transforms atuais, clipping, BBox, opacidade de fills, modo de mistura, soft masks, colorantes sem marcação e knockout de grupos aplicam-se à malha concluída; bytes de streams retidos, a superfície temporária de páginas e duas linhas de grelha juntam-se à admissão de memória de trabalho

Análise de vértices, rasterização de triângulos e funções partilham limites agregados de operações e consulta de cancelamento; registos malformados ou truncados e linhas de grelhas incompletas falham antes da publicação da saída

A aceitação focada verifica equações barycentric fechadas e saídas separadas de MuPDF e Poppler; registos de provas mantêm as falhas de leitores fonte separadas para padding de vértices, bits de flags não usados e transparência de malhas, e usam equações alternantes explícitas de leitores para cores sem marcação e valores Indexed normalizados

Malhas Coons e de patches tensoriais

ShadingTypes 6 e 7 pintam fronteiras cúbicas Coons e redes de controlo tensoriais, com reutilização de bordas precedentes, registos alinhados a bytes, semântica de flags de dois bits baixos e as mesmas precisões de coordenadas e de componentes que as malhas de triângulos

Componentes de cantos interpolam bilinearmente nos parâmetros de patches antes de funções opcionais e conversão de cores; as fronteiras Coons elevam-se a uma rede Bernstein bicúbica equivalente, cujos bounds de segundas derivadas selecionam subdivisões com erro geométrico máximo de 0,125 píxeis de saída

A inversão polinomial refina parâmetros de píxeis; a cobertura dobrada escolhe o maior parâmetro v e depois o maior parâmetro u para v iguais, enquanto patches posteriores substituem cores anteriores antes de o shading concluído receber a transparência do objeto

O compositor partilhado de malhas aplica clipping, BBox, padrões de shadings, colorantes sem marcação, opacidade, mistura, soft masks e knockout de grupos; duas linhas de subdivisão e arrays por píxel de parâmetros e de ordens juntam-se à admissão ativa de bytes de trabalho

Análise de pontos de controlo, subdivisão, rasterização e funções de cores partilham 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 leitores fonte registadas separadamente da verificação ordinária de páginas de equações RGB

Estado de texto herdado

Streams filhas de Forms, Type3 e padrões herdam o objeto de tipo de letra aplicável, tamanho de tipo de letra, espaçamento de carateres, espaçamento de palavras, escala horizontal, leading, modo de renderização e rise do estado inicial de gráficos delas; um recurso filho com o mesmo nome de tipo de letra não substitui um tipo de letra herdado até um Tf local o selecionar

O estado de gráficos guardado restaura os parâmetros de texto, e os operadores TD e de aspas duplas mantêm as alterações deles de leading e de espaçamento para streams filhas subsequentes; cada filho começa com as matrizes de texto próprias dele

Aparências independentes de anotações partem de parâmetros de texto por defeito sem reter o estado final de texto do conteúdo das páginas

Texto Type3 no modo de renderização 3 não contribui com gráficos visíveis de glyphs; a prova focada de texto Type3 aninhado retém o desvio de parâmetros por defeito do MuPDF separadamente das equações de estado herdado, enquanto o Poppler segue os parâmetros herdados nessas fixtures

Padrões de mosaicos e de shadings

Espaços de cor de padrões suportam padrões de mosaicos coloridos e não coloridos, TilingType 1–3, padrões de shadings, PatternMatrix, BBox de células, espaçamento positivo ou negativo, seleção de padrões, restauração de estados guardados e pintura de fills ou strokes

Padrões não coloridos obtêm as componentes deles a partir de um espaço de cor base suportado e podem pintar stencils de imagens; alterações explícitas de cores, imagens coloridas e shadings diretos dentro de uma definição não colorida são conteúdo PDF inválido e são rejeitados também através de Forms aninhados e procedimentos Type3

Padrões selecionados mantêm o espaço de coordenadas por defeito da stream de conteúdo que resolveu a definição deles; operações cm posteriores e um padrão herdado usado dentro de um Form não substituem essa origem

As definições partem do estado inicial suportado de gráficos do pai e dos parâmetros por defeito de transparências dele; definições de mosaicos formam um grupo não isolado e sem knockout, enquanto definições de shadings usam knockout de objetos

Células transparentes e sobrepostas de mosaicos avaliam-se contra o fundo atual; o alfa e o modo de mistura do objeto de entrada aplicam-se uma vez ao pintar o padrão concluído, incluindo padrões aninhados, texto, strokes e máscaras de imagens

O ExtGState de padrões de shadings aumenta os parâmetros suportados de shadings, incluindo opacidade e soft masks; o Background é pintado antes do shading, o BBox corta ambas as contribuições, e cores None sem marcação não contribuem com cor nem com forma

A avaliação de padrões admite duas superfícies de páginas e conteúdo de células descodificado, delimita a enumeração de células visíveis ao clip atual e consulta o cancelamento enquanto renderiza células e remove a contribuição do fundo

Fixtures focadas comparam equações fechadas de coordenadas, de cores e de composição com píxeis nativos e saída independente de leitores; ficheiros de provas retêm diferenças de leitores para origens herdadas de padrões de Forms, opacidade de ExtGState de padrões de shadings e cores None sem marcação, com páginas separadas de equações vetoriais ordinárias para esses casos

Tipos de letra CFF com chaves CID

Tipos de letra CIDFontType0 incorporados resolvem CIDs CFF reais em contentores autónomos e OpenType, incluindo mapeamentos não identidade, CID 65535, CMaps incorporadas de Encoding, origens verticais W2, contornos transformados e clipping de texto

Faces CFF autónomas 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 carateres não mapeado ou um CID pedido 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; intervalos têm alvos CID constantes e entradas de carateres têm precedência, enquanto glyphs presentes mantêm o CID pedido deles

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

Ficheiros de provas retêm diferenças de leitores fonte para seleção de glyphs OpenType com chaves CID e substituições notdef omitidas; a alternativa de omissão é medida separadamente e não substitui a equação nativa exigida de fontes

Limites e cancelamento

Encodings Type0 incorporados exatos cobrem todos os 200 nomes de encodings incluídos: Identity-H e Identity-V, dezasseis mapeamentos UCS2 e UTF16 e 182 mapas adicionais legados e Unicode com overrides verticais achatados de carateres

Operandos mistos de um a quatro bytes usam bounds de codespaces por byte e recuperação de códigos inválidos por prefixo mais comprido; a descodificação UTF8 e UTF32 e a codificação inversa preservam scalars suplementares e bytes de zeros à esquerda significativos

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

Cada CMap filha mantém o modo de escrita próprio dela, com default horizontal quando WMode é omitido; o modo vertical explícito seleciona mapeamentos herdados e as métricas verticais do tipo de letra

A herança de CMaps usa limites thread-local de profundidade aninhada sem alterar 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 falhas de fontes nomeadas UTF8 e UTF32 num leitor independente sem essas tabelas incorporadas, verifica companheiros separados de mapas incorporados e regista diferenças de texto fonte quando múltiplos códigos selecionam o mesmo CID

Tests/Linux/Run-HeadlessLegacyCMapAcceptance.sh compila e testa intervalos exatos de encodings, PDFs fonte de larguras mistas, renderização aninhada, isolamento de threads e recuperação de cancelamento em Linux nativo

Tests/Linux/Run-HeadlessLegacyCMapWindowsAcceptance.py corre executáveis nativos correspondentes de Windows, regista hashes de fontes, binários, PNGs e diagnósticos e depois transfere capturas fixas para armazenamento nativo de Linux para verificações separadas de MuPDF e Poppler

Os mapas empacotados mantêm os hashes de recursos deles e os avisos completos de redistribuição; mantenha a licença de dados CMap com as distribuições de fonte e de binários

Escapes hexadecimais em valores de PDF names e operandos de nomes de conteúdo descodificam-se uma vez antes de resolver tipos de letra, espaços de cor, modos de mistura e recursos; um hash literal produzido pela descodificação permanece parte do nome semântico

O descodificador partilhado de tipos de letra aplica estas semânticas a valores de dicionários de tipos de letra, encodings nomeados, nomes de glyphs de Differences e CIDToGIDMap, sem modificar objetos emprestados nem descodificar valores de strings

Nomes de renderizadores com escape usam descodificação linear, admissão temporária de bytes de trabalho, limites agregados de operações e consulta de cancelamento; a aceitação focada compara bytes PNG nativos equivalentes e texto mais saída independente de MuPDF e Poppler

O trabalho raster de shadings e as funções de cores partilham limites agregados de operações e consulta de cancelamento; a superfície temporária e uma cache de coordenadas exatas de no máximo 8,192 cores convertidas juntam-se à admissão ativa de bytes de trabalho

A aceitação focada de shadings usa equações fechadas de geometria/funções/cores e páginas separadas de equações vetoriais, retendo diferenças de leitores fonte para clipping de BBox, geometria degenerada, conversão de cores, nomes especiais de colorantes e tesselação de knockout

As opções delimitam píxeis de superfícies, buffers geridos ativos, bytes descodificados cumulativos, bytes PNG codificados, trabalho de tokens e de operadores e profundidade recursiva ou de estado de gráficos

A descodificação de tipos de letra usa quotas conservadoras de admissão: 32 MiB de capacidade transitória, 64 vezes o tamanho descodificado de streams de tipos de letra, 128 vezes slots de arrays verificados recursivamente e duas vezes a estimativa retida do descodificador no agregado ativo

Tabelas CID admitem 65,536 entradas retidas; a enumeração delimita charstrings reais, e arrays notdef juntam-se à contabilidade de cópias profundas e de bytes retidos do descodificador

O parsing de CMaps e a consulta notdef partilham bounds thread-local e aninhados de entradas e consulta de trabalho; âmbitos de renderizadores partilham limites agregados de tokens e de operações, e varreduras lexicais compridas consultam no máximo a cada 256 bytes

O intérprete também reserva capacidade por glyph de sequências Unicode a partir dos bytes de operandos de entrada e do mapeamento ToUnicode mais comprido antes de criar registos de glyphs, para que mapeamentos compridos repetidos não possam contornar a admissão de memória de trabalho

Um orçamento pequeno de memória de trabalho pode rejeitar um tipo de letra simples mesmo quando a alocação eventual dele caberia; estas verificações cobrem buffers geridos e superfícies de imagens CPU, enquanto as caches de Cairo, Fontconfig e FreeType e o RSS total do processo ficam fora da contabilidade

Superfícies de transparências, soft masks, fundos, opacidade e knockout de objetos juntam-se ao orçamento ativo de superfícies; funções de transferência partilham o orçamento agregado de operações, codecs ICC e de imagens usam admissão conservadora, e o descodificador nativo JBIG2 delimita cumulativamente a alocação de bitmaps/contextos e consulta o cancelamento durante a descodificação

Travessias complementares de CMY, de preto e de formas geométricas partilham os limites agregados de operações, descodificação e cancelamento; perfis usando a mesma stream resolvida partilham um transform validado e uma reserva ativa de admissão até a renderização da página terminar

Streams retidas de funções, avaliação de funções e registos de estado de gráficos juntam-se à admissão de bytes de trabalho; funções de tint recursivas, interpolação multidimensional e instruções de calculadoras partilham limites de operações e de cancelamento

O token de cancelamento emprestado é consultado durante descodificação delimitada, tokenização, operadores, chamadas de resolvers de glyphs, linhas de imagens, recursão, codificação PNG e antes da publicação; quem chama é dono do tempo de vida dele

O renderer verifica a permissão de extração através da política emprestada do documento e mantém valores de objetos fonte e bytes fonte

Propriedade da saída

HPDFRenderHeadlessPagePNG conclui a renderização e a codificação PNG em privado antes de escrever numa stream própria de quem chama; uma falha final de I/O na stream pode reter bytes já aceites

HPDFRenderHeadlessPagePNGFile verifica a identidade da fonte, cria exclusivamente um ficheiro de staging no diretório alvo, faz flush dele, verifica identidade e cancelamento outra vez e substitui atomicamente o destino

A publicação em 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, repetindo apenas erros de acesso negado, de violação de partilha e de violação de bloqueios; o cancelamento é verificado antes de cada tentativa e em ambos os lados de cada espera

A publicação falhada em Windows reporta o código final capturado de erros de 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 recorre a cópia não atómica

Falhas de renderização, orçamento, cancelamento e staging preservam um destino existente e removem ficheiros de staging próprios não publicados; aliases de caminhos de fontes e de hardlinks são rejeitados

Aceitação

A aceitação de runtime em Windows usa executáveis nativos correspondentes de consola e um fecho de importação portátil de DLLs isolado e fixado por SHA256; um processo WSL separado corre verificações independentes de píxeis, equações e geometria de MuPDF e Poppler contra os ficheiros PNG produzidos em Windows

Substitutos de tipos de letra standard em Windows usam faces GDI explícitas de Cairo para texto Unicode e contornos reais, incluindo clipping e modos de fill e stroke; tipos de letra incorporados mantêm o mapeamento FreeType de glyphs deles

Chamadas OpenJPEG usam a ABI stdcall de Windows e exportações decoradas Win32, enquanto callbacks de streams e de mensagens mantêm a convenção C de callbacks

Tests/Linux/Run-HeadlessCairoAcceptance.sh realiza compilações nativas ELF frescas, limpa DISPLAY e WAYLAND_DISPLAY, rejeita bibliotecas de desktop diretamente ligadas e corre oráculos independentes de pypdf/MuPDF

As fixtures exercitam tipos de letra standard, TrueType Unicode, Type3, todos os modos de renderização de texto e de mistura, alfa e knockout, grupos de transparência RGB, profundidades de amostras e Decode, máscaras de imagens e Matte, cores Indexed e ICC, codecs terminais, cadeias de filtros encriptadas AES, geometria de páginas, transforms de anotações, orçamentos, cancelamento, preservação de fontes e saída atómica

Veja THPDFHeadlessRenderResult para contadores e EHPDFHeadlessRenderError para o tratamento de erros