[scribus] barcodes

[Kunda Loves Scribus]

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>