UPC_A support on iOS?

[timdmackey]

With the demo app, even though the app is set to scan EAN_13 codes, it still scans UPC_A codes and just adds a zero to the beginning of them. In fact, this isn't surprising given that EAN_13 is a superset of UPC_A, and 12-digit UPC_A codes can be converted to an equivalent EAN_13 code by prepending a zero to the code.

This leads me to wonder, why is it that UPC_A codes aren't supported on iOS? What is preventing it? Is it possible to add support? Or should I be using EAN_13 for both, and treating all UPC_A codes as EAN_13?

[EddyVerbruggen]

I think it actually does support UPC_A because of what you mentioned. So with EAN_13 enabled you can also scan UPC_A, according to this: https://developer.apple.com/documentation/avfoundation/avmetadataobjecttypeean13code?language=objc

Do you think updating the readme would suffice?

[timdmackey]

Good point, thanks for the link to Apple’s docs. I also found this page that explicitly states the behavior of adding a leading zero: https://developer.apple.com/library/archive/technotes/tn2325/_index.html#//apple_ref/doc/uid/DTS40013824-CH1-IS_UPC_A_SUPPORTED I think how to proceed may depend on how Android behaves when using the UPC_A flag. If Android returns a 12-digit code, the inconsistency would be problematic if developers aren’t aware that they’ll need to normalize the codes before using the data.

…

On Dec 6, 2018, 2:51 AM -0800, Eddy Verbruggen , wrote: I think it actually does support UPC_A because of what you mentioned. So with EAN_13 enabled you can also scan UPC_A, according to this: https://developer.apple.com/documentation/avfoundation/avmetadataobjecttypeean13code?language=objc Do you think updating the readme would suffice? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[timdmackey]

If Android does return a 12-digit code, it looks like it’s pretty straightforward to normalize this. As noted here, EAN-13 codes with a leading zero are by definition a UPC-A code, so all you need to do is either add or remove the leading zero depending on which direction you’re converting: https://stackoverflow.com/questions/22767584/ios7-barcode-scanner-api-adds-a-zero-to-upca-barcode-format

…

On Dec 6, 2018, 2:51 AM -0800, Eddy Verbruggen ***@***.***>, wrote: I think it actually does support UPC_A because of what you mentioned. So with EAN_13 enabled you can also scan UPC_A, according to this: https://developer.apple.com/documentation/avfoundation/avmetadataobjecttypeean13code?language=objc Do you think updating the readme would suffice? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[EddyVerbruggen]

Interesting findings, thanks. I'm personally not interested in UPC-A so don't hold your breath for me doing this any time soon, but I'll flag it as 'help wanted' and perhaps on a rainy day I can take a stab at it myself.

[timdmackey]

Fair enough, thanks for your feedback!

…

On Thu, Dec 6, 2018 at 4:37 AM Eddy Verbruggen ***@***.***> wrote: Interesting findings, thanks. I'm personally not interested in UPC-A so don't hold your breath for me doing this any time soon, but I'll flag it as 'help wanted' and perhaps on a rainy day I can take a stab at it myself. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#176 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALJ9Eyhg6rLnrjr1Zo9wTS9bofy9h7jks5u2Q-JgaJpZM4ZGL0r> .

[EddyVerbruggen]

This is now past of 3.0.0 which I'll likely publish tomorrow.

Details: as you suggested I've compared and aligned with Android, and have done what's mentioned at that SO post you linked to. Seems to work pretty well.

Because this is breaking change (a leading '0' will be dropped for EAN_13 codes which are actually UPC_A codes) so I decided to bump the major version.

[timdmackey]

Ooh, fantastic! Thanks for doing this.

[timdmackey]

Looking over this, I think it would be better if the zero was only stripped when UPC_A is specified in the formats value. If the format is specified as EAN_13, then the zero should be kept.

Since the two codes are functionally equivalent, the difference comes down to how the barcode value is stored and displayed. A developer who is working with EAN_13 will expect that their data always has 13 digits, while a developer working with UPC_A only will expect 12 digits.

Of interest, I came across this article today (Are UPC and EAN the Same), which give a lengthy explanation of how and why UPC_A is equivalent to EAN_13. This image from the article is particularly helpful, showing how the barcode is identical and only the printed numbers or the data stored in the computer system are different:

[timdmackey]

With this change, I suggest also making a note in the documentation that you cannot use both UPC_A and EAN_13 at the same time, that you must choose one or the other.