I don’t have a printer available at this moment, so please take the rotation part with a grain of salt.
I experimented with two technologies:
- sapscripts to send raw commands to the printer
- smartforms, that have (partial) native support for these printers
The first technology I worked with is the older: I used a software called “bar one” to graphically design the labels,assigning the field names, and then export a file that I later imported in the sapscript.The file basically contained a sequence of Zebra commands with some sapscript variables, and apart from variable substitution it completely skips the SAPSCRIPT engine to send raw commands to the printer.
This worked smoothly, but had a couple of annoyances:
- the screen preview is a set of Zebra commands, to see how a label looks like I had to actually print it.
- every change to the label has to be done on a file, I had to keep track of which sapscript came from which file.And versioning relied on proper manual file management by the team members.
- if I modified the sapscript (i.e. conditional output of a field) I had to detect and copy the changes manually every time.
All in all, it’s a bad solution but works fine.
When I heard that I could design everything by hand with smartforms (although with a few caveats) I was quite excited at the idea of getting rid of that external tool.
I took a look at note xxx and agreed with the business that the labels had to be printed in portrait. Everything worked fine in the test environment, but then the production printers was too narrow and I was required to rotate the label.
Then the nightmare begun.
The zebra driver is quite odd: doesn’t care about paper width and is unable to rotate the page.Every window and line has to be rotated manually, and smartforms don’t support it.So the only way to get a landscape layout is cheating.
Some OSS note explains how (setting a command S_LZPL_SETUP to ‘^FWR’), but wisely doesn’t go too deep in how to accomplish that, so I’ll try to explain it in detail here.My goal is to dissuade you to even try doing it, but you can also use it as a limited how-to document.
The rotation required is shown below, any point (X,Y) becomes (H-Y,X): for the lines and boxes everything is fine, you just have to apply that transformation to the coordinates and exchange widths and heights.
Barcodes are only a little more tricky: thay need custom barcode formats, identical to the originals but with vertical orientation.
The real pain comes with the text.To rotate the text you add a command node with a raw zebra control sequence that rotates the text by 90 degrees for the time being.
Since the driver doesn’t care about that, it can’t handle multiple lines, and the box containing the text has to be WIDE enough to accomodate the line, even though the text will be actually displayed vertically.If the window is too narrow, the driver keeps changing line and adding to the vertical position, writing several characters above each other.I don’t remember if it worked better changing the width with the length of each field or setting every dimension to the bigger one (thus making every box a square).If you are brave enough you can try it yourself.