Join forces with zxing-cpp?

[axxel]

Hi there. Apologies in advance if someone thinks the following proposal is inappropriate.

I'm the maintainer of zxing-cpp. Since this PR we have a wrapper for iOS. The project has been ported to c++ from the Java version about 4 years ago but has been improved/rewritten substantially over the years. Depending on the use case it is now 2x to 10x faster than the original and has improved detection capabilities as well. Glancing over the open issues an PR list here, I estimate that the following issues would go away by switching to zxing-cpp: #470, #483, #485, #498, #501, #567, #517, #524, #570.

It seems that this project here is partly abandoned (based on the date of the last commit) but quite a few people are using/working on this port. I'd therefore like to invite anyone who is interested to give zxing-cpp a try and if you find something is lacking with the new wrapper, please let me know. I'd love to help consolidate the rather fragmented landscape of zxing ports and bring the community closer together working on one solution instead of fixing issues multiple times in different code bases.

[benjohnde]

@axxel yeah, I wanted to rewrite the ObjC port with Swift some while ago but didn't find the time to do so. I fixed some bugs and as the original zxing is kind of dead, I tried to port all the outstanding changes from zxing to this objc port. I succeeded in doing so but keeping up with issues and bugs did not work out for me. With @Liftric we started playing around with the cpp port and actually it is super fast and convenient for us to use. I don't really see any point in either rewriting the ObjC port to Swift or cleaning this repo up. You made awesome progress and I believe it is more meaningful to support your port instead of this. I will add a remark to this repos README and archive it in a couple of months.

[benjohnde]

And no, your proposal is relevant, appropriate and the right thing to do from my point of view :)

[benjohnde]

@axxel I will put a small hint on the top of the README to redirect people to your project, which makes sense the most IMHO.

[benjohnde]

@axxel with zxing-cpp/zxing-cpp#630 the zxing-cpp project should be fully working and could replace this one. There is still room for a bit more work on the iOS wrapper in terms of documentation and feature richness but it is already a noteworthy replacement.

After this PR is merged and released, I would invest a bit of time in some README enhancements in zxing-cpp and add a remark to this repository (and probably in the near future archive it). It can still be taken over if somebody is interested in maintaining that.

[alexmanzer]

@benjohnde and the others:
I may have another reason why you would want to switch from this ObjC variant to the C++ variant:

Long story:
We have many UseCases where we have to deal with 2D barcodes (especially DataMatrix) that contain binary data. (Especially for the purpose of VDS - Visible Digital Seals)

I have noticed that the zxing-objc has problems reading these codes with binary payloads correctly. The dangerous thing is that scanning works, but unfortunately there is simply a complete block of data missing in between the decoded payload.

We noticed this problem with one of our older apps in which we have still used zxing-objc. But since we were already in the process of switching to zxing-cpp anyway, we "solved" the problem by throwing out zxing-objc completely instead of looking for the error here for a long time.

But the bottom line is that there are still problems somewhere in zxing-objc when processing binary barcodes.

You can try it out for yourself:

This VDS contains the binary raw data:
1a)
E75F9D58C54785D6ADC087AA322CBBF3EC7C9AB447E7B855F482149143BE6E0C90267614E9A432CE15DE8E1FC0497A10EFEA606709E4332153EF73B3ADEC0F9AC4A3CE46028366F27568B3F5D7B6FE21514639E7ED4016A0A92A7262AB2DDDBA94F237F1AE6CE2EE874406F14E6F782DDB5065E5FDB6D9895E7381FBE0336381FCEE4B4D328E5A305DB3D73E7785D651137A6E1E1009C3819D34CA61F78F26BC53E98018AE45DB720AA037CD64FA

1b) --> after correct datamatrix decoding this will have the payload bytes:
DC01D9C56D296AE819A699FDF799FDF77F04010C474E58504D34513650594748020A4A6F686E20536D69746803034DB293041139383220526567656E742053747265657405105065746572626F726F75676820504538FF4034A79345A053405AA1E6AE5E82A9D2B2292C5480D59D289CBBD3B3321D9FC3506AAA29A286D5932DB69BF8BF2B7B4178B84F109E70138C472C592A89A3FF6387

But zxing-objc gives as result in _result.rawBytes:
2a)
E75F9D58C54785D6ADC087AA322CBBF3EC7C9AB447E7B855F482149143BE6EC90267614E9A432CE15DE8E1FC0497A10EFEA60679E4332153EF73B3ADECF9AC4A3CE4628366F27568B3F5D7B6FE21514639E7ED4016A0A92A7262AB2DDDBA94F237F1AE6CE2EE87446F14E6F782DDB5065E5FDB6D9895E7381FBE0336381FCEE4B4D328E5A305DB3D73E7785D651137A6E1E109C3819D34CA61F78F26BC53E98018AE45DB72AA037CD64FA

2b) --> and after datamatrix decoding this will have the payload bytes:
DC01D9C56D296AE819A699FDF799FDF77F04010C474E58504D34513650594748020A4A6F686E20536D69746803034DB2930411FF4034A79345A053405AA1E6AE5E82A9D2B2292C5480D59D289CBBD3B3321D9FC3506AAA29A286D5932DB69BF8BF2B7B4178B84F109E70138C472C592A89A3FF6387

The strange thing about this is that both the start range and the end range are the same, only one data block is missing in between, which of course makes the result from zxing-objc useless.

You could dive really deep into it now and it would certainly be an interesting journey, but the effort is too high for me right now, given that our decision in favor of zxing-cpp had already been made beforehand anyway.