Andre Maute

That looks great now. I will let my coworkers evaluate these. Though feedback might take quite a time, because we are in the holiday season already right now.

Thank you very much Martin for developing this long awaited feature now. The grayscale version will get almost unreadable for the usages i have in mind. Perhaps a bigger font would do somewhat better. But the 1bit monochrome is a lot better, though the font is still too small. We use as a rule of thumb '8 pixels are 1mm'. With some additional smearing from a bad printer, still almost unreadable. If the font gets bigger the HRT itself might even get wider as the barcode proper. would that be doable...

regarding the very first comment inside the source file "stb_truetype.h" doesn't look that promising for me and my co-workers. That would indicate a need to embed the font file into the library file, so it isn't easily exchangeable. I hope you can understand why I still think the use of a bitmap font would be the best here.

Hi Martin, I have a test for a GS1 Databar Expanded Stacked Barcode, where with a very hacky procedure, a two row text rendering is placed under the barcode. My caveats: The barcode proper of this test has height approximately 140 px. the rendered character of the number "1" has height 16. and was done with Roboto Condensed 18. The font height was not configurable, though the height somehow was. (I don't know if the HRT height has to correlate somehow with the height of the barcode proper itself)...

Hi Martin, that would be great. Though I must admit I can't still work with a complete dependency tree for cairo and pango here for text rendering. I hope you remember that we together had a discussion, in a different thread with Robin Stuart about this, but I don't know anymore where this discussion was held. Bitmap fonts as used for the other symbologies with HRT would be the best option for me. to have almost no additional dependency tree for the libzint library. there are still a lot thermal...

I would like to ask in what current state the ongoing implementation is? Best Regards Andre

Hi Martin, thanks for posting your insights, I wonder if it would be possible to let the two projects converge a little bit more, so my fix functionality isn't needed anymore. Perhaps Axel reads this. https://github.com/a3emdot/zintzxingcppdemo/blob/e025de87460cd88769a2ef289a5401b5f37c66ba/src/barcode.cpp#L336 int zintFixZintSymbology(const std::string& input, int zintsymbology); and https://github.com/a3emdot/zintzxingcppdemo/blob/e025de87460cd88769a2ef289a5401b5f37c66ba/src/barcode.cpp#L509 std::string...

UPC-A and GS1 Databar inconsistencies with Upstream zxing-cpp and zint versions