Expanding the test code coverage for Okapi Barcode recently, I ran across what looks like a pair of bugs in the DataBar Expanded implementation -- and Zint appears to have a similar issue. Specifically, when FNC1 is encountered during ALPHA or ISOIEC encodation, the mode is being changed to NUMERIC. However, I don't think this is necessary or desired -- I think we want to stay in the current encodation mode.
Okapi Barcode commit which fixed the issue here:
https://github.com/woo-j/OkapiBarcode/commit/1618589376f23db7436d6a9de14ffc77ef58f6c5
Two test cases which trigger the bug here:
This was initially detected because we verify that each of our Okapi test barcodes can be decoded by the ZXing library, and ZXing failed to decode these two test samples without this change.
Corresponding lines in the Zint code:
https://sourceforge.net/p/zint/code/ci/master/tree/backend/rss.c#l1666
https://sourceforge.net/p/zint/code/ci/master/tree/backend/rss.c#l1705
Hi Daniel,
I've had a look at this and I think the code in Zint is right. Here is my reasoning...
The specification (ISO 24724) refers to the sequence 01111 as "FNC1/Numeric latch" in both table 12 (alphanumeric encodation) and table 13 (ISO/IEC 646 encodation).
FNC1 in a GS-1 symbol will always be followed by an AI, and AIs are always numeric, so it makes sense to have an implied latch to numeric mode, reducing the length of the general purpose data compaction field by 3 binary digits.
Tec-It's encoder seems to produce the same symbol as Zint:
https://barcode.tec-it.com/en/RSSExpanded?data=420TEST%5CF39231234567
Robin.
Hi Robin,
Thanks for looking at this! Your logic sounds right to me, and it's compelling that other tools generate the same output. I'm going to leave the implicit mode change out in Okapi for now in order to achieve wider compatibility (with e.g. ZXing), but hopefully it can be added back in at some point.
Daniel
Daniel,
may this ticket be closed ?
Thank you,
Harald
I think it is safe to close this ticket now.