[reportlab-users] upc-a barcodes

[Steve Romanow]

I understand that upc-a and its ilk are related to EAN-13, however, it
does not seem trivial to get UPC-12 barcodes out of ean.py.

Between upc-12, ucc's, and ean's it is dangerous to use the length of
the string as an indicator as to how it should be encoded. Is this
already sorted out in teh community and I am just behind?

Thanks,

Steve
_______________________________________________
reportlab-users mailing list
reportl...@lists2.reportlab.com
http://two.pairlist.net/mailman/listinfo/reportlab-users

[Peter]

On Tue, Sep 7, 2010 at 9:51 PM, Steve Romanow <slest...@gmail.com> wrote:
>
>  I understand that upc-a and its ilk are related to EAN-13, however, it does
> not seem trivial to get UPC-12 barcodes out of ean.py.
>
> Between upc-12, ucc's, and ean's it is dangerous to use the length of
> the string as an indicator as to how it should be encoded. Is this
> already sorted out in teh community and I am just behind?

It has been a while since I worked on this, but aren't 12 digit UPC-12
barcodes the same thing as a 13 digit EAN barcode with a leading
zero added?

In a sense, you *have* to look at the length to tell them apart ;)

i.e. If you have a 12-digit UPC barcode number, you can add a
leading zero and it becomes a 13-digit EAN barcode number, and
both should give identical barcode images.

Also, if you have a UPA barcode image, it is by definition also
an EAN-13 barcode image, so you can read it as either, giving
a 12 or 13 digit barcode number. Which you get is normally
handled as part of the barcode scanner configuration.

Peter

[Andy Robinson]

I have to admit that within ReportLab we don't get involved with
real-world barcoding much and our knowledge is severely limited.

We are therefore reliant on all of you to tell us
(a) if anything in the software is actually wrong, or should be changed, and
(b) if we are explaining it incorrectly in our docs.

It sounds to me like there is a case for a subclass of EAN13 to
implement UPC-12, which would validate the input more strictly and add
the zero behind the scenes.

Time permitting, we are probably going to rig up a 'test page' on our
website - a web form with a text field that renders a bitmap. This
would initially for QR codes but it could cover more codes - in the
hope that people will be able to give feedback without needing to
install our package and write Python code.

- Andy

[Steve Romanow]

On 9/8/2010 5:11 AM, Peter wrote:
> On Tue, Sep 7, 2010 at 9:51 PM, Steve Romanow<slest...@gmail.com> wrote:
>> I understand that upc-a and its ilk are related to EAN-13, however, it does
>> not seem trivial to get UPC-12 barcodes out of ean.py.
>>
>> Between upc-12, ucc's, and ean's it is dangerous to use the length of
>> the string as an indicator as to how it should be encoded. Is this
>> already sorted out in teh community and I am just behind?
> It has been a while since I worked on this, but aren't 12 digit UPC-12
> barcodes the same thing as a 13 digit EAN barcode with a leading
> zero added?
>
> In a sense, you *have* to look at the length to tell them apart ;)
>

I think my difficulty with this stems from storage of UPC values with
the check digit already computed. Even if I took off the last char, the
barcode was still shifted one position when using ean.py. I have moved
on to another task, but will revisit this in the future.

[Peter]

On Wed, Sep 8, 2010 at 2:37 PM, Steve Romanow <slest...@gmail.com> wrote:
>
>> It has been a while since I worked on this, but aren't 12 digit UPC-12
>> barcodes the same thing as a 13 digit EAN barcode with a leading
>> zero added?
>>
>> In a sense, you *have* to look at the length to tell them apart ;)
>
> I think my difficulty with this stems from storage of UPC values with the
> check digit already computed.  Even if I took off the last char, the barcode
> was still shifted one position when using ean.py.  I have moved on to
> another task, but will revisit this in the future.

Again, this is from memory, but isn't the check digit the trailing (right
most) digit? On the other hand, the "extra" leading zero present in
EAN13 barcodes is the left-most digit.

I don't recall the details, but computing the check digit on demand
is pretty easy.

If you are storing 11 digit UPC numbers without the check digit, you
would have to compute and append the missing checkdigit to get a
full 12 digit UPC number, and add the leading zero if you wanted to
turn this into a full 13 digit EAN number. (Or do the reverse if that
is what you meant).

Peter

[Steve Romanow]

IIRC, the ean.py routine does the check digit calculation for you, even
if you already have it on there.