3 Replies Latest reply on Apr 12, 2016 2:12 PM by Mark Warren

    ^FPR alignment question

    Mark Warren

      This is the first time I have worked with a right-to-left language (Hebrew) with ZPL and have never paid much attention to the ^FP command before.

       

      Can anyone explain why the weird alignment features with ^FPR, especially with Inverted orientation, ^FO positioning and left justification?

      Why is the text offset from the origin?

       

      None of the examples in the ZPLII programmers manual (section Field Interactions, Inverted Orientation) make any sense...

       

      Thanks, Mark

        • Re: ^FPR alignment question
          Robin West

          Hi Mark,

          I'll try to explain by breaking down the commands. Fonts are tricky to understand.  Our font engine is advanced, but doesn't always do what you may expect.  It helps if you think of this as if you were handwriting the text. You need to decide where to start your pen stroke.  Normally you start a character and a word by drawing the first character starting from the bottom-left.  That's the ^FT command.  You could also start drawing from the top-left- ^FO.

          It helps if you look just at the ^FPH progression (left column) first.  Left justification should be clear given my explanation.  Right justification should also look clear, but is more complicated than you might think as the font engine takes into account the width of the last character for it's origin point.  Right justification means not just the word, but the characters are right justified as well. Not all characters in most fonts are the same width.   The example is, but that's not common. Keep that in mind.

          Now if you look at the ^FPR progression (right column), it may be a little clearer.  Even if you are writing a word from right-to-left, most of us will start with the first character's bottom-left.   In the example, the string is "ABCDE", so right-to-left would print "EDCBA".  The first character you would probably print if you were hand writing the string as a string is the A no matter what direction you were writing in.  In fact, if you remember that we do not know the width of each character ahead of time, it is necessary.  You have to draw them in order for the characters to look right and not bunched or too wide spread.  The last character printed is the E. Left justification origin is still the top or bottom left corner of the first character in the string. Right justification is still the top or bottom right corner of the last character in the string.

          Does that help?

          Also you have the added bonus that most Hebrew fonts are scripted fonts, which means the character typeset may vary based on the preceding and/or following characters.  It's like writing in cursive.  A lower case 'i' is drawn differently if the character before it was a 'l' or a 'f'.

          Our font engine does the work to figure it out, but you have to tell it where to start, hence the ^FO, ^FT, and ^FP commands.

          FieldInteractions.jpg

          Let me know if this clarifies or confuses things.

          Robin

            • Re: ^FPR alignment question
              Robin West

              Additionally - Inverted orientation switches the origin point from the top left to the bottom right, flipping it.  That means the left justified ^FO is the bottom right of each character, and ^FT is the top-right.  If most of your text is inverted, it's far easier to lay out you label in normal orientation and flip the entire thing using the ^POI.

                • Re: ^FPR alignment question
                  Mark Warren

                  Hi Robin,  thanks for the response.

                   

                  I am not convinced I like the way the left/right alignment works with ^FPR.  (And I must use the inverted orientation because the top half of the label is normal orientation, the bottom half inverted.)  When emitting inverted right-to-left text, you want it left aligned.  But the way both ^FO and ^FT are implemented, the text is never flush; it will always be offset by the variable width of the first glyph.  This is especially noticeable when one line of text begins with a wide glyph and the next line down, with a narrow glyph.

                   

                  Fortunately, there is more than one way to skin this cat, and I can just use ^FPH with a diacritical-marks-aware string reversal.

                   

                  Cheers, Mark