W3C logo Web  Accessibility Initiative    (WAI) logo

SVG Linearizer tools

Internship report and software download

Guillaume Lovet - July to August 2000 training period
Please send comments to Daniel Dardailler (dd@w3.org) and Guillaume Lovet (guillaume.lovet@supelec.fr)
Last udated 08/25/2000

Quick tour: Convert graphics into structured text using SVG and Metadata in RDF.


This summer 2000 project was about writing an SVG-to-text converter, more preciselly doing it in 3 different steps:

  1. The development of an RDF vocabulary, allowing the description of an SVG document (pictures, schemas, graphics), in order to make the information carried by such a document accessible, regardless of the support at one disposal to exploit it (computer screen, speaker, tactil screen).
  2. The development of a tool (written in Java) able to exploit such an RDF description, thus using the elements of the previous vocabulary. The results of the proceeding will have to be presented in a textual form, ready then to be exploited by various accessibility tools (for example, a vocal module or a "Braille" screen for people with visual impairment).
  3. Eventually, the development of another tool (in Java again) implementing the edition process of an SVG document, in order to attach a description oriented to its accessibility. The user of such a tool will have few or no RDF notions, therefore the edition process will have to be as tranparent, simple and graphic as possible.

I. RDF Vocabulary

The review of various pictures (see the example pages in this dependency statement) which may be SVG documents "to be described" helped me to build a set of properties that should correctly fill the specified requests.

The RDF vocabulary is made of these 29 properties (or words) . Such a vocabulary forms the namespace axsvg (for Accessibity SVG), and has an associated RDF Schema. Most of these properties are 'by reference', ie in the RDF statement for which they are the predicate, the subject and the object are some 'entities' of the SVG document, identified by their 'id' attribute. For example, if the SVG document presents somewhere the following piece of code:

<g id="Roof">
...svg code that draws a roof...

Then somewhere else:

<g id="House">
...svg code that draws a house...

In the RDF description, we could see the following piece of code:

<rdf:Description about="#Roof">
<axsvg:SitsOnTop resource="#House" />

Which means, in English: The entity identified by 'Roof' sits on top of the entity identified by 'House'.

The vocabulary covers several categories of properties:

  1. Structural properties

    These properties are dedicated to the description of the document structure, in a conceptual way:

  2. Geographic properties

    Useful to situate relatively the SVG document elements, in order to have a better memory representation (for the user, not the computer) of the document.

  3. Graphic properties

    Dedicated to the description of graphics with dots, curves, or 'cheese-like' graphics:

  4. Special

Moreover, some attributes can be added to -theorically- each of these properties (the user who creates the description is responsible for the meaning of his statements. For example, a property 'by value' should logically have at least an attribute, which cannot be 'resource'):


- The names of properties and attributes have been chosen as close as possible to their semantic content. The study of the Java tool implementing the presentation of the RDF code in text mode will enlight more precisely the semantic attached to each of these attributes or properties (see the RDF Schema and the class Sentence that proceeds to the translation property/attribute -> English sentence).

- For more elegance, lisibility, and an easier proceeding, we set a syntaxic rule for the RDF code redaction: In a statement, the object (when it's an SVG entity: 'by reference' case) must be pointed thanks to the attribute resource of the property. Thus, one must write:

<axsvg:InFrontOf resource="#ObjectId" />

And not:

<axsvg:InFrontOf parseType="resource">#ObjetId</axsvg:Propriete>

As a consequence, in the DOM tree image of the RDF document, the nodes should not have any children with type TEXT_NODE (these ones will be ignored when proceeding the DOM). Yet, they can have some children of type ELEMENT_NODE whose name will be rdf:Bag or rdf:li, when a property concerns several objects (multiple-statement).


<rdf:Description about="#Pool">
<rdf:li resource="#BigComputer" />

<rdf:li resource="#MidComputer" />

<rdf:li resource="#SmallComputer" />

...other properties...

II. Java translator

As announced, such a tool will take an SVG file as a parameter, with its own RDF description within a <metadata> tag. Here is a typical example of an SVG document, that presents some structural concepts which may be described with the axsvg namespace properties: lan.svg (browsable version of the SVG markup, pixmap version as screen dump of Jackaroo)

Such a document can be rendered in graphic mode thanks to an SVG browser (for example: Jackaroo). It's the pale copy of a jpg picture taken from the example page previously quoted (we tried to reproduce the same and only structure which is important for our study, regardless of the pictural aesthetic).

The translator will proceed in two steps:

  1. First of all, he has to parse the XML document (indeed, SVG is an XML application), and build the associated tree: the DOM, which will then contain some elements of both namespaces svg and rdf.
  2. It will work on this tree in order to extract in a textual form the RDF description (associated with the one already contained in the svg part of the document, thanks to the <desc> element). In order to have a smart text, with consitent sentences, here again we had to impose a syntaxic rule that has to be respected when writing the SVG description of an entity (ie, the content of a <desc> node) : Such a descritpion should begin by a verb, as if the desc was coming just after the entity id. Ex:

    <g id='computer'>
    <desc>is the symbol of a laptop computer</desc>
    ...svg code that draws the computer...

The first task is practically done by a set of classes from Jackaroo, the SVG browser developed by the Koala team.

8 classes are in charge of the second task. Those classes are constituting the package 'axsvg':

The program requires jdk1.2.2 (or higher) to run correctly. Here is an executable jar file gathering all the required classes : axsvg.jar. You will also need to have the RDF Schema in the same folder: axsvg-schema.rdf.

To run the program, just type:

java -jar axsvg.jar file.svg

Where file.svg is the SVG file (with an embedded RDF description) to be described in textual mode. You can use for testing purpose lan.svg which can also be viewed with Jackaroo.

You may also use the -h option. In this case, the description is printed in HTML rather than in plain text:

java -jar axsvg.jar -h file.svg

Here's the output in HTML for lan.svg: lan.htm.


III. Java Editor

Such a tool should allow the edition of metadatas within SVG files, using the properties of the axsvg namespace defined in the RDF Schema axsvg-schema.rdf. It has a Graphic User Interface (using the java swing package), which is supposed to be as convenient as possible. Eventually, it should run on any platform which implements a java virtual machine (reported to work on Solaris, Linux, Windows 98, NT 5).

  1. Starting the editor

    The editor requires only two files to run correctly:

    Of course, for it is a java program, a Java virtual machine -including the swing package, such as jdk.1.2.2 or higher- is also required.
    Now don't bother with your classpath, just let the two files (edition.jar and axsvg-schema.rdf) in the same folder and type in:
    java -jar edition.jar
    java -jar edition.jar file.svg
    if you want an svg file to be directly opened...

    Remark: Windows users can also double click on the edition.jar icon.

  2. The Graphic User Interface

    Here is a screenshot of the GUI.

    As one may see on the screenshot, the interface is basically made of 4 areas and a File menu.

  3. The source code

    The 5 classes that actually constitute the editor are gathered in a package called 'edition', child of the 'axsvg' package. By the way they use all the axsvg package classes. Here are the sources for these 5 classes:

  4. Comments and future extensions

    As one may have already noticed, the editor only deals with the RDF code embedded in the processed edited file, within a <metadata> markup as specified in the SVG spec (NB: it creates such a markup if it does not exist yet). Unfortunatly, the svg code structure is critical, on account of it basically sets the possibilities of RDF statements to be formed.

    For example, let's say that we have an svg file representing a house. Thinking in terms of Accessibilty, we would like to state that the roof sits on top of the walls, thanks to the axsvg property 'SitsOnTop'. If the svg code is not structured so that the roof is separated from the walls, with the appropriate id attributes (like <g id='roof'> markup parenting the roof svg code, and <g id='house'> the house one), we won't be able to add such a simple description with our editor...unless we cope with the svg code, manually or thanks to another appropriate editor which would allow us to deal with the svg structure in a convenient way. Yet, as I'm writing, I haven't heard of the existence of such an editor.

    Of course, we could state that in a 'brave new world', all the SVG files should be well structured and commented, but until then, a good extension of the RDF editor would be to add functionalities to cope with the svg structure directly on the rendered image. This will be done by adapting the code of svg renderers which will efficiently implement event listeners attached to SVG nodes on the rendered image.

    By that time, the editor tool presented here may be useful to:

    At last, I will point that the rdf Schema (axsvg-schema.rdf) where the properties and their meanings are fetched by the descriptor/translator as well as by the editor is an external file (ie external to the runnable jar file). Thus, it can be updated easily, new properties being added or modified

Guillaume Lovet

Copyright  ©  2000 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.