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

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

Points:

0You voted ‘up’

Hi Nathaniel,

Several ^F commands can effect origin (centroid) points. If you stick to specifying origin using the ^FT and ^FP for all fields you should be good, but some things to look out for:

^FW provides a default orientation for fields.

Use of different fonts can effect placement. One font can place say a lowercase 'p' with the line below an origin, and others may place it at the origin and a 'a' above the origin.

The commands shown for text also apply to barcodes and their origin (centroid) points. Barcodes also have the ^FM command that cam be used to specify multiple origin points for some specific barcodes.

As you want to ensure correct placement, always specify all parameters in your commands. Default values in parameters of ZPL commands can often be changed and persist.

All other commands which effect placement, effect the entire label. Commands like ^PO and ^LH will change the orientation and rotation of the entire label. These are just two of the many commands which wholesale effect placement on a label.

Robin

Points:

1You voted ‘up’

Hey Robin,

Thank you very much for the info. That helps a lot.

I am using this at the top of the document to make the origin is 0,0 so there is no problem.

^LH0,0^LRN

Cheers,

Nathaniel Nesler

Points:

0You voted ‘up’

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.

Points:

0You voted ‘up’

Hi Robin,

Actually on our end this already works. I am using the math I sent in the links to achieve this.

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

I would like to point out that we are not trying to find the Centroid for the graphics elements but rather we are defining it. We are doing this by using a transform matrix. If you were to consider each character in a font or each bar = character in the barcode as a point in 2D space you could use a transform matrix to scale, position, and rotate all of these together as a mathematical system. This is achieved by forming the transform matrix and then multiplying the transform matrix by the position points in 2D space that make up that object. Where the text for say a tag would be a set of characters that needed to be displayed and each letter would be a point in space that needed to be drawn. Since we are defining the centroid point in space there is no need to find it. In this way all of the mathematical operations work together perfectly in a logical manner all from the same point of reference aka the centroid for the object aka the text or the barcode in question. I would also like to point out that a centroid does not have to be in the center of an object like text or a barcode. In fact our centroids are not in the center of our objects they are in the upper left corner and neither is ZPL's centroids are also not in the center for their transform operations. You can set the centroid anywhere you like for an object with mathematics and then all mathematical operations for transforms applied to that object by multiplying the transform matrix by each point in that object is then transformed accordingly to that centroid.

So I am not trying to figure out how to do this in our application I have already done it. My issue is there is no logical point of reference aka a centroid for all of the transform operations in the ZPL instead each transform operation in the ZPL has its own centroid and even then it is not consistent between rotations. It is different centroids for each 90 degree rotation. If we were to do the same kind of transforms in our application text and barcodes would be popping all over the screen as someone were trying to rotate the text or barcode or scale it or position it because there is no consistency from which it would be scaling, rotating, or being positioned.

To respond to your earlier statement about finding a centroid in text. You were referring to fonts that were not monospaced because as you mentioned below monospaced fonts have fixed widths versus that of proportional fonts that have variable widths. So of course for fixed width fonts its easy to find the centroid just add up the width of all of the characters and then divide by 2. For variable width fonts their widths are included in a TTF aka True Type Font so you would add up the character widths based on the lookup from the TTF and then divide by 2 to get its centroid.

Pretty much all of your graphical design layout programs, games, film software, architectural, mechanical engineering applications etc use these transform matrices to move text, graphics, objects, etc. Programs like word or other typing type applications work probably in the manner you described. ZPL however is a language for graphic design because people are designing labels and not for writing papers like you would in microsoft word or libre office writer.

If Zebra does not have the concept of using transform matrices in their ZPL are there any other tags or something I have to worry about that will modify the position of the text or barcodes since I will have to plot points on a graph for the different tag operations and engineer new mathematical formulas to get consistent behavior out of the translating aka positioning, rotating, and scaling of barcodes and text for the ZPL API. I do not want to have to go back over and over again and re-engineer the same mathematical formulas because I find oh by the way there is the other tag and it modifies the position for some particular reason further down the road. If I have to engineer these mathematical formulas I would like to only to do it once.

I will not have to engineer new mathematical formulas for ZPL if ZPL has a way of doing transforms around a single centroid instead of many different centroids for many different situations.

Cheers,

Nathaniel Nesler

Points:

0You voted ‘up’

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

Points:

0You voted ‘up’