-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compatibility mid-line rendering attribute to textPath #337
Comments
Svg used in example:
|
Also, I suggest a change in wording in the first paragraph after the layout rules list:
change:
to:
or to:
|
@AmeliaBR @karip @BigBadaboom @fsoder Any guidance how to proceed here? Is there anything I can/should do? |
You could file bugs on implementations to gauge any "interest" in fixing the current behavior. The difficult part to assess there is if there's any content (and, if so, how much) that might depend on the current behavior. That's for the feature/behavior as currently speced. |
@fsoder This is more about the fact that what the browsers implement (de-facto web standard) and what the SVG specification language specifies are different. Only Edge implements the spec correctly and with some (perhaps?) unexpected results. So I'm now thinking, would it be best to define the current de-facto standard web browser behaviour as the default? And then, the specification standard as the optional one. Thus, if browsers actually want to implement and make available the standard SVG 1.1 text on a path algorithm (and SVG 2.0), and conform the same way as Edge, then they can choose to expose the new attribute, to enable triggering the non-default, but correct behaviour. |
Regardless of the exact path you want to take, I think the steps will be roughly the same. To get interop on the most widely implemented behavior, there's still one browser that has to change its behavior (Edge.) Then/at the same time the spec has to change (this type of change would seem to fit nicely within the new SVG2 charter though, so this has a decent chance of succeeding.) Then the new feature would be introduced (see my previous comment.) |
@fsoder Alright, true. Thanks for your help! I'll look into discussing it with someone on the Edge / SVG team and see what they think about the situation, or if they're even aware of having a different implementation from the rest. |
Not blocking updated 2.0 CR publication - assigning 2.1 WD milestone |
Specification: SVG 2, Text chapter, 11.8.3. Text on a path layout rules
https://svgwg.org/svg2-draft/text.html#GlyphMidline
And following list item.
Excerpt:
This wording is different from how Chrome, Firefox, Opera etc render text on a path. Only Edge seems to actually implement this. I'm implementing and improving the svg spec conformance of react-native-svg, and have implemented both algorithms almost completely (extending the path for the start to end-point calculation, when midpoint is on the path but either start or end is not, is still missing). software-mansion/react-native-svg#406
I suggest adding a compatibility 'mid-line' attribute for the 'textPath' element, with the values 'sharp | smooth', initial value 'smooth'.
The initial value would be the strict interpretation of the spec, and sharp would be the one currently implemented in the wild.
The current common behavior is that it doesn't e.g., bend text smoothly along a right angle curve, (like Edge does) but keeps the mid-line orthogonal to the mid-point tangent at all times instead.
I've already added this attribute to react-native-svg in my fork:
msand/react-native-svg@d081031
Example screenshot: (Smooth on top, sharp below)
The text was updated successfully, but these errors were encountered: