https://wiki.inkscape.org/wiki/index.php?title=PathOps&feed=atom&action=historyPathOps - Revision history2021-11-27T06:08:20ZRevision history for this page on the wikiMediaWiki 1.36.1https://wiki.inkscape.org/wiki/index.php?title=PathOps&diff=3660&oldid=prevConversion script: link fix2006-01-22T02:33:29Z<p>link fix</p>
<p><b>New page</b></p><div>Conceptually, most path operations can be considered as a transform from regular affine space into a curved space found by generating a matching orthonormal basis using the curve's normals:<br />
<br />
http://www.inkscape.org/mockups/unnormalised.png<br />
<br />
However, as you can see from this, we also need to normalise along the length of the curve:<br />
<br />
http://www.inkscape.org/mockups/normalised.png<br />
<br />
The difficulty comes from the fact that none of the primatives provided by inkscape are invariant under this transformation. Thus, we need to re-match a curve to the transformed polygonal approximation. inkscape already include a bezier curve fitter, but the curve fitter is unaware of corners. This turns out not to be a big problem because we can work out where the corners are and simply perform the curve fit on segments.<br />
<br />
With this strategy we can transform almost any shape into the path coordinate system.<br />
<br />
What things do people want? a simple offset function that moves the curve f(t) to f(t)+o*&nabla;f(t) and the matching outline stroke function were requested on [[PathEstimation]]. Other interesting operations include:<br />
<br />
* mapping text to the path. This required simply rotating and translating each glyph to sit on the curve in the direction of the normal. This get a little trickier with sharp bends such as this:<br />
<br />
* tingham 11.21.03:: What if we have a configurable parameter for text-path mapping which states that we should split characters on curves under N degrees. This would cause characters to sit on either side of the sharper curve where the normals are more "sane". njh: This will solve the outside curve problem, there is still a problem with the inside of the curve.<br />
<br />
http://www.inkscape.org/mockups/sharp.png<br />
<br />
* mapping shapes to the path. At the basic level we can perform the same approach for mapping shapes to the curve, namely to rotate each and line it up with the glyphs, then translate. Or, we could map the shape properly into the appropriate curve space. This is harder, but gives more predictable results.<br />
<br />
If arbitrary shapes are allowed to be mapped to curves, then we immediately have a way to provide stroke styles. For example:<br />
<br />
http://www.inkscape.org/mockups/string-of-pearls.png<br />
<br />
A simple regular language can be provided to allow the artist to build more powerful styles. for example, the style (<greendiamond>(<leopardcircle><dot>)*<greendiamond>) would generate this path:<br />
<br />
http://www.inkscape.org/mockups/double-kite.png<br />
<br />
The style can include specific points to match in the curve (lengths, fractions of total, knot points). Some kind of stretchiness should be provided, most likely using the [[TeX]] glue idea. Combine this with the dynamic programming solution to line breaking and we can have text mapped to multiple curves.<br />
<br />
Representing a style in the document probably should be implemented as a special group with the metadata specific to the style and the original path, and also a rendered version. Clearly the user needs to be able to edit the original path rather than a 'flattened' version. Clicking on the convert to curve button will 'flatten' the style path so the artist can then moving things around.<br />
<br />
There seems to be some common ground with markers. (That is, [[PathOps]] is a superset of markers)</div>Conversion script