Aparências de anotações e de campos OpenType CFF

Os construtores nativos de aparências aceitam tipos de letra OpenType OTTO com contornos CFF 1, além das entradas TrueType existentes deles

Aparências de texto plain, rich, shaped e family incorporam o ficheiro OpenType original completo através de FontFile3 com Subtype OpenType e um descendente CIDFontType0

CFF com chaves de nomes usa índices de glyphs como CIDs, enquanto CFF com chaves CID mantém o Registry, Ordering, Supplement e mapping de charset reais dele, de índices de glyphs para CIDs

A CMap de Encoding gerada mapeia códigos de carateres de texto para os CIDs reais; as larguras usam esses CIDs, ToUnicode mantém o texto lógico, e CIDFontType0 não recebe CIDToGIDMap

Posições e extensões de glyphs usam métricas OpenType de HarfBuzz, incluindo bounds de fragmentos rich e de marcas de combinação; fragmentos rich partilham leitores imutáveis de tipos de letra por estilo e um recurso único de tipo de letra incorporado

As métricas CFF exigem uma biblioteca HarfBuzz da arquitetura correspondente mesmo quando ShapeComplexText é False; HOTPDF_HARFBUZZ_LIBRARY seleciona um caminho explícito, e o shaping complexo usa adicionalmente a dependência FriBidi existente

Uma anotação FreeText visível sem aparência normal pode usar um recurso válido de aparência default contendo um tipo de letra OpenType CFF completo; a precedência existente de recursos, o clipping, as cores e a política de embedding só de leitura aplicam-se

A geração de campos editáveis continua a exigir permissão instalável ou editável; o fallback só de leitura permite permissão de pré-visualização e impressão, enquanto contornos restritos ou apenas de bitmap continuam rejeitados, e no-subsetting mantém todos os bytes originais do tipo de letra

Os orçamentos de bytes de tipos de letra, glyphs, tamanho de objetos, agregado de tipos de letra rich, cancelamento e render nativo permanecem impostos; offsets malformados de INDEX CFF, dicionários, intervalos de charsets, CIDs duplicados e strings de coleções em falta são rejeitados antes da publicação

O mapeamento de formatos segue a ISO 32000-1:2008 9.7.4.2 e 9.9, incluindo o mapping explícito de charsets OpenType com chaves CID

Renderização nativa, MuPDF e Ghostscript passam os fixtures OpenType de CIDs esparsos; os backends Poppler testados têm uma incompatibilidade separada de mapping OpenType de CIDs esparsos, enquanto os controlos Poppler de OpenType identity-CID e de CIDFontType0C raw esparso renderizam corretamente

Leitores independentes podem sintetizar de forma diferente uma aparência de anotação em falta; aparências geradas explícitas são verificadas separadamente do comportamento de fallback de cada leitor

Aparências de anotações em falta também podem manter recursos originais Type1 simples, Type1C e CIDFontType0C através do caminho original de anotações com tipos de letra raw; entradas OpenType CFF2 usam o backend de aparências estático da instância por defeito separado, com conversão explícita de formatos, em vez de incorporar CFF2 diretamente numa stream de tipos de letra PDF 1.7

Veja HPDFBuildHeadlessTextAppearance e TryGetCompactFontTable