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