Open Office XML Format and SVG

["Paul Langille" <Paul.Langille@corel.com>]

The following is my personal analysis of the benefits of standardizing
on SVG for graphics in the Open Office XML Format.

The basis for using SVG for all vector graphic description has many
benefits that may not be initially apparent.

Benefits:
- Standardized vector and raster image format
- Open standard
- SVG is a FULL featured vector format. 
- SVG has fully articulated graphic descriptions
- SVG has specified the means to contain and store raster (bitmap)
images within the format.
- SVG has specified vector description for glyphs (font characters).
- SVG has full support for text paths (beyond the confines of the linear
line).
- There are many open-source and closed source viewers, converters and
editors available.
- No ties to a proprietary binary format.
- Extensible (it is XML using namespaces)
- Support layers
- Supports full gradient descriptions
- Supports animation of grouped objects (for those who want animation in
their presentation)

My participation in defining this format was to allow
inter-communication between office applications. I know of many
applications that have 'rolled their own', even in their own family
(look at Word 95->97->98->2000->2003). You have the creation of new
documents that are TOTALLY incompatible with their siblings. It is next
to impossible to properly reproduce the documents produced by Word in
anything but Word. I do not want this to happen with Open Office XML
format. Shapes are one of those 'rarely considered' aspects of document
reproduction that are so critical to the proper reproduction of a
document. Graphics and shapes are not well represented in the office
community, and I see this as an opportunity to rectify that issue.

The tag 'arrow' could mean any number of types. Without a definition of
the shape, in a standard form, an implementer could decide to 'do what
they wish' in regard. The document should last longer than the
application.

Standardizing on SVG does NOT mean that we have to destroy the Open
Office XML format.  I was trying to make the point that the SVG was
essentially the 'style' of the existing shapes. SVG would be in the
context of describing the style of the shape. To continue the train of
thought, we would want to store the SVG description of the shape AS a
style IN the context of 'styling'. An author/content creator would want
to change/define the style (representation of the shape) because
sometimes shapes only having meaning as shapes. Any and all other
graphic representation outside of shapes should then be SVG.

One HUGE advantage of SVG is that all elements can be put into described
'groups'. I could take three four-sided polygon's to create a '3d-box',
and this shape can be given it's own NAME for reference in the format.
This allows the creator to 'name shapes'. It has been a very important
ability to supply 'fonts' and 'clipart' to users, but 'clipart' that is
self describing is of importance. I cannot see the OOXF format having
that capability so well encapsulated as much as I see in the SVG format.


Another point made was 'we don't want to 'embrace and extend' SVG.
- I totally agree regarding extending SVG. I fully agree to that point.
The point I was making was that the defined shapes have names but no
form. If you analyze the motto: 'A picture is a thousand words', you
have described the entire meaning of SVG in my opinion. It has the full
contextual description that defines a 'picture'. The Open Office XML
format (shortening to OOXF for reference)

- One large 'point' that may not be understood about namespaces is that
they were a means of allowing mixed content without constraints. It
allows for one program to 'ignore' any tags that it did not understand,
but in a means that could be retained safely.

The point was given that the 'styles' and attributes 'closely' match
SVG. 
- We want a one-for-one matching, reasons are the same reasons for
creating SVG in the first place.
- The counterpoint is that we are then 'redefining' graphical
description! We should only have to XSLT out the SVG from the root
document.
- The context of using SVG namespace is to allow those applications that
understand SVG to be able to edit the SVG itself without having to worry
about corrupting the document itself. This allows for a more
'Object-Linking-And-Embedding' approach without the overhead that the
original designers had with that approach. By using XML for the basis,
we ideally can use ANY editor, not just the Open Office or Star Office
application.

Another point made was 'how do we handle text inside of graphics'?
- An important point, I will agree. I have seen many applications that
never formatted text in a box the same way, especially when it came to
making the box bigger or smaller. Word wrapping has been a big problem
for graphics for a very long time. This is a problem that we should
approach the SVG council about. My personal take is that we should have
to handle text in such context EXACTLY how SVG defines it. That way, we
don't have to worry about it. If a string does not fit inside of the
graphic, do we redefines the shape or size of the graphic? I would say
'it depends what the user wanted'. The user should have the choice
between the two options. The text itself does not have to be stored in
the SVG. It can be referenced to using Xlink to the textual string. The
Open Office can add all the context that it wants to the string, but the
SVG would render it.

By describing the shapes in 'SVG', and storing it in or reference it
from the document, any implementer can create and reuse SVG viewer and
creation code to allow the user to view and edit.

It is in our mandate to make the best decision regarding graphics. At
the current time, my professional opinion is that SVG should be the
standard, solely because it IS a standard.