On Thu, May 15, 2014 at 4:02 AM, Terry Burton <tez at terryburton.co.uk> wrote:
> On 14 May 2014 17:40, Gregory Pittman <gpittman at iglou.com> wrote: > > I think it's worth pointing out that there is more than one way to skin > > a barcode. > > > > The main thing that the barcode generator offers is convenience. It's > > not the only way, and in some ways not the best method for generating > codes. > > > > Barcodes follow a set of rules that typically involve the following: > > > > 1. Thin line elements > > 2. Thick line elements > > 3. Thin space elements > > 4. Thick space elements > > 5. Starting and stopping codes, to show where a barcode begins, and > > where it ends > > 6. Checksum elements > > 7. Some restrictions on which characters can be coded > > > > Once you are able to get access to the rules of a particular code, it is > > not difficult (I wouldn't call it trivial) to create such codes within > > Scribus. > > Hi, > > I entirely agree that there is a certain elegance and efficiency in > making barcodes using routines that are native to Scribus. > > However, for barcode formats more complicated than Code 39 or EAN/UPCs > the generation process in nowhere near this simple. > > > Mathematicians and coders talk about elegance in some formula or code. > > The elegance in these scripts, I think, is that they are native Scribus > > generators of barcodes, using lines and spaces of precise width and > > numerically spaced on the page. The length of the lines is also user > > definable, as is the font used when you wish to show the code in > > numerical format. > > I think that the key question is whether the Scribus project has the > resources to develop and maintain a niche feature over the long term. > To do so requires access to the International Standards, huge amounts > of coding and testing effort (see below), as well as continuous access > to barcode verification equipment costing in excess of ?2000, as well > as independent certification for some formats used by postal services, > pharmaceuticals and healthcare whose entry into the supply chain is in > some cases regulated. > > A native-to-Scribus barcode generator will get no where near the > amount of exposure and field testing as a common library and so > quality and confidence in the output would be dubious for some time. > This has commercial implications, especially in the case of point of > sale symbols where the cost of product recall due to a barcode > misprint is high. > > Speaking from personal experience, to gauge the development effort > required to create a credible set of POS symbols consider just some of > those which are expected to be commonplace at point of sale within the > next 10 years [1]. In terms of my library this breaks down into the > following amount of largely mathematical coding: > > EAN/UPC Composite = ~2500 SLOC > GS1 DataBar Composite = ~3500 SLOC > GS1 QR Code = ~1100 SLOC > GS1 DataMatrix = ~700 SLOC > > It's a tall order and the popular open source libraries (such as Zint) > have really struggled to maintain development focus over the years. > > > [1] http://www.gs1.org/barcodes/technical/bar_code_types > > > All the best, > > Terry > > Hey Terry, I'm enjoying this thread. Thank you for taking the time to explain some of the complexities involved and for your work on this subject. Very interesting. Cheers, /Kunda -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.scribus.net/pipermail/scribus/attachments/20140515/c13cdfe0/attachment.html>
