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
