[reportlab-users] barcodes encoded with Code 128 not always optimally encoded

[Josh Hieronymus]

Right now I just have access to an Android phone with the ZXing Barcode
Scanner client, which is what I've been using to test some of my own Code
128 barcode-producing software. I should be able to make the necessary
changes to the code myself, but I can only test it with the ZXing client at
the moment. There is another avenue for testing, which would be to
hand-generate some barcode images and encoding patterns to compare with the
output. Would the combination of using the ZXing client to read the output
and doing comparisons with hand-generated images and encodings be
sufficient for testing purposes?

On Sun, Feb 24, 2013 at 9:08 AM, Andy Robinson <andy at reportlab.com> wrote:


> Josh, thanks for this.

>

> The barcode code was a contribution from someone who worked in the

> field, and none of our current developers are very familiar with the

> standards.  We adopted a pretty simple standard of "if our scanner

> reads it, it's OK".  I am a little nervous of making a change.  Are

> you in a position to help with testing on a variety of readers if we

> make a change?

>

> - Andy Robinson, ReportLab

>

>

> On 24 February 2013 00:09, Josh Hieronymus <josh.p.hieronymus at gmail.com>

> wrote:

> > I've noticed that when I use ReportLab to create Code 128-encoded

> barcodes,

> > the barcodes are longer than they need to be. The barcode created by

> > Code128("A\x00"), for example, encodes two extra symbols. Looking through

> > code128.py, it seems that the generated barcode for this example

> > unnecessarily begins in subcode B, switches to subcode A to code the

> symbol

> > for "\x00", then switches back to subcode B. If the barcode started in

> > subcode A, it would not need to switch.

> _______________________________________________

> reportlab-users mailing list

> reportlab-users at lists2.reportlab.com

> http://two.pairlist.net/mailman/listinfo/reportlab-users

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/reportlab-users/attachments/20130224/e0a0a3a5/attachment.htm>