UPC-A barcode render effect broken - generating 13-digits instead of 12

Bug #301129 reported by Reederoo
6
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
Medium
Unassigned

Bug Description

The effects->render>barcode barcode generator does not work for UPC-A (and maybe others) in v .46. UPC-A codes should consist of 11 digits plus a checksum for the 12th digit. Instead, Inkscape requires 12 digits to be entered and calculates a 13th digit as a checksum, which results in a 13-digit bar code with 1 leading digit, and then 6 digits on each side of the code, and no trailing digit. The UPC-A code SHOULD HAVE BEEN: 12 digits with 1 leading digit, then 5 each on each side of the center, and then 1 checksum digit trailing.

Entering anything except a 12-digit number gives the following error message:
Can not encode '71812280523' into EAN13 Barcode, Size must be 12 numbers only
No barcode was generated

That error message was generated when the "Barcode Type" was set to UPC-A and an 11-digit number was entered into the field. In other barcode generation software, UPC-A codes accept 11 digits and then auto-calculate the 12th digit. The error message given above suggests the UPC-A function is expecting a 12-digit EAN13 number. Apparently, the UPC-A setting is not invoking the code for UPC-A?

Please let me know if there is a fix for this in some unreleased version. I'd really like to use this effect as soon as possible
Thank you!

Related branches

Revision history for this message
Šimánek (jasonsimanek) wrote :

I am just learning about UPC codes, but I am working on a product package design and was hoping this 'Effect' would allow me to regenerate the existing raster barcode image provided by my client. Unfortunately none of the UPC types seem to generate the 1-5-5-1 number arrangement or even a bar code that matches the raster example. Outside of this problem, the feature seems to have a lot of promise!

Revision history for this message
jwelshjr (jwelshjr) wrote :

Ditto. I venture that there are a lot more folks who would appreciate this fix than are speaking up about it. Part of that may simply be that they see a code generated and don't realize it is incorrect. This might seem like an insignificant issue to some, but it is a big deal for others of us. I see a bit of chatter in various blogs, etc. about this not working correctly. Hope to see a fix sooner than later - it's already been quite a while.

su_v (suv-lp)
tags: added: extensions-plugins
Revision history for this message
mbeach (mbeaches) wrote :

using ubuntu 9.04, jaunty, version 0.45, built April 8, 2009, if you edit the
/usr/share/inkscape/extensions/render_barcode.inx
file, and amend line 10 from:
<item value="ean13">UPC-A</item>
to
<item value="upca">UPC-A</item>

the proper rendering behaviour for UPC-A barcodes is achieved. You can then use either 11 or 12 digits, if 11, the last check digit is calculated, if 12, the last digit is checked to be correct (I believe).

I suspect lines 11 and 12 of that inx file may also need to be corrected (hunch).

good luck,
mb.

Revision history for this message
mbeach (mbeaches) wrote :

As it turns out, if you only have the 12 digits, the checksum digit is not calculated correctly (runtime attribute error).

I've found if you modify the varifyChecksum function in
/usr/share/inkscape/extenstions/Barcode/EAN13.py

to look like:
 def varifyChecksum(self, number):
  #new = self.computeChecksum(number[:12])
  new = self.getChecksum(number[:11])
  existing = number[11]
  return new == existing

the UPC-A checksum works correctly, however, not knowing about EAN13 and UPC-E, those also call the varifyChecksum function, so editing that function may break those upc code generators.

Revision history for this message
mbeach (mbeaches) wrote :

... and if the devs happen to be looking here, may as well change line 46 to correct typo in the error string to users:

/usr/share/inkscape/extenstions/Barcode/EAN13.py

sys.stderr.write("EAN13 Checksum not correct for this barcode, omit last character to generate new checksum.\n")

instead of
"charicter"

Revision history for this message
su_v (suv-lp) wrote :

> version 0.45
is this version number correct? Do your changes also work with the just released Inkscape 0.47?

current version of 'extensions/Barcode/*' in the 0.47 SVN branch:
<http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/branches/RELEASE_0_47_BRANCH/share/extensions/Barcode/>
current version of 'extensions/Barcode/*' in the 0.47 SVN HEAD:
<http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/share/extensions/Barcode/>

Revision history for this message
mbeach (mbeaches) wrote :

sorry about that - 0.46, not 0.45.

I haven't tried 0.47 yet - been short on time and didn't want to lose any functionality.

However, looking at the svn release:

EAN13.py
http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/share/extensions/Barcode/EAN13.py?revision=20466&view=markup

- still contains the typo for 'character'

- appears to me that the UPC-A functionality would be broken if the user was to enter a 12 digit number. It looks like the checksum digit would be validated, but throw an index out of range error in the varifyChecksum function for UPC-A barcodes (again - not sure about the UPC-E and EAN13).
in head and release 0.47 it is:
 def varifyChecksum(self, number):
  new = self.getChecksum(number[:12])
  existing = number[12]
  return new == existing
I would think that those 12's should be 11's.

UPCA.py file:
http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/share/extensions/Barcode/UPCA.py?revision=20240&view=markup

- I think the error message there on line 37 should be amended to indicate UPC-A and fix the typo in 'character' here as well.
- From reviewing that bit of code, it definitely looks like only a 12 digit code is being sent off to the varifyChecksum function, thus should cause an error when that function fires.

The render_barcode.inx file looks good, the item values match the onscreen descriptions.
http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/share/extensions/render_barcode.inx?revision=20241&view=markup

It would appear patch 1681456 may have fixed most of this - from the svn notes: "Add doctormo's barcode extension. Patch 1681456."

I'll install 0.47 and give it a whirl.

Revision history for this message
su_v (suv-lp) wrote :

There is also work in progress to add EAN-5 to this extension - tracked in bug #477809 “No EAN-5 barcode”:
<https://bugs.launchpad.net/inkscape/+bug/477809>

Maybe you can then merge your proposed changes with the updated version for EAN-5 by Alvin Penner?

Revision history for this message
mbeach (mbeaches) wrote :

Hi ~suv,

I would love to, but sorry, I don't quite have the ability to merge and submit (don't know how).

The error is thrown in version 0.47 (Inkscape 0.47pre0 r21549, built Jun 12 2009) - I can't seem to find any more recent .deb

Regardless, I suggest the varifyChecksum could be as follows so that it is not hard coded for 13 characters (EAN13) or 12 (UPC-A), instead it would just check the last digit - since the calling function already checks for correct/valid lengths:

 def varifyChecksum(self, number):
  new = self.getChecksum(number[:-1])
  existing = number[-1]
  return new == existing

http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/share/extensions/Barcode/EAN13.py?revision=20466&view=markup

While at it, might be good to rename it to "verifyChecksum"

Revision history for this message
su_v (suv-lp) wrote :

Attaching patch file against current SVN (r22598) for the three files with your changes.

Revision history for this message
su_v (suv-lp) wrote :

SVG with UPC-A and EAN13 tested unpatched (r22598) and patched

Changed in inkscape:
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Alvin Penner (apenner) wrote :

- running Windows XP and Inkscape 0.47 r22583 (Nov 21 2009)
- I am attaching an svg file with two of the above barcodes in it, generated using UPC-A. As far as I can see they are behaving as expected. Could someone confirm whether there are still outstanding issues that need to be fixed?

Revision history for this message
su_v (suv-lp) wrote :

Did you try it with the proposed changes from comment #9 (attached as patch in comment #10) or the unchanged version included in 0.47?

Revision history for this message
Alvin Penner (apenner) wrote :

sorry about that, I just tried to duplicate the svg from comment 11 and I see there are still some remaining problems. I'll try to look at this once the trunk re-opens for business, and if I can successfully start up bzr or whatever.

Revision history for this message
su_v (suv-lp) wrote :

When I make the changes as proposed by mbeach, I can enter a 12-digit for UPC-A and the code is generated without errors whereas with the unpatched version included in the released Inkscape 0.47 entering a 12-digit number for UPC-A gets the predicted error failing with:

(…)
  File "/Volumes/blue/src/Inkscape/Inkscape-0.47-1.LEOPARD+/Inkscape-047-1.app/Contents/Resources/extensions/Barcode/EAN13.py", line 88, in varifyChecksum
    existing = number[12]
IndexError: string index out of range

tested with these numbers:
a) UPC-A: 71812278372
b) UPC-A: 718122783724

Revision history for this message
Alvin Penner (apenner) wrote :

thanks, mbeach and ~suv!
I've applied the patch from comment 10 to my files and have duplicated the svg results in comment 11.
Everything looks good to me, will try to commit these changes as soon as it is allowed to do so...

su_v (suv-lp)
Changed in inkscape:
status: Triaged → In Progress
Revision history for this message
mbeach (mbeaches) wrote :

no problem - love this program and wish I was able to contribute more.

Alvin Penner (apenner)
Changed in inkscape:
status: In Progress → Fix Committed
jazzynico (jazzynico)
Changed in inkscape:
milestone: none → 0.48
jazzynico (jazzynico)
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.