<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 15, 2014 at 4:02 AM, Terry Burton <span dir="ltr"><<a href="mailto:tez@terryburton.co.uk" target="_blank">tez@terryburton.co.uk</a>></span> wrote:<br>

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

<div><br></div><div>Cheers,</div><div>/Kunda</div></div></div></div>