#15 Some Databar issues
Hi there,
I've found two issues in Databar barcodes implementation in Zint.
Buffer overrun
I tryed to make a Databar Stacked Expanded barcode with data arranged this way: (17)140704(01)90614141000015(10)AB-123 in 4-segments mode, but get just a single row instead of 3 rows. However, if I swap 01 and 17 application ids, it works fine.
After some debugging I tracked this down to the very beginning of the rss_binary_string() function where you allocate space for general_field and general_field_type arrays by using strlen(source) as a size. This leaves no space for the trailing zero if the whole source line goes uncompressed.
The fix is to add +1 to both strlen() calls there. Worked fine for me. There is another function called rssexpanded() that has the same issue. There must be +1 there for both general_field and general_field_type variables, as otherwise there may be not enough space for terminating zero.
Databar compression
Some of the databar barcodes I created with Zint were not parsed by various online decoders, so I traced this down to general_rules() function that tries to plan a better compression. I did some comparisons with GS1 software (http://www.gs1.org/barcodes/databar/software) and found that for the block "(10)-000" which is converted to "10-000" you make "nnannn" rules line, while the GS1 implementation makes "nnaaaa" one. After some investigations it's been traced down to these lines:
if(current == ALPHA_OR_ISO) {
block[1][i] = ALPHA;
}
The problem is that in the next block of code you check the "current" variable again, but it is not updated with the block array item. So here is the fix:
if(current == ALPHA_OR_ISO) {
current = block[1][i] = ALPHA;
}
The data line that you can use for tests is "(01)00000000000000(10)-000", the main idea is that you need a non-number, followed by some numbers. I don't know whether it is OK to encode the same data a different way, but it seems that online decoders cannot handle "nnannn" case, while "nnaaaa" case works just fine.
Hope this helps. Once again thanks for your amazing library!
Thank you for your well-researched and well-documented bug report. I have put both your fixes into the repository.
I can confirm your second fix now produces correct behaviour - the standard states "Whenever an Alphanumeric latch is encoded, the encodation scheme is changed to reflect that latch." (ISO 24724 §7.2.5.5.1) so those online decoders were right to reject the symbols.
Also, good tip finding the GS1 encoder, which I notice has the C code, too. It's interesting to see an "official" implementation.
Thanks for report and fix.
Could the reporter verify the effectiveness of the fix ?
May the ticket be closed ?
Thank you,
Harald
The fix is fine, you can close the ticket. Cheers :)