SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
I’m Jean-Claude Moissinac from Telecom ParisTech. I’m associate professor and work on media technologies
First I will present the motivations behind SuperPath
As seen previously in the map, we have a lot of shared chunks. With current specification of SVG, we need to replicate the shared chunks. For example, the shared part of the yellow and green region must be completely repeated in the definition of the yellow polygon and in the green one. In this sample, we have a yellow region which share a chunk of contour with the coastline. It shares another chunk with the green region. Such situation is very common in a lot of graphics. Here, some drawings are shared several times like a chunk of the coastline which is a limit for a region, a limit for a big region, and the coastline.
For a lot of vector graphics, among which maps and cartoon drawings, the main part of the data resides in the representation of the points that define the contours. When a group of points is duplicated, the file size is unnecessarily increased. Using a single representation of duplicated group of points will therefore reduce the file size. Holes are contours inside a contour which define a region excluded from the main contour (and presumably transparent). Using a better representation of duplicated chunks also allows for better re Fig. 5 shows two ways to get a blue shape containing a green shape containing a hole which lets you see what is behind the green and blue shapes. In the first way (first line of the figure), the green shape shares its external contour with the blue shape. In the second way (second line in the figure), the green and blue shapes share the description of the hole. presentation of holes.
Here we see some results of applying SuperPath to an existing SVG file. The result is: we can benefit of Superpath without making the file grows. In the list of benefits, tqsqssqwwqwwwwwwwwwwhe benefit on the file size is not clear in this case. Such benefit will appear mainly on files created to use SuperPath.
If the SVG file contains the information that two chunks of contours are the same, both contours can be adapted in a coherent manner, processing it only once and avoiding artifacts produced by divergent adaptations
A player that knows that two chunks of contours are the same can optimize the rendering operations, for example performing the linearization of Bezier curves into straight segments only once.
We need to introduce the concept of chunks using the target language model. As a chunk can be used by different contours with different display styles, a chunk must not be dependent on a style. The chunk therefore only contains geometrical data (points and control points).
We need to be able to reuse these chunks in different shapes. This is usually achieved through an explicit or implicit identifier for the chunk and further referencing in each shape which uses this chunk. Obviously, if the targeted language has syntax to express references, we need to be coherent with that syntax for chunk referencing (e.g., SVG xlink or BIFS DEF/USE mechanisms).
As illustrated in Fig. 6, duplicated chunks could be used as they are first defined or in the reverse order. The syntax must enable such usage. We propose the following new SVG elements: &lt;superpath&gt;: this element has no specific attribute. It supports traditional SVG attributes such as id, transform, class… It is used as a container element for the elements below and defines its own styling. &lt;subpath&gt;: this element declares a chunk used in a SuperPath . Its syntax is the same as the standard SVG &lt;path&gt; element, but the semantics are different. This element is only displayed when it is a child of a &lt;superpath&gt; element.
A subpath can have two forms: It can contain a d attribute, analog to the one in the path element; if it has an id attribute, then the d part can be reused by referencing another SuperPath; It can contain an xlink:href attribute which references the id of another subpath. In this case, its geometry is defined by the d attribute of the referenced subpath.
In addition, the geometry of a subpath can be used in the reverse order, as explained in 4.A. An “order” attribute is therefore defined with possible values ‘direct’ or ‘reverse’; the ‘direct’ value is the default. In both forms, the “cmd” attribute expresses how the subpath is joined with the previous one. There is currently only one possible value “line”, indicating that a straight line is used to join the chunks. Please note that the definition of a chunk can be similar to the definition of the corresponding part of the original content. An overhead will come from the size of the references to the chunk. As an example, Fig. 4 can be represented as follows: The subpath with id sp1 is the one shared by the green and red shapes; the subpath with id sp2 is shared by the red and blue shapes; the subpath with id sp4 is shared by the green and blue shapes.
Note the bar
Graph web superpath-2015 - SVG Extension
Graphical Web 2015
What is SuperPath?
Proposed for SVG Open 2010
• Smilar ideas by D.Dailey and Chris Lilley
• the capability to describe one path assembling several
smaller chunk of path
• the capability to share some smaller chunk of path
between several path
Today, such capabilities is
not available in SVG
Benefits of SuperPath
To avoid duplication of shared chunks
Institut Mines-Télécompage 5
To reduce the file size
Same hole repeated for each shape in the stack
The internal path of the blue shape is the external path of the green shape
Each shape has a hole that reveals the shapes below it
4 paths; 15 chunks
15043 bytes for the paths
95%=path data/total size
11 KB with SuperPath
(9 KB for paths)
page 6 Jean-Claude Moissinac
866 KB for the paths
99 % = path data/total data
865 KB with SuperPath
page 7 Jean-Claude Moissinac
Institut Mines-Télécompage 9
To enable coherent processing
Coherent adaptation: two neighboring polygons
share a border part; when adapting that part, the
adaptation must be coherent
Institut Mines-Télécompage 10
And others benefits but more generally…
Which is useful in all the situations seen above
potentially for a lot of other situations not foreseen today
preserves the knowledge that
two chunks are identical
What is needed to define
Defining the chunks
We need to define the chunks, the portion of path
which can be reused
• A chunk will be reused by contours with different display
─ => a chunk must not be dependent on a style
─ => a chunk must only contain geometrical data
• Our approch
─ A chunk is a sequence of standard command defined in a path
Using chunks references
Mean to identify a chunk to reuse
• SVG uses ID to do internal or external references
Yellow polygon is made of:
Chunk C1, C2, C3
Coastline is made of:
…, C4, C1, C5…
Green polygon is made of:
…, C6, C2, C4…
New proposed syntax for SuperPath
(name|…sequence of standard commands…)
• A command to define a chunk
• A command to use a chunk in direct order
• A command to use a chunk in reverse order
Note the | as separator
• Used to avoid problem with numbers and z following
names of chunks
We need a parser tolerant to non standard
=> I implement an expandable parser in
And the support for the new commands in
• It defines four chars: ( # ! | which can be changed for
other chars not used by the standard path commands
For facility, both sources are joined in
• SuperPathExpander.js or SuperPathExpander.min.js
How it works
Each chunk definition is internally converted to
use only relative commands to the context of the
definition of the chunk
expandPaths() process each definition and
reference of chunk to get equivalent standard
expandPaths() must be explicitly called on the
expandPaths() is automatically called each time a
chunk is redefined
How to use it?
• On your svg element
• To enable the efficient use of SuperPath in existing
Tools to use SuperPath
• Tiling big svg content
• Vectorized bitmap images
Use the parser to add the bearing support
• Combined with SuperPath, it could be a great
functionnality for paving
Maps and tiling maps
… plus texture or gradient?
Detail (colors changed)
M50 200#c1|#c2|l-100 30 -100 50 -50 50z
Returned by IE
And then I can’t do nothing to standardized a non-
standard content. I will explore solutions