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

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.

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?

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?

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

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.

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.

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.

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

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

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

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

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.

Ah, I see, that makes perfect sense 👍