From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>

Date: Fri, 14 Feb 2014 13:40:11 +0100

To: www-svg@w3.org

Message-Id: <201402141340.11398.Dr.O.Hoffmann@gmx.de>

Date: Fri, 14 Feb 2014 13:40:11 +0100

To: www-svg@w3.org

Message-Id: <201402141340.11398.Dr.O.Hoffmann@gmx.de>

Hello, another thing about bearing: There are at least three options to use something like this, but currently only two are covered with B and b. If one does not use straight lines, but arbitrary curves to construct objects with rotation symmetry, the current tangent affinity of b does not help - it would be more useful to have the bearing relative to the current bearing, not the current tangent. For all these use cases still one can forget about relative bearings by using only B however, but because relative commands are currently more relative to the current 'situation', that something is relative to an abstraction like the tangent is something surprising/new for this b command, maybe not what one might expect to get. However for some other use cases it might be a help as well to continue automatically in the direction of the tangent to get no undesired edges in the path - currently one has to determine this by analysing the previous control point(s) manually - and one still has for the 'last' segment of a closed subpath. However as it turned out for markers already, it is obviously not easy to implement it correctly to determine the correct and meaningful tangent - therefore in practice some combinations of path data and the current b is quite risky for authors. As for markers and linejoins as well it will be useful to have a list of more problematic situation in the implementation notes, how to get the tangent right to help implementors. Another issue about bearing in the path section: I think, it is suboptimal for understanding and the whole structure of the section, that it already talks about bearing before this is defined. This should be done after bearing is defined. 'Relative path commands are also influenced by the current bearing, which is an angle set by the bearing commands. This allows for paths to be specified using a style of "turtle graphics", where straight line and curved path segments are placed with their starting point at a tangent (or at some other angle) to the current bearing.' does not really explain, what bearing is. Therefore my suggestion is, either to define the bearing commands before other commands, it has influence on, or to move all the explanations of the influence in the bearing section. About the formulas with sin and cos - for one coordinate it should be '-sin' and not 'sin' to get a rotation, else the determinant of the transformation matrix is typically not 1 -> no rotation, maybe a combination of skewing, rotation and scaling. Additionally - for cubic curves the mentioned formula is related to the final point, not the control point - x y is point, x1 y1 x2 y2 control points. Respectively for the quadratic curves. More to consider: Can it help implementors to add an information, that bearing can have influence on marker directionality, linejoin on the related vertex? It should be possible now to align the linecap with final B, b right? With B even if the subpath itself has no directionality - is it worth to mention this as a hint for authors as well? OlafReceived on Friday, 14 February 2014 12:40:40 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 8 March 2017 09:47:35 UTC
*