You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Text objects can be horizontally aligned via alignment="center", but vertical alignment turns out to be a lot trickier.
Measuring the height property gives some information, but this already contains several assumptions. An extra line may have been inserted during height calculations, to give room for descending text elements. The size of this line is in turn computed from current font size and line separation settings. To get an accurate compensation for these factors basically requires rewriting a whole chunk of renderText out in user code.
That's not optimal. I'd rather have that information available on the text object itself, where it can be computed once.
I can see three ways of exposing this information:
Implement a vertical alignment similar to the extant alignment property, so the object will automatically line itself up as desired. Issue: We already have an alignment property, so some semantic contortions may be required.
Push alignment information into the anchorPoint data. Issue: This data is user-accessible, so it might be overwritten and become irretrievable. Issue: If the user configures their own anchorPoint data, calling renderText (or changing text properties, which invokes the method) will overwrite that data.
Provide vertical centroid data as a unique property on the object. Issue: This is not standard, and might not be immediately recognised by users. Issue: This still requires users to implement their own positioning solutions.
The vertical alignment solution does sound most optimal at this stage.
The text was updated successfully, but these errors were encountered:
Text objects can be horizontally aligned via
alignment="center"
, but vertical alignment turns out to be a lot trickier.Measuring the
height
property gives some information, but this already contains several assumptions. An extra line may have been inserted during height calculations, to give room for descending text elements. The size of this line is in turn computed from current font size and line separation settings. To get an accurate compensation for these factors basically requires rewriting a whole chunk ofrenderText
out in user code.That's not optimal. I'd rather have that information available on the text object itself, where it can be computed once.
I can see three ways of exposing this information:
alignment
property, so the object will automatically line itself up as desired. Issue: We already have analignment
property, so some semantic contortions may be required.anchorPoint
data. Issue: This data is user-accessible, so it might be overwritten and become irretrievable. Issue: If the user configures their ownanchorPoint
data, callingrenderText
(or changing text properties, which invokes the method) will overwrite that data.The vertical alignment solution does sound most optimal at this stage.
The text was updated successfully, but these errors were encountered: