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

[Robin Becker]

Josh,

make the fix if you feel able and then post the diff to us. We can test with our 
own barcode reader; if all's well then we can add the patch to our repos.


On 24/02/2013 20:23, Josh Hieronymus wrote:

> 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 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.

.....

>

At barcode island they support this assertion ie we can start in A, B or C. 
However, I'm not sure that I can prove optimality easily. The three character 
sets cover different value spaces and it's not clear to me when we should switch 
between them optimally. Wikipedia says it may be a dynamic programming problem. 
There are some easy special cases though. All uppercase ==> A, mixed case ==> 
'B' & all digits ==> C. Anything else is an issue.
-- 
Robin Becker