Codabar start/end control chars should be included in the result
Closed this issue · 3 comments
At least the native Barcode Detection APIs from Android Chrome and iOS17/macOS Sonoma 14 (which can be manually activated through Safari Settings) include the two start/end control chars (A,B,C or D) into the result.
There might be an appropriate (deprecated?) option in zxing-wasm:
https://zxing-wasm.deno.dev/interfaces/full.ReaderOptions.html#returnCodabarStartEnd
Perhaps it makes sense to conform to the current implementations of the native API in the fields.
There might be an appropriate (deprecated?) option in zxing-wasm:
Yes, this option will be removed but it will be enabled always. Ref: zxing-cpp/zxing-cpp#704
Can you confirm enabling this option aligns with the native Barcode Detection APIs from Android Chrome and iOS17/macOS Sonoma 14 in this demo page? Although it is marked as deprecated it still works.
Yes, this option will be removed but it will be enabled always. Ref: zxing-cpp/zxing-cpp#704
Thanks for pointing me to that discussion. Very interessting to read - also the thoughts behind Code-39 and Code-93 (during my tests, Andoid Chrome also was not able to scan Code-93 Extended and has Problems with ITF barcodes not having length of 14 chars).
Can you confirm enabling this option aligns with the native Barcode Detection APIs from Android Chrome and iOS17/macOS Sonoma 14 in this demo page? Although it is marked as deprecated it still works.
Seems they all output the control chars.
Scan in Android Chrome 127
using this webapp https://georapbox.github.io/barcode-scanner/ results in A2342342$2022+B
.
Scan in iOS 17.6.1 Safari
using this webapp https://georapbox.github.io/barcode-scanner/
with native Shape Detection API manually activated via Safari settings, results in A2342342$2022+B
.
Scanning Codabar barcode, with Return Codabar Start End activated:
using https://zxing-wasm-demo.deno.dev/ results in A2342342$2022+B
.
[
{
"isValid": true,
"error": "",
"format": "Codabar",
"bytes": {
"0": 65,
"1": 50,
"2": 51,
"3": 52,
"4": 50,
"5": 51,
"6": 52,
"7": 50,
"8": 36,
"9": 50,
"10": 48,
"11": 50,
"12": 50,
"13": 43,
"14": 66
},
"bytesECI": {
"0": 93,
"1": 70,
"2": 48,
"3": 65,
"4": 50,
"5": 51,
"6": 52,
"7": 50,
"8": 51,
"9": 52,
"10": 50,
"11": 36,
"12": 50,
"13": 48,
"14": 50,
"15": 50,
"16": 43,
"17": 66
},
"text": "A2342342$2022+B",
"eccLevel": "",
"contentType": "Text",
"hasECI": false,
"position": {
"topLeft": {
"x": 42,
"y": 2
},
"topRight": {
"x": 345,
"y": 2
},
"bottomRight": {
"x": 345,
"y": 101
},
"bottomLeft": {
"x": 42,
"y": 101
}
},
"orientation": 0,
"isMirrored": false,
"isInverted": false,
"symbologyIdentifier": "]F0",
"sequenceSize": -1,
"sequenceIndex": -1,
"sequenceId": "",
"readerInit": false,
"lineCount": 100,
"version": ""
}
]
Thank you, I think I should change the returnCodabarStartEnd
option for this library. This might be a breaking change for others but I consider this as a bug given that this library is meant to be used as a polyfill, so a patch release will be published including this fix.