Repository navigation
'pathLength' interaction with <textPath> with a percentage 'startOffset' #383
Description
While 'pathLength' in combination 'startOffset' can be considered a no-op for most cases since it's technically just another mechanism for the same thing, and even if applied it should - in a perfect world - just cancel out (i.e something like: offset-percentage / 100 * author-path-length * (computed-path-length / author-path-length).)
However, for a value of 0, per:
A value of zero is valid and must be treated as a scaling factor of infinity. A value of zero scaled infinitely must remain zero, while any value greater than zero must become +Infinity.
(https://svgwg.org/svg2-draft/paths.html#PathLengthAttribute)
you'd expect that all 'startOffset's would map to 0? (There doesn't appear to be many implementations to check here ATM, but Gecko seems to treat '0' as an invalid value for 'pathLength' in general.)
Activity
longsonr commentedon Feb 7, 2018
That text is new in SVG 2, we simply a) weren't aware of it and b) haven't got round to implementing it, or even considering whether we're prepared to implement it.
AmeliaBR commentedon Feb 8, 2018
The intention of the quoted text is that, if the author has set pathLength="0", but the actual path length is non zero, then any effect set to use a position of 0 would use the exact start of the path, and any effect set to use any other positive position value would use the exact end of the path (clamped down from computed infinity).
I don't think we'd specifically thought about
startOffset, and I'm pretty sure we didn't do the math on percentages. In particular, what's unique aboutstartOffsetis that it isn't supposed to clamp values. So the "infinity" interpretation becomes problematic.So perhaps different text is required.
But to me, the guiding principle should be: if the author set
pathLength="0", they are expecting the path to behave as a zero-length path segment. (Which wouldn't fit any text on it at all.)fsoder commentedon Feb 8, 2018
I suspect the current tests - as well as most (all?) browser implementations - would need to be updated then =). (At least it looks as if 'pathLength' is only applied to the 'startOffset'...)
ewilligers commentedon Feb 8, 2018
Can our guiding principle be that pathLength="0" means pathLength is epsilon, an arbitrarily small positive number. Then pathLength simply cancels out when the offset is a percentage:
offset-percentage / 100 * epsilon * (computed-path-length / epsilon).This principle gives the existing meaning when startOffset is a number instead of a percentage:
zero * (computed-path-length / epsilon)remains zero, and(any value greater than zero) * (computed-path-length / epsilon)becomes arbitrarily large, i.e. +Infinity.fsoder commentedon Feb 8, 2018
That would be in practice be the same as saying to ignore 'pathLength' if 'startOffset' is a percentage. (If you were to actually perform the computation, it's a very real possibility that it wouldn't cancel out.)
AmeliaBR commentedon Feb 9, 2018
Makes sense to me.
That also makes sense. We could add a note saying that implementations may make that simplification, to avoid weird rounding errors when dealing with arbitrarily small floating point values.
boggydigital commentedon Jun 11, 2018
Not blocking updated 2.0 CR publication - assigning 2.0 Recommendation milestone to clean this up before 2.0 REC
css-meeting-bot commentedon Jul 2, 2018
The Working Group just discussed
pathLength, textPath, and startOffset.The full IRC log of that discussion
<AmeliaBR> Topic: pathLength, textPath, and startOffset<AmeliaBR> Github: https://github.com//issues/383
<AmeliaBR> Tav: I believe this is just an editing issue, but I wanted to confirm.
<krit> mm https://github.com//pull/476
<AmeliaBR> ...I've got a pull request (link ^)
<AmeliaBR> Amelia: This says it fixes #382, does it also fix #383 ?
<AmeliaBR> ... Can you follow up async, so that everything gets reviewed & merged?
<AmeliaBR> Eric: Yes, and I can create the PR for 383.
pathLength does not affect percentage calculations