Proposal for a path extension

Introduction

Most 2D graphics languages deployed on the internet today lack the ability to efficiently represent the topology of contiguous regions. This is becoming problematic with the growing number of map-based applications. In this proposal, we introduce a new graphical command to extend the data attribute of the SVG path element. This command is a way to represent the contours in a 2D graphic with a set of reusable chunks of contour. Our proposal is to add new commands in the path syntax. Several syntax has been previously suggested to implement the functionnality by adding new elements; it remains a possibility but it introduces a very different way to define shapes which could be a difficulty for implementers and developers. Our first focus is on completing the <path> element syntax; so, it will be possible to use such path evrywhere where a path can be used and in a very coherent way with the current path implementation.

Proposal: the subpath command

(to be included in the specification as a set of new commands in the path element)

The piece (or patch, choose a name) commands are as follows:

Command	Name	Parameters	Description
P or p	piece	(iri)+	Draws a piece of the current path from the current point and using the commands of the referenced path as if they was present in the current path.
R or r	reversed piece	(iri)+	Draws a piece of the current path from the current point and using the commands of the referenced path as if they was present in the current path but in reverse order (see comments below).

Example piece01 shows some simple uses of piece and reversed piece commands within two path.

 <svg xmlns="http://www.w3.org/2000/svg" viewbox="0 0 1200 600"
   version="2.0" >
   <title>Example piece01 - piece and reversed piece commands in path data</title>
   <desc>Picture of a simple paving of a region with two path sharing a piece</desc>
   <defs>        
     <path d="L330,150 280,230 330,310 280,400" id="p1" />                             
   </defs>
   <rect x="1" y="1" width="1198" height="598"
     fill="none" stroke="blue" stroke-width="1" />
   <path d="M 90,190 220,90 P#p1 120,375 z"
      fill="yellow" stroke="blue" stroke-width="5" />
   <path d="M 500,385 390,460 R#p1 450,50 565,81 z"
      fill="red" stroke="blue" stroke-width="5" />
 </svg>

Example piece01

The value iri associated with a piece command is an IRI reference to a path defined within an SVG document. If several iri follows a piece command, each one is used as if the piece command was repeated.

Refer to Piece implementation notes for detailed implementation notes for the path data piece commands.

Comments

How are the piece and reverse piece commands processed?

Here, we propose a model for processing a reversed piece of path. It's a model, not an implementation guide.

First principle: when a P or R command is found, a virtual drawn is produced as if the current point is (0,0); it becomes a sort of primitive which will be connected as a whole to the current path. This primitive takes the absolute or relative attribute of the first command of the referenced path.

With the direct command (command P), we have a special case of curve: the current point is the starting point for the 'curve', so originin (0,0) of the 'curve' is translated to the current point and the last point of the 'curve' becomes the current point.

With the reverse command (command R):

if the first command of the referenced path is absolute, we simply draws the path and ...???
if the first command of the referenced path is relative, we simply draws the path and ...???

Example

If the referenced path data is the string:

m 100,350 450,0 c 190,0 270,180 120,280

then the virtual reverse path is

c 150,-100 70,-280 -120,-280 l -450,0

Here, we take in the reverse order with some necessary calculus. We have

c x1 y1 x2 y2 x y

which becomes

c x2-x y2-y x1-x y1-y -x -y

and then the ralative line (450, 0) becomes a relative line (-450,0)

Piece command and animation

TO BE DESCRIBED

Circular references

The proposed command introduce the possibility for cross-reference -a path is defined with reference to another path which is defined by a reference to itself- or circular references.

To avoid problem with such cases, we suggest to find recursively all the references used directly or indirectly to define a path and to stop the process as soon as a circular reference is discovered.