Re: [office] SVG Issues and Opportunities

[robert_weir@us.ibm.com]

Doug Schepers <schepers@w3.org> wrote on 10/14/2009 11:52:12 PM:

> 
> I will be happy to advise and even do some of the heavy lifting to help 
> resolve these matters, and any others of an SVG nature.  I'm pretty good 

> at writing spec text, and I can even be taught simple tasks.  I'm new to 

> OASIS, and I'm not sure what the next steps are (forming a subcommittee, 

> maybe?), so any advice is welcome.
> 

First I think we need to motivate our work in this area.  Why are we doing 
it?  What is the benefit of doing something more meaningful with SVG?

I think the arguments may be:

1) SVG is experiencing something of a resurgence in interest.  It is now 
supported in most web browsers and looking forward to HTML 5 we would 
expect it to be even more widely used.

2)There are benefits to the end user to be able to easily share data 
between the document world and the web world.  For example, the ability to 
drag & drop a SVG graphics from a web page into an ODF document would be 
cool.  It can also help with conversion of ODF to HTML 5.

3) Further, to the extent that web-based editors like Google Docs (and 
others) become more popular, the runtime toolkit of the document editor 
will likely already include an SVG editor.  So it will be far easier for 
such editors to write vector graphics in SVG format when saving an ODF 
document.

4)As SVG becomes more prevalent, we'd expect to see more people with 
skills in this area, more code libraries and components, both commercial 
and open source, more clip art libraries, royalty bearing and free, etc. 
So essentially, the network effects of a common format standard.

Any other good arguments for why we want to do something here?

Further, I think we want to consider the various degrees we can progress 
our use of SVG:

1) Verify that what we are using of SVG today is done in a sensible way, 
and certainly not in a way that conflicts with the SVG REC.

2) Allow SVG graphics as first-class objects in ODF document, much as we 
do MathML.

3) Use SVG more widely, such as being the preferred vocabulary for vector 
graphics throughout ODF, including places where we currently have another 
vocabulary.

Anything else?

Note: I'm not saying we do all this, but we should consider the 
cost/benefit of these kinds of changes in ODF-Next.

The technical concerns I have are generally how SVG would relate to 
document concepts in ODF.  Three examples (and there are likely more like 
this):

1) Relationship of text in SVG and text in ODF.  How do the style 
vocabularies relate?  ODF generally uses the XSL:FO text styling 
vocabulary.  A use case might be for a user to be able to change a named 
style and have all text with that style to change its attributes, 
regardless of whether the text is in a paragraph or an SVG graphic.

2) Interactions of SVG graphics and change tracking.  Users do not expect 
change tracking for embedding objects, but if we progress to have inline 
SVG, then it would be reasonable to track changes to graphics.  How would 
this be done?

3) Relationship of SVG and SMIL, which is used in presentations to 
describe animation.

To have SVG really work as a first-class citizen in ODF, we need to figure 
out the above.

But I should set expectations -- the ODF TC members are generally 
"heads-down" on getting ODF 1.2 out to public review, and with the 
upcoming ODF Plugfest and OpenOffice.org Conference.  So it will be very 
difficult to get the bandwidth to engage in a broader SVG discussion until 
mid-November.  You've joined us at "crunch time".  And we probably won't 
be actively working on ODF-Next until early next year.  But let's do what 
we can do.

-Rob