Re: [office] SVG Issues and Opportunities

[Doug Schepers <schepers@w3.org>]

Hi, Rob-

robert_weir@us.ibm.com wrote (on 10/15/09 9:43 AM):
> Doug Schepers<schepers@w3.org>  wrote on 10/14/2009 11:52:12 PM:
>
> 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?

That's an excellent summary.  As a corollary to #4, pluggable SVG 
implementations (open source or commercial) will allow people to more 
quickly and easily create that aspect of an ODF implementation, 
increasing the chance that there will be more ODF-compatible office apps 
created.


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

If I had to add to that list, I'd say, enable new use cases of vector 
graphics in ODF that weren't available before.

One immediate thing that pops to mind, besides the scripted 
interactivity which you may not wish to add, is that the SVG WG is 
developing a color management profile, which should meet high-scale 
print needs.


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

SVG already has this kind of relationship with styling languages, 
including CSS and XSL-FO.  In practice, it is mostly used for CSS, but I 
don't see (on the surface of it) why this should be different for XSL-FO 
properties.

As an aside, the SVG WG has a good working relationship with the XSL-FO 
WG, and many of the SVG properties were adapted from XSL-FO.  In turn, 
they will most likely use SVG for some of their upcoming work, notably 
text wrapped to an arbitrary shape.


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

Very interesting question.  I can see real value in this for charts, or 
even changes of colors in clipart.  Since SVG is a markup format, most 
changes would be easy to store, though maybe not as easy to visually 
represent (you wouldn't "strike through" a color change...)


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

SVG already uses SMIL for animation, too, though it may be a different 
subset of SMIL.  SVG uses the SMIL animation sandwich model and much of 
the SMIL syntax.  SVG Tiny 1.2 additionally adds support for multiple 
time containers in the same document.


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

Understood.  If there are things that can be done in the context of ODF 
1.2 (which I doubt), I am glad to help.  Otherwise, I will sit back and 
observe the general process you follow, so I can get up to speed for 
discussions in mid-November and beyond.  I don't want to disrupt the 
current work going on at all.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs