DataBar Expanded: FNC1 latches to numeric, workaround incorrect latch

[gitlost]

Fixes DataBar Expanded decoding of FNC1 ("01111") in general purpose field, which should latch to numeric (ISO/IEC 24724:2011 Table 12 and Table 13).

Plus a wWorkaround for generators that incorrectly encode a numeric latch ("000") after an FNC1. (There are a number of examples of this in the test samples: rssexpanded-1/{10,11,32}.png, rssexpanded-3/{75,76,108}.png, rssexpandedstacked-1/{22,23,55}.png)

Unit test. Test samples generated by Zint.

[axxel]

I don't understand your comment about samples present that are affected by this (wrong) encoder behavior. If those 9 existing samples were affected, then their expected text result would need to change, too?

[gitlost]

The encodings are the same except that FNC1 is encoded in effect as "01111000" instead of "01111". So the text is unaffected. Without the workaround the samples would fail to scan as the decoding goes out of sync.

I should mention that the workaround means that correctly encoded barcodes could fail if a generator put an Alphanumeric latch directly after the FNC1, but this is very unlikely as there's no reason to do that, AIs (GS1 Application Identifiers) being numeric.

Alternatively the workaround could be removed and the badly encoded samples left to fail. I don't know what generated them in the first place.

[axxel]

My question still remains: e.g. the mentioned rssexpanded-1/10.png reads as (01)98898765432106(15)991231(3103)001750(10)12A(422)123(21)123456(423)012345678901 without your workaround. What is wrong with that?

[gitlost]

There's 2 parts to the change: 1) the fix, which sets the encoding state to NUMERIC; 2) the workaround, which skips a numeric latch. Without the fix, correctly encoded barcodes won't scan (this is how I discovered the bug). With the fix but without the workaround, the mentioned samples won't scan.

[axxel]

Now I get it (and finally have the time and energy again to open my github page ;)). Thanks as always.