Preenchimento original typed rich de formulários no Windows

File jobs do Windows e hpdf_document_execute_json_v1 aceitam requisições forms.fill contendo richTextRuns junto de atualizações comuns de texto, choice e botões; todos os campos compartilham um PDF candidato autenticado

Os runs tipados originais chegam diretamente ao composer nativo de aparências; a geração de AP não faz round trip pela representação serializada de cores RV; V simples, RV rich padrão e AP real são preparados juntos

Requisição

{
  "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 valor escalar ou valores; um valor opcional ao lado de richTextRuns precisa corresponder exatamente ao texto simples derivado nativamente, 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

Tamanhos de runs precisam ser positivos e de no máximo 4096 pontos; um tamanho ausente usa o fontSize do campo ou 12 pontos; a formatação numérica nativa do PDF ainda se aplica, enquanto o CSS padrão de RV serializa cores para componentes de oito bits

Opções de aparências de campos incluem fontSize, padding, characterSpacing, wordSpacing e paintWhiteBackground; a geração genuína de AP é obrigatória, então appearance=false é inválido

Programas reais de fontes

Um array field fontFamilies sobrepõe o array da operação; arrays configurados contêm um a dezesseis rótulos válidos e não vazios de famílias; o matching decaixa letras ASCII e compara os demais caracteres Unicode exatamente; um fontFamily de run explícito precisa corresponder a um rótulo configurado, e um rótulo de run ausente seleciona a primeira família

Sem fontFamilies, o path original de família única permanece disponível; o rótulo do callback de fontes vem do fontFamily do campo, do fontFamily da operação ou de DejaVu Sans; runs originais de família única omitem o fontFamily do run

File jobs adicionam input, output e fonts; fonts mapeia cada rótulo configurado de família para os paths de arquivos regular, bold, italic e boldItalic; apenas os estilos usados e a face regular exigida por aparências escalares são carregados; paths de arquivos não podem ser aliases da saída

Chamadores versionados da C ABI usam a extensão hpdf_form_data_operation_v1 existente e retornam tabelas legíveis hpdf_io_v1 pelo callback de fontes dela; rótulos de famílias são UTF-8 e valores de estilo são de 0 a 3; todos os programas reais são copiados para bytes próprios delimitados antes de compor as aparências

Os símbolos V1 originais, os tamanhos da estrutura base e os offsets opcionais da extensão permanecem inalterados; assets de famílias/estilos são cacheados dentro de uma requisição e compartilhados entre campos sem cobrar a mesma alocação própria repetidamente

fallbackFontFamilies=true opt-in aplica o fallback de graphemes completos entre as 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 fontes de famílias fornecidas no Windows para a herança de requisições e o carregamento de callbacks de quatro estilos

Grafo atual e publicação

Sem InputIO, a C ABI usa a revisão carregada própria dela e o grafo pendente real; um InputIO opcional fornece um PDF de substituição, copiado e autenticado privadamente antes de qualquer callback de fontes; nem a mutação de entrada emprestada nem uma substituição com falha podem alterar o contexto commitado

OutputIO e ResultIO são obrigatórios; o PDF candidato real e o JSON de resultado precisam terminar com sucesso ambos, seguidos do checkpoint final de cancelamento, antes de a C ABI trocar o documento e a origem

Um callback com falha pode já ter recebido bytes candidatos; os chamadores devem descartar esses bytes quando o status retornado não for nulo; o contexto previamente commitado da biblioteca permanece inalterado

File jobs preparam o candidato completo e a resposta delimitada antes da substituição atômica da saída solicitada; uma fonte ausente, falha de política, cancelamento ou falha de capacidade preserva o alvo existente

Políticas e resultado

Integridade existente de assinaturas, DocMDP P1/P2/P3, locks FieldMDP, flags read-only e permissões AES de form-fill são aplicados pelo engine nativo autenticado; signaturePolicy aceita as mesmas configurações explícitas de confiança, timestamp e revogação dos imports de formulários do Windows

Uma atualização read-only de mesma entrada tem sucesso apenas quando os operadores AP reais, fontes, recursos e valores de campos são equivalentes; streams AP comprimidos e RV equivalente não canônico são suportados; uma mudança real de estilo ainda é uma mudança mesmo se a cor RV dela quantizar para o mesmo valor CSS

Uma requisição genuinamente inalterada publica os bytes exatos da revisão corrente preparada após a autenticação da política; edições pendentes do grafo são materializadas naquela revisão corrente 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 esses entry points implementados

Cada item de fields retém o name comum, o valor escalar e o resumo fieldType; um choice respaldado por um array tem um valor escalar vazio neste resumo, enquanto a seleção completa dele permanece no PDF salvo e no export FDF/XFDF subsequente

A facade direta de jobs ExecuteLoadedOperation e a extensão mais antiga de callbacks de handle/fonte HPDFDocRunJob permanecem trabalho separado; este binding não adiciona interchange de anotações, arquivos embutidos, actions nem FDF incremental

Tópicos relacionados

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