Textpath startOffset & textAlign

[melchiar]

I'm just starting work on adding some additional properties to the textpath implementation beginning with the startOffset property, and am looking for some feedback.

According to the W3 SVG Specs, startOffset should accept either a distance or a percent value. With the current gradient implementation we store the unit (pixels|percentage) in the gradientUnits property. Should we do something similar for startOffset, or should it simply intuit the appropriate unit based on the value being a number or a string containing the % symbol.

Thoughts?

[melchiar]

The other option would be to omit % as an option entirely and use the textAlign property to achieve the necessary text positioning. I'm starting to prefer this approach actually since it seems to me that having a percentage based startOffset is a poor substitute for proper textAlign support which is lacking in SVG textpaths.

Here's a JSFiddle showing text on a path with startOffset and textAlign support if anyone cares to experiment.
https://jsfiddle.net/melchiar/vhgtesoy/

[melchiar]

I've updated the fiddle with some more properties. It now has startOffset, textAlign, side, and direction for rtl text

https://jsfiddle.net/melchiar/vhgtesoy/

[melchiar]

just added a dedicated branch for this if anyone wants to track progress

https://github.com/fabricjs/fabric.js/tree/textpath-moreprops

[asturur]

Keep a PR open on master from this branch, is so much easier to see what is going on. I ll open it now.

[asturur]

So for sure textAlign left/right/center ( justify ? ) is probably one missing thing that we actually need.
WIthout considering that we have also RTL to take care of.

We don't have a way to measure a path from right to left, i wonder if with textAlign or at least with RTL we should just flip the path.

[asturur]

You should have the total length of the line already, why should you loop it?
I would image that textAlign is a side effect of implementing startOffset.

Not sure if you digged deep into text routines, but text has different stages of calculation
measuring the bouding box, where we check how much space each char takes,
then we measure each text line how long is it.
We can keep those values and reuse them until you change text.
When you then switch textAlign the leftOffset position of a normal text line is calculated on the fly.

Now with textPath this changed and the part that measure the text is also the part that measure the angle of each char and their final position in x/y, this in the same for-loop.

Now as you said, you need to measure or loop over it twice because you can't know how long is a line and therefore you don't know how to start with the path measurements.

I would suggest you add that double loop there in that existing function _measureLine, looking at how it was before the introcution of the path, so that in that function one loop will take care of the lines' straight length, and the next loop can fit this length in a particular part of the path.

[melchiar]

Yes, that's the approach I've taken in my fiddle which seems to work well (https://jsfiddle.net/melchiar/vhgtesoy/)

It looks though like there's a bug in our current getPointOnPath calculation when text flows over from the end to the start of the path (see screenshot)

[melchiar]

So it looks like what's causing this issue is the way the starting point is calculated at the beginning of the path.

The first character at path's start never crosses the beginning of the path, while the end of the path does allow a character to flow over the end slightly (as long as the character's center is still on the path). This is fine for open paths, but not great for paths that are a closed loop.

Perhaps we should change getPointOnPath to recognize if the path is closed or open?

[asturur]

Also segments junctions are an issue if i recall correctly.

[zzq0324]

Is there any new news? I am now render text in a circle path, and the first and last characters are close together, even i set charSpacing.