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!!!
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!