W3C home > Mailing lists > Public > www-svg@w3.org > February 2014

[SVG 2] bearing path command

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>

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?

Received 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