I need to develop EAN-13 barcode support in next two weeks to migrate one university library from custom software. First step should be creation of RFC document, but I didn't receive confirmation e-mail from wiki, so I can't add it there directly. I tried with this and gmail.com e-mail address, so I would be greatful if somebody could help me with that. Basically, library now uses EAN-13[1] barcode which is zero-padded primary key in old system istead of ISBN or ISSN. Since books allready have barcodes on them, we can't change it. To make things more insteresting, at least one barcode reader reports it as UPC-A[2] without first leading zero, since EAN-13 has backwards compatibility with it. So, my first question is should I store barcodes padded with zeros in Koha? It seems that itemBarcodeInputFilter syspref and small change to barcodedecode in C4/Circulation.pm will support both solutions, and it seems to be that 13-digit EAN-13 with padded zeros is cleaner solution. Next, I would need to implement plugin which generates new barcodes in same format (with check digit). This would involve change to autoBarcode syspref in cataloguing/value_builder/barcode.pl and new C4/Barcode/EAN13.pm to support next barcode while ignoring last checksum digit. Finally, we need to print them. PDF::Reuse::Barcode allready supports EAN13, so it seems that small change to C4/Labels/Label.pm would be sufficiant. Am I missing something important other than tests? :-) 1: http://en.wikipedia.org/wiki/EAN-13 2: http://en.wikipedia.org/wiki/UPC-A -- Dobrica Pavlinusic 2share!2flame dpavlin@rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin
W dniu 2011-06-01 19:58, Dobrica Pavlinusic pisze:
I need to develop EAN-13 barcode support in next two weeks to migrate one university library from custom software.
First step should be creation of RFC document, but I didn't receive confirmation e-mail from wiki, so I can't add it there directly. I tried with this and gmail.com e-mail address, so I would be greatful if somebody could help me with that.
Basically, library now uses EAN-13[1] barcode which is zero-padded primary key in old system istead of ISBN or ISSN. Since books allready have barcodes on them, we can't change it.
To make things more insteresting, at least one barcode reader reports it as UPC-A[2] without first leading zero, since EAN-13 has backwards compatibility with it.
So, my first question is should I store barcodes padded with zeros in Koha? It seems that itemBarcodeInputFilter syspref and small change to barcodedecode in C4/Circulation.pm will support both solutions, and it seems to be that 13-digit EAN-13 with padded zeros is cleaner solution.
Next, I would need to implement plugin which generates new barcodes in same format (with check digit). This would involve change to autoBarcode syspref in cataloguing/value_builder/barcode.pl and new C4/Barcode/EAN13.pm to support next barcode while ignoring last checksum digit.
Finally, we need to print them. PDF::Reuse::Barcode allready supports EAN13, so it seems that small change to C4/Labels/Label.pm would be sufficiant.
Am I missing something important other than tests? :-)
1: http://en.wikipedia.org/wiki/EAN-13 2: http://en.wikipedia.org/wiki/UPC-A
By the way... we are using EAN13 in Koha 2.2.x without problems:) All 13-digits are saved in barcode field, to print barcodes we are using php class;) -- The Main Library of Szczecin University. Computerization Department. http://bg.szczecin.pl
On Wed, Jun 01, 2011 at 08:20:50PM +0200, Wojciech Zatorski wrote:
So, my first question is should I store barcodes padded with zeros in Koha? It seems that itemBarcodeInputFilter syspref and small change to barcodedecode in C4/Circulation.pm will support both solutions, and it seems to be that 13-digit EAN-13 with padded zeros is cleaner solution.
By the way... we are using EAN13 in Koha 2.2.x without problems:) All 13-digits are saved in barcode field, to print barcodes we are using php class;)
Ok, so I will store all 13 digits so you can have clean upgrade path :-) -- Dobrica Pavlinusic 2share!2flame dpavlin@rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin
I have made some progress this week. Changes are available at: http://git.rot13.org/?p=koha.git;a=log;h=refs/heads/koha-6448-EAN-13_barcode Curretly, they are split into several patches. Should I merge all the changes together before attaching it to related bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6448 or attach them one-by-one? Should I open separate bugs for itemBarcodeInputFilter, autoBarcode and label support? On Wed, Jun 01, 2011 at 07:58:28PM +0200, Dobrica Pavlinusic wrote:
First step should be creation of RFC document, but I didn't receive confirmation e-mail from wiki, so I can't add it there directly. I tried with this and gmail.com e-mail address, so I would be greatful if somebody could help me with that.
I still haven't received any wiki confirmation, so I'm spamming devel list. I hope you don't mind :-) -- Dobrica Pavlinusic 2share!2flame dpavlin@rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin
Dobrica Pavlinusic wrote:
Curretly, they are split into several patches. Should I merge all the changes together before attaching it to related bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6448 or attach them one-by-one?
I think either is fine, but maybe the RMs have an opinion?
Should I open separate bugs for itemBarcodeInputFilter, autoBarcode and label support?
I don't think I would, if the fixes are related.
On Wed, Jun 01, 2011 at 07:58:28PM +0200, Dobrica Pavlinusic wrote:
First step should be creation of RFC document, but I didn't receive confirmation e-mail from wiki, so I can't add it there directly. I tried with this and gmail.com e-mail address, so I would be greatful if somebody could help me with that.
I still haven't received any wiki confirmation, so I'm spamming devel list. I hope you don't mind :-)
No, that's fine. The wiki is currently crippled by http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6326 and we're a bit limited in who can fix it. Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha
participants (3)
-
Dobrica Pavlinusic -
MJ Ray -
Wojciech Zatorski