1 person found this helpful
Use the endHorizontalOffset property instead.
One of the issues with text objects (which can be a blessing or a curse depending on what you happen to want at any particular moment) is a principle I call "The last shall be first." That's because the last insertion point of any particular text object is the same insertion point as the first of the next similar text item.
So, for example,
nextPara = thisPara.insertionPoint[-1].paragraphs
A consequence of this is that the last insertionPoint of a line has two different positions, the end of one line and the start of the next.
Even the UI is confused by this. Click at the end of a story that ends in a paragraph mark and place a graphic. You'll see that the cursor marker stays at the same insertion point, but whereas before placing it is at the left of the line to which you've just added the graphic now it is at the end of the previous line.
This is very weird behavior that has freaked me out for over a decade now.
Amazing. Thank you. That did it. Appreciate your help.
one should note here, that the position of endHorizontalOffset is calculated wrong, if a word is hyphenated.
I think, we already had this discussion, but by using endHorizontalOffset and its couner part endBaseline I finally found a reliable way to calculate the position of an endBracket in a textPath:
I temporarily set the justification of the text to Justification.FULLY_JUSTIFIED and did not allow hyphenation.
Note: The position of endBaseline is very unreliable with a hyphenated word.
As we can see here in this example where I placed the guides in the found and x and y positions endHorizontalOffset and endBaseline were suggesting:
The text at the textPath on top is formatted with FULLY_JUSTIFIED and hyphenation off.
The three text paths below, that are threaded to a single story are just FULLY_JUSTIFIED:
Here a close-up of the situation with the hyphenated words:
I still did not find out why the distance of the y positions with the red guide and the green differ so much.
At least I found a solution for my problem with the endBracket position…
My only explanation for the wrong y positions calculated with endBaseline and hyphenation is, that the insertion point between the "c" and the "h" at the top example was read out. Respectively the insertionPoint between the "u" and the "l" on the path below. Each time one character too soon ( the automatic hyphen ignored at all).