codemonkey82

Hi Martin, Just as info. This feature would be very convinient for me too: "Currently only Code 128 supports manual FNC1s, though there are plans in the fairly short term to extend it to all other barcodes that can encode FNC1s." For context: I have gotten this abomination from a customers site: "^FD>;>80014009895220145656910>600326316^FS" It begins in GS1 in subset C, but then switches back to subset B while still using GS1. I have never seen this before, but I will have to support it at some point...

Hi guys, I hope the new year made a good impression on you all so far. In my case it made a hacky start. A customer wants to switch between mode B and mode C in a code128 to achieve a specified width instead of only using the module width. A new IT-system insists on sending such horrors after a software update in the production plant. Here is an example for the ZPL-viewer: http://labelary.com/viewer.html ^XA ^BY3^FO100,100^BCN,100^FD>:12345>56789^FS ^XZ We start in B, and after 12345 we switch to...

Hi Martin, this looks perfect. Harald's suggestion with the input_mode was even better than what I originally wanted. I will also test the fast version of the QR code when it is implemented.

Hi Martin, yes that is exactly how I would want it :-) If there are other competing algorithms for speed vs size regarding other symbols, it would be great to collect them all in Zint, and make them optional over the API. (Edit: And document in Zint.h which one are slow and fast etc)

Hi Martin, yes that is exactly how I would want it :-) If there are other competing algorithms for speed vs size regarding other symbols, it would be great to collect them all in Zint, and make them optional over the API. (And document in Zint.h which one are slow and fast etc)

Hi Martin, yes that is exactly how I would want it :-) If there are other competing algorithms for speed vs size regarding other symbols, it would be great to collect them all in Zint, and make them optional over the API.

Hi Martin, So the following option will improve the compression in some border cases, but will create these slowdowns as a default? It could be great to have the choice by setting options here like you suggested, even if the slow but compact algorithm is the new standard. I would generally support the philosophy of choosing different algorithms for speed vs size for different symbols. option_3 |= DM_COMPRESSION

Hi Martin, that sounds really good with the GS1 data. I will soon try it out again. Here is a test for the white lines in PDF417. Hopefully the the problem can be reproduced: void Test(void) { struct zint_symbol *Symbol = ZBarcode_Create(); Symbol->symbology = BARCODE_PDF417; Symbol->height = 16.000; Symbol->scale = 1.5; Symbol->option_1 = 5; Symbol->option_2 = 8; Symbol->option_3 = 0; const char *Send = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBB";...