[scribus] barcodes

[Terry Burton]

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