Comment fonctionnent les champs de formulaire PDF ? AcroForm, flux d'apparence et aplatissement

Vous avez rempli un formulaire PDF et l'avez envoyé, et le destinataire vous dit que « les champs apparaissent vides ». Ou bien le formulaire s'affiche correctement dans un logiciel et avec une autre police dans un autre. Toutes ces bizarreries trouvent leur origine dans la façon dont les formulaires PDF sont structurés. Dans cet article, nous expliquons ce à quoi correspondent les champs de formulaire à l'intérieur du fichier et comment l'aplatissement fait disparaître cette structure.

Deux mondes distincts : contenu de page et couche interactive

Une page PDF comporte deux types de contenu différents.

Le flux de contenu de page est la suite d'instructions décrivant comment dessiner la page. Texte, traits, remplissages, images — tout ce qui est statique se trouve là.

Les annotations sont des objets distincts posés sur la page. Les pense-bêtes, les surlignages, les hyperliens et — c'est notre sujet — les widgets de champs de formulaire relèvent de cette catégorie.

Cette distinction est déterminante : un champ de formulaire ne fait pas partie du contenu de la page. C'est un objet séparé, listé dans le tableau /Annots de l'objet page. Le code qui dessine la page et celui qui dessine le champ de formulaire empruntent des chemins différents.

AcroForm : le dictionnaire de formulaire au niveau du document

L'objet catalogue du document contient une clé /AcroForm qui pointe vers un dictionnaire. Ce dictionnaire gère l'ensemble du formulaire :

• /Fields : la liste de tous les champs de formulaire du document. Les champs peuvent être hiérarchiques ; un champ parent peut regrouper plusieurs champs enfants.
• /DA : la chaîne d'apparence par défaut. Des informations comme la police, la taille et la couleur y sont définies (par exemple /Helv 0 Tf 0 g).
• /DR : le dictionnaire des ressources par défaut. Les définitions réelles des polices nommées dans /DA s'y trouvent.
• /NeedAppearances : un indicateur déterminant ; nous y reviendrons.
• /XFA : le cas échéant, les données de formulaire dynamique fondées sur XML.

L'objet du champ de formulaire lui-même porte quant à lui :

• /FT : le type de champ — /Tx (texte), /Btn (bouton/case à cocher), /Ch (liste de choix), /Sig (signature).
• /T : le nom du champ (« nom_prenom », « date »).
• /V : la valeur du champ — la donnée saisie par l'utilisateur.
• /AP : le dictionnaire d'apparence — comment cette valeur doit être dessinée.

Le flux d'apparence : la source des incohérences

Nous arrivons maintenant au point le plus important. La valeur d'un champ de formulaire (/V) et son apparence (/AP) sont deux choses distinctes.

/V n'est qu'une donnée : (Jean Dupont). L'information indiquant avec quelle police, à quelle taille et selon quel alignement ce texte sera dessiné sur la page n'y figure pas.

/AP est en revanche un flux d'apparence — un petit XObject form contenant des instructions de dessin, exactement comme un flux de contenu de page. Un programme de remplissage de formulaire correct met à jour, quand vous saisissez quelque chose dans un champ, à la fois la valeur /V et le flux d'apparence /AP.

Le problème est que certains programmes sautent la seconde étape. Ils écrivent la valeur sans mettre à jour l'apparence. Que se passe-t-il alors ?

Cela dépend de la visionneuse. Une visionneuse évoluée produit elle-même l'apparence si /AP est absent ou périmé — en utilisant l'information de police de la chaîne /DA. Mais toutes ne s'y prennent pas de la même façon : elles diffèrent sur l'interlignage, l'alignement vertical, le rognage du texte qui déborde.

Dans les visionneuses simples, le champ apparaît vide. Certaines visionneuses PDF légères et applications mobiles ne savent pas produire d'apparence. En l'absence de /AP, elles ne dessinent rien.

Les pilotes d'imprimante rencontrent le même problème. C'est la cause technique la plus fréquente de la plainte « j'ai rempli le formulaire mais il sort vide ».

L'indicateur NeedAppearances

Pour répondre à cette situation, la norme a introduit l'indicateur /NeedAppearances. Réglé sur true, il signifie : « ne faites pas confiance aux flux d'apparence de ce formulaire, régénérez-les vous-même ».

Les outils de remplissage de formulaire activent cet indicateur lorsqu'ils ne peuvent pas mettre à jour l'apparence.

Mais l'indicateur ne règle pas totalement le problème :

• Les visionneuses incapables de produire une apparence l'ignorent et le champ reste vide.
• Celles qui savent le faire s'y prennent chacune à leur manière ; le résultat varie d'un logiciel à l'autre.
• Les pilotes d'imprimante n'en tiennent généralement pas compte.

Autrement dit, /NeedAppearances résout le problème dans certaines visionneuses mais n'offre aucune garantie universelle.

Comment l'aplatissement met fin à cette incertitude

L'opération d'aplatissement fait ceci :

1. Elle récupère le flux d'apparence de chaque champ. Si /AP existe, il est utilisé directement ; sinon, il est produit à partir de la valeur /V et de l'information /DA.

2. Elle dessine cette apparence dans le flux de contenu de la page. À l'aide de la position (/Rect) et de la taille du champ, elle l'ajoute sous forme d'appel de XObject form ou d'instructions de dessin directes.

3. Elle retire l'annotation widget du tableau /Annots.

4. Elle supprime le dictionnaire /AcroForm et la liste /Fields qu'il contient.

5. Elle supprime les scripts JavaScript du formulaire — les codes de calcul et de validation deviennent inopérants.

Résultat : la valeur est désormais une partie permanente de la page. Aucune interprétation de la part d'une visionneuse n'est nécessaire, l'affichage est identique dans tous les logiciels et sur toutes les imprimantes.

| Aspect | Avant aplatissement | Après aplatissement | |---|---|---| | Cohérence d'affichage | Dépend de la visionneuse | Certaine | | Fiabilité à l'impression | Dépend du pilote | Certaine | | Modifiabilité | Oui | Non | | Calculs JavaScript | Fonctionnent | Supprimés | | Étiquettes de formulaire pour lecteurs d'écran | Présentes | Perdues | | Taille du fichier | — | Légèrement réduite |

Que se passe-t-il si le flux d'apparence est défectueux

C'est là que se cache un piège de l'aplatissement. L'outil fige le flux d'apparence /AP existant. Si ce flux est périmé ou vide — c'est-à-dire si le programme de remplissage a écrit la valeur sans mettre à jour l'apparence — l'aplatissement peut figer une apparence vide ou erronée.

Le symptôme : quand vous ouvrez le fichier dans un logiciel, les valeurs apparaissent (ce logiciel produit lui-même l'apparence), mais après aplatissement, le champ ressort vide.

Solution : ouvrez le formulaire dans un logiciel qui produit correctement les flux d'apparence et enregistrez-le, puis aplatissez. Ou bien, si votre outil d'aplatissement sait produire l'apparence à partir de la valeur /V, utilisez cette possibilité.

Le problème du texte qui déborde

Les champs de formulaire sont dessinés à l'intérieur de leur propre rectangle (/Rect). Si le texte saisi n'y tient pas, le champ peut être défilé en mode interactif — vous cliquez et faites défiler pour lire.

À l'aplatissement, le défilement n'existe pas. Seule la partie visible est figée ; le reste est perdu.

C'est un risque réel de perte de données dans les champs d'adresse longs, les zones de commentaires et les champs de texte multilignes. Il faut vérifier les champs au contenu long avant d'aplatir.

Les formulaires XFA : un monde à part

Certains PDF utilisent XFA à la place (ou en plus) de l'AcroForm. C'est la technologie de formulaire dynamique d'Adobe fondée sur XML : les champs grandissent selon les données, des lignes s'ajoutent aux tableaux, le nombre de pages peut varier.

Les formulaires XFA ne font pas naturellement partie de la norme PDF ; c'est une technologie distincte embarquée dans un PDF. Ils ne fonctionnent pleinement que dans les produits d'Adobe. Dans les autres visionneuses, vous voyez généralement l'avertissement « Adobe Reader est nécessaire pour afficher ce document ».

XFA a été supprimé des versions récentes du PDF. Aplatir un formulaire XFA que vous rencontrez est généralement impossible ; il faut d'abord le convertir en AcroForm simple ou en PDF statique.

Le lien avec la signature numérique

Une signature numérique conserve l'empreinte cryptographique de la plage d'octets telle qu'elle était au moment de la signature. Comme l'aplatissement réécrit le fichier, cette empreinte ne correspond plus et la vérification de signature échoue.

Par ailleurs, le champ de signature est lui-même un champ de formulaire (/FT /Sig). Si l'aplatissement le transforme en contenu fixe, la structure cryptographique de la signature disparaît également — il ne reste que sa représentation visuelle, qui n'a aucune valeur de vérification.

Le bon ordre : remplir → aplatir → signer.

En résumé

Les champs de formulaire PDF vivent dans une couche interactive distincte du contenu de page. La valeur du champ (/V) et son dessin (le flux d'apparence /AP) sont deux structures séparées, et lorsque le flux d'apparence est absent ou périmé, chaque visionneuse en propose sa propre interprétation — c'est là l'origine des affichages incohérents et des impressions vides. L'indicateur /NeedAppearances est une solution partielle mais non universelle. L'aplatissement met fin à cette incertitude en dessinant définitivement l'apparence dans le contenu de la page et en supprimant totalement la couche interactive. Son prix est l'irréversibilité et la perte de la structure d'accessibilité ; son risque, le figement d'un flux d'apparence défectueux ou d'un texte tronqué.