web-dev-qa-db-fra.com

PDFTK, CODE128 et UTF-8

J'ai l'habitude de remplir PDF formulaires de PHP à l'aide de PDFTK. Récemment, on m'a demandé d'insérer un code à barres code 128 dans un fichier PDF. Pour ce faire, j'ai créé un PDF avec plusieurs champs de texte pour les entrées lisibles par l'homme ainsi qu'un champ de texte spécial, le texte étant rendu avec une police spéciale représentant les symboles du code 128. Cette police peut être trouvée ici: http://www.jtbarton.com/Barcodes/Code128.aspx . La seule différence entre les champs lisibles et les codes à barres est la police utilisée pour afficher les caractères.

Jusqu'à cette étape, tout fonctionne bien. Avec Adobe Reader, je peux copier-coller un code à barres préparé dans mon champ spécial, le rendu est parfait, ce code peut être numérisé par des lecteurs de codes à barres. Exemple: Ñ000002HÓ (Ñ est un démarreur, puis mes données 000002, la somme de contrôle H suit et le tout se termine par le bouchon Ó ).

Je rencontre ensuite des problèmes lorsque je tente de remplir le formulaire avec PDFTK. Si j'essaie de remplir mon champ spécial avec Ñ000002HÓ, il ne restitue que les caractères de la table ASCII (c'est-à-dire 000002H) et affiche une sorte de carré au lieu du code à barres attendu pour Ñ et Ó. Plus surprenant, essayer de remplir les champs lisibles par l’homme avec exactement la même phrase Ñ000002HÓ fonctionne comme un charme.

J'ai vérifié que les deux types de champs recevaient exactement la même séquence de caractères (y compris le codage utf-8), que la police était bien intégrée afin d'éviter les problèmes d'affichage, que le fichier XFDF est bien formé, etc.

Voici un exemple XFDF utilisé pour remplir un formulaire PDF avec des champs nommés 'humain' et 'code à barres'

<?xml version="1.0" encoding="UTF-8"?>
<xfdf xmlns="http://ns.Adobe.com/xfdf/" xml:space="preserve">
    <fields>
        <field name="human"><value>Ñ000002HÓ</value></field>
        <field name="barcode"><value>Ñ000002HÓ</value></field>
    </fields>
</xfdf>

J'ai bien peur de ne plus avoir d'idées pour résoudre ce problème. Si vous le faites, votre aide serait grandement appréciée.

2
MaxAuray

Enfin, j'ai trouvé une solution. Plus précisément une solution de contournement.

Il semble que PDFTK ne gère pas correctement les caractères UTF-8 avec les polices incorporées Identity-H appliquées aux champs de formulaire. Pour rendre le fichier PDF correctement, au lieu de remplacer un champ par un contenu, définissez simplement ce contenu comme étant le valeur par défaut de ce champ. Cela fera en sorte qu'Acrobat gère le processus de rendu du champ de formulaire au lieu de le déléguer à PDFTK.

Pour ce faire, ajoutez simplement need_appearances à la ligne de commande PDFTK.

NOTE - Le champ de formulaire reste dans le PDF créé par PDFTK, ce qui signifie que son contenu peut ensuite être modifié par l'utilisateur dans Adobe Reader.

1
MaxAuray