The std::any part sounds a bit 'scary' to me. First of all, I don't now how that would be modeled in e.g. kotlin/native. And even if we check that we have something appropriate in every current wrapper, I can imagine that there might come along a new one where that non-typed any-value would be an issue. Second of all: every wrapper needs to know the type of the individual value. A std::string does not have either of these issues.

Also what is the canonical dictionary data structure in C? I would argue that serializing the data into a string would be the easiest way to transport the map from c++ via c to .NET, etc. But each wrapper (that cares about it) could add a trivial "flat JSON to dictionary" function to not have all client-code need to do that?

A first draft of the JSON channel is implemented but I failed to quickly add this feature here since it is not obvious to me what exactly is of interest here:

1. the quiet zone in pixels/modules? That would not be very helpful to the general user as they would not know how to interpret the number.
2. a plain hasIsoCompliantQuietZone boolean? That would not really have helped the issue in Image border seems to be considered as a quiet zone (Interleaved 2of5) #869 as often the quiet zones are not compliant but still work, e.g. ITF requires 10 modules, while zxing-cpp is fine with 6 to not loose too many real-world examples.
3. something like croppedQuietZone? Is that true if one side is cropped or only if both are?

I'd like make sure the data we add is actually useful and as generic (across symbologies) as possible. Suggestions?

ITF detection depends heavily on how quiet zones are handled by the scanner, at least when scanning with a live camera, as can be seen in #869.
Something like croppedQuietZone would have been helpful in this regard, as it would have been possible to ignore all detection results without iso-compliant quiet zones.

@gitlost and @oehhar do you know from the top of your head if there is any symbology currently supported that has a default encoding other than ISO_8859-1?

Yes, JAB-Code has utf-8. But it is not supported by zxing-cpp ;-).

When you write, that you want to change the output of TextMode::ECI:

For me, one mode would be great: do what a standard scanner does:
if (hasECI) return bytesECI else return symbologyIdentifier+bytes

For me, one mode would be great: do what a standard scanner does:
if (hasECI) return bytesECI else return symbologyIdentifier+bytes

That is exactly what Barcode::bytesECI() does (or is supposed to do, anyway).

Thanks, great !
Lets look to two examples:

The first code is a system login code with non ISO-8859-1 characters, e.g. containing an ECI:

The code contains an ECI 2 for ISO-Latin-2 and the data "1HJ" then a byte with decimal value 234 then "drek".
The byte with decimal 234 in ISO8859-2 is unicode codepoint x0119 "ę"
The decode result is as follows. Remark that byte 234 is shown by its Unicode representation "ê".

• text 1HJędrek
• format DataMatrix
• bytes 1HJêdrek
• bytesECI ]d4\0000041HJêdrek
• content Text
• symbologyIdentifier ]d1
• hasECI 1

Here, bytesECI is, what a normal scanner would output. The item "text" with the decoded ECI is great (remark the change of "ê" to "ę" due to the ISO-8859-2 decoding).

The output of a standard scanner is exactly what "bytesECI" contains.

Now try a HIBC code without any ECI which only contains printable ASCII:

The decode result is:

• text +E4947611201/$LI
• format DataMatrix
• bytes +E4947611201/$LI
• bytesECI ]d4+E4947611201/$LI
• content Text
• symbologyIdentifier ]d1
• hasECI 0

The output of a standard scanner is what the concatenation of "symbologyIdentifier" and "bytes" contains.

To get the standard output in both cases, I do:

if (hasECI) return bytesECI else return symbologyIdentifier+bytes

Thanks for all the great work !
Harald

Thanks a lot for this insight. Let's follow up this discussion in #936.

This patch adds another usability improvement to the idea, completely removing the need to parse a JSON string in case one knows the key name in advance. Noteworthy: key-names are compared case insensitive.

Current HEAD includes this addition to ZXingReader that allows to output a (more or less) complete JSON serialization of the barcode object, including JSON conform character escaping which is something I overlooked when first drafting this idea.

Thanks for sharing your idea but I don't see myself investing time in that direction. Without even looking at the details, it sounds like a lot of work, which was exactly what I was trying to avoid in the first place. Also my gut feeling tells me that this would go against my goal of having all wrappers feel native to their language and not be forced into some common denominator API.