Activity for codemonkey82
-
codemonkey82 posted a comment on ticket #350
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";...
-
Hi Martin, yes the dummy [] for GS1 data work perfectly. I no longer need to have the error message disabled, but I suspect that we have a bug in the if statement. I still get the error when using the [] dummy, because the if statement basically says: if(!RelaxMode || ErrorNoticed) SetError() it should instead be: if(!RelaxMode && ErrorNoticed) SetError() Your other plans also sound good. Our pattern has worked great so far: I give you a hacky example of my intentions, and you do something flexible...
-
Hi Martin, I have once again succumbed to the temptation of spending another day with Zint. I have a deadline looming in the background, but your latest updates just looked too good to wait for. I will test your raster optimizations on a live machine this week, and the needed patches from my side have been reduced to just two. What a difference from the earlier days! I still remember when I needed about 10 different complicated patches, changing with every release, to get things working! Now I just...
-
Hi Martin, don't worry about the ratios. I have an acceptable solution in my frontend, and I'm ready to wait for a solution which is both efficient and maintainable. I'm always around to watch your progress through the code jungle from the trees above. It has been an awesome journey so far. The guardheight suggestion is absolutely perfect! Then I can also decrease this value while increasing the scale to avoid the guardbars growing too long. One customer has complained about it, and I have promised...
-
Hi guys, I finally got some time to update my Zint backend to the latest version, and as usual it was a very pleasant experience. The new options and the ongoing refactoring has been big wins for me, and the patches needed when updating are just speedbumps now. Here are the ones still remaining for me. If we could integrate some of these points in some form in Zint it would be great, but I already consider myself a very satisfied user: First some warnings from the compiler. I use the -pedantic option,...
-
Yes, I would also allow the setting of ratio for all barcodes where it makes sense, independently of the ZPL. It isn't possible however to emulate width changes with ratio changes, and the width will always increase the guardbar height because of the scaling. This isnt't an important problem, and you are definitly right about the solution being hacky. I will play around with it and see if there's a better solution. Until then, the float height, manual FNC1, and ratios will be more than enough to...
-
I would still need the guardbar adjustment, because width and ratio being different things in ZPL. In many barcodes you can change both independently of each other, and with upcean barcodes you can only change the width and not the ratio. Here is an example with an EAN-8: http://labelary.com/viewer.html ^XA ^BY3,2.0^FO100,100^B8N,100,Y,N^FD1234567^FS ^BY4,2.0^FO100,250^B8N,100,Y,N^FD1234567^FS ^BY5,2.5^FO100,400^B8N,100,Y,N^FD1234567^FS ^BY6,3.0^FO100,550^B8N,100,Y,N^FD1234567^FS ^BY7,3.0^FO100,700^B8N,100,Y,N^FD1234567^FS...
-
I understand that you have been busy - that was a huge merge request! I use Freetype to render my text so I haven't noticed any problems, but perhaps I will check out the fonts provided by Zint again. When I first tried them when discovering Zint, they didn't work for scale 0.5, so I dismissed them immediately. If you are checking out the handling of guardbars etc, I have another suggestion. When using for example: int Width = 5; symbol->scale = Width*0.5; symbol->height /= Width; to increase the...
-
You guys are absolutly right! The UPCE-issue was a bug in my code! I sent 12345678 in one of my tests to check the guardbars. Even ZPL is cutting it off to 1234567. ZPL normally wants 10 chars and extracts 7 out of those. Thank you for asking questions about my intentions when asking for possibly insane things! Robin: I'm also thinking about catching the Planet/Postnet in my frontend. The only issue will be when the customer wants a certain barcode size without caring about it being scannable or...
-
Hi guys, I was curious enough of all the new features that I decided to make a backend-update of Zint in my software. The machine has been running for several hours and everything looks good. Here are some quick observations. Very smooth adjustments in the frontend. The immediate buffer and fast scaling are pure gold for me: Symbol->warn_level = WARN_ZPL_COMPAT; Symbol->output_options |= OUT_BUFFER_INTERMEDIATE; integer_t ZintRet = ZBarcode_Encode_and_Buffer(Symbol,(unsigned char *)Send,Size,0);...
-
Those are great news! The FNC_MODE/ESCAPE_MODE and the float height should be enough to update my Zint version. If you manage to throw in a REMOVE_GUARDBARS, I'll buy you a beer! https://sourceforge.net/p/zint/tickets/204/
-
Yes, that sounds perfect. I'm actually translating _1 and >8 into 0xFF in my GS1 strings to symbolize the FNC1, which I then translate to [ID] when dealing with Zint. We should probably use a better escape character. '\F' is probably a good choice, and leaves room for additional escape characters in the future. We would need to switch off the escape characters when not needing any FNC1 - someone could actually write the string "\F" to a barcode. When dealing with FNC1, the user input "\F" could also...
-
Yes, that sounds perfect. I'm actually translating _1 and >8 into 0xFF in my GS1 strings to symbolize the FNC1, which I then translate to [ID] when dealing with Zint. We should probably use a better escape character. '\F' is probably a good choice, and leaves room for additional escape characters in the future. We would need to switch off the escape characters when not needing any FNC1 - someone could actually write the string "\F" to a barcode. When dealing with FNC1, the user input "\F" could also...
-
Yes, that sounds perfect. I'm actually translating _1 and >8 into 0xFF in my GS1 strings to symbolize the FNC1, which I then translate to [ID] when dealing with Zint. We should probably use a better escape character. '\F' is probably a good choice, and leaves room for additional escape characters in the future. We would need to switch off the escape characters when not needing any FNC1 - someone could actually write the string "\F" to a barcode. When dealing with FNC1, the using input "\F" could...
-
"(Having a mechanism to manually switch modes A/B/C for Code 128 only would not be high on my list though!)" No protest from me. I was almost ashamed of mentioning it: I'm handling it in the frontend today :p Could we perhaps be using [] as FNC1 sign? I think the documentation mentioned that those aren't GS1 signs and therefore ideal? (I might we wrong about this).
-
Universal ZPL-ticket
-
Yes that sounds interesting. I also use the GS1 mode for Datamatrix, so it would be nice to have this escape character in all cases where GS1 is possible. ZPL allows the insertion of FNC1 and manual mode switching for EAN128/CODE128 between mode A,B,C. I'm working around this with the [] insertions and forcing the manual mode identification into verious modes at certain times. Would that be hard to implement?
-
Hmm... I don't know. I could try to put a dummy [] in front, with the size of 2 or 1? [03]1234 or [18]1234 Would these be exactly the same as: 031234 or 181234 ?
-
The problem is that you don't know if the customer means: [03]1234 or [031]234 etc So you must only copy the string to Zint: 031234 There are horrible many combinations of this. The string starts as correct GS1 but suddenly an incorrect ID comes, and then you must stringcopy the rest to Zint without any [], unless the rest is less than 2, then you should cut out the rest, etc. All this crap I would keep away from Zint. I only wish Zint to replace the errors with warnings and let me decide what to...
-
Hi GitLost, that sounds really promising. ZPL allows the following ratios: 2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3.0 Here is the logic how the ratio is getting calculated: Example1: Ratio = 2.8; Width=1; Zint->Scale = 0.5 * Width; Zint->Height /= Width; int Narrow = Width int Wide = Narrow * Ratio; Result: Narrow = 1; Wide = 2; Example2: Ratio = 3.0; Width=1; Zint->Scale = 0.5 * Width; Zint->Height /= Width; int Narrow = Width int Wide = Narrow * Ratio; Result: Narrow = 1; Wide = 3; Example3: -...
-
Hi GitLost, the problem is the the customer wants to scan exactly what he's sending, no matter if it makes sense or not. Try this code in the ZPL-Viewer: http://labelary.com/viewer.html ^XA ^BY3 ^FO50,100^B5N,100^FD123456789123456789^FS ^FO50,300^BZN,100^FD123456789123456789^FS ^FX No limit here on the length... ^XZ ^XA ^BY3 ^FO50,100^BCN,100^FD>;>8031234^FS ^FX An ID of 03? Well who cares, right? Will just scan to 031234 ^XZ I don't know if any scanner out there can handle the Postnet/Planet cases,...
-
Hi Robin, it looks really good. As a general rule, I would say that everything should be allowed, as long as the barcode can be generated. The resposibility of identifying errors should be in the frontend, which makes it possible to separate Zint from all the quirks that are found in different printing protocols. I think that the changes with the GS1-checks and PLANET/PostNet will go a long way. As an example: One protocol that I'm implementing is using an old GS1 standard to check for errors. ZPL...
-
Hi Robin, that sounds like a good idea! Is it possible to create forums/mailinglists here on souceforge for such projects? I would definitly help in any way I can.
-
Barcode Ratio in Zint backend
-
Hi Robin, yes, I have been working on various interpreters with focus on ZPL for the last 5 years. Zint has been a wonderful resource for me in implementing them. I bet you already know about the ZPL viewer, if you are thinking about creating an interpreter? http://labelary.com/viewer.html My feature requests here are very ZPL orientered; everything needs to be fast (my interpreter is running in a machine) and I want warnings intead of errors: https://sourceforge.net/p/zint/tickets/142/ The next...
-
Hi GitLost. That looks perfekt! Thanks!
-
Hi Harald, as a software developer I agree with you completly. The standards are there for a reason, and everyone should stick to them to ensure that everything works, and that software and production systems remain mantainable. My request comes from this text in the ZPL manual for PDF417: h = bar code height for individual rows (in dots) Values: 1 to height of label Default: value set by ^BY This number multiplied by the module equals the height of the individual rows in dots. If this number is...
-
Hi Harald, as a software developer I agree with you completly. The standards are there for a reason, and everyone should stick to them to ensure that everything works, and that software and production systems remain mantainable. My request comes from this text in the ZPL manual for PDF417: h = bar code height for individual rows (in dots) Values: 1 to height of label Default: value set by ^BY This number multiplied by the module equals the height of the individual rows in dots. If this number is...
-
Hi GitLost. That all sounds great to me! If i remember correctly; my row_height_input was a workaround for the fact that height wasn't a float. In my older Zint-version, I think I got some errors in my integration-test when changing it. I produce png files for all barcodes, text, and graphics that I want to print, and then compare them between versions with the compare tool from imagemagick. "compare -metric mae". I get red pixels in each image when pixels are changing, which is great to spot unintended...
-
I always use 0.5 (1 pixel/dot as smallest unit), and then 1.0 for 2, and 1.5 for 3 etc. Most barcodes have height parameters so that is ok. To set the width, for example to 3, I use the following logic: Width = 3; Scale = 0.5* Width; Height /= Width; For PDF417 etc, I get the problem that the customer wants to use one dot as base unit (Scale 0.5), and then some other value for dots per line (DPL). Scale 0.5 and DPL 2. Or Scale 2.0 and DPL 2.5 etc. Therefore I need the float/double parameter to set...
-
That sounds interesting. My only worry there is about speed. I had to rewrite the scaling function to optimize for regular scales like 0.5 -> 1.0 -> 1.5 etc. I work in the embedded area where I can only waste some mS, but not many of them. Which performance will this new scaling option have you think? The advantage with my row height hack is that its still very fast... /*if (scaler == 0) { scaler = 0.5; } scale_width = image_width * scaler; scale_height = image_height * scaler; // Apply scale options...
-
I made a ticket in the past about making the row number into a parameter. What do you think about this? It would make my work a little bit easier, but I understand if it remains rejected for technical reasons. https://sourceforge.net/p/zint/tickets/159/
-
Yes, it works fine for me. The ticket can be closed. Thanks!
-
Ok, then it would make sense to keep the Zint philosophy here. Thank you for your thoughts about this.
-
Alright, that makes sense. Zint always tries to ensure that the symbol is valid. ZPL instead only does what the user wants, but gives no guarantees that the symbol will scan. This is also the reason for my ticket about an option to replace errors with warnings in Zint. I appriciate your thoughts about this, and it is no big hassle for me to patch Zint in my application.
-
Regarding the float, you are completly right - I need it for precision. In the end, the content in symbol->row_height[] lands in a float variable in plot_raster_default in raster.c If symbol->row_height[] is not float, the opportunity for this additional precision is wasted. The parameter row_height_input could also be used for barcodes like CodaBlock, where the same parameter would be possible to set.
-
Hi guys, ok then my suspicion that it was changed during development is obviously wrong. I also can't say if my suggestion to change it is reasonable. You guys know the standard much better than me, so I leave it to your good judgement to decide. If we were to change it, however, it would be one less thing for me to manually change when updating Zint in my application. (Zebra printers for example, use the algorithm that I suggest above)
-
Hi Harald! Printer protocols often allow that option to be set. One example is the Zebra Programming Language (ZPL). https://www.zebra.com/content/dam/zebra/manuals/printers/common/programming/zpl-zbi2-pm-en.pdf Format: ^B7o,h,s,c,r,t r = number of rows to encode Values: 3 to 90 Default: 1:2 (row-to-column aspect ratio) You can specify the number of symbol rows giving control over the height of the symbol. For example, with no row or column values entered, 72 codewords would be encoded into a symbol...
-
PDF417 code word calculation
-
Row size input for PDF417
-
Hi Harald, we additionally need to change the draw_bullseye function to support resolutions less than 1.0 Change the function call to: draw_bullseye(pixelbuf, image_width, image_height, (2 * xoffset), (2 * yoffset), scaler * 10); and the implementation to: void draw_bullseye(char pixelbuf, int image_width, int image_height, int xoffset, int yoffset, int scaler) { / Central bullseye in Maxicode symbols */ float x = 14.5 * scaler; float y = 15.0 * scaler; if(scaler < 10) { x = 16.0 * scaler; y = 16.5...
-
Zint builtin barcode text corrupted with scale 0.5
-
Option to replace error controls with warnings
-
ITF14 box should be able to deactivate
-
Hi Robin. Thanks for the fix. I'm printing this symbol with 203 dpi, with the scale of 0.667 - there is much ancient equipment out there... (203 dpi is the lowest resolution still being used widely in label printing.) Here is my fix for the bullseye problem. It works like before for scales >= 1.0, but additionally supports scale 0.667 when scale < 1.0 It should be possible to generalize this function for other scales less than 1.0 after some cleanup. draw_bullseye(pixelbuf, image_width, image_height,...
-
Hi Robin. Thanks for the fix. I'm printing this symbol with 203 dpi, with the scale of "0.667". There is much ancient equipment out there... Here is my fix for the bullseye problem. It is hardcoded to work for the scales 1.0 and 0.667, but it should be possible to make more general after some cleanup: draw_bullseye(pixelbuf, image_width, image_height, (2 * xoffset), (2 * yoffset), scaler * 10); void draw_bullseye(char *pixelbuf, int image_width, int image_height, int xoffset, int yoffset, int scaler)...
-
Maxicode with scale less than 1.0
1
