Relleno rich de formularios con tipos originales en Windows

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

Los runs con tipos originales llegan directamente al compositor nativo de apariencias; la generación de AP no pasa de ida y vuelta por la representación RV serializada del color; la V plana, la 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 valor escalar o una lista de valores; un value opcional junto a richTextRuns debe coincidir exactamente con el texto plano derivado nativo, 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 formato numérico nativo del PDF sigue aplicándose, mientras que la 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 genuina de AP, así que appearance=false no es vá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 no vacías; la comparación ignora mayúsculas en 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, la ruta 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 trabajos de fichero añaden input, output y fonts; fonts mapea cada etiqueta de familia configurada a rutas de fichero regular, bold, italic y boldItalic; solo se cargan los estilos usados y la cara regular que necesitan las apariencias escalares; las rutas de fichero no deben ser alias de la salida

Los llamadores versionados del C ABI usan la extensión existente hpdf_form_data_operation_v1 y devuelven tablas hpdf_io_v1 legibles desde su callback de fuente; 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 las estructuras base y los offsets de extensión opcionales no cambian; los activos de familia/estilo se cachean dentro de una misma petición y se comparten entre campos sin cobrar dos veces la misma asignación propia

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

Grafo actual y publicación

Sin InputIO, el C ABI usa su revisión cargada propia y el grafo pendiente real; un InputIO opcional aporta un PDF de reemplazo, copiado y autenticado en privado antes de cualquier callback de fuente; 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 terminar ambos con éxito, seguidos del checkpoint final de cancelación, antes de que el C ABI intercambie el documento y el origen

Un callback fallido puede haber recibido ya bytes del candidato; los llamadores deben descartar esos bytes cuando el estado devuelto es distinto de cero; el contexto de biblioteca confirmado previamente queda intacto

Los trabajos de fichero preparan en staging el candidato completo y la respuesta acotada antes del reemplazo atómico de la salida solicitada; 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 existentes, DocMDP P1/P2/P3, los bloqueos FieldMDP, los flags de solo lectura y los permisos AES de relleno de formularios se aplican mediante el motor nativo autenticado; signaturePolicy acepta los mismos ajustes explícitos de confianza, timestamp y revocación que las importaciones de formularios de Windows

Una actualización de solo lectura con la misma entrada solo tiene éxito cuando los operadores AP reales, las fuentes, los recursos y los valores de campo son equivalentes; los streams AP comprimidos y una RV equivalente no canónica están soportados; un cambio de estilo real sigue siendo un cambio aunque su color RV se 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 grafo se materializan en esa revisión actual antes de la comparación

Las respuestas con éxito 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, el valor escalar y el resumen fieldType ordinarios; un choice respaldado por un array tiene un valor escalar vacío en este resumen, mientras que su selección completa permanece en el PDF guardado y en el posterior export FDF/XFDF

La fachada de trabajo directa ExecuteLoadedOperation y la extensión legacy de handle/callback de HPDFDocRunJob siguen siendo trabajos separados; este binding no añade intercambio de anotaciones, ficheros incrustados, actions ni FDF incremental

Temas relacionados

FillTypedData, Transacción de Windows, Actualizaciones tipadas mixtas nativas, Intercambio FDF/XFDF de Windows