OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] Open Office XML Format and SVG

(Forwarding answer from my colleague, Rob Buis)

On Friday 09 May 2003 20:23, Daniel Vogelheim wrote:

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

Well IMHO its not very hard, since its well documented and readable, OTOH
there is a lot of material.

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

I think svg documents remain editable in terms of their own parameters,
ie. a <rect> remains editable by its parameters x, y, width, height, rx
and ry. Also transformations remain editable.

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

Svg generally recommends/demands png and jpeg formats, next to full svg
"images", by that I mean svgs can reference other svgs as embedded images.
I am not sure whether svg forbids other formats.

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

Its in chapter 5 ( http://www.w3.org/TR/SVG11/struct.html#ImageElement ).
A bit related to it is the masking and filter capabilities.

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

[ large example snipped]

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

I think this is a wrong example. AFAICS marker support in current OOo
format works the same as in svg. In svg line-ends represented as markers (
start, mid or end) will remain attached at their chosen positions on the
line points. Note that I am assuming here svg export will correctly
translate the line-endpoint graphics to true, referenced markers, not its
graphic contents only.

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

I dont think svg was created as an output only format. Sure its important,
but it emphasises content as well...


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]