1         Introduction

SVG documents may be very large. It is therefore desirable to compress these documents. On the web, it is common practice to encode SVG documents as SVGZ. SVGZ is SVG compressed with a universal compression technique, Deflate typically. These universal compression techniques being well supported on most platforms, this is a good way of compressing SVG documents.

W3C EXI is a new technology developed for compressing XML data. It is designed to give very good compaction results while retaining XML compatibility with all the XML chain tools. The EXI technology is now mature and almost finalized. EXI is now starting to be used by other XML technologies like XML Security formats. One design goal of EXI is to have a single binary format for all existing XML applications. It is therefore interesting to see how EXI is performing for SVG documents, in particular in comparison with LASeR (a binary format dedicated to SVG based on BiM, a general XML compression format) and SVGZ.

Section 2 describes the EXI technology and the compaction results obtained on XML and SVG documents. Section 3 describes a new SVG syntax that would improve EXI performances and provide additional benefits in terms of XML editing. Section 4 details how EXI can be upgraded to improve compaction on existing SVG documents and compaction results obtained by EXI are described and compared with other alternatives in section 5. The paper finishes with some recommendations.


2         EXI Applied On SVG

2.1       EXI Presentation

This section briefly presents the EXI format. The EXI primer [1] and EXI specification [2] are worthwhile reading for more information on EXI. The EXI format can represent any XML Infoset in a very compact way as a stream of events using contextual dictionaries for both structure and content.

2.1.1         EXI Design Goals

EXI was designed to be general, minimal, efficient, flexible and interoperable. In particular, the EXI format was designed to be as simple as possible while being applicable to a wide range of use cases and competing with hand-optimized formats. For that purpose, the EXI format is based on the core concept of grammar-based encoding and defines different sets of encoding options designed to fulfill the performances requirements of most XML applications. The remainder of the section details EXI internals and options.

2.1.2         EXI Events

EXI organizes XML data in a stream of EXI event. EXI events can be start element (SE) event, end element (EE) event, attribute (AT) event, character (CH) event, comment (CM) event... Figure 1 shows an XML document and Figure 2 represents it as a list of EXI events (both figures are taken from the EXI primer). Events contain structure information drawn as white bullets in Figure 2 and may also contain content drawn as colored bullets.

Text Box: <?xml version="1.0" encoding="UTF-8"?> 
<notebook date="2007-09-12">
   <note category="EXI" date="2007-07-23">
      <subject>EXI</subject>
      <body>Do not forget it!</body>
   </note>
   <note date="2007-09-12">
      <subject>Shopping List</subject>
      <body>milk, honey</body>
   </note>
</notebook>
Figure 1: XML document (notebook)

An EXI processor can be represented as a finite state machine: the encoding process consists in selecting the finite state machine path representing the document structure. Each state has a related grammar that defines the possible transitions (called productions in EXI terms) to the next state. Each transition is associated with a binary code that represents the EXI event to encode.

 

Figure 2: EXI event stream organization

 

The value of the EXI event, if any, is encoded either as a string or using a dedicated type encoding. The EXI specification defines several built-in encodings that efficiently represent the XML Schema part 2 built-in types (integers, floats, binary data, lists...).

2.1.3         EXI Grammars

EXI grammars are central to EXI. They provide the binary codes used to represent EXI events in EXI streams. They can be seen as simplified Huffman tables: shorter codes are given to the most probable events while longer codes are given for the other events. EXI grammars are composed of EXI productions that relate EXI events, EXI event codes and value typed encoding if any. Productions also enable the selection of the grammar to use for the next event.

2.1.3.1           Built-in Grammars

Built-in grammars are used to represent the element structure when no schema knowledge is available to the encoder and decoder for the given element. In particular, the schemaless mode only uses built-in grammars to represent XML data. These grammars are updated during the EXI processing: new productions are added to the grammar for events occurring for the first time. These new productions will provide short codes when the same specific event occurs again in the document.

Built-in grammars encode all values as XML strings. XML strings are encoded either as index inside string tables or as literals. EXI processors have element and attribute scoped local tables yielding to small indexes and global value table containing all indexed string values for completeness.

2.1.3.2           Schema-informed Grammars

Schema-informed grammars are generated from an XML schema using a deterministic algorithm defined in the EXI specification. These grammars do not need to learn the structure document. They lead to shorter codes than built-in grammars and do not evolve during the processing. They also trigger the use of typed encoding that is selected according the value type information available in the schema.

2.1.4         EXI Main Modes

To support efficiently a wide range of use cases, the EXI format defines a number of encoding options. Two options are of particular importance for compaction results: use of schema and use of compression.

First, EXI users need to decide whether or not to use schema information. Schema information needs to be available at both encoder and decoder. Second, EXI users need to decide whether or not to use an additional generic compression step. When using this option, called EXI compression mode, the EXI stream is reordered so that structure information is placed at the beginning of the encoded stream followed by the content which is organized into channels of similar values. The reordered stream is then compressed using DEFLATE. Generally, this option largely improves the compaction at the expense of increased processing overhead.

Other encoding options are available. Some of these options are detailed in section 5.5.

2.2       EXI Results for XML

As part of its charter, the EXI WG produced the EXI evaluation note [3]. This note evaluates EXI results with textual XML and Gzipped XML representations in terms of compaction performances and with JAXP in terms of decoding and encoding performances. Results presented below are extracted from the EXI evaluation note. These results are computed from a wide range of XML documents, and contain 5 SVG documents. Schema information is used whenever available.


EXI Compactness (without compression)
(Baseline is XML file size)


EXI Compactness (with compression)
(Baseline is zipped XML file size)


EXI Decoding speed vs. XML
(Baseline is JAXP parsing speed)


EXI Encoding speed vs. XML
(Baseline is JAXP writing speed)

Table 1: EXI General results

For all figures, the X-axis represents the document set. For the compactness figures, the Y-axis corresponds to the compaction ratio (size of the encoded file divided by the size of the initial file, the lower the better). For all 4 figures, the documents are sorted according the results obtained by EXI. For speed figures, the Y-axis corresponds to a throughput ratio (throughput of a processor divided by the throughput of the baseline).

As illustrated in Table 1, EXI both with and without compression achieves good compaction results across the whole XML document set: the size is divided on average by 4 without ompression against textual XML and on average by 2 with compression against GZipped XML. It also achieves consistent improvements in decoding and encoding speed.

2.3       What about SVG?

2.3.1         SVG EXI Evaluation Results

Table 2 illustrates where the 5 SVG samples stand in the EXI graph results presented in Table 1.


EXI Compactness (without compression)


EXI Compactness (with compression)


EXI Decoding speed vs. XML


EXI Encoding speed vs. XML

Table 2: SVG results in EXI result graphs

As shown in the graphs, EXI improves the compaction and processing efficiency of SVG documents but the improvements are not as good as hoped. The average compaction improvement of the 5 SVG documents is 1.4 which is far from 4, the average for the whole XML document set without compaction. The same results are obtained with compression where EXI improves the compaction results by 20% against GZIP. In terms of encoding and decoding performances, the improvements provided by EXI are also limited.

Two main reasons may explain these results:

1.       The SVG documents were encoded without any schema information.

2.       SVG large documents tend to have very large attributes which do not compress well

2.3.2         Schema-informed Mode

In the evaluation note, no SVG schema is used to encode the SVG documents. The reason is that there is no interoperable and widely available XML schema describing SVG documents. However, SVG structure is currently described using RelaxNG. Using Trang, it is possible to derive an XML schema from the RelaxNG schema. As the transformation is not unique, several different SVG schemas can be generated. It should be noted that grammars generated from the different schema flavors may vary significantly in terms of memory size.

Figure 3: EXI Compression ratio on SVG documents
with and without schema
(Baseline is SVG file size)

To investigate EXI schema-informed compaction, we used the SVG schema designed for LASeR/BiM technology in our experiments. This SVG schema is a simplified version of SVG schemas that can be translated from SVG RelaxNG schema. All SVG elements are present with full description of possible attributes. But no description of the element hierarchy (which SVG elements can appear as children of a given SVG element) is preserved to reduce the complexity of the schema.

Figure 3 presents the results of EXI compaction with and without LASeR/BiM SVG schema on a set of SVG documents. This set of SVG documents, represented by the X-axis, was gathered from internal SVG documents and publicly available SVG documents, like the SVG documents gathered by the EXI Working Group. They contain both small and large documents, highly and loosely structured documents. The documents are sorted according the compaction ratio obtained when no schema is used. The Y-axis corresponds to compaction ratio obtained by the EXI format.

The results show improvements, particularly on more structured SVG documents. The improvements are nonetheless low, especially for large SVG documents: generally, these documents mainly contain large path or animation attributes values, which schema does not help to compress efficiently. These attributes are encoded as strings and indexing is not generally useful for those values.


3         SVG XML Syntax

The current SVG syntax tries to minimize the size of textual SVG documents. In particular, some attribute values (path data, animate data, transform data) contain both structure and content data. While this provides a compact textual syntax, this makes EXI optimization more difficult. This also leads to more difficult XML editing of SVG documents. This section proposes a simple XML syntax for the elements whose content tend to be very large, such as path or animation data. In general, a better separation between structure and content information can be obtained. This should lead to easier XML editing and better EXI compaction of these documents: values can be efficiently represented using typed encodings and structure information is well optimized using EXI grammars.

3.1       Path Syntax

<?xml version="1.0" encoding="utf-8"?>

<svg width="100%" height="100%"

  version="1.1" fill="none"

  xmlns="http://www.w3.org/2000/svg">

 

 

 

  <path

      d="M20,30 Q40,5 60,30 T100,30"

      stroke="red" stroke-width="0.5"/>

 

 

 

 

 

 

 

  <path

     d="M20,30L40,5L60,30L80,50 L100,30"

     stroke="#888" stroke-width="0.2"/>

 

 

 

 

</svg>

<?xml version="1.0" encoding="utf-8"?>

<svg width="100%" height="100%"

  version="2.0" fill="none"

  xmlns="http://www.w3.org/2000/svg">

 

  <path stroke="red" stroke-width="0.5">

      <moveTo coord-ref="absolute"

                x="20" y="30"/>

      <quadraticBezier coord-ref="absolute"

                x1="40" y1="5" x="60" y="30"/>

      <quadraticBezierSmooth

                coord-ref="absolute"

                x="100" y="30"/>

  </path>

 

  <path stroke="#888" stroke-width="0.2"

          coord-ref="absolute">

      <moveTo x="20" y="30"/>

      <lineTo x="40" y="5"/>

      <lineTo x="60" y="30"/>

      <lineTo x="80" y="50"/>

      <lineTo x="100" y="30"/>

  </path>

 

</svg>

This is a simple example of how the SVG path syntax could be modified to potentially make them more compressible. The current syntax is illustrated on the left. On the right, is presented an example of how the path syntax could be broken down into different elements to work in SVG while being compressible. As can be seen, this syntax is more structured: it is textually more verbose but it can be compactly represented by EXI grammars. It splits values in small XML strings that can be compactly represented by EXI typed encodings.

The new syntax requires new elements that represent the various path segments (move to, line to, arc, etc). These segments can be nested within the <path> element. In addition to new elements, a new attribute is introduced to define how coordinates are referenced: the attribute 'coord-ref' is assigned to a value of either 'absolute' for absolute path coordinates or 'relative' for relative path coordinates. The usage of this attribute is illustrated in the example.

 

 

 

<?xml version="1.0" encoding="utf-8"?>

<svg width="100%" height="100%"

  version="1.1"

  xmlns="http://www.w3.org/2000/svg">

 

 

 

 

 

 

 

 

    <path

     d="M300,200 h-150 a150,150 0 1,0 150,-150 z"

     fill="red" stroke="blue"

     stroke-width="5" />

 

 

 

 

 

 

 

 

 

    <path

     d="M275,175 v-150 a150,150 0 0,0 -150,150 z"

     fill="yellow" stroke="blue"

     stroke-width="5" />

 

 

 

 

 

 

 

 

 

 

 

 

    <path

     d="M600,350 l 50,-25

    a25,25 -30 0,1 50,-25 l 50,-25

    a25,50 -30 0,1 50,-25 l 50,-25

    a25,75 -30 0,1 50,-25 l 50,-25

    a25,100 -30 0,1 50,-25 l 50,-25"

     fill="none" stroke="red"

     stroke-width="5"  />

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

</svg>

<?xml version="1.0" encoding="utf-8"?>

<svg width="100%" height="100%"

  version="2.0"

  xmlns="http://www.w3.org/2000/svg">

    <defs>

        <lineTo id="common_line_to"

                x="50" y="-25"/>

    </defs>

 

    <path fill="red"

          stroke="blue" stroke-width="5"

          coord-ref="relative">

        <moveTo coord-ref="absolute"

                x="300" y="200"/>

        <lineToHorizontal x="-150"/>

        <arc rx="150" ry="150"

             x-axis-rotation="0"

             arc-flag="large"

             sweep-flag="negative"

             x="150" y="-150"/>

        <close/>

    </path>

 

    <path fill="yellow" stroke="blue"

        stroke-width="5" coord-ref="relative">

        <moveTo coord-ref="absolute"

                x="275" y="175"/>

        <lineToVertical y="-150"/>

        <arc rx="150" ry="150"

             x-axis-rotation="0"

             arc-flag="small"

             sweep-flag="negative"

             x="-150" y="150"/>

        <close/>

    </path>

 

    <path fill="none"

          stroke="red" stroke-width="5"

          coord-ref="relative">

        <moveTo coord-type="absolute"

                x="600" y="350"/>

        <use href="#common_line_to"/>

        <arc rx="25" ry="25"

             x-axis-rotation="-30"

             arc-flag="small"

             sweep-flag="positive"

             x="50" y="-25"/>

 

        <use href="#common_line_to"/>

        <arc rx="25" ry="50"

             x-axis-rotation="-30"

             arc-flag="small"

             sweep-flag="positive"

             x="50" y="-25"/>

 

        <use href="#common_line_to"/>

        <arc rx="25" ry="75"

             x-axis-rotation="-30"

             arc-flag="small"

             sweep-flag="positive"

             x="50" y="-25"/>

 

        <use href="#common_line_to"/>

        <arc rx="25" ry="100"

            x-axis-rotation="-30"

             arc-flag="small"

             sweep-flag="positive"

             x="50" y="-25"/>

        <use href="#common_line_to"/>

 

    </path>

 

 

</svg>

The paths in this example use different path segments compared to the paths in the previous example. The current syntax is illustrated on the left. This document exemplifies a possible more readable syntax for the <arc> element. This definition improves the ease of authoring of <arc> element. It also enables to define default values. This example also illustrates the reusability feature of SVG: a path segment element is defined once and then referenced multiple times through the <use> element.

3.2       Transform Syntax

<?xml version="1.0" standalone="no"?>

<svg width="100%" height="100%"

  version="1.1"

  xmlns="http://www.w3.org/2000/svg">

 

 

    <rect x="50" y="50"

      width="100" height="100"

      fill="red" stroke="none"

      transform="translate(-50 -50)

             rotateZ(30)

             translate(50 50)" />

 

 

 

 

</svg>

<?xml version="1.0" encoding="utf-8"?>

<svg width="100%" height="100%"

  version="2.0"

  xmlns="http://www.w3.org/2000/svg">

  <defs>

      <transform id="rotate_z_about_centre">

          <translate x="-50" y="-50"/>

          <rotateZ angle="30"/>

          <translate x="50" y="50"/>

      </transform>

  </defs>

  < rect x="50" y="50"

      width="100" height="100"

      fill="red" stroke="none"

      transform="url(#rotate_z_about_centre)"

  />

</svg>

This is a simple example of how the SVG transform syntax could be modified to potentially make it more compressible. The current syntax is illustrated on the left.

The new syntax, illustrated on the right, defines a new element <transform>. Additionally, other elements that defines the transformation (<translate>, <rotate>, <scale>, etc) are introduced. In terms of editing, the possibility to walk through the DOM tree to manipulate the transform values adds some benefit. In addition, the possibility to type each transformation content ('x' and 'y' attributes) would also enable better EXI compaction performances.

 

3.3       Animate Syntax

<?xml version="1.0" standalone="no"?>

<svg width="100%" height="100%"

  version="1.1"

  xmlns="http://www.w3.org/2000/svg">

 

  <path fill="#e6f6f9" stroke="#000"

          d="M50 50

           L50 100

           L100 100

           L100 50

           Z">

 

 

 

 

 

 

 

 

 

    <animate attributeName="d" dur="3s"

        fill="freeze"

        repeatCount="indefinite"

        keyTimes="0;0.33;0.66;1"

        values="

     M50 50 L50 100 L100 100 L100 50 Z;

     M50 50 L50 100 L200 100 L200 50 Z;

     M50 50 L50 100 L150 100 L150 50 Z;

     M50 50 L50 100 L250 100 L250 50 Z"

     />

 

 

 

    <animate attributeName="fill"

        dur="6s" fill="freeze"

        repeatCount="indefinite"

        keyTimes="0; 0.25; 0.5; 0.75; 1"

           values="#e6f6f9; #ffff66;

               #e6f6f9; #ffff66;

               #e6f6f9"

    />

 

    <animateTransform

        attributeName="transform"

        type="translate"

        dur="6s" fill="freeze"

        repeatCount="indefinite"

        keyTimes="0; 0.25; 0.5; 0.75; 1"

        values="50,50;

                50,100;

                0,150;

                0,200;

                0,250"

    />

 

 

 </path>

 

 

 

 

 

 

</svg>

<?xml version="1.0" standalone="no"?>

<svg width="100%" height="100%" version="2.0"

  xmlns="http://www.w3.org/2000/svg">

 

    <path fill="#e6f6f9" stroke="#000"

          coord-ref="absolute">

        <moveTo x="50" y="50"/>

        <lineTo x="50" y="100"/>

        <lineTo x="100" y="100">

           <animate attributeName="x" dur="3s"

                     fill="freeze"

                     repeatCount="indefinite">

                <key t="0" value="100"/>

                <key t="0.33" value="200"/>

                <key t="0.66" value="150"/>

                <key t="1" value="250"/>

           </animate>

        </lineTo>

        <lineTo x="100" y="50">

           <animate attributeName="x" dur="3s"

                     fill="freeze"

                     repeatCount="indefinite">

                <key t="0" value="100"/>

                <key t="0.33" value="200"/>

                <key t="0.66" value="150"/>

                <key t="1" value="250"/>

           </animate>

        </lineTo>

        <close/>

 

        <animate attributeName="fill"

                   dur="6s" fill="freeze"

                   repeatCount="indefinite">

            <key t="0" value="#e6f6f9"/>

            <key t="0.25" value="#ffff66"/>

            <key t="0.5" value="#e6f6f9"/>

            <key t="0.75" value="#ffff66"/>

            <key t="1" value="#e6f6f9"/>

        </animate>

 

        <animateTransform dur="6s"

                   fill="freeze"

                   repeatCount="indefinite">

            <key t="0">

                <translate x="50" y="50"/>

            </key>

            <key t="0.25">

                <translate x="50" y="100"/>

            </key>

            <key t="0.5">

                <translate x="50" y="150"/>

            </key>

            <key t="0.75">

                <translate x="50" y="200"/>

            </key>

            <key t="1">

                <translate x="0" y="250"/>

            </key>

        </animateTransform>

    </path>

 

</svg>

The example above illustrates how the <animation> element would be applied to the elements and attributes of a path. Any attributes in the path are animated using the <animation> element which specifies which attribute to animate. Any elements in the path that require animating have a nested <animation> element.

As can be seen in these examples, animation data is broken into smaller XML pieces. These pieces are more easily compressible as typed encodings and schema information can be efficiently used. The new syntax is also more readable.

3.4       Other Elements

The syntax of other elements may also be modified to improve the compaction. Though not studied in details in this article, two kinds of consideration are of particular interest:

1.       Enable lists to be described as an XML Schema list simple type. For instance, polygon and polyline could be defined as a list of coordinates.

2.       Some SVG values contain numeric information with its unit value (pixel, cm...). This reduces the ability to represent the numeric information efficiently. Additionally, it may be beneficial to enable setting the unit information at the scope of a sub-tree and not only at the value level.


4         SVG Enhanced Compaction

This section describes different approaches to more efficiently compress existing SVG documents. Section 4.1 briefly describes the LASeR/BiM technology. Section 4.2 details different path encodings that can be used to efficiently compress SVG path data. Section 4.3 describes small modifications to the SVG syntax that allow largely improving EXI compaction results.

4.1       LASeR/BiM

BiM is an ISO format dedicated to compact representation of XML documents. BiM generally requires XML schema descriptions to achieve decent compaction results. The LASeR specification defines a precise use of BiM to efficiently encode SVG documents. This notably includes the following techniques:

1.       Use of a simplified SVG schema: all SVG elements with all their attributes. The element children are loosely defined as wildcards.

2.       Attribute value normalizations/transformations: @transform, RGB colors, ids, data-kind URLs.

3.       Specific codecs for path data (Fixed-length and Exponential-Golomb encodings described in section 4.2 of this document) and float lists (encoding as 12 bits).

The compaction results are very good although one main missing feature is the support of schema deviations. As exemplified in the test suite, SVG documents may contain invalid values or may have missing information parts like missing mandatory attributes. In those cases, BiM encoding generally fails without handmade editing.

4.2       SVG Specific Path Encodings

4.2.1.1           Fixed-length Integer Encoding

Path data can be encoded through a fixed length encoding defined in the LASeR/BiM specification. The path commands are encoded using a simple Huffman table. The path values are sampled as integers and all absolute coordinates are converted as relative coordinates. The min and max values are computed and encoded for both X and Y axes. Values are then encoded as the minimum number of bits against the min and max values.

This encoding was designed to be simple and fast while giving good results, especially on small paths. This encoding is available within LASeR/BiM.

4.2.1.2           Variable-length Integer Encoding

This encoding is similar to the previous encoding for path commands but uses a variable-length integer representation to represent coordinates, like the integer encoding defined in the EXI specification. Integers are represented as a sequence of bytes: the first bit of each byte is a continuation bit while the other 7 bits are data bits.

This encoding is similar in terms of complexity to the previous encoding. It is equivalent to the encoding of the EXI encoding of the coordinate values as a list of integers and to the encoding of the EXI coordinates as a string using a restricted character set.

4.2.1.3           Exponential-Golomb Encoding

This encoding uses the Exponential-Golomb integer encoding for path coordinates in lieu of the integer variable-length encoding used previously. The path values are sampled as integers and all absolute coordinates are converted to relative coordinates. The initial path values are encoded as integers. The k parameter of the Exponential-Golomb integer encoding is then encoded for both X and Y axis. The values are then encoded according to this particular encoding.

This encoding should generally achieve very good compaction results, especially on long paths. It also requires more processing for both encoding and decoding than the fixed-length encoding. This encoding is available within LASeR/BiM.

4.2.1.4           Scalable Encoding

Another SVG encoding was designed internally based on the Exponential-Golomb encoding. The goal was to split the path values into different resolution layers. Typically, path values are subsampled and then approximated to simpler primitives (cubic->quadratic->linear). The path values are encoded in three layers: approximated values, reconstruction data, and super-sampling data. This format allows both high precision data for high quality rendering and quickly parsed data for low resolution rendering while retaining very good path data compaction.

4.3       Simple SVG Adaptations

To improve EXI compaction results on existing SVG documents, modifications may be done at the EXI level or the SVG level. Either the EXI processor may be specialized for a particular kind of data or the data may be modified before being sent to the EXI processor.

LASeR/BiM uses both approaches where several attribute values are normalized and large attribute values have specific codecs. In our experiments, we decided to use attribute value modification means only. This modified SVG syntax, named SSVG in the remainder of the document, is used to generate the compaction results of section 5. The principle is to modify as little as possible the existing SVG syntax while enabling as much as possible the use of EXI typed encoding for values. The main advantages of this approach are:

1.       The back and forth transformations between SVG and SSVG are very easy and lightweight to implement with existing tools such as XSLT or JavaScript. The structure changes are small as the element hierarchy remains unchanged and only a small number of new attributes are created and some attribute values are updated.

2.       There is no need to modify the internals of the EXI processor. In particular, no specific new typed encoding is needed. Only the schema used by the EXI processor is updated to improve the typing of the values.

3.       The results of this syntax should be relatively close to results that would be obtained using a new SVG syntax as presented in section 3. To be noted also that experiments show consistent and stable compaction results for different variations of new SVG syntaxes as long as values are typed encoded (for instance coordinate values as attributes or elements, introducing relative and absolute command elements).

4.3.1         Attribute Structure Modifications

4.3.1.1           Path Attribute Modifications

The path@d attribute is split in two attributes:

1.       A 'd-commands' attribute: the resulting string is compressed using a restricted character set corresponding to the existing commands.

2.       A 'd-values' attribute: the resulting value is compressed as a list of numerical values. It is particularly advantageous to put the path values as integer relative coordinates that will be encoded using EXI variable-length Integer encoding.

Similar modifications are applied to path data used for <animateMotion> and <animate> elements. This modification gives similar results to the variable-length integer encoding presented in section 4.2.1.2. In all cases, all paths were rewritten using relative commands before being split in two attributes. This leads to smaller integer values that can in many cases be encoded as one octet.

4.3.1.2           Image Attribute Modifications

The image@xlink:href attribute is changed to an image@base64data attribute whenever the content of the original attribute is a data-type URI. The image@base64data is assigned the base64Binary encoding.

4.3.1.1           Animate Attribute Modifications

The animation elements @values attribute contains a list of items. The type of the item depends on the animation type. Animation of the 'visibility' attribute will lead to a list of enumerated strings. Animation of a SVG transformation will lead to a list of float values. To enable typing, the 'values' attribute is changed to an attribute that depends on the animation target (for example, values-string for a list of strings, values-integer for a list of integers). The schema is updated accordingly.

4.3.2         Attribute Value Normalization

Attribute values that contain numerical values with associated unit (like animate@dur) are normalized to keep the numerical values only. Since this is not always possible, the unit information is kept sometimes. In those cases, attributes are encoded as deviations and attribute values are encoded as XML strings.

Several attribute values correspond to list of items (for example: svg@viewBox, animate@keyTimes, animateTransform@values, animate@values, polyline@points). Since SVG allows several list syntax (with different item delimiters), a normalization is applied to keep only one syntax. Each attribute type is then associated to a list of typed items.

A last attribute value modification is performed on attribute values identified as list of low accuracy floats, typically animate@keyTimes. These attributes contain a list of float values with a small number of digits after the comma. In this case, the EXI integer encoding is used to improve the compaction. The attribute modification consists in writing first a scaling factor (the number of digits after the comma) as an integer and then each float value scaled to an integer. The modified attribute value can then be encoded as a list of integers. This modification is applied notably to animate@keyTimes attribute and animateTransform@values attribute.


5         SVG Enhanced Compaction Results

5.1       SVG vs. SSVG

Figure 4 to Figure 7 compare EXI compaction results on SVG documents with the standard syntax and with the SSVG syntax. Each figure draws compaction ratio, the baseline being the SVG document size when the compression mode is not used and the SVGZ document size when the compression mode is used. Figure 4 presents the compaction results without schema and compression mode off, Figure 5 with schema and compression is off, Figure 6 without schema and with compression mode on, Figure 7 with schema and with compression mode on. For all figures, results are sorted according the SSVG results. Figure 5 and Figure 7 contain an additional chart in green that corresponds to the use of a very small SVG schema: only <path> and <animation> elements are described in that schema.

Figure 4: Compression ratio of SVG and SSVG
without schema, compression mode off
(Baseline is SVG file size)

 

Figure 5: Compression ratio of SVG and SSVG
with schema, compression mode off
(Baseline is SVG file size)

 

Figure 6: Compression ratio of SVG and SSVG
without schema, compression mode on
(Baseline is SVGZ file size)

 

Figure 7: Compression ratio of SVG and SSVG
with schema, compression mode on
(Baseline is SVGZ file size)

 

SSVG generally compresses quiet well when EXI is used. The compaction improvement provided by SSVG is bigger when schema information is used. In that case, the SSVG syntax is better compressed by a factor of two on average when compression mode is off. Although the use of the EXI compression mode reduces the compaction differences between the two syntaxes, the SSVG syntax is consistently better compressed for the whole document set by 25% on average.

The more schema information that is known, the better the resulting compaction is. Retaining only a small number of SVG elements already provides most of the benefits (<path> and <animation> elements mainly) as exemplified by the green line in Figure 5 and Figure 7. The compaction loss between the full schema and the minimal schema is around 10%.

5.2       EXI+SSVG vs. LASeR/BiM

Figure 8 and Figure 9 present the compaction ratios of LASeR and EXI+SSVG with and without the use of the compression mode. The baseline is the SVG document size in Figure 8 and the SVGZ document size in Figure 8. Results are sorted according the LASeR results for both figures.

EXI compaction results are very close to LASeR/BiM results. With the compression mode off, EXI is slightly less compact than LASeR/BiM by an average of 5%. With the compression mode on, EXI is slightly more compact than LASeR/BiM by about 15%. As can be seen, EXI is very competitive in terms of compaction and provides additional benefit such as:

1.       Fidelity options: namespace declarations, comments, PIs can be preserved

2.       Schema-deviation support: EXI supports schema deviations, which are difficult to always avoid and happened in the SVG document set used in the experiments.

3.       Bounded memory tables

All these options (and more) are available within EXI without sacrificing performances. Additionally, the cost of adapting SVG to EXI is not huge as simple attribute values transformation and schema modifications are all that is needed. With the progress of typed APIs, both compactness and processing efficiency should be readily available.

Note that the results in Figure 9 are only an approximation of the actual results of LASeR/BiM. LASeR/BiM has a dedicated Zlib encoding mode which should improve results over the presented results.

Figure 8: Compression ratio of LASeR and EXI SSVG
(compression mode off, baseline is SVG file size)

 

 

Figure 9: Compression ratio of LASeR and EXI SSVG
(compression mode on, baseline is SVGZ file size)

 

 

5.3       EXI Path Codecs

As described in section 4.2, specific codecs can be used to optimize the representation of path data. Results presented in this section use the same EXI processor with the same SVG schema. What varies is the codec used to compress the path values. Three sets of results are gathered:

  1. Values are encoded using the variable-size encoding (named VS in the charts).
  2. Values are encoded using the fixed-length encoding (named FS in the charts).
  3. Values are encoded using the Exponential-Golomb encoding (named EXPG in the charts).

The variable size encoding is interesting since it provides the same path value compaction results as EXI with SSVG: commands are encoded in 5 bits using the restricted character set string encoding and coordinates are encoded using EXI default integer encoding which is the variable-size encoding.

Figure 10 and Figure 11 present the compaction results of EXI with the three codecs against the baseline (SVG document size is the baseline for Figure 10 and SVGZ document size is the baseline for Figure 11). Results are sorted according the Exponential-Golomb results for both figures. Figure 10 shows that the Exponential-Golomb algorithm clearly outperforms the two others by an average of 15%. Figure 11 shows that, when using EXI in compression mode, the difference is smaller: the variable size encoding is even smaller by 5%.

Figure 10: EXI compression ratio
with different path codecs
(compression mode off, baseline is SVG file size)

 

Figure 11: EXI compression ratio
with different path codecs
(compression mode on, baseline is SVGZ file size)

 

 

 

Figure 12 and Figure 13 present the same results in a different way: the compaction results of the linear and Exponential-Golomb are compared according the variable-size compaction results. Results are sorted according the Exponential-Golomb results. When EXI compression mode is off, the Exponential-Golomb results are clearly better than the variable-size encoding. On the contrary, the fixed-length encoding does not perform consistently better than the schema-based EXI encoding. This is particularly true for large paths where the variable-size encoding can better adapt to values that can be in a large range.

When compression mode is on, the performances of all 3 encodings are close to each other. As can be seen, neither the Exponential-Golomb encoding nor the fixed-length encoding achieve better results than the variable-size path encoding.

Figure 12: FS and EXP compression ratio
baseline is EXI default encoding (VS)
(compression mode off)

 

Figure 13: FS and EXP compression ratio
baseline is EXI default encoding (VS)
(compression mode on)

 

 

 

Although SVG path dedicated codecs improve compaction over the standard schema-based EXI encoding of the SSVG syntax, the improvement is not large. For the applications requiring the best achievable compaction, the EXI compression mode is a good option in which case the selection of a particular codec makes little difference.

5.4       Decoding Speed Results

Figure 14 compares the decoding speed of SVG documents using the standard syntax and the SSVG syntax in the context of SVG rendering, typically through an API similar to Open VG. The higher are the figures, the faster is the decoding of the SSVG syntax compared to the standard SVG syntax.

Figure 14: Comparison of decoding speed
ratio between current SVG syntax and modified SVG syntax decoding speed

The decoding speed includes the conversion of path data to a typed representation that can be readily used by the rendering API. The decoding speed is largely improved, by a factor of 2 to 6 for half of the test sets. For the remaining tests, the decoding speeds are close to each other.

The EXI documents that show large speed improvement generally have large content. These documents are well compressed using the SSVG syntax and the decoding speed is largely improved. Most of the documents for which speed is not largely improved are generally small fairly structured documents. EXI compaction and speed is generally already good for those documents. These results show that EXI is performing very well with the modified syntax SVG documents, both in terms of speed and compaction.

 

5.5       EXI Encoding Options Evaluation

This section presents some features brought by the EXI technology and how they can benefit to SVG applications. Note that these features can generally be combined.

5.5.1         EXI Schema Mode

Within the test-suite, we fixed some document issues: some attributes, mandatory according the schema were missing; some attribute values were schema-invalid. LASeR/BiM cannot encode these invalid documents without modifying the documents. By default, EXI is able to encode them while still retaining excellent compaction results, especially in the case of invalid attribute values, where the major impact is the encoding of invalid attribute values as XML strings. All results presented in the last section were generated in this mode. This mode also supports the preservation of processing instructions, comments and namespace declarations which may be a requirement for some SVG applications.

For applications that do not require all these preservation options, EXI also provides a strict mode in which only schema-valid documents can be encoded. This allows EXI to more efficiently compress the structure by pruning unneeded productions from the EXI grammars.

Figure 15 represents the size of EXI streams in default mode divided by the size of EXI streams in strict mode for SVG documents. As illustrated, the compaction difference between the strict mode and the default mode is not huge for the given schema-valid SVG document set: the added cost to support deviations is less than 1% in average. First, the bulk of the SVG data is content and not structure. Second, most grammars generated from the SVG schema used in these experiments tend to have several productions. For those grammars, the removal of one top production do not change the number of bits required to encode the remaining productions. The difference between the default and strict modes may be higher with a more structured XML syntax like the one proposed in section 3. This could be evaluated if going further in the design of this syntax.

Figure 15: Comparison of EXI strict and deviation mode compaction ratios

5.5.2         EXI Compression Mode

The EXI compression mode reorders the SVG content by grouping similar values together into channels. For instance, all path@d values are grouped together in a channel inside the EXI stream. This allows better DEFLATE algorithm performances. The downside is that SVG content can no longer be rendered incrementally: all path@d values of a document would typically be decoded first, their related fill or stroke information being decoded afterwards.

This means additional memory and/or processing requirements that may not be available for particular devices and applications, especially when streamed rendering is used. It also disables the progressive rendering which may reduce the responsiveness of some specific SVG applications. Other applications, SVG storage applications for instance, may prefer the EXI compression mode. It is easy for applications to select the more appropriate EXI mode since it can be turned on or off very easily.

5.5.3         EXI Additional Features

5.5.3.1           Self-contained Elements

Self-contained elements allow the independent encoding of elements of a same document. This may be useful for random access or partial processing of some documents. This feature may be useful for some SVG applications, especially if SVG nodes or elements are organized into pages that can be processed independently. Note that this feature is not compatible with the EXI compression mode.

The compaction impact of this feature is mainly that XML string indexing is reinitialized for each self-contained element. If SVG content is mostly represented using typed encodings and not as XML strings, the compaction loss should be relatively small.

5.5.3.2           Datatype Representation Map

The datatype representation map allows mapping any given simple type to a typed encoding different from the one defined by default in the EXI specification. As such, SVG applications may use that feature to select the specific encoding for SVG coordinate values. SVG applications requiring very accurate coordinates may prefer a float or IEEE float representation while embedded applications may prefer an integer representation.

Figure 16: Compaction performances
when using float or integer encoding for path values
with compression mode on (red) and off (blue)

Figure 16 compares the compaction results obtained when encoding coordinates as floats or integers. The Y-axis corresponds to the ratio of EXI streams size with coordinates encoded as floats against EXI streams size with coordinates encoded as integers.

As illustrated, results show a clear performances drop without EXI compression mode. EXI streams are 40% bigger on average and may be up to twice bigger when using float encoding for coordinates. When EXI compression mode is used, the performance drop is smaller (by 8% on average) although it can be up to 20-40% depending on the exact SVG document.


6         Conclusion

6.1       EXI and SVG Today

 

EXI already provides good compaction results. In open systems, the use of XML schema is not available yet since no SVG XML schema is available. The use of the EXI compression mode will largely improve the results (although not to the best achievable level) in an interoperable manner. This is especially useful for applications that either requires storage of large SVG documents or for applications where bandwidth is the most important criterion.

For closed environment, or environments where encoders and decoders can be controlled, EXI can be applied with better results. The use of a SVG XML schema, like the one defined by LASeR is a good starting point and additional refinements such as lightweight attribute values modifications will generally provide large benefits.

6.2       EXI and SVG Tomorrow

EXI can be very efficient for compressing SVG documents. The inherent flexibility of the EXI technology, which is close to becoming a W3C recommendation, makes it an ideal for SVG document exchanges on the web. For existing SVG versions (SVG1.0, SVG1.1), additional work could be conducted to reach the full potential of EXI:

1.       An interoperable SVG XML schema is needed for EXI processors. Though complete XML schemas generally improve compaction and flexibility, EXI's design - in particular grammar learning and support for schema-deviations - allows specific XML schema to be efficiently tailored for EXI compaction (and not for describing all possible SVG documents).

2.       Improved SVG attribute values encoding:

a.       Either through dedicated codecs plugged in using the Datatype Representation Map, or

b.      through lightweight attribute value modifications and standard EXI typed encoding.

As for the future SVG versions, the direct support of an XML syntax will definitely improve EXI performances without requiring specific SVG support within EXI processors, to the extent that an XML Schema dedicated to EXI processors is available. The exact compaction results will vary depending on the exact XML syntax but should be close to the results shown above. It may be interesting to evaluate various SVG syntaxes both in terms of usability and compaction efficiency. As studied internally, EXI will generally behave very consistently on various possible syntaxes. Some points are worth noting:

1.       SVG DOM APIs help to define the separation of structure and content, which is a key point for EXI efficiency.

2.       Having simple typed values generally help. Separating the values from the unit system will generally help the compaction.

3.       Coordinates size is especially important for compaction as floats have bigger encoding size than integers.

4.       EXI flexibility enables optimizing some use cases without sacrificing the support of other use cases

We therefore encourage SVG developers to support the idea of defining an interoperable EXI SVG profile. We also encourage the SVG Working Group to provide an XML syntax for SVG that would be of benefit for both ease of editing/integration into the XML chain tools and processing/transmission efficiency.


7         Bibliography

[EXI Primer]: http://www.w3.org/TR/exi-primer/

[EXI Specification]: http://www.w3.org/TR/exi/

[EXI Evaluation Note]: http://www.w3.org/TR/exi-evaluation/

[LASeR]: ISO/IEC FDIS 14496-20:2006(E)

[BiM] ISO/IEC FDIS 23001-1:2005(E)