2 Replies Latest reply on Aug 17, 2017 6:07 AM by Tim Lightbourne

    Hi Guys, we're printing Labels to a GK420d using ^GF command and think maybe we could improve speeds using compression, read the guide but still a bit unsure the best way to approach,thanks

    Tim Lightbourne

      For example, I saved the ZPL data that our application outputs to a file just to see what was being sent and it looks like this

       

      ^XA

      ^GFA,119900,119900,100,0000000.... lots more data.....

      ^XZ

       

      The file is actually 235kb in size. Just out of interest I did a search and replace of 0 in the file as there appeared to be an awful lot of them

      and it made 200,000 matches! So I'm assuming compression could drastically reduce the size of the file maybe?

       

      I read in the notes from Programming Guide for ZPL II by Zebra that

       

      "A comma in the data pads the current line with 00 (white space), minimizing the data sent"

       

      and also it mentions compression types

       

      A = ASCII hexadecimal (follows the format for other download commands)

      B = binary (data sent after the c parameter is strictly binary)

      C = compressed binary (data sent after the c parameter is in compressed binary format. The data is compressed on the host side using Zebra’s compression algorithm. The data is then decompressed and placed directly into the bitmap.) Default: A

       

      So I was thinking that maybe this could be useful? But I'm not sure how to implement it.

       

      Thanks

      Tim

        • Re: Hi Guys, we're printing Labels to a GK420d using ^GF command and think maybe we could improve speeds using compression, read the guide but still a bit unsure the best way to approach,thanks
          Robin West

          Hi Tim,

          There are plenty of ways of compressing the data you send to the printer. Your app is converting all the data into a bitmap in the least compressed method.   Doing anything to compress that already modified image in your ^GF command will be difficult.  You're better off converting the data from the start in a different way.  It's hard to know how to direct you without knowing how your app is creating that ^GF command, but some of your options are:

          1. Initially do not convert your label into an image, but create an actual ZPL label.  This takes more work initially, but usually gets you the smallest data stream.  Tools - ZebraDesigner.

          2. Convert the image into a base 64 encoded image.  Download it with the ~DY command and print with ^IL to print... i.e.

               ~DYE:LABEL,P,P,1044,,:B46:H4sIC...more data...:a1b2    ^XA^ILE:LABEL.PNG^XZ

               You can use several tools to do this conversion including the Link-OS SDK

          1 of 1 people found this helpful
            • Re: Hi Guys, we're printing Labels to a GK420d using ^GF command and think maybe we could improve speeds using compression, read the guide but still a bit unsure the best way to approach,thanks
              Tim Lightbourne

              Hi Robin,

               

              Many thanks for your response and advice, much appreciated.

               

              Actually I do agree with you that we’d probably be better off creating a label with ZPL commands and in fact I think we used to!

               

              To give you a bit of background I’ve only recently arrived in the software development team and from what I can gather historically I think we used to generate labels with ZPL commands via a purchased in Neodynamics software component and it produced the ZPL for our application, creating a small output file and the labels printed incredibly quickly. Unfortunately I think we may have run into problems when we tried to use the Neodynamics component in a multi threaded environment and its performance suffered (probably no reflection on the component itself, maybe the use we put it to) so I think at that point a rewrite took place which resulted in the approach being adopted to go via the bitmap route.

               

              To be fair I can see why maybe this approach was appealing as the ASP.NET web application allows the end user to choose exactly what sort of output they want (label, bitmap, jpeg, pdf etc) for each order produced, so I guess maybe the thinking was to produce a bitmap in code and then in theory it can be translated fairly easily to the other formats, but with hindsight now I think we can see the benefits of the original ZPL for the labels.

               

              I suppose I’ve got the task now really to give my managers an appraisal of where we can go from here - for the time being anyway!

               

              Just to say thanks a lot for the heads up on the DY command, I tried that with a PNG and it does speed things up a lot, producing a very small output file too, so that’s an option for us. Also for the mention of the SDK, didn’t know about that so have downloaded it and am going to investigate.

               

              Just out of interest Robin I can see the PDF guide also mentions Z64, using the LZ77 algorithm and I wondered if you had any advice about that or if it’s something to stay away from? I did have a go and wasn’t sure I was using the correct algorithm as the printer seemed to ignore my sent data.

               

              Many thanks

               

              Tim

               

               

               

              Hi Tim,

               

              There are plenty of ways of compressing the data you send to the printer. Your app is converting all the data into a bitmap in the least compressed method.   Doing anything to compress that already modified image in your ^GF command will be difficult.  You're better off converting the data from the start in a different way.  It's hard to know how to direct you without knowing how your app is creating that ^GF command, but some of your options are:

               

              1. Initially do not convert your label into an image, but create an actual ZPL label.  This takes more work initially, but usually gets you the smallest data stream.  Tools - ZebraDesigner.<https://www.zebra.com/us/en/products/software/barcode-printers/zebralink/zebra-designer.html>

               

              2. Convert the image into a base 64 encoded image.  Download it with the ~DY<https://www.zebra.com/content/dam/zebra/manuals/en-us/software/zpl-zbi2-pm-en.pdf#page=156> command and print with ^IL<https://www.zebra.com/content/dam/zebra/manuals/en-us/software/zpl-zbi2-pm-en.pdf#page=216> to print... i.e.

               

                   ~DYE:LABEL,P,P,1044,,:B46:H4sIC...more data...:a1b2    XAILE:LABEL.PNG^XZ

               

                   You can use several tools to do this conversion including the Link-OS SDK<http://www.zebra.com/sdk>.