What about SVG? - GullFOSS

RSS Feed

Atom Feed

Bookmark to Delicious

More Flickr photos tagged with openoffice

Today's Page Hits: 2453

« New: OpenOffice.org... | Main | Improved text output... »

Friday, 23 Mar 2007

What about SVG?

Kai Ahrens

I regularly get mails asking for a better SVG ('Scalable Vector Graphics', http://www.w3.org/Graphics/SVG) export or for an SVG import at all. In both cases there's some good and some bad information available, but all in all these questions show that this is a part we should definitely keep an eye on in the future (read soon).

For the first part of the question, the answer is quite easy at the first look: OpenOffice already offers an SVG export filter for many years.

StarOffice/OpenOffice.org was one of the first 'fat' productivity suites tightly integrating this feature into its feature set. To be precise, this export filter was the outcome of a new kind of Internet printing protocol, some people from Sun worked on at that time, requesting some applications to implement this protocol for prototyping purposes. SVG has been chosen as the format to transport the content of single pages. From that time on, the filter was part of OOo, got some rework from time to time, but wasn't really in focus of our daily work as much as it should have been.

On the other hand, being far away from a perfect export, it helped many people with their first steps regarding SVG content creation and even at the first OpenOffice.org conference, held in Hamburg a few years ago, I met some people using this technology for their quite impressing educational framework, for which OOo was an essential part of.

The question regarding an SVG import can be answered quite easily, too: there is already an import filter solution available, that has been created by community member Dr. Bernhard Haumacher and that can be found at http://www.ipd.uni-karlsruhe.de/~hauma/svg-import. The main reason for not being part of OOo itself is, that its requirements regarding the baseline are quite on the high side, due to the fact that it requires the very good but huge Batik framework (http://xmlgraphics.apache.org/batik) as an essential part to work. Nevertheless, many thanks and congrats to Bernhard from my side for his great work on this.

Next step to overcome the lack of an integrated SVG import filter is the Google Summer Of Code (GSoC, http://code.google.com/soc) application proposal, hosted by the community members Jan Holesovsky and Fridrich Strba as possible mentors. Current state of this project is, that it has been announced as a GSoC proposal but still needs final approval (http://wiki.services.openoffice.org/wiki/Summer_of_Code_2007).

So, coming back to our initial questions, the answer would be that OOo already has full SVG support, but for sure needs to be improved quite a lot to reach the status of a full featured SVG authoring solution. Improvements begin with the addition of many many enhancements to the export filter for which I already have a bunch of tasks. Exporting whole presentations including slide transitions and object animations is also on the top of my wish list, offering an alternative to Flash or PDF based presentations. Getting an integrated SVG import filter during this years Google Summer Of Code would be really great, and last but not least, replacing the internally used WMF format for vector graphics with SVG is one the things OOo needs.

I already got some requests from community members to work on this, which is absolutely great. I will definitely come back to you as soon as we have a clear picture of the things we need and how to implement them best, basically. Any input from your side is highly appreciated.

All the other users of OpenOffice.org, waiting for solutions for their needs, please be assured that this is still a hot topic, even if you may have the feeling that it is not.

tags: gsoc openoffice.org svg

Posted by Kai Ahrens on 23 Mar 2007 | PermaLink |

To Delicious |

Digg this | Comments[16]

Comments

Bryan Cole said:

I feel the issue of SVG-support has not been fully understood by Kai. As has been pointed out, the need for SVG-import into Draw has already been addressed. This is not at issue. However, SVG *import* is not "full support". What is required is the ability to embed and render SVG natively in *all* document types, just like OOo does for PNG, JPEG, WMF etc.. This is permitted by the ODF specification: all that is required is a native SVG-renderer (this could be implemented as a java extension using Batik, for example).

I want to be able to insert an SVG into a Writer document and have it rendered directly. When I save the file, I want the original SVG saved inside the .ODT xml (or link to an external SVG URL). I do *not* want to have to import each of my SVG figures into Draw then cut 'n paste them into Writer as OLE objects (so losing the original svg). The ability to author SVG in OO-Draw is less important (though still quite nice) as there are many other OSS SVG-authoring tools available. But what's the point of having SVG tools and artwork if you can't using them in any office documents?

I tried to spell this out clearly, so I hope I don't sound too blunt.

Posted by Bryan Cole on March 23, 2007 at 09:52 PM CET #

Mathias Bauer said: Kai has addressed this in his blog:
"Getting an integrated SVG import filter during this years Google Summer Of Code would be really great, and last but not least, replacing the internally used WMF format for vector graphics with SVG is one the things OOo needs." </br>
This should be understood as exactly what you described: anywhere where you can use WMF (e.g. inserting them into Writer or use it for replacement images of OLE objects) you should be able to use SVG. </br>

Posted by Mathias Bauer on March 23, 2007 at 11:04 PM CET #

Someone said:

It's the priority which seems misplaced to me. This was my point.

An import filter which loses the SVG, by internally transforming it to ODG is of limited value. This throws away the advantages of using SVG (which is the ability to re-edit your embedded/linked graphic using any of the many SVG authoring tools available). Once you convert to Draw, you lose this. As well as this problem, it's also duplicating functionality already available in the SVG Draw import filter extension (I'm not convinced the size and java-1.5 dependencies of this plugin are that big a problem, but maybe others think different).

Thus, I think an import filter may not be the best use of of a SoC project. If someone is to be sponsored to work on this, better would be to go straight for a SVG->GDI renderer (I think the work involved is about the same) and get the ability to render SVG (even if you can't edit them directly in OOo). A "convert to Draw" function could be added later. Essentially I'm saying "hey, don't work on that feature! Work on this instead!". ;-)

Posted by 62.253.128.11 on March 24, 2007 at 12:29 PM CET #

Mathias Bauer said: SVG->GDI is indeed desperately needed. OTOH such a component would be able to import only an SVG subset while SVG->Draw could import much more. So it depends what your primary goal is: have the best possible SVG support or have the most flexible one that can be used in more places.
As I'm working on the Writer project I agree with you: give us the SVG->GDI converter first. But Kai is working on the Graphics project so maybe that could explain if he has different priorities.

Posted by Mathias Bauer on March 24, 2007 at 12:39 PM CET #

Kai Ahrens said: Yes, both of you are absolutely right regarding the priorities, sorry for not stating this clear enough within my blog entry. I just wanted to give an overview of the current state and things that are going on here and there regarding this topic. That there's an approach from some of the named community members to integrate an SVG import filter for documents was there own decision, which itself is IMO based on feedback from their customers etc. or an interest of their own. Needless to say, that OOo needs this filter and if this filter is developed in parallel to your high priority features, why not, as long as every single part gets implemented. I really don't want to convince Jan or Fridrich to mentor a different project, if they feel quite well with this one. On the other hand, GSoC has only a short timeframe and even if participants are willing to work longer on their project, we need to take care that significant parts of the project will be done within this timeframe. In this case I'd vote for implementing the basics of a SVG graphic import (your topic) inhouse at Sun, just due to the fact that we (Sun OOo development) know details, possible pitfalls, needed classes, the larger context etc. better than somebody being new on the code. Believe me, working on the ODF structure or via OOo API is much more convenient for Newbies than digging around in code, that is oftenly not obvious to understand and that has been written by different people over a long period of time. So, to come to a conclusion, a new document import filter will be developed, if accepted by Google, by somebody new to the community using ODF or the OOo API, which are both well documented. I will take care of the graphics filter part and the framework to handle SVG's inside our core and documents. This will be done till a state is reached, where development of the open parts will be straight forward and can be made by others or me.

Posted by Kai Ahrens on March 24, 2007 at 02:03 PM CET #

Someone said: Thanks all for the follow on comments. I'm happy that both these aspects of svg support are on the OOo development radar.

Posted by 62.253.128.11 on March 24, 2007 at 06:51 PM CET #

JZA said: Well we wonder a lot about input of SVG too, specially because that will solve a very big issues for end users such as the clipart. We have the open clip art project running on SVG (not ODG) and also many other graphical standards are run on SVG. The issue however is that the import and interpretation of SVG is not there on the render engines within the OOo make the inclusion and production of project like OpenClipArt come short. The official reason why OpenOffice.org didnt include the OpenClipArt project was because they will bloat the OOo installation. However that is mainly because they will need to import the images as PNG. If OOo Clipart Gallery accepted SVG, the clipart size will decrease by order of magnitude. From 800k to merely 50k per image making it more efficiently compressed up to more than 50% since is ascii instead of binary format. So it escalate.

Posted by JZA on March 26, 2007 at 01:03 AM CEST #

JZA said: Here is an interesting and challenging question. What if OpenOffice.org Draw Format gets dropped and adopt SVG as the native file format. I understand the pieces that handle the file formats are very standard and having SVG as a native standard will require a lot of rework on the file management code. However, what if it instead of replacing the actual fileformat, the schema gets droped for SVG. This will require less work, so in other words content.xml will be replaced by the SVG schema. This will make a more open standard office suite, I agree with OpenDocument Text and Calc as an open standard but I dont consider OpenDocument Impress nor Draw as open standards simply because there are not many people really implementing this as a graphic or vector formats. I dont see many people dropping similar formats like Freehand, Corel Draw and Adobe Illustrator for OpenDraw. On the other side I do feel SVG has a better positon since all of the past software are SVG ready, there are many free SVG readers like Scribus and writers like Inkscape, also there are svg-toolkit and even animations drawn on SVG.

Posted by JZA on March 26, 2007 at 11:36 PM CEST #

Kai Ahrens said: SVG is mainly intended to describe two-dimensional vector graphics, it is not considered to be a document format itself, containing different pages, master pages etc., although this would be possible by using one or the other 'trick' like scripting with making single pages visible, using different viewports for the single pages etc.. But all this won't help you with most of your standard apps, just for the reason that they are not designed for this purpose. A further aspect is, that many types of Draw/Impress content can not be represented by SVG itself. e.g. OLE objects, Forms or 3D scenes. For this purpose you either have to define these elements by yourself and use them, or you need to rely on other XML specifications like SMIL, which would be easy in case of animations. Text is a different area, where SVG wouldn't fit our needs. Having a look at text objects in Draw/Impress, they don't contain static content, but behave more like floating text with different linebreaks etc., for which SVG is not designed for. What you are really looking for could be W3C's Compound Document Format (CDF, http://www.w3.org/2004/CDF) that is an approach regarding all these requirements, but as you can easily see, it is currently only available in a Draft state, and wasn't available at all during the initial development of ODF. So, SVG wasn't the answer to all our questions and so the ODF format specification had to be created even for these graphic centric apps.

Posted by Kai Ahrens on March 28, 2007 at 02:16 PM CEST #

JZA said: I see, that clears many specifics and you are right on the difference between ODG and SVG. I know that SVG are also used for animation, I cant think of an authoring tool for doing SVG animations but I do remember seen animations purely on SVG including 2D and 3D animations. However my question is how does OOo internally interprate graphics, and how much work will it be to just adopt the new schema. I want to think that OOo manipulate XML internally and learning the SVG would bee a trivial job, it will just get new rules for the SVG-specific tags. But if OOo converts the ODG XML into a "binary-like" then I can see an issue. I remember some developer mentioning this when I was testing adding new metadata tags in the meta.xml. I guess we can bring discussion back to dev@graphics.openoffice.org. Thanks for your response.

Posted by JZA on March 28, 2007 at 04:43 PM CEST #

AngryMike said: "I cant think of an authoring tool for doing SVG animations" You can do animations using Ikivo Animator or Beatware mobile designer. (Just to name two) And I imagine your phone will probably run those animations as well. :)

Posted by AngryMike on March 29, 2007 at 01:21 PM CEST #

Jeff Schiller said: "A further aspect is, that many types of Draw/Impress content can not be represented by SVG itself. e.g. OLE objects, Forms or 3D scenes." SVG handles this via the foreignObject element. I've only briefly looked at the ODF spec, but if you compare: draw:rect - http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1-html/OpenDocument-v1.1.html#outline:9.2.1.Rectangle svg:rect - http://www.w3.org/TR/SVG11/shapes.html#RectElement How difficult would it have been to use the svg:rect (i.e. the rect element in the SVG namespace) within ODF instead of inventing your own draw:rect element? You could have added any number of draw: attributes to the svg:rect element as long as they are defined in their proper namespace. I am not spec expert, so I'm genuinely curious as to what challenges that would have posed.

Posted by Jeff Schiller on March 29, 2007 at 04:52 PM CEST #

Jeff Schiller said:

Ugh, your HTML parser swallowed my whitespace/formatting. Should have used the Preview button! :) Here it is again:

"A further aspect is, that many types of Draw/Impress content can not be represented by SVG itself. e.g. OLE objects, Forms or 3D scenes."

SVG handles this via the foreignObject element. I've only briefly looked at the ODF spec, but if you compare:

draw:rect - http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1-html/OpenDocument-v1.1.html#outline:9.2.1.Rectangle
svg:rect - http://www.w3.org/TR/SVG11/shapes.html#RectElement

How difficult would it have been to use the svg:rect (i.e. the rect element in the SVG namespace) within ODF instead of inventing your own draw:rect element? You could have added any number of draw: attributes to the svg:rect element as long as they are defined in their proper namespace. I am not spec expert, so I'm genuinely curious as to what challenges that would have posed.

Posted by Jeff Schiller on March 29, 2007 at 04:55 PM CEST #

Christian Lippka said: Hi Jeff, when we designed the first version of an xml format for StarOffice before it became OpenOffice we tried not to reinvent the wheel. Thats why many elements and attributes are the same as in other standards. Others are only based on other standards. Thats exactly the recommendation when inventing xml formats. If something existing is the same, use it. If you do something new, make something new. So while both svg:rect and draw:rect represent a Rectangle, both are not the same. The draw:rect element is a more high level view on a rectangle, it has more features as a svg:rect. Now all that a draw:rect can do can be represented by svg, but you have to use more svg elements to do so. This distinction is also a help for people that like to transform ODF to other formats. If you find something that is named the same in both formats you can just take it. Anything else needs transformations. You may ask why we use a high level view on that when we could have also used from the beginning. Well with the same argument we could use pixels to store our documents ;)

Posted by Christian Lippka on March 30, 2007 at 10:24 AM CEST #

Jeff Schiller said: Christian,

That's fine, but being unfamiliar with ODF, I don't know what those "other features" are that ODF required for a rectangle - can you give an example or two of what other SVG elements would have been required?

The "X" in XML is for eXtensible, right - so it just seems like you could have taken svg:rect and extended it using your own attributes and child elements in your own namespace. Again, I will freely admit I have no experience with the ODF though.

Thanks,
Jeff

Posted by Jeff Schiller on March 30, 2007 at 02:59 PM CEST #

Christian Lippka said: Jeff,

like any other shape in ODF a draw:rect can have a shadow. The geometry of the shadow is then created on the fly by the application and not exported inside the odf format, which would be required for svg.

Again, XML is not XML, ODF is not SVG for a reason since it target different types of applications. If you think that ODF is not what you want then you are free to create your presentations with a SVG editor. Sure we could have named the draw:rect as svg:rect but it would have no benefit at all. See it as documentation that there is more to draw:rect than that what is specified and documented for svg:rect. If you go on and just replace draw:rect by svg:rect in an odf document you will find that still no svg renderer will render that file correctly. You need at least do an xslt transformation anyway and then you get the translation from draw:rect to svg:rect nearly for free but you would have to add transformation code for all other features that are part of ODF which are not part of SVG.

I think the main concept that is hard to understand is that ODF is not an eXtension to SVG, its a different format for a different type of document.

Regards,
Christian

Posted by Christian Lippka on March 30, 2007 at 03:13 PM CEST #