search

zint / zint-gpl-only

Zint Barcode Generator
https://zint.org.uk/
GNU General Public License v3.0
522 stars 137 forks source link

Accept 13 digits for EAN-13 #13

Closed Sukender closed 2 years ago

Sukender commented 12 years ago

Hi, It seems EAN-13 isn't supported, where EAN-12 is. Could this be easy to patch? Cheers,

woo-j commented 9 years ago

There is no EAN-12 standard! Zint supports EAN-8 (7-digit input) and EAN-13 (12 digit input).

oehhar commented 9 years ago

I suppose, the poster spoke about UPC-A which is very similar to EAN-13 but contains 12 digits...

Sukender commented 9 years ago

Sorry, this was a old post :)

When posted, I didn't know that EAN-13 had 12 digit input. Actually I was trying to replicate an existing EAN-13 code. Of course, typing 13 digits resulted in an error (hence this issue). But typing the 12 first digits perfectly does the job (the last digit being deduced).

So, yes, zint supports what I want. But maybe it's a bit confusing for users that do not know how codes work. Here is my suggestion:

oehhar commented 9 years ago

Unfortunately, zint goes over the aim. The check digit is part of the data and not part of the code. It should be possible to enter 13 characters. But, in practice (Supermaret, books etc), the check digit is always used so the current behavior may match user expectations. I personally dont like those automatic things on a low-level system...

woo-j commented 9 years ago

It's an interesting question which afftects any barcode which uses GTIN: EAN, UPC, DataBar, ITF-14 or even any symbol which can encode GS1 data. Zint is quite inconsistent in how it deals with this - for example with DataBar-14 it will calculate the check digit, the same as EAN, but DataBar Expanded requires the user include the check digit, and doesn't perform any check to see if it is valid.

Having Zint automatically generate the check digit does kind of circumvent the purpose of that check digit - to validate the user input. It relies on the user checking that the check digit is what they expected.

On the other hand if I were using the generator to produce a range of barcodes, say for a series of books which have consecutive ISBNs, I would find having to calculate all of the check digits first a tedious extra step.

I'm guessing that most of the time people will be generating EANs, UPCs and ITF-14s from data which will include the check digit, so it would seem to make sense to have logic which says "if I have 13 digits, then the last one should be the check digit, go and check it!".

This also raises a question about UPC-E - the input for which matches the barcode to be produced rather than the GTIN which it represents.

Perhaps what is really needed here is more information about how Zint is actually being used - despite the fact that I wrote most of the code, I don't actually make use of it, so don't know what format the input data is likely to take.

Sukender commented 9 years ago

True.

So, how about generalizing my suggestion (= optionally accept the extra digit(s) and warn if they are not valid)?

oehhar commented 9 years ago

This is a good suggestion. Added to the sourceforge tracker: https://sourceforge.net/p/zint/tickets/5/

gitlost commented 2 years ago

EAN-13 now accepts 12 or 13 digit input so marking as closed, thanks for the suggestion.