bwip-js QRCode Scan Failure - Empty Data Mode 0100 (Byte encoding)

Hi,

I have an interesting bug reported by a user.

Consider these two QR Codes:

Created with BWIP

bwipjs-api metafloor com

Created with TEC-IT

qrcode-customer-tec-it

As far as I can tell, these should be the "same" but the BWIP version doesn't scan using a "Socket Mobile S740 barcode scanner." For what it's worth, these both scan using built-in iPhone QR scanner.

Here's where it gets interesting ... Using this online decoder/debugger https://qrlogo.kaarposoft.dk/qrdecode.html we see some interesting differences.

BWIP version:

skew_limit=3.984375
skew=0
left=4 right=253 top=2 bottom=251
size=250
findModuleSize matchVersion version=1 grade=0
matchVersion version=2 finder0=64 finder1=64 finder2=64
matchVersion version=2 timing0=1 timing1=1 alignment=1
matchVersion version=2 format_NW =9 0 format_NESW =9 1 format = 9 ecl = 1 mask = 1
matchVersion version=2 grades(F(V)TAF): 4444->4
findModuleSize matchVersion version=2 grade=4
findModuleSize version=2 grade=4 error_correction_level=1 mask=1
getCodewords mask=1 length=44
getCodewords = 64,2,9,169,126,144,160,78,171,190,119,240,116,235,169,240,144,13,125,41,8,0,236,17,236,17,236,17,236,17,236,17,236,17,171,155,39,228,235,171,69,33,167,7
setBlocks n_blocks_first=1 n_blocks_second=0 n_blocks=1 n_block_words_first=34 n_block_words_second=0 n_block_ec_words=10 total=44
setBlocks block 0 (44): 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43
RS calculateSyndroms: No errors
correctErrors in = 64,2,9,169,126,144,160,78,171,190,119,240,116,235,169,240,144,13,125,41,8,0,236,17,236,17,236,17,236,17,236,17,236,17,171,155,39,228,235,171,69,33,167,7
correctErrors out = 64,2,9,169,126,144,160,78,171,190,119,240,116,235,169,240,144,13,125,41,8,0,236,17,236,17,236,17,236,17,236,17,236,17
error_grade=4
extractData bytes in (34) = 64,2,9,169,126,144,160,78,171,190,119,240,116,235,169,240,144,13,125,41,8,0,236,17,236,17,236,17,236,17,236,17,236,17
extractData mode = 4
extract charcount = 0
extractData mode = 2
extractAlphanum charcount = 19
extractData mode = 4
extract charcount = 3
extractData mode = 0
extractData data(22) = 69,88,45,74,69,66,65,74,76,68,76,69,78,73,65,76,69,45,50,95,74,66

TEC-IT version:

skew_limit=2
skew=0
left=0 right=99 top=0 bottom=99
size=100
matchVersion version=1 finder0=34 finder1=34 finder2=32
findModuleSize matchVersion version=1 grade=0
matchVersion version=2 finder0=64 finder1=64 finder2=64
matchVersion version=2 timing0=1 timing1=1 alignment=1
matchVersion version=2 format_NW =9 0 format_NESW =9 1 format = 9 ecl = 1 mask = 1
matchVersion version=2 grades(F(V)TAF): 4444->4
findModuleSize matchVersion version=2 grade=4
findModuleSize version=2 grade=4 error_correction_level=1 mask=1
getCodewords mask=1 length=44
getCodewords = 32,154,151,233,10,4,234,187,231,127,7,78,186,159,9,0,215,210,144,128,236,17,236,17,236,17,236,17,236,17,236,17,236,17,169,61,21,72,169,146,31,204,44,131
setBlocks n_blocks_first=1 n_blocks_second=0 n_blocks=1 n_block_words_first=34 n_block_words_second=0 n_block_ec_words=10 total=44
setBlocks block 0 (44): 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43
RS calculateSyndroms: No errors
correctErrors in = 32,154,151,233,10,4,234,187,231,127,7,78,186,159,9,0,215,210,144,128,236,17,236,17,236,17,236,17,236,17,236,17,236,17,169,61,21,72,169,146,31,204,44,131
correctErrors out = 32,154,151,233,10,4,234,187,231,127,7,78,186,159,9,0,215,210,144,128,236,17,236,17,236,17,236,17,236,17,236,17,236,17
error_grade=4
extractData bytes in (34) = 32,154,151,233,10,4,234,187,231,127,7,78,186,159,9,0,215,210,144,128,236,17,236,17,236,17,236,17,236,17,236,17,236,17
extractData mode = 2
extractAlphanum charcount = 19
extractData mode = 4
extract charcount = 3
extractData mode = 0
extractData data(22) = 69,88,45,74,69,66,65,74,76,68,76,69,78,73,65,76,69,45,50,95,74,66

Same decoded bytes... but the thing that caught my eye is BWIP's possibly superfluous:

extractData mode = 4
extract charcount = 0

According to Wikipedia QR Encoding:

2020-10-01 at 7 48 PM

4 == 0100 == Byte encoding

Thoughts on this?

Oct 02 '20 00:10 semireg

Please show the options/values used in bwip-js to generate the barcode.

Oct 02 '20 01:10 metafloor

Hi @metafloor, they are linked in the URL above.

https://bwipjs-api.metafloor.com/?bcid=qrcode&text=EX-JEBAJLDLENIALE-2_JB&eclevel=L&scale=2

Oct 02 '20 01:10 semireg

Please verify the following barcode with your scanner:

Oct 02 '20 01:10 metafloor

I've submitted to my customer. I'll report back when I hear from them. 👍 Thank you!

Oct 02 '20 01:10 semireg

@metafloor, the customer reports this barcode is not scannable with their scanner. Hmm. 🤔

Oct 02 '20 14:10 semireg

@terryburton: Hope you are following this. Comparing the debug output provided for the BWIPP/bwip-js generated symbol:

extractData bytes in (34) = 64,2,9,169,126,144,160,78,171,190,119,240,116,235,169,240,144,13,125,41,8,0,236,17,236,17,236,17,236,17,236,17,236,17
extractData mode = 4
extract charcount = 0
extractData mode = 2
extractAlphanum charcount = 19
extractData mode = 4
extract charcount = 3
extractData mode = 0

Against the TEC-IT symbol:

extractData bytes in (34) = 32,154,151,233,10,4,234,187,231,127,7,78,186,159,9,0,215,210,144,128,236,17,236,17,236,17,236,17,236,17,236,17,236,17
extractData mode = 2
extractAlphanum charcount = 19
extractData mode = 4
extract charcount = 3
extractData mode = 0

Note how the BWIPP symbol starts in mode 4 and encodes zero bytes, then switches to mode 2. I am wondering if that bit of oddness is what the scanner is glitching on. That last barcode that I had the OP check was produced by BWIPP's online generator. It has identical encoding as the original bwip-js symbol. (bwip-js doesn't have all the new ECI updates you've recently added.)

Oct 02 '20 15:10 metafloor

@metafloor:I suspect your analysis is correct. I'm working on the optimisation code now...

Oct 02 '20 15:10 terryburton

@semireg Please could you ask the customer to test the following which has been generated using https://github.com/bwipp/postscriptbarcode/commit/cad3e87bbbff84cdca870cbf914bf7776cc0fbba which fixes the erroneous byte-mode selection for the start:

Oct 02 '20 15:10 terryburton

@terryburton Will do!

Oct 02 '20 15:10 semireg

The user has confirmed they can scan the latest barcode in this thread. 😄

Oct 02 '20 17:10 semireg

The user has confirmed they can scan the latest barcode in this thread.

Good. BWIPP 2020-10-02 released.

Oct 02 '20 18:10 terryburton

Looks like the PS to JS trace compiler is having issues with some of the new code constructs. Will need to do some sleuthing this weekend to track it down...

Oct 02 '20 19:10 metafloor

Working through the PS/JS translation issue is going to take more time than I have right now. So I have patched the current version of BWIPP that is being used by bwip-js with the additional optimization check that was added to the latest release. This is the barcode image produced by the patched version of bwip-js:

It is different from the one Terry uploaded as it is missing the ECI mode (not needed for ASCII data).

@semireg: Please have the customer verify against their scanner.

@terryburton: Thank you for the quick response!

Oct 03 '20 16:10 metafloor

It is different from the one Terry uploaded as it is missing the ECI mode (not needed for ASCII data).

@metafloor LGTM. The only difference it that your symbol is generated with eclevel=L whereas mine is eclevel=M.

Oct 03 '20 17:10 terryburton

@metafloor, if you push to a feature branch I'll build a beta for my user to test on Monday morning. Thank you so much.

Oct 03 '20 21:10 semireg

Not sure why github auto-closed this issue. The patch passes all tests so pushing to the master branch. Please give it a try.

Oct 04 '20 16:10 metafloor

bwip-js bwip-js copied to clipboard

QRCode Scan Failure - Empty Data Mode 0100 (Byte encoding)

bwip-js
bwip-js copied to clipboard