Hello Support,
Our company has a label designer built into our over all software solution. We are using the commonly used technique of transform matrices for doing position, rotation, and scale for text and barcode objects. We are setting the upper left corner of the text or barcode as our centroid pivot point for the transform operations, however when we pass these correct position values into ZPL language with the rotation tag of N, R, I, or B a standard centroid point is not maintained and the position printed is not as expected. It seems that the centroid is changing for each and every rotation point along each 90 degree rotation. We are also encountering an issue with the ^BY scaling tag where when scaling the centroid point is at a different position than the rotation points. So far the behavior we are getting is a different centroid position for each mathematical operation for each rotational position.
Is there a setting in ZPL where we can set the centroid point for rotations, positions, and scaling? If there is not a way of setting the centroid position for transform operations then we will have to derive a formula for each rotation position with respect to position and scaling. Is there any other tags that could change the position of a barcode or a text element other than that of scaling and rotating? I ask because I do not want to redevelop these algorithms over and over again if other things need to be included in my formula for these calculations. The end result should be what we position on the screen should match what gets printed.
Matrix Transforms Mathematics:
Euler Rotations:
Euler angles - Wikipedia, the free encyclopedia
Euler Angles -- from Wolfram MathWorld
Quaternion Rotations:
Quaternions and spatial rotation - Wikipedia, the free encyclopedia
Changing the barcode from I to R, N, B will help illustrate the issue of the changing centriod. Also changing the value on the BY tag from 4 to another number will also illustrate the position changing as the scale changes in a completely different centroid position and direction.
^XA
^LH0,0^LRN
^FO100,403
^BY4^BCI,300,Y,N
^FDSDGAD_0100001323^FS
^FT75,901
^A0B,100,100
^FH^FDSTUFF^FS
^XZ
Cheers,
Nathaniel Nesler
Centroid Transforms For ZPL II Language |
3 Replies
Hey Robin,
Thank you for the link. It clearly shows that as text is going through its rotations the centroid position is not maintained and it is jumping all over the place. The + is the centroid in these examples that text is being transformed about.
Top Left Corner For The Centroid:
Normal Orientation:
^FO Left Justified for the column ^FPH is a good match but as we rotate this centroid is not maintained.
Rotated Orientation:
^FO Right Justified for the column ^FPH is a good match for the centroid noticed we had to jump from left justified to right justified.
Bottom Up Orientation:
^FT Left Justified for the column ^FPH is the closest match for the centroid but it is not in the top corner instead it is in the bottom corner and there is no match.
Inverted Orientation:
^FT Left Justified for the column ^FPH is the closest match for the centroid but it is not in the top corner instead it is in the bottom corner and there is no match.
So this means I will have to engineer mathematical formulas to correct the positions for the text objects for ZPL. Is there anything else that can change the position of these text objects besides the position, rotation, or scaling for these text objects?
Is there anything in the documentation like this for barcodes?
Thank You Very Much,
Nathaniel Nesler
Hi Nathaniel,
I'm not sure if there is an easy way in ZPL to do what you are looking for. There is a section in the ZPL Guide on Field Interactions and Rotations that might help explain how rotations work in ZPL with typesets. You will notice that none of the rotations (or scaling for that matter) are using a centroid position but an origin point based on the typeset or page origin.
^XA
^FT300,300
^A0N,40,40
^FDNormal^FS
^FT300,300
^A0R,40,40
^FDRotated^FS
^FT300,300
^A0B,40,40
^FDBottom^FS
^FT300,300
^A0I,40,40
^FDInverse^FS
^XZ
The primary reason for this is because of the way most font engines work from a starting character and create the image as they move through a string. Different characters often have different widths so it's nearly impossible to determine the length of a printed string prior to rendering it. Yes the center point could be back calculated prior to printing and the position adjusted, but this is not a common request so is not currently part of ZPL.
Hope this helps,
Robin
Additionally: You may be able to calculate out a centroid point yourself as part of you calculations if you use a monospace font. Monospace fonts have each character the same width so it is possible to calculate the length of a string ahead of time and figure it's center point.