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

[semireg]

Hi,

I have an interesting bug reported by a user.

Consider these two QR Codes:

Created with BWIP

Created with 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:

4 == 0100 == Byte encoding

Thoughts on this?

[metafloor]

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

[semireg]

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

[metafloor]

Please verify the following barcode with your scanner:

[semireg]

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

[semireg]

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

[metafloor]

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

[terryburton]

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

[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:

[semireg]

@terryburton Will do!

[semireg]

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

[terryburton]

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

Good. BWIPP 2020-10-02 released.

[metafloor]

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

[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!

[terryburton]

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.

[semireg]

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

[metafloor]

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