Axel Waggershauser

Compile issue in output.c when included in external build

So the general feeling seems to be that it should be changed back to plain char... I would support that. After your argument about std::char8_t being unsigned which is a valid point, I thought about whether I should reconsider using char* ZXing_Barcode_text() but decided against that. While a char* does not convey anything about the encoding, neither does unsigned char*, which does not even hint at the fact that it contains text at all. If there was a char8_t in C and printf() et al would accept...

Re size: yes, this hypothetical scenario where all barcodes would be encoded with ECI 26 was in the back of my mind, I guess. So changing zint to make that the default would bring is (a tiny) step closer but I completely get the symbol-size argument and would not do that either. Thanks for your time.

malloced the rows on demand Does that mean you can't know how many rows are required before you start putting data into the buffer? I would argue that allocating one contiguous block is way to go here. I was thinking about putting on the stack in my implementation but will probably not do that after all. Even if not, I imagine that the most use cases would be fine with a few hundred bytes instead of 28k and it just seemed inconsistent to have some output buffers with a fixed size and others dynamically...

I see. But I don't understand the "UTF-8 is more likely" statement. Since the input is a UTF-8 string to begin with it is guaranteed to work as UTF-8? And if the approach is trivial, then why not try the multi-byte ones as well and choose the one with the shortest encoded stream of bytes? (Not that I personally care about, e.g. GB18030.) This whole subject was raised mainly because I wanted to know the reasoning behind the choice and because if there would not be encoding other than UTF8, life would...

I understand that code size / symbol size would be potentially larger with utf8 instead of one of the others. And if that is the topmost priority, then this answers my second question. But depending on input, that is also true for one of the omitted ones, like 32, which is apparently the reason why China wants to keep it and if I got your explanation about the proposed standardization correct, ECI 32 would still be supported as encoding, unlike say 21. Or is their concern about only returning UTF8...

Automatic fallback ECI selection

Questions regarding sizeof(zint_symbol)