Comment générer correctement un code à barres GS1-128 (anciennement EAN-128) dans TCPDF

Question

Nous essayons de générer des codes EAN-128 corrects pour les étiquettes de produit, avec la bibliothèque TCPDF, mais notre client dit que le lecteur de codes à barres ne lire le code à barres généré. Le code à barres et chaîne d'origine (ancienne):

La chaîne de code est:

$codeString = "(01)08437013308045(3013)2675(15)161201(10)150518" 

Si nous passons la chaîne directement à la fonction TCPDF, comme ceci:

$label->write1DBarcode($codeString, 'C128A', $x, $y, $w, $h); 

nous obtenons une sortie correcte (que le scanner ne lira pas) mais les barres sont plus denses comparées au code à barres d'origine qui semble plus court d moins denses (ils disent que c'est-EAN 128):

Nous avons trouvé ici (EAN-128 with FNC1) que l'ajout chr(241) avant la $codeString devrait aider, mais si l'on ajoute, l'image résultante est dépouillée de tout code lisible par l'homme :

Puisque nous ne possédons pas un lecteur de codes à barres, nous ne pouvons pas vérifier les erreurs nous-mêmes.

Qu'est-ce qui manque ici? Nous utilisons TCPDF version 6.2.12.

Answer 1

Il y a un certain nombre de problèmes que je vais résoudre. Tout d'abord, vous avez mal lu le texte du code à barres d'origine qui contient le champ Identificateur d'application (AI) de longueur fixe (3103)2775 représentant le poids net.

Vous avez écrit un code contenant (3013)2675 qui n'est pas valide. Il n'y a pas d'AI (3013) et, malheureusement, ce préfixe correspondrait à l'AI légitime (30) représentant un compte d'éléments qui est un champ de longueur variable. Par conséquent, un décodeur continuerait à lire les données restantes jusqu'à la fin du code dans AI (30) puisqu'il n'y a pas de caractère de terminaison de champ suivant (FNC1). C'est beaucoup d'éléments - plus de huit chiffres en fait, de sorte que le lecteur peut indiquer une faute! La partie «extraction» de this answer fournit un contexte sur la façon dont les données GS1 codent dans un code à barres Code 128 pour produire un symbole GS1-128 valide. Supposons que vous vouliez coder les données GS1 (01)08437013308045(3103)2675(15)161201(10)150518

Les données brutes que vous devez encoder dans le code 128 sont {FNC1}0108437013308045310326751516120110150518.

Ceci est dérivé comme suit:

• Les données commence par un caractère de drapeau de FNC1 (ce qui indique la présence de données au format GS1).
• Les parenthèses autour des IA ont été omises.
• Étant donné que vos données sont composées uniquement d'IA de longueur fixe, nous ne devons pas terminer un champ de longueur variable avec un caractère séparateur FNC1 ^[*].

^{[*] Notez que la liste des EAE fournies dans les GS1 General Specifications §3.2 « GS1 Identifiants d'application en ordre numérique » indique si elles exigent la résiliation par un caractère FNC1 lorsqu'il est suivi par des données supplémentaires.}

Comment cette connaissance se traduit-elle en code pour TCPDF? Je ne l'ai jamais utilisé désolé, mais cela pourrait être utile:

Votre $codeString variable serait nécessaire de définir quelque chose comme:

$codeString = chr(241).'0108437013308045310326751516120110150518'; 

Cela suppose que le lié à répondre sur le forum de support est correct indiquant que TCPDF utilise ASCII ordinal 241 pour indiquer un caractère FNC1. (There is some doubt whether this is the case.) Si cela fonctionne alors c'est un choix spécifique à la bibliothèque et vous ne devriez pas lire beaucoup dans le fait qu'ils ont choisi la valeur 241. See here pour plus de détails sur le codage des caractères non-données tels que FNC1.

Je remarque aussi que vous passez C128A au paramètre type de write1DBarcode qui limite le symbole en mode A (chiffres, lettres majuscules et caractères de contrôle.) Ce serait terriblement inefficace et est susceptible d'entraîner un symbole trop large (ou trop dense lorsqu'il est redimensionné) pour numériser avec la plupart des équipements standard utilisés pour les applications logistiques.

Code 128 prend en charge un mode C qui offre une compression double densité de chiffres de sorte que vous devriez utiliser, probablement en passant type=C128C ou type=C128 (auto) dans l'hypothèse d'auto-encodage qui TCPDF est des symboles bons et futurs que vous allez créer peut besoin de contenir des lettres.

$label->write1DBarcode($codeString, 'C128', $x, $y, $w, $h); 

En ce qui concerne le texte lisible par l'homme sous le code à barres est concerné, si cela ne présente pas correctement pour les données correctement codées alors vous devrez peut-être soulever un rapport de bogue ou demande de fonctionnalité contre TCPDF.