Llenado rich tipado original en formularios de Windows

Los file jobs de Windows y hpdf_document_execute_json_v1 aceptan peticiones forms.fill con richTextRuns junto a actualizaciones ordinarias de texto, choice y botones; todos los campos comparten un único PDF candidato autenticado

Los runs tipados originales llegan directamente al compositor nativo de apariencias; la generación de AP no pasa de ida y vuelta por la representación serializada de colores de RV; el V plano, el RV rich estándar y el AP real se preparan juntos

Petición

{
  "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 aporta richTextRuns o un value o values escalar; un value opcional junto a richTextRuns debe coincidir exactamente con el texto plano nativo derivado, incluidos los retornos de carro entre párrafos tipados; el richText serializado no es una entrada de runs tipados

Cada run exige text y acepta fontStyle, fontSize, color, underline, strikeOut, paragraphBreakBefore y alignment; fontStyle es regular, bold, italic o boldItalic; alignment es left, center o right; los componentes RGB son números finitos de cero a uno

Los tamaños de run deben ser positivos y de 4096 puntos como máximo; un tamaño ausente usa el fontSize del campo o 12 puntos; el formateo numérico nativo de PDF sigue aplicando, mientras que el RV CSS estándar serializa los colores a componentes de ocho bits

Las opciones de apariencia del campo incluyen fontSize, padding, characterSpacing, wordSpacing y paintWhiteBackground; se exige generación de AP genuina, así que appearance=false es inválido

Programas de fuente reales

Un array fontFamilies del campo sobrescribe el array de la operación; los arrays configurados contienen de una a dieciséis etiquetas de familia válidas y no vacías; el matching ignora mayúsculas/minúsculas ASCII y compara el resto de Unicode de forma exacta; un fontFamily de run explícito debe coincidir con una etiqueta configurada, y una etiqueta de run ausente selecciona la primera familia

Sin fontFamilies, el camino original de familia única sigue disponible; la etiqueta del callback de fuente sale del fontFamily del campo, del fontFamily de la operación o de DejaVu Sans; los runs originales de familia única omiten el fontFamily del run

Los file jobs agregan input, output y fonts; fonts mapea cada etiqueta de familia configurada a paths de archivo regular, bold, italic y boldItalic; solo se cargan los estilos usados y la cara regular que necesitan las apariencias escalares; los paths de archivo no deben ser alias del output

Los callers de la C ABI versionada usan la extensión existente hpdf_form_data_operation_v1 y devuelven tablas hpdf_io_v1 legibles desde su callback de fuentes; las etiquetas de familia son UTF-8 y los valores de estilo van de 0 a 3; todos los programas reales se copian a bytes propios acotados antes de componer las apariencias

Los símbolos V1 originales, los tamaños de estructura base y los offsets de extensión opcionales siguen sin cambios; los assets de familia/estilo se cachean dentro de una petición y se comparten entre campos sin cobrar la misma asignación propia repetidamente

El opt-in fallbackFontFamilies=true aplica fallback de grapheme completo entre las familias realmente suministradas; los runs tipados pueden conservar un array fontFamilyCandidates ordenado, con los candidatos declarados considerados antes del orden configurado; consulta fallback de fuentes rich con familias suministradas en Windows para la herencia de la petición y la carga de callbacks de cuatro estilos

Graph actual y publicación

Sin InputIO, la C ABI usa su revisión cargada propia y el graph pendiente real; un InputIO opcional suministra un PDF de reemplazo, copiado y autenticado en privado antes de cualquier callback de fuentes; ni la mutación de la entrada prestada ni un reemplazo fallido pueden alterar el contexto confirmado

OutputIO y ResultIO son obligatorios; el PDF candidato real y el JSON de resultado deben ambos terminar con éxito, seguidos del checkpoint final de cancelación, antes de que la C ABI intercambie el documento y la fuente

Un callback fallido puede haber recibido ya bytes del candidato; los callers deben descartar esos bytes cuando el estado devuelto sea distinto de cero; el contexto previamente confirmado de la biblioteca sigue sin cambios

Los file jobs preparan en staging el candidato completo y la respuesta acotada antes del reemplazo atómico del output solicitado; una fuente ausente, un fallo de política, la cancelación o un fallo de capacidad preservan el destino existente

Políticas y resultado

La integridad de firmas existente, DocMDP P1/P2/P3, los locks FieldMDP, los flags read-only y los permisos AES de form-fill se hacen cumplir por el motor autenticado nativo; signaturePolicy acepta los mismos ajustes explícitos de trust, timestamp y revocación que las importaciones de formularios de Windows

Una actualización read-only de misma entrada solo tiene éxito cuando los operadores de AP reales, fuentes, recursos y valores de campo son equivalentes; los streams AP comprimidos y un RV no canónico equivalente son soportados; un cambio de estilo verdadero sigue siendo un cambio aunque su color de RV cuantice al mismo valor CSS

Una petición genuinamente sin cambios publica los bytes exactos de la revisión actual preparada tras la autenticación de política; las ediciones pendientes del graph se materializan en esa revisión actual antes de la comparación

Las respuestas exitosas incluyen typedRichText=true, typedRichProfile=original-typed-runs-v1, updated, fieldCount, fontBytes y fields del candidato real preparado; formDataExchange.typedRichFill describe estos puntos de entrada implementados

Cada elemento de fields conserva el name ordinario, el value escalar y el resumen fieldType; un choice respaldado por un array tiene un value escalar vacío en este resumen, mientras que su selección completa queda en el PDF guardado y en la posterior exportación FDF/XFDF

La fachada directa de jobs ExecuteLoadedOperation y la extensión legacy de handle/callback de HPDFDocRunJob siguen siendo trabajo separado; este binding no agrega intercambio de anotaciones, embedded files, actions ni FDF incremental

Temas relacionados

FillTypedData, transacción de Windows, actualizaciones tipadas mixtas nativas, intercambio FDF/XFDF de Windows