Question
Tom Cross · Jul 20

Patient Labels Design Dilemma: ZPL Abstract Class vs JReport(LOGI)

I am reaching out to find out if anyone has come across a similar dilemma. 

In my current role, I have been asked around the best way to design some patient labels for a client.

 I primarily would stick to what I know and veered towards designing the label in ZPL and then creating a Abstract Class to call the ZPL code, however I have been asked why not to design via JReport. The patient labels will be processed via thermal ink printers primarily Zebras, I am wondering if anyone out there has come across this or  would recommend to stick to what you know. 

I have reached out via I-Service but great to hear what other developers would recommend?  

 

 

Product version: IRIS 2021.2
0
0 76
Discussion (4)1
Log in or sign up to continue

Talking about sticking to what you know:

In my experience printing to the zebra thermal printers was a matter of printing via a RAW print queue.

1. Designing a Zebra label template file using zebra software. ( Paid software to render the template files after designing it graphically. )

2. Have the application produce the correct data file in the format expected by the zebra printer.

3. Print via the RAW queue in one transaction the template file followed by any number of data files to have the printer merge the two and print the labels.

This means the application only need provide the data elements in a flat file.

Alternatively you need to "speak" ZPL from the application and directly control the print on the printer.

Not sure if this helps - but there is my 2c worth.

Thanks Angus,

I get what your saying using the paid Zebra Software. 

We have already designed the template using a ZPL viewing tool Link

^XA
^FO50,20^ABN,25,15^FD<SURNAME>, <FIRSTNAME>^FS

^FO50,50^ABN,25,15^FD<NHIXXX>^FS
^FO210,50^A0N,25,20^FD<DD/MM/YYYY , XXy>^FS
^FO420,50^A0N,25,20^FD<Sex/Gender>^FS

^FO50,80^A0N,25,20^FD<Visit_Number>^FS
^FO210,80^A0N,25,20^FD<Case_Manager>^FS

^FO50,110^A0N,25,20^FD<Ward_Code>^FS
^FO210,110^A0N,25,20^FD<Department_Name>^FS
^FO420,110^A0N,25,20^FD<Team_Name>^FS

^FO50,140^BCN,40,Y,N,^FDNHI999XVISITXXX^FS

^FO750,20^A0N,25,20^FD<NHIXXX>^FS
^FO700,50^A0N,25,20^FD<TEL:027123456>^FS

^FO750,70^BQ,2,6^FDQA,NHI999XVISITXXX^FS

^XZ

I am still working through the Abstract Class/Print function to call the printer directly as this was similar to what was setup on UK sites. 

Cheers

TC

My experience with Zebras was quite a few years ago, so this may or may not still apply... Using Zen reports at the time, the print server would end up rendering the label as a bitmap and sending that over to the Zebra. ZPL code to print an equivalent label was much smaller than a bitmap, so ZPL labels tended to print faster than those rendered by a report.

Hi. Label printers are a pain. :-) In the application I worked on, the printing was originally to matrix/line printers via a "driver" that knew the escape codes to use. But then along came the "thermal" printers using things like ZPL, and squeezing that into a line by line driver was not easy. Had to keep track of a virtual print head "position".

Using a tool to build a template and just providing the field data from IRIS sounds like a much easier route. I think you can save templates in the printer memory, if you don't want to store the text in IRIS.

If you do want to build the printer commands yourself, I recommend hiding them behind a class that stores a virtual label, and have methods to add the commands that take sensible inputs like x and y in mm (or inches), rotation in degrees, font in points, etc. Then internal functions can convert to dots, replace special characters, work out font to use, etc. And then have a final "print" method that writes the whole set of label commands out.

Have fun,

Mike