¿Cómo funcionan los campos de formulario de un PDF? AcroForm, flujo de apariencia y aplanado

Has rellenado un formulario PDF y lo has enviado, y el destinatario te dice que "los campos se ven vacíos". O el formulario se ve bien en un programa y con otra tipografía en otro. Todas esas rarezas tienen su origen en cómo están construidos los formularios PDF. En este artículo explicamos cómo se traducen los campos de formulario dentro del archivo y cómo el aplanado elimina esa estructura.

Dos mundos separados: contenido de página y capa interactiva

En una página de PDF hay dos tipos de contenido distintos.

El flujo de contenido de página es la secuencia de instrucciones que describe cómo dibujar la página. Texto, líneas, rellenos, imágenes: todo lo estático está ahí.

Las anotaciones son objetos aparte que se sitúan sobre la página. Las notas adhesivas, los resaltados, los hipervínculos y —lo que nos ocupa— los widgets de campo de formulario entran en esa categoría.

Esta distinción es crítica: un campo de formulario no forma parte del contenido de la página. Es un objeto independiente listado en el array /Annots del objeto de página. El código que dibuja la página y el que dibuja el campo funcionan por vías distintas.

AcroForm: el diccionario de formulario a nivel de documento

En el objeto catálogo del documento hay una clave /AcroForm que apunta a un diccionario. Ese diccionario gestiona el formulario completo:

• /Fields: la lista de todos los campos de formulario del documento. Los campos pueden ser jerárquicos; bajo un campo padre puede haber varios campos hijos.
• /DA: la cadena de apariencia por defecto. Aquí se definen la tipografía, el tamaño y el color (algo como /Helv 0 Tf 0 g).
• /DR: el diccionario de recursos por defecto. Aquí están las definiciones reales de las tipografías nombradas en /DA.
• /NeedAppearances: un indicador crítico que detallaremos enseguida.
• /XFA: si existe, los datos de formulario dinámico basados en XML.

El objeto del campo de formulario en sí lleva esto:

• /FT: el tipo de campo: /Tx (texto), /Btn (botón/casilla), /Ch (lista de selección), /Sig (firma).
• /T: el nombre del campo ("nombre_apellidos", "fecha").
• /V: el valor del campo, el dato que ha introducido el usuario.
• /AP: el diccionario de apariencia, cómo se dibuja ese valor.

El flujo de apariencia: el origen de las inconsistencias

Llegamos ahora al punto más importante. El valor de un campo de formulario (/V) y su representación (/AP) son cosas separadas.

/V es solo el dato: (Ana García). Ahí no está la información de con qué tipografía, a qué tamaño ni con qué alineación se dibujará ese texto en la página.

/AP, en cambio, es un flujo de apariencia: un pequeño formulario XObject que, igual que el flujo de contenido de página, contiene instrucciones de dibujo. Un programa de relleno de formularios que funcione correctamente actualiza, cuando escribes en un campo, tanto el valor /V como el flujo de apariencia /AP.

El problema es que algunos programas se saltan el segundo paso. Escriben el valor y no actualizan la apariencia. ¿Qué ocurre entonces?

Depende del visor. Un visor avanzado genera él mismo la apariencia si /AP falta o está desactualizado, usando la información tipográfica de la cadena /DA. Pero no todos los visores lo hacen igual: se comportan de forma distinta en cuestiones como el interlineado, la alineación vertical o el recorte del texto que se desborda.

En los visores sencillos, el campo se ve vacío. Algunos visores ligeros y aplicaciones móviles no tienen capacidad de generar apariencias. Si no hay /AP, no dibujan nada.

Los controladores de impresora sufren el mismo problema. Esta es la causa técnica más frecuente de la queja de "he rellenado el formulario pero sale en blanco".

El indicador NeedAppearances

Como solución a esta situación, el estándar incorporó el indicador /NeedAppearances. Cuando se pone en true, significa: "no os fiéis de los flujos de apariencia de este formulario, regeneradlos vosotros".

Las herramientas de relleno de formularios activan ese indicador cuando no pueden actualizar la apariencia.

Pero el indicador no resuelve el problema del todo:

• Los visores sin capacidad de generar apariencias ignoran el indicador y el campo se queda vacío.
• Los visores que sí pueden generarla lo hacen a su manera; el resultado varía de un programa a otro.
• Los controladores de impresora suelen hacer caso omiso del indicador.

Es decir, /NeedAppearances resuelve el problema en determinados visores, pero no ofrece una garantía universal.

Cómo termina el aplanado con esa incertidumbre

La operación de aplanado hace esto:

1. Toma el flujo de apariencia de cada campo de formulario. Si /AP existe, se usa directamente; si no, se genera a partir del valor /V y de la información de /DA.

2. Dibuja esa apariencia en el flujo de contenido de la página. Se añade como una llamada a un formulario XObject o como instrucciones de dibujo directas, usando la posición (/Rect) y el tamaño del campo.

3. Elimina la anotación widget del array /Annots.

4. Borra el diccionario /AcroForm y su lista /Fields.

5. Elimina los JavaScript del formulario: los códigos de cálculo y validación quedan sin efecto.

Resultado: el valor pasa a ser una parte permanente de la página. No hace falta que ningún visor lo interprete y se ve igual en cualquier programa y en cualquier impresora.

| Aspecto | Antes del aplanado | Después del aplanado | |---|---|---| | Consistencia de apariencia | Depende del visor | Segura | | Fiabilidad al imprimir | Depende del controlador | Segura | | Editabilidad | Sí | No | | Cálculos de JavaScript | Funcionan | Se eliminan | | Etiquetas de formulario para lectores de pantalla | Sí | Se pierden | | Tamaño de archivo | — | Baja un poco |

Qué pasa si el flujo de apariencia está mal

Aquí está una de las trampas del aplanado. La herramienta fija el flujo /AP existente. Si ese flujo es antiguo o está vacío —es decir, si el programa de relleno escribió el valor pero no actualizó la apariencia—, el aplanado puede fijar una apariencia vacía o incorrecta.

El síntoma es este: cuando abres el archivo en un programa se ven los valores (porque ese programa genera la apariencia por su cuenta), pero tras aplanarlo sale en blanco.

Solución: abre el formulario en un programa que genere correctamente los flujos de apariencia, guárdalo y después aplánalo. O bien, si la herramienta de aplanado es capaz de generar la apariencia a partir del valor /V, usa esa opción.

El problema del desbordamiento de texto

Los campos de formulario se dibujan dentro de su propio rectángulo (/Rect). Si el texto que introduces no cabe en ese rectángulo, en modo interactivo el campo se puede desplazar: haces clic y desplazas para leerlo.

En el aplanado no existe el desplazamiento. Solo se fija la parte visible; el resto se pierde.

Esto supone un riesgo real de pérdida de datos en campos de dirección largos, en cajas de observaciones y en campos de texto multilínea. Antes de aplanar conviene revisar los campos con contenido largo.

Formularios XFA: un mundo aparte

Algunos PDF usan XFA en lugar de AcroForm (o junto a él). Es la tecnología de formularios dinámicos basada en XML de Adobe: los campos crecen según los datos, se añaden filas a las tablas y el número de páginas puede cambiar.

Los formularios XFA no forman parte natural del estándar PDF; son una tecnología aparte incrustada dentro del PDF. Solo funcionan por completo en los productos del propio Adobe. En otros visores suele aparecer el aviso de "se necesita Adobe Reader para ver este documento".

En las versiones nuevas del PDF, XFA está descatalogado. Normalmente no es posible aplanar un formulario XFA que te encuentres; antes tendrás que convertirlo en un AcroForm plano o en un PDF estático.

Su relación con la firma digital

Una firma digital guarda el resumen criptográfico del rango de bytes del documento en el momento de firmarlo. Como el aplanado reescribe el archivo, ese resumen deja de coincidir y la verificación de la firma falla.

Además, el propio campo de firma es un campo de formulario (/FT /Sig). Si el aplanado lo convierte en contenido fijo, la estructura criptográfica de la firma también se pierde y solo queda su representación visual, que no tiene ningún valor de verificación.

El orden correcto: rellenar → aplanar → firmar.

En resumen

Los campos de formulario de un PDF viven en una capa interactiva separada del contenido de la página. El valor del campo (/V) y el dibujo de ese valor (el flujo de apariencia /AP) son estructuras distintas, y cuando el flujo de apariencia falta o está desactualizado cada visor hace su propia interpretación: ese es el origen de las apariencias inconsistentes y de los problemas de impresión en blanco. El indicador /NeedAppearances es una solución parcial, pero no universal. El aplanado acaba con la incertidumbre dibujando la apariencia de forma permanente en el contenido de la página y eliminando por completo la capa interactiva. Su precio es la irreversibilidad y la pérdida de la estructura de accesibilidad; su riesgo, que se fije un flujo de apariencia defectuoso o un texto desbordado.