ThermalLabel SDK 4.0 future plans

Our team is working on next major release of our ThermaLabel SDK for .NET product and customer’s feedback is always appreciated. Since ThermalLabel SDK first release, we’ve tried our SDK leverages Zebra Programming Language (ZPL) as well as Eltron Programming Language (EPL) for generating outputs to thermal printers. Sadly, forcing our product to stick with those printer languages make that some high requested features sent by our customers become impossible to accomplish. Some of the most requested features are the following:

  • Landscape printing
    A very simple concept but it is not provided by ZPL or EPL natively and the only workaround with current release of our product is that you have to design the label applying 90 or 270 degree rotation on EACH item placed on it for simulating a Landscape printing scenario. This is a big problem (and a waste of time) because if you have to support Portrait printing too, then you are forced to design the same label with the same items but without rotation. But that’s not all… in EPL most 2D barcodes like Aztec, Data Matrix, Maxicode, etc DOES NOT support rotation!!!
  • Print Preview
    With current release of ThermalLabel SDK you need a real printer to test your label outputs. A Print Preview feature would add some nice advantages like coding with ThermalLabel without the need of having a printer, great savings by not printing physical labels (“Go Green ” touch) as well as a visual preview for application’s end-users.
    One approach to get this out would be a conversion of the generated ZPL or EPL commands to some image format. Sadly, the main issue to accomplish this regards on barcodes because some symbologies have different algorithms that generate different barcodes although all of them could be valid. Because we do not know how the barcode algorithms inside the firmware printer are coded, we cannot provide an accuracy preview of a label i.e. in other words it’d not be WYSISWYG. Other problem is also with text and fonts which is very difficult to port from ZPL/EPL to GDI+ or WPF drawing engines. And not to mention that we’ll need to write two different conversion tools for each printer language.
  • Visual Label Designer
    This would be a great/big feature. Sadly, the same issues apply on this scenario as described above for Print Preview feature.
  • ASP.NET Client-side Printing
    Some customers commented us the need of having this feature added. The fact is that since v1.0 of ThermalLabel SDK, we tried to fill this gap without success. The main problem here is that in ASP.NET, printing on the client-side relies on the client’s browser printing support or on some plug-in technology based on ActiveX, Java, Flash or Silverlight. In all our tests, we have not found one approach that is 100% reliable. The current issue here is to find a way for sending raw plain text commands to the printer from the browser.

Those are the most requested features for ThermalLabel SDK. We are brainstorming v4.0 and we think we need to provide some of those features with it. Based on all limitation about ZPL/EPL to get them out, we’re seriously thinking about changing our labeling engine and port it to a “Graphic-based” approach.

In v3.0 we introduced some barcodes that are not present in ZPL or EPL firmware like 4-State Postal barcodes, Telepen and Pharmacode as well as a new GraphicTextItem with more features than the standard TextItem like Text Sizing, Multiline, Unicode support, Right-To-Left (Hebrew, Arabic, etc.), Custom Windows TTF files, etc. All these new additions were added thanks to our Barcode Professional product lines as well as .NET drawing classes. Here we just convert the .NET drawings generated by Barcode Professional algorithms to ZPL or EPL image commands.

So, the idea in v4.0 is to move ALL items to a graphic-based approach including barcodes and texts. Now that our Barcode Professional product lines provides almost all barcodes found in ZPL or EPL, then it’d be simple to replace them with our algorithms. In addition we could provide some Human Readable Text features like custom font settings, justify alignment and centering which are not supported by ZPL or EPL. And for texts, we could provide from simple text to rich text formatting!
If we move our labeling engine to that graphic approach, then all most requested features i.e. Landscape printing, Print Preview and Visual Label Designer could be a reality (ASP.NET Client-side printing is simplified too although it will require further testing)
One more important benefit on this new approach is that you NO longer will need to create separated labels for each printer language (ZPL or EPL)! With the graphic-based engine you’d create one label design for both printer languages 😉

But what would be the cons by going for that Graphic approach? Well, our product will continue generating ZPL or EPL commands but because now all items are in a “graphic” surface, the printer commands for it will increase the print job size a bit and printing speed performance could decrease in some way.

In conclusion, our main idea for v4.0 is move to a new graphic-based labeling engine for providing better new features while saving development time to our customers. Anyway, this post is for our current and future customers so all of you can comment or provide us further feedback. Thanks for your time!


11 thoughts on “ThermalLabel SDK 4.0 future plans

  1. Stefano Paparesta October 28, 2010 / 3:20 am

    If I can mix graphics and ZPL I do not see big problems, the graphis elements slow the printing speed

    • neodynamic October 28, 2010 / 8:06 am

      Hi Stefano,

      If you use some image item on the label, then it is converted to ZPL/EPL graphic commands. Things change if you are not using any image item in which case the current approach is lightweight if comparing it to a graphic-based engine. Anyway, we’re facing lot of benefits with the new graphic-based engine to developer needs. Thanks for your comments Stefano!

  2. Will Robinson October 28, 2010 / 4:18 am

    The fact of the matter is that if you keep the current release available for sale – people can resort to that if speed is what they need.

    I’d happily take the performance hit of a graphics based engine for the advantage of landscape printing!

    Also, wouldn’t a grpahics based engine allow us to generate images for ASP.Net websites? This would be an extra feather in ThermalLabel’s cap!

    • neodynamic October 28, 2010 / 7:53 am

      Hi Will,

      Thanks for your comments. Yes, a graphic-based engine will allow to display output labels on ASP.NET web pages and maybe this approach might work for client-side printing.

  3. Olen Penn December 21, 2010 / 2:56 pm

    I would like to see client side printing implemented ASAP. I developed a project and as soon as I moved it to the server, I quickly realized that I had a problem. I’ve searched for solutions and really haven’t found one.

    • neodynamic December 21, 2010 / 4:18 pm

      Hi olen,

      As we stated above, we tried to provide a reliable solution for web client side printing without success, sadly. In v4.0 we’re facing one because with it an image of the output label can be displayed on a webpage and printed out by using the client printer driver.

    • Olen Penn January 3, 2011 / 2:25 pm

      I figured out a way around my problem. At first I thought about deploying the application on each machine locally that needed to print. But since decided to write the information about the print job to a table from the application and then have a windows application sitting on the client computers that do nothing but print. So the windows app will go to the table, look for print jobs for a certain user, and then print locally on the clients computer.

      • neodynamic January 3, 2011 / 3:06 pm

        Thanks for sharing it, Olen!

  4. Rodion Pronin January 3, 2011 / 1:17 pm

    I would really love to see label designer to be available as Control that we can leverage inside our application. That control could be disconnected from the data source and we, as developers, would take care of all the data binding.

    • neodynamic January 3, 2011 / 1:46 pm

      Thanks Rodion for the feedback. Yes, we’re working on providing a control for the canvas part of the visual label designer. The canvas designer will feature elements arrange, selection and handlers for resizing and rotating items; an undo/redo engine, a ruler, “snap to grid”, zooming, output label preview, etc. Then you can develop your own whole designer app by providing your toolbox, menubar/toolbar or ribbon UI.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.