Re: [office] Open Office XML Format and SVG

[Daniel Vogelheim <Daniel.Vogelheim@sun.com>]

Hello Paul,

well, I'm admittedly a bit out of depth here because I don't know SVG 
too well. So first, I'll make some more general remarks; I'll also put 
some more detailed comments inline. There's a number of things I have 
not commented on; I'll try to catch up with you as I learn more about 
SVG... :-)


The general problem is to determine how much overlap there is between 
office shapes and SVG. I suspect the main problem is that SVG is an 
output format, which doesn't represent information which is necessary to 
edit the application. Graphics are to be rendered in SVG, and rendering 
is usually a one-way street. Office documents must remain editable, of 
course. For example, our applications (and thus the OOo format) support 
a hierarchical style concept, grouping, and 3D objects. All of them can 
be rendered quite easily in SVG: The styles can be propagated to the 
shapes, the groups are irrelevant for display, and 3D objects can be 
broken into 3D shapes. But, what if a user wants to load the document 
and, say, changes the top-level style to use blue rather than red, moves 
a group of objects, and rotates a 3D cube just a little more? If you 
have rendered the information to output level, you simply cannot do 
those things anymore. That's a problem....

(There's a lot of features like this. I'll use the line-with-arrowhead 
example you've given below for a more elaborate explanation.)

The other thing is, I'm actually not quite clear on what exactly you are 
suggesting:

1) Do you want to embed full SVG into the document?
2) Do you want to replace exisiting elements by their SVG equivalent?
3) Do you want shape descriptions in SVG, which will be linked from 
within the document content?
4) Do you want to completely replace all graphical content by SVG, much 
like we use MathML exclusively for formulas?


Oh, and one thing which has never been mentioned: The draw:image element 
includes, well, images. We have never restricted (and I don't think we 
should...) what kind of image formats are supported, so one can embed 
full SVG into documents in the OOo format as well. That's a user's 
choice then, and it's not exclusive in that graphical content would 
typically still be represented in own SVG-like (but not SVG) elements.




Paul Langille wrote:
> 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)

This contains some arguments I didn't know yet---

Where is suppose for raster images? I didn't see anything when browsing 
over the spec (1.1)?


> 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.

Ermm, I'm admittedly rather irritated by this paragraph. I am very well 
aware of the shortcomings of binary formats, particularly if they are 
largely undocumented. After all, we have created (with community 
participation) a fully documented, XML format for OpenOffice.org, and 
are now pursuing a standardization effort based on just this format...

Of course shapes (and any graphical content) must be fully reproducable. 
But of course the OOo format can do that, too, so this will not really 
help us determine whether to follow SVG or the OOo format. I take the 
above paragraph to be a more general remark, not an argument pro/con 
particular shape representations then...


> 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.

We are in complete agreement on the goal: The document should (and will) 
last longer than the application!

Here's what the OOo format does when you draw a line and choose a line 
style with arrow-head:

In the content, you'll find a line. I used the 'draw' application, so 
this inside a draw:page element:

   <draw:page [...]>
     <draw:line draw:style-name="gr2" draw:layer="layout"
                svg:x1="4.575cm" svg:y1="12.733cm"
                svg:x2="12.568cm" svg:y2="11.851cm"/>
   </draw:page>

OK, so there's a line and svg-coordinates tell us where it's placed on 
our page. If we want to know how the line looks like, we'll have to look 
at its style, which happens to be called "gr2". We'll look into the 
styles and auto-styles, and we find:

   <style:style style:name="gr2"
                style:family="graphics"
                style:parent-style-name="standard">
     <style:properties draw:marker-start="Circle"
                       draw:marker-start-width="0.25cm"
                       draw:marker-end="Arrow"
                       draw:marker-end-width="0.25cm"
                       draw:textarea-horizontal-align="center"
                       draw:textarea-vertical-align="middle"/>
   </style:style>

Aha! The line has start and end markers, using marker styles "Circle" 
and "Arrow". Also, if any text should be included, it's going to be 
center/middle-aligned. Actually, this info is quite superflous here; I 
don't know why the OOo app writes it out, but that's an application 
issue (a weakness, if you will) and not really a problem. Definitely not 
a format problem, anyway.

Other style property are inherited through the style hierarchy from the 
style "standard", and ultimately from the default style. Excerpts from 
those are:

   <style:style style:name="standard" style:family="graphics">
     <style:properties draw:stroke="solid"
                       svg:stroke-width="0cm"
                       svg:stroke-color="#000000"
                       draw:fill="solid"
                       draw:fill-color="#00b8ff" [...] /> [...]
   </style:style>

   <style:default-style style:family="graphics">
     <style:properties fo:color="#000000" [...] />
   </style:default-style>

In this case, the "standard" style contains all the relevant 
information: It's a black hair line (svg:stroke-color, 
svg:stroke-width), painted solid (unlike a dotted line, draw:stroke). If 
the style is applied to a rectangle it would be filled in some blue-ish 
color.

Now we can draw the line, and we can even translate it into SVG. Except 
for the marker ends. So we will look up the marker styles "Arrow" and 
"Circle" as well. In the styles section we will find:

   <draw:marker draw:name="Arrow"
                svg:viewBox="0 0 20 30"
                svg:d="m10 0-10 30h20z"/>
   <draw:marker draw:name="Circle"
                svg:viewBox="0 0 1131 1131"
                svg:d="m462 
1118-102-29-102-51-93-72-72-93-51-102-29-102-13-105 13-102 29-106 51-102 
72-89 93-72 102-50 102-34 106-9 101 9 106 34 98 50 93 72 72 89 51 102 29 
106 13 102-13 105-29 102-51 102-72 93-93 72-98 51-106 29-101 13z"/>

Since the markers are given in SVG paths as well, an SVG transformation 
would have to do a proper transform (scale them to the size given in 
"gr2" and move/rotate them to the line begin/end).

Note that all information is present. And all vital information is 
present in SVG attributes, too. I don't think things will get any better 
with respect to document longevity. It might get better with respect to 
some use cases vs others by leaning towards a different representation.


Now, having said all this, I would like to point out what I would see as 
missing from SVG as-is: (Actually, I'm not too familiar with SVG, so I'm 
happy to be corrected in case any of this turns out to be wrong...)

Notice that we store a line and say this line has certain formatting 
properties, including start/end markers. If the user changes the line, 
the arrow-head will move accordingly. It will be at the line's end, 
aligned along the axis of the line, with fixed size. An SVG line doesn't 
let us do that: On SVG export we will export a line, a circle and a 
triangle (the arrow-head). The information that these are really 
line-ends has been lost. What happens if the user moves the line? The 
arrow-head should of course move along with the line. Note that this 
applies to both, GUI applications and XML transformations.

SVG was constructed as an output format, for which it is completely 
irrelevant whether there is a line and incidentally there is a triangle 
on one end of the line, or whether there is a line which has an 
arrow-head. For editing, this information is vital. Which is why OOo 
preserves it.


> 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.

I'm having trouble following you here... Sorry. :-/

> 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.

Ah, groups may solve one problem I've mentioned above.

> 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.

I'll concede on that. I would previously have considered this bad style, 
and we've been careful to reuse namespaced attributes/elements 
completely or not at all. If the XML community thinks it's OK, I'm with 
them...

[...]


Well, more later on, when the discussion unfolds... :)

Sincerely,
Daniel