HPDFBuildHeadlessTextAppearance
function HPDFBuildHeadlessTextAppearance(const Text: UnicodeString;
const TrueTypeFont: SysUtils.TBytes; FirstObjectNumber: Integer;
const Options: THPDFHeadlessTextAppearanceOptions): THPDFHeadlessTextAppearance;
Constrói um Form XObject Unicode real e os objetos de tipos de letra dele usando o parser partilhado do HotPDF, as classes de objetos, o leitor de cmaps, os avanços e metadados de descritores reais de TrueType e o shaping opcional HarfBuzz/FriBidi
O bundle devolvido é dono de sete objetos consecutivos a começar num FirstObjectNumber positivo; use o método de documentos de aparências para registo de objetos, ligações de campos, encriptação e saída incremental delimitada
Entradas TrueType exigem contornos nomeados glyf/loca, uma assinatura sfnt e magia de head consistentes, offsets de glyphs ordenados e delimitados e uma cmap Unicode completa e válida contida na extensão declarada da tabela dela; entradas OpenType OTTO podem em vez disso fornecer uma tabela CFF 1 delimitada com charset e metadados de coleções validados
A consulta Unicode não faz fallback para mapeamentos Symbol ou MacRoman; glyphs em falta são rejeitados em vez de substituídos por um glyph visualmente alheio
O texto suportado é Latino, Grego, Cirílico, CJK simples, Hangul pré-composto, símbolos matemáticos selecionados e emoji isolados na horizontal direta, quando o tipo de letra fornecido contém cada scalar
Layout multilinha CR/LF, wrap medido, células comb, rotações de quartos de volta e contornos retangulares ou circulares são controlados pelo registo de opções
Com ShapeComplexText ativo, scripts complexos, sequências de combinação, bidi e ligaduras usam shaping nativo HarfBuzz e ordenação de runs FriBidi; surrogates malformados, carateres de controlo não suportados, glyphs em falta, permissões inválidas de tipos de letra e orçamentos esgotados continuam a ser erros
Glyphs complexos recebem posicionamento individual incluindo offsets de shaping, mapeamentos ToUnicode conscientes de clusters e ActualText de marked-content que retém a fonte lógica; os leitores podem usar a ordem própria deles de extração de texto de anotações
Linux carrega libharfbuzz.so.0 e libfribidi.so.0; Windows exige libharfbuzz-0.dll e libfribidi-0.dll da arquitetura correspondente, com caminhos explícitos opcionais através de HOTPDF_HARFBUZZ_LIBRARY e HOTPDF_FRIBIDI_LIBRARY
Os bytes completos do tipo de letra original são incorporados com o nome PostScript real dele, bounds, ascent, descent, ângulo itálico e flag de passo fixo; a cap height usa OS/2 quando disponível e caso contrário o ascender do hhea, enquanto StemV usa uma estimativa conservadora de descritores de passo fixo
Embedding instalável ou editável é exigido; no-subsetting é respeitado pelo embedding completo, e permissões de embedding restritas, de pré-visualização e impressão, apenas de bitmap, ausentes ou desconhecidas são rejeitadas
O construtor verifica bytes de tipos de letra, contagem de glyphs, tamanhos de streams e dicionários, validade de scalars e cancelamento antes de devolver um bundle próprio
Veja THPDFHeadlessTextAppearanceOptions, THPDFHeadlessTextAppearance e SetTextFieldValueWithAppearance
Tipos de letra OpenType CFF 1 são suportados através do backend de aparências de compact fonts, preservando o tipo de letra completo, o mapping CID real, texto Unicode, larguras e política de embedding