Preenchimento tipado rich original de formulários em Windows

Trabalhos de ficheiros de Windows e hpdf_document_execute_json_v1 aceitam pedidos de forms.fill contendo richTextRuns ao lado de atualizações ordinárias de texto, escolhas e botões; todos os campos partilham um PDF candidato autenticado único

Os runs tipados originais chegam diretamente ao compositor nativo de aparências; a geração de APs não faz viagem de ida e volta através da representação serializada de cores RV; V plain, RV rich standard e AP real são preparados em conjunto

Pedido

{
  "schemaVersion": 1,
  "type": "forms.fill",
  "fontFamilies": ["DejaVu Sans", "DejaVu Serif Condensed"],
  "fields": [
    {"name": "Input", "richTextRuns": [
      {"text": "Original typed precision", "fontFamily": "DejaVu Sans",
       "fontStyle": "regular", "fontSize": 12.123456,
       "color": [0.123456, 0.234567, 0.345678]},
      {"text": "Another paragraph", "fontFamily": "DejaVu Serif Condensed",
       "fontStyle": "boldItalic", "fontSize": 14.125,
       "paragraphBreakBefore": true, "alignment": "center",
       "underline": true, "strikeOut": false}
    ]},
    {"name": "Plain", "value": "Changed scalar"},
    {"name": "Choice", "values": ["B", "C"]},
    {"name": "Check", "value": "Yes"}
  ]
}

Cada campo fornece richTextRuns ou um value ou values escalar; um value opcional a par de richTextRuns tem de corresponder exatamente ao texto plain nativo derivado, incluindo carriage returns entre parágrafos tipados; richText serializado não é uma entrada de runs tipados

Cada run exige text e aceita fontStyle, fontSize, color, underline, strikeOut, paragraphBreakBefore e alignment; fontStyle é regular, bold, italic ou boldItalic; alignment é left, center ou right; componentes RGB são números finitos de zero a um

Os tamanhos de runs têm de ser positivos e no máximo 4096 pontos; um tamanho em falta usa o fontSize do campo ou 12 pontos; a formatação numérica nativa PDF continua a aplicar-se, enquanto o RV CSS standard serializa cores para componentes de oito bits

As opções de aparências de campos incluem fontSize, padding, characterSpacing, wordSpacing e paintWhiteBackground; a geração genuína de APs é exigida, pelo que appearance=false é inválido

Programas reais de tipos de letra

Um array fontFamilies de campos sobrepõe o array da operação; arrays configurados contêm entre uma e dezasseis etiquetas válidas não vazias de famílias; a correspondência ignora maiúsculas ASCII e compara outros Unicode exatamente; um fontFamily explícito de runs tem de corresponder a uma etiqueta configurada, e uma etiqueta de runs em falta seleciona a primeira família

Sem fontFamilies, o caminho original de família única permanece disponível; a etiqueta do callback de tipos de letra vem de fontFamily de campos, fontFamily da operação ou DejaVu Sans; runs originais de família única omitem fontFamily de runs

Trabalhos de ficheiros acrescentam input, output e fonts; fonts mapeia cada etiqueta configurada de famílias para caminhos de ficheiros de regular, bold, italic e boldItalic; apenas os estilos usados e a face regular exigida por aparências escalares são carregados; caminhos de ficheiros não podem ser alias da saída

Quem chama à ABI C versionada usa a extensão existente hpdf_form_data_operation_v1 e devolve tabelas legíveis hpdf_io_v1 a partir do callback de tipos de letra dela; etiquetas de famílias são UTF-8 e valores de estilos são 0 a 3; todos os programas reais são copiados para bytes próprios delimitados antes de compor aparências

Os símbolos V1 originais, os tamanhos base de estruturas e os offsets opcionais de extensões permanecem inalterados; recursos de famílias/estilos são colocados em cache dentro de um pedido e partilhados através de campos sem cobrar repetidamente a mesma alocação própria

fallbackFontFamilies=true opt-in aplica fallback de graphemes completos entre famílias realmente fornecidas; runs tipados podem reter um array ordered fontFamilyCandidates, com candidatos declarados considerados antes da ordem configurada; veja o fallback rich de tipos de letra de famílias fornecidas em Windows para a herança de pedidos e o carregamento por callbacks de quatro estilos

Grafo atual e publicação

Sem InputIO, a ABI C usa a revisão carregada própria dela e o grafo pendente real dela; um InputIO opcional fornece um PDF de substituição, copiado e autenticado em privado antes de qualquer callback de tipos de letra; nem a mutação de entrada emprestada nem uma substituição falhada pode alterar o contexto confirmado

OutputIO e ResultIO são obrigatórios; o PDF candidato real e o JSON de resultados têm ambos de terminar com sucesso, seguidos do checkpoint final de cancelamento, antes de a ABI C trocar o documento e a fonte

Um callback falhado pode já ter recebido bytes candidatos; quem chama tem de descartar esses bytes quando o status devolvido é diferente de zero; o contexto previamente confirmado da biblioteca permanece inalterado

Trabalhos de ficheiros preparam o candidato completo e a resposta delimitada antes da substituição atómica da saída pedida; um tipo de letra em falta, falha de políticas, cancelamento ou falha de capacidade preserva o alvo existente

Políticas e resultado

Integridade existente de assinaturas, DocMDP P1/P2/P3, bloqueios FieldMDP, flags só de leitura e permissões AES de preenchimento de formulários são impostas através do motor nativo autenticado; signaturePolicy aceita as mesmas definições explícitas de confiança, de timestamps e de revogação que as importações de formulários de Windows

Uma atualização só de leitura de mesma entrada tem sucesso apenas quando operadores reais de APs, tipos de letra, recursos e valores de campos são equivalentes; streams AP comprimidas e RV não canónico equivalente são suportados; uma alteração real de estilos continua a ser uma alteração mesmo que a cor RV dela quantize para o mesmo valor CSS

Um pedido genuinamente inalterado publica bytes exatos da revisão atual preparada depois da autenticação de políticas; edições pendentes do grafo são materializadas nessa revisão atual antes da comparação

Respostas bem-sucedidas incluem typedRichText=true, typedRichProfile=original-typed-runs-v1, updated, fieldCount, fontBytes e fields do candidato realmente preparado; formDataExchange.typedRichFill descreve estes pontos de entrada implementados

Cada item fields mantém o resumo ordinário de name, value escalar e fieldType; uma escolha apoiada por um array tem um valor escalar vazio neste resumo, enquanto a seleção completa dela permanece no PDF guardado e na exportação FDF/XFDF subsequente

A fachada direta de trabalhos ExecuteLoadedOperation e a extensão mais antiga de callbacks de handles/fontes de tipos de letra HPDFDocRunJob continuam a ser trabalho separado; este binding não acrescenta intercâmbio de anotações, ficheiros incorporados, ações nem FDF incremental

Tópicos relacionados

FillTypedData, Transação de Windows, Atualizações nativas mistas tipadas, Troca FDF/XFDF de Windows