Proposals/Shared Path Motivation

From SVG

Principle

Syntax to:

  • Describe one path by grouping several smaller paths
  • Share some smaller paths among paths

(the proposal extend this to the possibility to get new paths by operators -union, intersect, ...- between existing paths)

Main benefits

Preserving the knowledge that two chunks are identical along the lifecycle of a document (edit, store, transport, present, adapt)

which is notably useful

  • to enable processes that takes benefits of that knowledge like dynamic adaptation to a context (screen size...), editing...
  • to reduce the file size (when applicable)

Possible benefits:

  • edit: edit in the same way each occurence of identical sub-paths
  • store, transport: in some cases, reduce the file size and the data to transport; preserve the knowledge that two chunks are identical to avoid to find them again and again (computation which has probably a complexity of N^N, where N is the number of points in the document)
  • present: avoid repeted processing on each occurence of a sub-path; limit the anti-aliasing problem (see presentation)
  • adapt: when a terminal or an intermediary (adaptation proxy) receives an SVG document, it could decide to adapt it by changing some parts of the document (width/height ratio, coordinate precision, text size...); knowledge of chunks identity enables coherent adaptation between these chunks

About implementation

If limited to the veReverse and veJoin described in the proposal, the implementation could remain simple.

veIntersect and veUnion could result in unpredictable results in some cases, if we get cumulative computation errors by an internal representation of coordinates with floats or doubles. So, we have to choose between:

  • don't support complex operators
  • accept errors in some complex cases
  • impose the computation of exact coordinates by using infinite precision arithmetics

See also

Shared/reverse paths presentation at SVG Open 2010

Proposal for a path extension