ODF and SVG: Evolving Standards for the Future

SVG Open 2009 conference


Abstract


With the advent of the Web -- based on HTML -- markup languages have been replacing proprietary formats. Productivity applications have been coalescing around two standards, namely ODF and OOXML. Vector markup languages (such as SVG and VML) have been adopted by most browsers to support reusable vector graphics. However, the use of vector graphics has been limited in browsers, due to the lack of consistent universal standards-support among all browsers. This has been one of the most significant missing-link in expressivity in web-pages including annotations, drawings, paintings, clip-arts, etc.; resulting in raster images holding up as the lingua-franca of graphical rendering at the moment. ODF has adopted SVG as the graphics representation standard. Interoperability among productivity applications is currently limited to the least common denominator of the features in most cases, since the standards themselves have lagged behind the requirements of the users, as well as future needs. There is no reason why documents that specialize in drawings, handwriting, annotations, sketches (as well as web-pages themselves) be treated as a separate class of documents, if the standards are directed appropriately. This paper highlights the strong and weak points of ODF and SVG compared to other standards, and points out significant areas of attention to bring these standards to be the best, and to be the very forefront of the industry. Focus on aspects of SVG graphics as it relates to ODF is expanded upon. Such gap-analysis would be extremely helpful in directing the standards bodies on both ODF and SVG side to take further steps to minimize the issues and maximize their potential for the future. Such analysis may also help browser vendors to adopt more ODF and SVG standards into content rendering, which may help converging of all applications into the browser. Examples of the use of vector graphics into web-pages and documents as against conventional techniques are also given. The experience of adopting standards (specifically detailed compatibility with respect to ODF and SVG) to productivity software that exhibits omni-functionality is also included for detailed examination.


Table of Contents

Introduction
Background
Evolution of Vector Graphics
Evolution of Open Office Formats
OOXML vs. ODF
Compound Documents
Mono-Functionality/Omni-Functionality
Designing Standards for the Future
Vector Graphics in Web Documents
Issues with Vector Graphics in Browsers
SVG Standards Limitations
Support of SVG in ODF
3D Objects
ODF Next
Conclusions
Bibliography

In 1989, Ray Kurzweil accurately forecast in his book Age of Intelligent Machines, that: “by the end of the 1990s, many documents would exist solely in computers and on the Internet, and that they would commonly be embedded with sounds, animations, and videos that would inhibit their transfer to paper format.”

Ray predicted in his next book (written in 1999) called the Age of Spiritual Machines, that: “By 2009, the majority of reading will be done on displays, although the ‘installed base’ of paper documents will be formidable. The generation of paper documents will dwindle, however, as the books and other papers of largely twentieth-century vintage will be rapidly scanned and stored. Documents circa 2009 routinely will include embedded moving images and sounds.”

He continued his predictions to 2019, when he said: “In 2019, thin, lightweight, handheld displays with very high resolutions will be the preferred means for viewing documents… the information will be downloaded wirelessly… Computers will have made paper books and documents almost completely obsolete.”

Clearly, the reality has been pretty much in line with Ray’s predictions so far. Web has clearly been a game changer in the equation. However, the productivity applications as of today still predominantly view documents as static-page based concepts, intended to show well on printed formats (or similar rigid displays).

Today, HTML, XML, and their variants have become the lingua-franca of the internet. Custom proprietary formats such as DOC, XLS, etc. are fading away to more open XML-based standards for document storage such as OOXML (from Microsoft) and Open Document Format (ODF) (from OASIS, Organization for the Advancement of Structured Information Standards).

While document life-cycle almost entirely revolves around virtual spaces rather than hard copies, disparities of formats threaten both the interoperability (among applications), as well as the long-term accessibility to the information (for the users).

How will open standards evolve into the future needs and expectations of the users? What can the key guardians of the industry do, to make the great opportunities possible?

People keep asking what Web 3.0 is, I think maybe when you've got an overlay of scalable vector graphics – everything rippling and folding and looking misty - on Web 2.0 and access to a semantic Web integrated across a huge space of data, you'll have access to an unbelievable data resource.

- Tim Berners-Lee, A 'more revolutionary' Web, New York Times, Tuesday, May 23, 2006

Tim Berners-Lee combined SGML (from Charles Goldfarb of IBM), Graphical User Interface (from Steve Jobs) and TCP/IP based Internet (from Vint Cerf) to make the World Wide Web. This was a giant leap in the way documents could be structured, stored and deployed [JP1]. Though SGML variants have been formulated since the 1960’s to enable computer-based document markup, Tim’s coalescing of the Hypertext idea to the network created the possibility of documents that could compose itself out of resources strewn all over the Internet.

As in any competitive industry – and especially in one that is as fast-paced as the computer industry – it is normal to experience converging and diverging trends in industry standards. However, the web and its technologies have been influencing the expectations of the user, and have magnified the possibilities that arise out of the massive adoption of the browser.

Though older formats like Windows Metafile (WMF) and Enhanced Metafile (EMF) are still seen in some implementations, vector representation languages evolved into two major formats over the last decade – (a) Vector Markup Language (VML) (and the related DrawingML) and (b) Scalable Vector Graphics (SVG).

Conventional software have adopted document technologies that act like containers which hold components tightly, rather than loosely-coupled lighter structures, where associated resources are combined on the fly as required. The newer data-file formats for office applications are getting influenced by the flexibility of the web. And, online applications like Google Docs and Zoho have been mimicking the offline variants to some extent.

Like print-and-paper in the past, electronic documents (along with databases) capture (and persist) almost all of the data, information and workflow details today. In our fast changing computer industry, players and technologies appear and disappear in years.

This creates massive issues for governments and corporations, who want to be able to have access to the information for decades. This has made such entities to insist on truly open standards – which give open access to users to their information using a variety of techniques.

Drawing from the success of HTML in the World Wide Web – primarily because of its openness and flexibility in standards – the industry has been adopting vector markup languages (such as XML variants) for many aspects of documents.

Users would rather have a universal standard; but until the world switches to newer concepts like omni-functionality [JP2] [JP3], the plurality of legacy interfaces required to interact with data demands that we converge these standards as much as possible. Yet on the other hand, the highly competitive nature of the industry inherently causes divergence in these standards.

In this paper, we will examine two open formats SVG and ODF – one for vector graphics and other for document formats – in more detail, with intent to highlight low hanging fruits that can enable better adoption and use for the common users.

The Semi-Automatic Ground Environment (SAGE), a control system for tracking and intercepting enemy bomber aircraft used by North American Aerospace Defense Command (NORAD) from the late 1950s inspired the invention of the computer mouse by Douglas Engelbart. SAGE Control System was possibly the first vector graphics based display system [SAGE1].

Since then, Computer Aided Design (CAD) systems, drawing tools (like AutoCAD), Geographic Information Systems (GIS), etc. have been routinely using vector graphics over the last several decades.

In 1998, Microsoft, Macromedia and others submitted VML (Vector Markup Language) to the W3C as a proposed standard for Vector Graphics on the web. W3C also received submissions such as Precision Graphics Markup Language (PGML) from Adobe Systems and Sun Microsystems. From these efforts, a new W3C working group was created, which eventually produced SVG (Scalable Vector Graphics).

In VML, for example, apart from other decorations, the code for an ellipse may look like the following:


              <v:oval 
              style="left:0;top:0;width:100;height:50" 
              fillcolor="blue" 
              stroked="f"
              />

              

In SVG, this may look like:

                
                <ellipse 
                  	cx="50" cy="25" rx="50" ry="25" 
                  	fill="blue" 
                  	stroke="none" 
                 />

            

Obviously, the essence is the same, though the syntax is slightly different.

Both OOXML and ODF have similar structures and techniques to store information. Both standards consist of datasets, which consist of folders and files, packaged up in zip files. OOXML files have extensions .docx, .xlsx, .pptx, etc., whereas ODF contains file extensions such as .odt, .ods, .odp, .odg, .odf, etc. – each type representing the application that is used to create it. For example, .xlsx and .ods both represent spreadsheet files.

To understand the structure of an OOXML file, one can change the extension of a simple sample .docx file to .zip; and open it in any zip format viewer. In this case, this sample file a.docx just contained ‘Hello World!’

OOXML files follow the Open Packaging Convention (ISO/IEC 29500-2:2008), which has the structure given in Figure 1 and 2.



As can be clearly seen, the text is embedded in XML tags, with styles, settings and fonts, set in separate .xml files (Figure 2). The text contents are given in document.xml as in Figure 3.

                    
              <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<w:document xmlns:ve="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:o="urn:schemas-microsoft-com:office:office"
    xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships"
    xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math"
    xmlns:v="urn:schemas-microsoft-com:vml"
    xmlns:wp="http://schemas.openxmlformats.org/drawingml/2006/wordprocessingDrawing"
    xmlns:w10="urn:schemas-microsoft-com:office:word"
    xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main"
    xmlns:wne="http://schemas.microsoft.com/office/word/2006/wordml">
    <w:body>
        <w:p w:rsidR="003D03C0" w:rsidRDefault="00807A9D">
            <w:r>
                <w:t>Hello World!</w:t>
            </w:r>
        </w:p>
        <w:sectPr w:rsidR="003D03C0" w:rsidSect="00544FB2">
            <w:pgSz w:w="12240" w:h="15840"/>
            <w:pgMar w:top="1440" w:right="1440" w:bottom="1440" 
                w:left="1440" w:header="720"
                w:footer="720" w:gutter="0"/>
            <w:cols w:space="720"/>
            <w:docGrid w:linePitch="360"/>
        </w:sectPr>
    </w:body>
</w:document>


                

Figure 3. Contents of the document.xml in the .docx.

 

A similar file in .odt ODF format is given in Figure 4. This can also be viewed by changing the extension of the file to .zip, and opening in any .zip viewer.


The content.xml has the content as given in Figure 5.

                
            <?xml version="1.0" encoding="UTF-8"?>
<office:document-content xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0"
    xmlns:style="urn:oasis:names:tc:opendocument:xmlns:style:1.0"
    xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0"
    xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0"
    xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0"
    xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0"
    xmlns:xlink=http://www.w3.org/1999/xlink
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0"
    xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0"
    xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0"
    xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0"
    xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0"
    xmlns:math="http://www.w3.org/1998/Math/MathML"
    xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0"
    xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0"
    xmlns:ooo="http://openoffice.org/2004/office" 
    xmlns:ooow="http://openoffice.org/2004/writer"
    xmlns:oooc="http://openoffice.org/2004/calc" 
    xmlns:dom="http://www.w3.org/2001/xml-events"
    xmlns:xforms="http://www.w3.org/2002/xforms" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:rpt="http://openoffice.org/2005/report"
    xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2"
    xmlns:rdfa="http://docs.oasis-open.org/opendocument/meta/rdfa#"
    xmlns:field="urn:openoffice:names:experimental:ooo-ms-interop:xmlns:field:1.0"
    office:version="1.2">
    <office:scripts/>
    <office:font-face-decls>
        <style:font-face style:name="Tahoma1" svg:font-family="Tahoma"/>
        <style:font-face style:name="Times New Roman"
            svg:font-family="&apos;Times New Roman&apos;" 
                   style:font-family-generic="roman"
            style:font-pitch="variable"/>
        <style:font-face style:name="Arial" svg:font-family="Arial"
            style:font-family-generic="swiss" style:font-pitch="variable"/>
        <style:font-face style:name="Lucida Sans Unicode"
            svg:font-family="&apos;Lucida Sans Unicode&apos;"
            style:font-family-generic="system" style:font-pitch="variable"/>
        <style:font-face style:name="Tahoma" svg:font-family="Tahoma"
            style:font-family-generic="system" style:font-pitch="variable"/>
    </office:font-face-decls>
    <office:automatic-styles/>
    <office:body>
        <office:text>
            <text:sequence-decls>
                <text:sequence-decl text:display-outline-level="0" 
                         text:name="Illustration"/>
                <text:sequence-decl text:display-outline-level="0" text:name="Table"/>
                <text:sequence-decl text:display-outline-level="0" text:name="Text"/>
                <text:sequence-decl text:display-outline-level="0" text:name="Drawing"/>
            </text:sequence-decls>
            <text:p text:style-name="Standard">Hello World!</text:p>
        </office:text>
    </office:body>
</office:document-content>


            

Figure 5. Contents of the content.xml in the .odt.

 

In Figure 5, note the line that indicates the invocation of the SVG namespace in ODF:          xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0"Also note the <text:p text:style-name="Standard">Hello World!</text:p>, which contain the edited text in the file.

OOXML uses smaller tags (as seen in <w:t>Hello World!</w:t>), to make the files smaller; but since the whole file is compressed in .zip format, this optimization may not be that significant in practice in saving space.

However, the most notable thing in both ODF and OOXML file folder structures is that they exhibit similarity to folder structures of common websites (Figure 6). Effectively, the document structures in both of these standards make documents equivalent to mini-websites.


This insight is significant, in that it highlights the encroaching of the web structures into document structures. This may suggest a future consolidation in formats, along these lines for integrating websites and documents. Though this may happen in future years, later in this paper we will focus on the evolution of ODF and SVG, and how they may interact to define documents in the future.

The most notable aspect of conventional software is the focus on one or few pieces of functionality. This maybe because of the way most legacy software was developed; each product needed targeted marketing messages to reach their niche markets.

Microsoft Office, Open Office, Google Docs, etc. are examples of Mono-Functional solutions that are put together into “integrated” solutions. The most interaction that is available among documents made by these solutions is still limited to copy/paste and object embedding.

Omni-functionality introduces the concept of the availability of any functionality that the users require – without regard to the sequence of creation or complexity. Whether the user wants to calculate or draw or compose, to any extent or complexity, the authoring platform seamlessly moulds itself to suit the user’s requirements

An intelligent document, that arise from omni-functional platforms, can be visualized as a document structure and platform that is: (a) active, (b) immersive, (c) interactive, (d) web-compliant, (e) seamless, (f) application-agnostic, (g) data-agnostic, (h) omni-functional, (i) shareable, (j) viewable, (k) editable, (l) function-agnostic, (m) feature-deep, (n) calculation-aware, (o) graphic-aware, (p) standards-based and (q) infinitely extensible [JP2].

The following expands the intent of the terms as used above:

  1. An active document dynamically manipulates its data.

  2. An immersive document allows the user to achieve all required functions without leaving the platform.

  3. An interactive document allows the user to interact with the content during the lifetime of the document, through scripting if required.

  4. A web-compliant document depends primarily on open web-standards or commonly available web-technologies at all stages of its lifetime.

  5. A seamless document is a document that is not fragmented into pieces based on separate features, unless the fragmentation is for convenient deployment.

  6. An application-agnostic document does not restrict its interpretation to a certain specific application only.

  7. A data-agnostic document can contain any type of data that the user wants to deal with.

  8. An omni-functional document provides any type of functionality to any part of the document in any sequence whatsoever.

  9. A shareable document can be viewed and interacted among appropriate actors separated by time and/or space at the appropriate level of content granularity.

  10. A viewable document is a document that provides view-only interaction during specific stages of its life-time.

  11. An editable document is a document that provides editing capability to a document at specific stages of its life-time.

  12. A function-agnostic document is a document that allows any function to be applied to any part of the document in any sequence based on the desires and needs of the user.

  13. A feature-deep document is in which the functionalities provided are of sufficient depth that for a majority of uses, the available functionality encompasses the needs comprehensively.

  14. A calculation-aware document is a document that can achieve a vast majority (and if possible all) of calculations achieved normally through specialized applications like spreadsheets as a part of the document itself.

  15. A graphics-aware document is a document that can create and manipulate vector and raster graphics of extreme complexity in multiple-dimensions.

  16. A standards-based document uses common web and other standards to represent information, rather than a proprietary format that may be specific to a vendor.

  17. An infinitely-extensible document is a document that can take new data and functionality at anytime during its lifetime for needs and uses that may be unexpected before or during its construction.

 


 


Figure 7 (a) and (b). Intricate paintings achieved by an Intelligent Immersive Omni-functional Platform – Using IE and VML.


Omni-functionality is natural to users, who would prefer documents to be like the way they think.  A classic document – whether it be a report, a presentation, a book, a paper or a notice – require elements of any data type in any sequence as the user desires and requires to express his/her ideas. In most cases, users are forced to use two-dimensional documents aimed at paper-formats that users can print out and read – not intended to interact or to provide an immersive experience. Multi-level multi-layered interactive experiences are expected to create the framework for documents in the future, based on web-standards (Figure 7(a), 7(b), 8).

Today, however, use of web technology for productivity applications are dramatically affected by disparate implementations of browser programs, as well as unacceptably tight restrictions on the basic standards of the web. The incompatibilities between browsers span from ‘box-models’ to much needed DOM methods (such as outerHTML).

In many cases, competitive and commercial reasons have prevented standards bodies from adopting a superset of functions or attributes. Instead in many cases, the prevalent official standards adopt half-baked incomplete solutions, as a technique to paint some specific vendors as ‘violating standards’. In fact, the lack of universal adoption of outerHTML in the DHTML DOM is a classic example of inconvenient incompatibilities that implementers have had to sidestep, using second-class solutions. However, this trend is seen all over in web-standards, as well as document-format standards.

Each element in an HTML Web Document falls into the following content categories:

o       Metadata content

o       Flow content

o       Sectioning content

o       Heading content

o       Phrasing content

o       Embedded content

o       Interactive content

o       Others (like Transparent Content)

According to the HTML standards, out of this, vector graphics can be present in Embedded Content, Flow Content and Phrasing Content. Content that imports another resource into the document, or content from another vocabulary that is inserted into the document is categorized as Embedded Content. Most elements that are used in the body of documents and applications are categorized as Flow Content. Text contained in a document, as well as elements that mark up that text at the intra-paragraph level (and paragraphs) form Phrasing Content.

For the most part, use of vector graphics in Embedded Content is straight forward, since this is separate in nature (like Shockwave/Flash embeds), and can be handled by any suitable handler application (like SVG Viewers in the case of SVG). However, flow content and phrasing content brings us to inline vector graphics, which considers the contained graphics in the scope of the larger DOM.

The overall design of vector graphics standards must keep these several uses of elements and their scope and role in the total document rendering and object model. For example, z–index layering, filters, transitions, animations, SMIL, etc. may need to work with the global object model in the Flow and Phrasing Content scenarios. On the other hand, these can be treated independent in the case of embedded content.

These aspects require two different approaches to the overall design of vector graphics standards; as well as treatments of arguments and counter-arguments of ‘backward compatibility’.

For example, a decision regarding flow-content inline graphics in a browser may need to ignore backward compatibility of z-indexes in some binary program that is intended to create graphics.

In today’s most popular browsers, Vector Graphics is achieved by either VML or SVG (if plug-in technologies like Adobe Flash are ignored). Internet Explorer depends primarily on VML as of 2009, and almost all the others use SVG. Adobe SVG Viewer was a popular technique to view SVG in Internet Explorer, but it was discontinued at the end of 2008 by Adobe. Techniques such as SVG rendering in IE using dynamically triggered Flash embeds (as in the recent SVGWeb – an open source project), or dynamic VML translation using libraries like Raphael, etc. have kept SVG alive inside IE through simulation.

Though the lack of native support for SVG in IE has been an issue to some; the lack of real native support for SVG in Firefox has been an equally cumbersome sticking point. For example, inline SVG is not supported in Firefox browser, unless the file is XHTML based (with content type of XHTML or files with .xhtml extension). This prevents the effective use of SVG in HTML files – considering HTML files (text/html content that includes flexible transitional formats) form the vast majority of pages in the world (over 97% by some estimates). The workaround uses iframing to enclose SVG files as separate files (as embedded content), which is then included in the HTML files. This is a serious gap that results in the prevention of popularity of SVG in browsers as well as true native vector graphics support, in even the ones that actually claim to support it.

Implementers have been requesting having SVG in text/html, but surprisingly, SVG technologies Working Group specifically stopped it from becoming a reality, citing technical reasons. The proposal was shot down with the reason that it ‘tries to change the SVG syntax in a way that is incompatible with all implementations to date,’ and ‘progress on allowing SVG in text/html while maximizing compatibility with the wide range of deployed SVG authoring tools and renderers.’ [AE1] This unfortunate reasoning has been preventing the use of SVG in a wider manner in Firefox and other standards-based browsers, while VML had been implemented and used by Internet Explorer without breaking the browser for about a decade. One of the reasons mentioned is that the malformed SVG code may break the rendering [10], however IE has been rendering VML in HTML pages with or without malformed code since 2000. Also, wide support exists in copying/pasting/exporting VML code between MS applications and even the browser itself.

Effective use of SVG requires inline use in HTML, rather than framed or separate SVG files (which is suitable only for embedded content, which is in most cases more effectively achieved by simple raster graphics or the popular Flash techniques). For example, annotations, handwriting, etc. in HTML documents require inline SVG format, rather than heavier iframe invocations (or flash based solutions like SVGWeb) that cannot be inlined effectively. This is a major issue from an editing and interaction point of view, as well as prevents full friction-free native interaction with the DOM.

The fact that SVG works in XHTML means that it is technically feasible to have inline SVG within HTML. It is a pressing need to have text/html to render SVG inline, and every effort need to be made to achieve this. By preventing smooth two-way interaction with the DOM (by having to adopt techniques such as iframes and Flash), use of SVG gets constrained and unnecessarily complex – and this is clearly caused by unnecessary backward compatibility arguments from a few. Making XHTML specific implementation prevents any practical use of SVG in browsers at this time, since a majority of users still use browsers that ignore strict XHTML content type in entirety. This puts mainstream developers in a bind, without achieving any technical advantage.

Almost every vector drawing software use z-index to specify rendering algorithms. However, SVG lacks z-index, leaving serious work with SVG difficult, in anything other than heavy binary authoring-tools. For example, in ODF 1.2 [SW2] specification for vector graphics, ODF adds z-index over the SVG-like properties, which obviously will not work in other platforms that use pure SVG – causing issues from an interoperability perspective.

Effectively, placing objects in different sequence in SVG requires moving the objects in memory or DOM (or copying and pasting code), which are error prone and unnecessarily complex solutions. Though instead of providing z-index capabilities, many solutions have been proposed on the web to solve this using DOM manipulation, such solutions work for only small cases, and creates a serious disconnect with all other vector platforms (including VML, Drawing ML, ODF Vector Draw, and many others).

For example, extracted code from among the SVG Web examples [SW1] that manipulate pictures vs. videos are shown below:

                    
Example 1: //for photos:
      function bringToFront(s) {
          var el = document.getElementById(s);
          el.parentNode.removeChild(el);
          document.getElementById("canvas").appendChild(el);
      }
Example 2: //for videos: // it does not work!
function bringToFront(s) {
          var el = document.getElementById(s);
          // commented out because it causes the video to restart
          //el.parentNode.removeChild(el);
          //document.getElementById("root").appendChild(el);
      }

                

Listing 1. bringToFront() function having code to be commented out for raising the object in the DOM without z-Index.

 

Raising an object into a different layer is easily achieved in other platforms like VML [8], AutoCAD, etc. by changing the z-index of the object. However, the requirement to manipulate SVG related objects to achieve this as in Listing 1, indicates the issues caused by the lack of simple z-index. If we add the complexity this causes in complex drawings and animations that require virtual layer-based manipulations, the choice so far to not have z-index in SVG is unfortunate.

It is to be noted that SVG was proposed to have z-index as per the working draft in 1999 (http://www.w3.org/TR/1999/WD-SVG-19990412/render.html), and later dropped without explanation. This is a sticking point as can be seen at http://wiki.svg.org/Rendering_Order, which says: “There are perennial discussions about the introduction of a z-index attribute which would control explicitly the layered placement of elements.” This is a major issue with interoperability with other standards (like VML/DrawingML and many others) which invariably use z-index as a basic aspect of rendering.

As of 2009, there are discussions on how to give z-ordering to SVG objects (http://www.w3.org/TR/SVG-Transforms/), but mostly as a part of the implementations for 3D and other transforms. This is a primary requirement that causes unnecessary issues for almost every user of SVG standard, and the provision of simple z-index should be treated as a very high priority.

Simulated 3D operations are another missing link in SVG, as we shall see later. However, work is ongoing on this aspect (http://www.w3.org/TR/SVG-Transforms/). Since the web will be increasingly 3-dimensional in the near future, it is important that SVG groups start looking at its integration or bridges into X3D, VRML, 3DMLW, O3D, OpenGL, U3D, COLLADA or similar languages and APIs, with a vision into the future. The success of web mapping software such as Google and Microsoft Maps (which are still predominantly 2-dimensional) have demonstrated the need for standard vector graphics languages. It is just a matter of time before these go into 3-dimensions, which could take advantage of such extensions to vector formats.

ODF adopted SVG as the vector graphics language in theory, but the use of SVG in the document model has been rather limited. ODF 1.2 states that for <draw:image> element, while the image data may have an arbitrary format, it is recommended that vector graphics are stored in the [SVG] format and bitmap/raster graphics in the [PNG] format (where the file is logically separate in nature). In fact, ODF still uses Draw (Open Office Native Format) [EE1] elements to describe the objects, with minimal mention about the SVG attributes. An example is given in Listing 2:

            
<office:drawing>
    <draw:page draw:name="page1" draw:style-name="dp1" 
             draw:master-page-name="Default">
        <draw:rect draw:style-name="gr1" draw:text-style-name="P1"
             draw:layer="layout"
             svg:width="9.525cm" svg:height="8.89cm" svg:x="4.175cm" 
                       svg:y="4.81cm">
            <text:p/>
        </draw:rect>
        <draw:ellipse draw:style-name="gr1" 
             draw:text-style-name="P1" draw:layer="layout"
             svg:width="9.525cm" 
	      svg:height="10.16cm" svg:x="7.985cm"
             svg:y="9.89cm">
            <text:p/>
        </draw:ellipse>
    </draw:page>
</office:drawing>

            

Listing 2. SVG use in ODF is at the moment overshadowed by the Draw native elements.

 

The use of SVG attributes is highlighted in Listing 2, but it can clearly be noted that is not the conventional standards based SVG syntax.

ODF Specification [SW2] indicates in Page 391:

 

                
18.234 draw:z-index
The draw:z-index attribute defines a rendering order for shapes in a document instance. Shapes are rendered in the order in which they appear in the document in the absence of this attribute.
The draw:z-indexattribute is usable with the following elements: <dr3d:cube>9.5.3, <dr3d:extrude>9.5.5, <dr3d:rotate>9.5.6, <dr3d:scene>9.5.1, <dr3d:sphere>9.5.4, <draw:caption>9.3.11, <draw:circle>9.3.8, <draw:connector>9.3.10, <draw:control>9.3.13, <draw:custom-shape>9.6.1, <draw:ellipse>9.3.9, <draw:frame>9.4.2, <draw:g>9.3.15, <draw:line>9.3.3, <draw:measure>9.3.12, <draw:page-thumbnail>9.3.14, <draw:path>9.3.7, <draw:polygon>9.3.5, <draw:polyline>9.3.4, <draw:rect>9.3.2, <draw:regular-polygon>9.3.6 and <office:annotation>13.1.
The draw:z-indexattribute has the data type nonNegativeInteger17.2.
OpenDocument-v1.2-part1-cd03.odt 30 July 2009 Copyright © OASIS Open 2002 - 2009. All Rights Reserved. Page 391 of 801: OpenDocument-v1.2-part1-cd03.pdf

            

 

Though z-index is assumed by the ODF standard, it is clearly not a part of the SVG specification. Adopting z-index as a common standard is something SVG can easily achieve [ZZ1].

Further research on the attributes named under the svg: namespace shows that the following SVG related attributes/elements are being used in ODF:

            
accent-height
alphabetic
ascent
bbox
cap-height
cx
cy
d
definition-src
desc
descent
fill-rule
font-face-format
font-face-name
font-face-src
font-face-uri
font-family
font-size
font-stretch
font-style
font-variant
font-weight
fx
fy
gradientTransform
gradientUnits
hanging
height
ideographic
linearGradient
mathematical
name
offset
origin
overline-position
overline-thickness
panose-1
path
r
radialGradient
rx
ry
slope
spreadMethod
stemh
stemv
stop
stop-color
stop-opacity
strikethrough-position
strikethrough-thickness
string
stroke-color
stroke-linecap
stroke-opacity
stroke-width
title
type
underline-position
underline-thickness
unicode-range
units-per-em
v-alphabetic
v-hanging
v-ideographic
viewBox
v-mathematical
width
widths
x
x1
x2
x-height
y
y1
y2

        

As can be observed, the appropriate attribute is given svg: prefix while being used as within the draw: element context.

The SMIL (Synchronized Multimedia Integration Language) adoptions in ODF use the anim: or smil: namespaces, many (though not all) use SVG standards.

ODF Next may consider using of more compliant SVG, but it does not seem to be a clear priority yet. However, lack of attributes like z-index clearly creates issues for ODF and other vendors in fully adopting SVG –– thus preventing further adoption of SVG.

In general, among Embedded Content (inserted into the document), Flow Content (general body of the document), and Phrasing Content (text of the document), SVG can be adopted fastest in embedded content. In general, the embedded content is the easiest to accommodate, since it can be treated as a foreign object with its own helper or filter application. However, flow and phrasing content require special attention to the full capabilities of ‘inline’ or ‘overlay’ SVG in comparison with competing standards like VML and DrawingML (and even Adobe Flash); since the products that use any standard as its default-native-format should not face a deeply adverse competitive situation, purely because it adopted it as the standard.

For this, a deeper feature-by-feature analysis is required with other standards with a view to identify any gaps, and proactively fill them [AX3]. In the end, the standard that excels users requirements will win, irrespective the backers or the noise and hype surrounding it. In this regards, the standards process must be very proactive and accommodating, and less prone to rigid stands based on ‘backward compatibility’. Fat-client tools are on the way out, and hence spending more focus on them as against the browser-as-an-editor paradigm may be the wrong step forward.

Instead, providing ‘forward’ compatibility with what the users need proactively is paramount in importance. In this regards, the willingness of the SVG WG to make necessary changes to accommodate to aid ODF adoption is commendable. At the same time it must be made in a user-centric way – keeping the role of the browser as the editor for future architectures.

It is important that the final experience of the users and his/her requirements drive the standards, rather than the limited views of software standards organizations (that are restricted by the least common denominators of the participants as well as their hidden agendas). Internet Browser is no longer a browser, it is a powerful editor. Achieving deep functionality should not be at the mercy of the decisions of a few who may fail to see (or refuse to see) the future needs. Any limiting designs (especially in the context of browsers) need to be considered as a serious defect, compared to features in any other software.

Especially since SVG is considered a premier standard for the WWW, it is important that decisions are focused on the web first, and on other software second in terms of compatibility. Decisions should reflect a proactive stance on catering to the web, and its uses, and that will drive adoption into other areas automatically. The SVG standard must have the effect of creating innovation, by positioning for the future than the past.

It is proposed that SVG committee look at the implementation of important issues like z-index to enhance its use into common and fine uses. Adopting inline HTML is another important thing to be pushed for. Working with ODF groups to achieve full SVG compliance need to be pursued; especially considering the fact that the convergence of document formats to web-based formats is inevitable.

ODF needs to transition into purely-web-enabled to interact with omni-functional documents as well as plain web systems. Hence serious consideration needs to be given for ODF standard to become more HTML/CSS compatible.

From the experiences with the implementations of SVG, it is clear that the main sticking points are quite feasible to remedy. Political aspects (such as adoption or lack of it) can be handled easily by adopting a web-based view in general, and by ironing out minor issues that are roadblocks.

It is still to be seen whether the ODF+SVG combination will unseat OOXML+DrawingML combination in the upcoming years. However, it can be expected that both ODF and SVG will benefit by moving closer towards the web-standards, possibly enabling systems that blur the difference between web-documents and productivity-documents.

 

It is just as important to be able to edit the Web as browse it.

- Weaving the Web, Tim Berners-Lee, The inventor of the World Wide Web.

References