Is anyone using those reader/decoding options?

[axxel]

Adding even more wrappers, I wonder (again)...

[If you never used any, please choose the last option. If you'd like to select more than one, please just leave a comment]

[axxel]

Since I don't know who of the regular users would actually see this poll, excuse me for shouting out a few names: @gitlost @markusfisch @alexmanzer @vkrause @Sec-ant @benjohnde @siiky @khoren93 @okarmazin @duanqn @SteveCookTU @cbm755

[Sec-ant]

I personally voted "none of the above" however I'm not a regular user of ZXing-Cpp or the wrapper I wrote 😂. What I do know is that a large part of the users of my wrapper don't use it directly but through some even higher-level packages which do not expose these options. So I assume "none of the above" can reflect most of the cases on my side.

[axxel]

Thanks. From what you wrote and my personal feeling overall, I would go as far as assume that "none of the above" can reflect all of the cases on your side. ;) Please be prepared to deprecate/remove some/all of them (see my comment below).

[SteveCookTU]

I would guess most users don't use the options, but my personal preference is having the checksum validations. Users could do this themselves but is good to have for more niche/strict usage.

[gitlost]

The zint test suite uses `tryCode39ExtendedMode` and `validateCode39CheckSum` as they're convenient. It doesn't use `validateITFCheckSum` as it does its own validation (variants can have no/different checksums). Re `returnCodabarStartEnd` I notice it was introduced upstream over 10 years ago with commit zxing/zxing@20193fd in response to a googlecode issue (no. 1737), which I haven't been able to track down, but presumably somebody found it useful...

…

On Thu, Jan 25, 2024 at 5:24 PM SteveCookTU ***@***.***> wrote: I would guess most users don't use the options, but my personal preference is having the checksum validations. Users could do this themselves but is good to have for more niche/strict usage. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[axxel]

Thanks for your feedback. I was looking into the code again to see what those 4 options are actually doing.

tryCode39ExtendedMode:
There is a strange inconsistency between Code39 and Code93. The latter seems to be defined (definitely implemented here) such that the 'extended mode' is mandatory, while for the Code39 it is optional. Looking at what this option does, I must say the name of the option is misleading: it does not 'try' something but rather enforces an extended mode reinterpretation of the content and returns a FormatError if that fails. Looking at the test samples we have and at a random google image search, I did not find a single (non-extended) symbol that would fail to decode correctly if we simply set this option to true by default. There are quite a few samples out there when not setting this option would lead to 'obviously' wrong results because they contradict the text printed next to the symbol. But since no-one seems to use this option (see poll numbers) and no-one complained, I conclude that Code39 is simply not relevant. Either way: I intend to change the implementation such that it actually 'tries' and if that fails, then simply assume the non-extended version. If I had the specification, I would have look if they have something to say about that subject. ;)

validateITFCheckSum:
If not even you find this useful... The code does an automatic checksum validation if the content length is 14 and sets the symbologyIdentifyer accordingly. Why not then simply always do this checksum -> symID transform and if someone really want's to know if the checksum is valid, they can look at the symID?

validateCode39CheckSum:
I see how that might be useful to you and also how you are quite likely the only person on the planet who uses that feature :-D.
If the spec would say something about the modifier like in the ITF case, we could get rid of this as well...

returnCodabarStartEnd:
Interesting hint to the original patch. Wikipedia says, that the start/stop characters can be used to distinguish between applications (like library inventory vs FedEx tracking numbers). So I see how someone might want to get access to this information. I wonder what the specification has to say about that. One idea to get rid of this would be 'define' that those characters are (always) part of the bytes/bytesECI result and then either not render them into the text at all or make that dependent on the TextMode.

Bottom line: with a little luck, all of those options can simply die.

[axxel]

The zint test suite uses tryCode39ExtendedMode and validateCode39CheckSum as they're convenient.

I'm working on refactoring this code under the assumption that if the library would basically 'try' the full-ASCII decoding and 'try' to validate the check digits (without removing it) and then report the findings via symbologyIdentifier you would still be able to implement the required functionality in your test suite, right?

Is your test suite zxing-cpp code publicly available to look at?

[axxel]

Update: I went ahead with the deprecation of the first 3 and regarding the last one (Codabar), I'm currently favoring simply always returning the start/stop character. A simple google image search for codabar showed that more than 50% of the HRI texts seem to think they ought to be included anyway. And if someone really cares about that, they can simply strip away the first and last character themself. I consider this such a niche application with a trivial fix in user code that I don't consider this worth the hazzle. Someone care to speak up against that idea?

[gitlost]

Re test suite source, it uses an intermediary "zxingcppdecoder" CLI to interface with ZXing-C++ (https://github.com/gitlost/zxing-cpp/blob/diagnostics2/example/ZXingDecoder.cpp) to which it passes options as appropriate (e.g. for Code 39 see https://sourceforge.net/p/zint/code/ci/master/tree/backend/tests/testcommon.c#l3791). The CLI returns a string (`result.text(TextMode::Plain`) which is then massaged to be comparable to the expected result (https://sourceforge.net/p/zint/code/ci/master/tree/backend/tests/testcommon.c#l3897). Re removing Code 39 options, as the test suite uses a fork of ZXing-C++ it can do its own thing (although I try to limit these to make merging easier) so its requirements aren't really that relevant to this discussion. Re removing options in general, I'm not in favour for what it's worth. The simplification doesn't justify the backward incompatibility in my eyes, and if part of the motivation is to reduce the size of the `ReaderOptions` structure, then I don't think that's a good motivation.

…

On Fri, Jan 26, 2024 at 3:40 PM axxel ***@***.***> wrote: Update: I went ahead with the deprecation of the first 3 and regarding the last one (Codabar), I'm currently favoring simply always returning the start/stop character. A simple google image search for codabar showed that more than 50% of the HRI texts seem to think they ought to be included anyway. And if someone really cares about that, they can simply strip away the first and last character themself. I consider this such a niche application with a trivial fix in user code that I don't consider this worth the hazzle. Someone care to speak up against that idea? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[axxel]

Re test suite source, it uses an intermediary "zxingcppdecoder" CLI to interface with ZXing-C++

All changes made so far can be hidden/dealt with inside your zxingcppdecoder binary, so below your own test code and above the zxing-cpp library.

e.g. the use of validateCode39CheckSum:

auto res = ReadBarcode(...);
if (validateCode39CheckSum && res.format() == BarcodeFormat::Code39
        && (res.symbologyIdentifier()[2] - '0') % 2 == 1)
    return false;

That is technically not true for some 'corner cases' with Code39 where any of $%/+ are involved outside of the full-ASCII use case (corner case in the sens that I have not seen a single sample online that would break with the newly implemented try-heuristic). Here it would be required to be able to prevent this new default tryCode39ExtendedMode behavior, otherwise a 'standard' symbol with the content "A+B" would be returned as "Ab". So I see a point of keeping the option to disable this behavior, even though it feels like you are the only one who would actually use it. ;) But if your tests should turn out not to be affected by this anyway, I might leave it as is right now.

The one change not yet performed (always return start/stop characters for Codabar) would only reduce your special handling by obsoleting this if-block: https://sourceforge.net/p/zint/code/ci/master/tree/backend/tests/testcommon.c#l4038 and making zxing-cpp being more in line with zint overall.

Re removing options in general, I'm not in favour for what it's worth. The simplification doesn't justify the backward incompatibility in my eyes, and if part of the motivation is to reduce the size of the ReaderOptions structure, then I don't think that's a good motivation.

Thanks for your input. My motivation is to get rid of useless cruft that no-one (except you in this case ;)) uses anyway. This whole wrapper business makes this particularly unpleasant where each and every wrapper is naturally inclined to expose this API surface as well. And those are really piling up: ios, Android, Rust, .Net, c, flutter, python, wasm1, wasm2, winrt.

With respect to making breaking changes in general: I'll not break the ABI before a 3.0 release. And since you seem to introduce breaking changes on pretty much every release of libzint according to your changelog, I would have expected you to be OK with that. :)

[gitlost]

Re `tryCode39ExtendedMode` in particular, as the spec says it's a decoder option, I think it should be kept as an option.

…

On Fri, Jan 26, 2024 at 5:23 PM Martin Burke ***@***.***> wrote: Re test suite source, it uses an intermediary "zxingcppdecoder" CLI to interface with ZXing-C++ (https://github.com/gitlost/zxing-cpp/blob/diagnostics2/example/ZXingDecoder.cpp) to which it passes options as appropriate (e.g. for Code 39 see https://sourceforge.net/p/zint/code/ci/master/tree/backend/tests/testcommon.c#l3791). The CLI returns a string (`result.text(TextMode::Plain`) which is then massaged to be comparable to the expected result (https://sourceforge.net/p/zint/code/ci/master/tree/backend/tests/testcommon.c#l3897). Re removing Code 39 options, as the test suite uses a fork of ZXing-C++ it can do its own thing (although I try to limit these to make merging easier) so its requirements aren't really that relevant to this discussion. Re removing options in general, I'm not in favour for what it's worth. The simplification doesn't justify the backward incompatibility in my eyes, and if part of the motivation is to reduce the size of the `ReaderOptions` structure, then I don't think that's a good motivation. On Fri, Jan 26, 2024 at 3:40 PM axxel ***@***.***> wrote: > > Update: I went ahead with the deprecation of the first 3 and regarding the last one (Codabar), I'm currently favoring simply always returning the start/stop character. A simple google image search for codabar showed that more than 50% of the HRI texts seem to think they ought to be included anyway. And if someone really cares about that, they can simply strip away the first and last character themself. I consider this such a niche application with a trivial fix in user code that I don't consider this worth the hazzle. Someone care to speak up against that idea? > > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you were mentioned.Message ID: ***@***.***>

[ryantrem]

I checked our usage and we do use tryCode39ExtendedMode as well. I looked at the PR where it was added and the author (@CoPrez, though not sure if he remembers any more context) said this about adding tryCode39ExtendedMode:

Additionally I'm adding one other hint for Code39 barcodes where they can use an extended mode that allows encoding the full ASCII table. Without the decoder hint the output strings have escape characters. Such as a Code 39 barcode generated with "Hello" in extended mode was being parsed as "H+E+L+L+O". Adding the decoder hint to try extended mode code 39 returns "Hello" as one would expect.

[axxel]

I understand. Thanks for the feedback. What I implemented this afternoon is basically something like setting harcoding tryCode39ExtendedMode = true. What would be of interest to me is if you encountered situations where this needed to be false to get the expected result.

[axxel]

Just to let you know: in the current HEAD this property is still there (and not deprecated anymore) and the default value changed from false to true, meaning it should work out of the box for your use-case.

[gitlost]

Re zint test suite, yes, anything can be worked around (almost), and as I said its requirements can be more or less ignored. Re codabar and the special handling in `testUtilZXingCPPCmp`, these details aren't interesting but it's probably like that to avoid having to deal with upper/lowercase issues as zint uppercases Codabar input. Re breaking changes and zint, yes, zint breaks ABI on every release. It tries very hard not to introduce backward incompatible API/CLI changes though, unless there's a significant benefit. Anyway, that's my 2 cents.

…

On Fri, Jan 26, 2024 at 9:20 PM axxel ***@***.***> wrote: I understand. Thanks for the feedback. What I implemented this afternoon is basically something like setting harcoding tryCode39ExtendedMode = true. What would be of interest to me is if you encountered situations where this needed to be false to get the expected result. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[gitlost]

Re `tryCode39ExtendedMode`, just remembered that the Health Industry Bar Code (HIBC) Supplier Labeling Standard (https://www.hibcc.org/wp-content/uploads/SLS-2.6-Final.pdf) uses "+" as a prefix followed by a 4-character alphanumeric Labeler Identification Code (LIC), with the first character always being alphabetic. So e.g. "+A123BJC5D6E71G" (with the final "G" being a checksum) will now be returned as "a123BJC5D6E71G". So this is another reason for retaining `tryCode39ExtendedMode`.

…

On Fri, Jan 26, 2024 at 10:39 PM Martin Burke ***@***.***> wrote: Re zint test suite, yes, anything can be worked around (almost), and as I said its requirements can be more or less ignored. Re codabar and the special handling in `testUtilZXingCPPCmp`, these details aren't interesting but it's probably like that to avoid having to deal with upper/lowercase issues as zint uppercases Codabar input. Re breaking changes and zint, yes, zint breaks ABI on every release. It tries very hard not to introduce backward incompatible API/CLI changes though, unless there's a significant benefit. Anyway, that's my 2 cents. On Fri, Jan 26, 2024 at 9:20 PM axxel ***@***.***> wrote: > > I understand. Thanks for the feedback. What I implemented this afternoon is basically something like setting harcoding tryCode39ExtendedMode = true. What would be of interest to me is if you encountered situations where this needed to be false to get the expected result. > > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you were mentioned.Message ID: ***@***.***>

[axxel]

Very good argument. I was already leaning towards the idea of keeping the option alive, just because something like this 'could' be out there and I don't want to make a change that fundamentally breaks a use case. So what I intend to do is to keep the current decoding logic as it is but enable it depending on that flag but have the default setting for tryCode39ExtendedMode to be true, because that obviously fixes more real-world input than it breaks.

[axxel]

I pushed that last night and hope that change sufficiently supports your use-case.

[axxel]

@markusfisch @benjohnde I have a question regarding the deprecation of API in ObjectiveC. Is there an analog of the Kotlin @Deprecated annotation? If so, could anyone of you add that to the code?

This is also potentially relevant for #705, even though there the situation is more complicated.

[markusfisch]

In Objective-C you would use __attribute__((deprecated)) for that. For example:

-(void)setTryHarder:(BOOL)tryHarder __attribute__((deprecated));

In iOS/macOS there are also the DEPRECATED_ATTRIBUTE and DEPRECATED_MSG_ATTRIBUTE(msg) macros (in AvailabilityMacros.h) that expand to the above attribute (if the compiler does support attributes).

[markusfisch]

Just a little follow up: I just received an issue to return the Codabar start/stop codes (in my barcode scanner app). Apparently the start/stop codes are used to determine if a barcode is complete or if there is a continuation code to scan.

So I am using returnCodabarStartEnd in my app now.

[axxel]

your fix simply enabled the property, correct? This is also what the behavior of the library is since I touched that code.

[markusfisch]

Yes, exactly. I just wanted to signal that the property is needed.

[axxel]

I'm arguing, that it is not needed. It will be enabled (which I believe it should have been the case ever since the code reached the upstream Java code base) and there will be no property to disable it. If someone does not want to see the first and last character of the content, then it is trivial to remove them in client/app code.

[markusfisch]

Ah, I see, that makes perfect sense 👍