Issue 2497

Summary: allow import of SVG (Scalable Vector Graphics)
Product: Draw Reporter: ddaniels <ddaniels>
Component: open-importAssignee: Armin Le Grand <Armin.Le.Grand>
Status: RESOLVED FIXED QA Contact:
Severity: trivial    
Priority: P3 CC: argasek, arielch, aw, bugs-openoffice, clippka, cmoulin, cno, daniele, davidf, email, esigra, fangqq, flibby05, giuseppe.castagno, haui,, irne.barnard, issues, jjc, jlp.bugs, jpalecek, jstaerk, kami911, kendy, khirano, marius.andreiana, masaya.k, mauro.giachero, mcepl, mfedyk, mlooo1, mmeeks, nathan, neteler, nicolas.mailhot, nunojsg, oo, ooffice, ooo, pagalmes.lists, parrenin.frederic, r.auberger, samuel.hartmann, simonbr, stx123, sundman, thb, towsonu2003,, y-catch, zmogas
Version: 641Keywords: oooqa, rfe_eval_ok, third_party_support
Target Milestone: AOO Later   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Latest Confirmation on: ---
Developer Difficulty: ---
Issue Depends on: 37213, 36713, 37210, 41343, 42959    
Issue Blocks: 48702    
Description Flags
an simple xslt filter for svg
add more features and some test files
Can't opened with the filter
Possible problems with text rendering
Updated version of SVG import filter. none

Description ddaniels 2001-12-10 17:16:47 UTC
enough said yeah?
Comment 1 bettina.haberer 2001-12-11 11:06:26 UTC
Here is one for you, Falko.
Comment 2 falko.tesch 2002-01-02 10:38:06 UTC
This issue is re-assigned to Christian Jansen for further evaluation.
Comment 3 christian.jansen 2002-01-08 13:48:05 UTC
We support SVG for export, I agree in the long term we have to support
this for import, too.
Comment 4 christian.jansen 2002-01-10 10:22:15 UTC
*** Issue 2570 has been marked as a duplicate of this issue. ***
Comment 5 tjwhaynes 2002-12-19 21:21:00 UTC
Looking at this defect, it would be nice to see a target milestone for
SVG import. Looking around the other vector graphic packages in
development, such as Sodipodi, SVG import and export is becoming more
important. Especially with PDF -> SVG conversion and other similarly
useful utilities making the availability of SVG source files easier
and with the Mozilla project supporting SVG rendering as well, it
would be nice to see this enhancement get in plan for a specific release.
Comment 6 horkana 2003-05-20 14:17:04 UTC
Please change OS to All (and probably platform too).  
(And please also close bug 7720 which is a duplicate).  
Comment 7 christian.jansen 2003-06-24 09:37:08 UTC
Greate feature, but I think that will take its time and ressources.
Bettina, I think we will not do this for OO.o 2.0. Could you please
add this to our feature list for upcomming versions? Thanks.
Comment 8 leveque 2003-07-07 15:29:07 UTC
Support for more Vector graphics brings better diplay and printing output.
Comment 9 leveque 2003-07-07 15:32:57 UTC
If import works, will it work for all types of coduments ?
Comment 10 andree 2003-07-22 14:35:23 UTC
Can someone please change this to All OS? (Has been brought up before
and not happened.)

Also, can we change this from component drawing to component
framework. I think this should definitely be available in all
applications. I stumbled across this when trying to use svg for
bullets in Impress for instance.

I have no idea what the timeframe for 2.0 is, but I'd definitely love
to see this in 2.0 (2 votes).

Comment 11 neteler 2003-08-06 13:53:04 UTC
... and another vote for import support of SVG.

At time it seems to be rather impossible to
get vector figures from Sketch or Xfig into
OpenOffice without rasterization.


Comment 12 bettina.haberer 2003-09-08 13:56:54 UTC
Yes, we should try it for the Q (OO.o 2.0) to get the SVG-Import-Filter.
Comment 13 falko.tesch 2003-09-12 12:15:54 UTC
*** Issue 7720 has been marked as a duplicate of this issue. ***
Comment 14 ooo 2003-11-03 14:07:50 UTC
*** Issue 7645 has been marked as a duplicate of this issue. ***
Comment 15 lcn 2004-01-06 23:17:10 UTC
*** Issue 7731 has been marked as a duplicate of this issue. ***
Comment 16 gisbertamm 2004-02-04 08:44:18 UTC
*** Issue 22470 has been marked as a duplicate of this issue. ***
Comment 17 jn0101 2004-03-04 13:08:15 UTC
Pleeeease do SVG imports! Better yesterday than tomorrow! 
Comment 18 henrikoxuk 2004-04-02 10:21:15 UTC
Having this feature resolved would help greatly in making a good clip art
gallery, like the one proposed by the Open CD team.
Comment 19 horkana 2004-04-03 13:33:05 UTC
Funny you should mention that, this issue is important to the Freedesktop
Clipart team too
Comment 20 efish 2004-04-05 15:49:37 UTC
Please change the component as the Import into Writer is needed as well. 
Comment 21 bettina.haberer 2004-04-08 17:48:08 UTC
There are unfortunately no ressources available for doing it into the Q.
Comment 22 stx123 2004-05-06 12:08:13 UTC
started/later looks like an abnormal state.
Comment 23 bettina.haberer 2004-05-06 13:15:50 UTC
BH->ST: "Started" means, that this issue is accepted as an enhancement, which
should get in into a milestone. A correct flag would be "in process", but as
such a fitting flag is not available on Issuezilla, we are forced to use the
existing ones. 
Comment 24 ianlynch 2004-08-22 14:10:51 UTC
OO.o Draw is the one component that gets OO.o into some entrenched MSO
environments. Its a strategic marketing issue to get SVG import asap.
Comment 25 lohmaier 2004-08-30 21:04:19 UTC
changing according to new RFE process... (OS, Platform -> ALL)
Comment 26 jketo 2004-08-31 12:55:50 UTC
This issue has been OPEN FOR 3 yrs now, hmmm...shows something of the state of
this least hints about lack of developers.

All the managers seem to do, is close the duplicates.

Hmm... what a shame since Open Office uses SVG internally as an graphics format
so is this really so hard to implement?
Comment 27 horkana 2004-08-31 15:18:33 UTC
> Hmm... what a shame since Open Office uses SVG internally as an graphics
format so is this really so hard to implement?

Draw only uses a small part of the SVG Specification internally (such as PATHS).  
The SVG specification is quite large.  

It should be relatively easy to produce a simple SVG importer that recogises
only PATHS to start with.  If someone started with that other might be
encouraged to build on it, but it would be a long time before they would have
something that would be good enough to include with stable releases of
OpenOffice or StarOffice.  

Anyone writing an importer would face the difficult task of importing many
different varieties of SVG, with differnt mixes of pure XML and Cascading Style
Sheets (CSS).  So while a basic importer might be easy, an importer that most
users would be happy and be really useful would be difficult and require getting
a lot of details right.
The smaller specification of SVG Mobile might serve as a useful subset that could support as an intermediate target rather than 
trying to support the full SVG specification.  

Bug Managers: 
t might be a good idea to change the subject to 
"allow import of SVG (Scalable Vector Graphics)"
to make it easier to search for, and it might help prevent a few duplicate reports
Comment 28 bryancole 2004-09-02 10:22:53 UTC
I think the most important feature here (from the user-perspective) is to be
able to insert, scale and render SVG images in OOo documents.

This is _not_ the same as being able to convert to OO-Draw's internal vector
format for editing, although this would be the best approach long-term (with
appropriate improvements in OO-Draws GDI engine). 

I.e. Why not treat SVG as "just another non-editable image format" and use an
existing SVG-rendering library to render the image as required (like you'd do
with PNG, JPEG etc.). Thus, where OOo would rescale a PNG image to the required
display resolution, it would simply re-render a SVG image to the required

I'm not sure what the best svg-rendering library would be, however; librsvg has
*nix/Gnome dependencies, ksvg requires libart (a KDE library AFAIK). Batik might
be a good option: written in java it fits OOo's Java-centric world, liberal
apache-style license, *full* W3C standard SVG support. Could it be handled as a
java plugin/extension?

Using a 3rd-party render would have the added benefit of much improved
rendering-quality. As much as I love OO-Draw, OOo's GDI rendering system sucks
(no anti-aliasing, jagged curves...).

Users have many many options for creating/editing SVG images (OO-Draw,
inkscape/sodipodi, sketch, Illustrator etc. etc.) but very few applications can
render them. SVG-rendering in OOo as a feature is a real 1-up on MS-Office.

Finally, I don't agree that a SVG importer must work with *all* SVG flavors to
be useful. All SVG flavors share a common subset of elements and these are the
"most useful" elements for illustrations/line-art. Partial SVG support early is
better than no SVG support until much later.
Comment 29 horkana 2004-09-02 20:40:59 UTC
Providing import by rasterizing SVG would be better than nothing but not ideal.
 Certainly an idea worth considering.  

> librsvg has *nix/Gnome dependencies

that is inaccurate, the GIMP has a librsvg based plugin which works on windows
too.  librsvg has many compile time _options_ to use Gnome technologies but they
are not requirements.  The requirements of librsvg are: 
librsvg has a small footprint only using libxml and libart (and optionally libgsf.) 

Comment 30 parrenin 2004-09-03 16:28:43 UTC
I fully agree with bryancole: what is important here in the short term is to
_render_ svg, not to edit it. 

SVG is the standard vector format for Linux: like WMF/EMF is on windows. On
linux, many drawing/graphing application can only output .eps and .svg as
vectors formats: xfig, xmgrace, gnumeric,... To use these images in e.g. a
Impress presentation or a Writer texte, you have to pixelize them. That means
poor rendering quality and big file sizes.

The edition of SVG is really of second importance. At least, there are other
tools to edit svg (e.g. Inkscape/sodipodi).

So please don't wait, render SVG for the Q! 
Comment 31 angelsh 2004-09-29 04:56:58 UTC
import the Scalable Vector Graphics
ooo is a very good program but.... it doesn't manage a Graphic format standard
and it is possible that svg in the future is it.
Comment 32 2004-10-12 09:45:06 UTC
OOo already use SVG to save graphics. 
Here is the body of a draw file. YOu can find svg 
   <draw:rect draw:style-name="gr1" draw:text-style-name="P1"
draw:layer="layout" svg:width="10.137cm" svg:height="8.162cm" svg:x="6.149cm"
   <draw:ellipse draw:style-name="gr1" draw:text-style-name="P1"
draw:layer="layout" svg:width="7.603cm" svg:height="10.1cm" svg:x="6cm"
   <draw:ellipse draw:style-name="gr1" draw:text-style-name="P1"
draw:layer="layout" svg:width="4.361cm" svg:height="8.125cm" svg:x="2.087cm"
svg:y="5.553cm" draw:kind="section" draw:start-angle="23.06"
So maybe we can create an xslt filter for it. It should be easy to import all
OOo supported parts.
Comment 33 2004-11-03 17:03:43 UTC
Created attachment 18892 [details]
an simple xslt filter for svg
Comment 34 2004-11-03 17:07:59 UTC
I just create a xslt filter for import svg files. just put it to
share/xslt/import/svg/ and create an xslt filter for ood. You can use it to
import simple svg files.
Comment 35 2004-11-05 09:59:00 UTC
Created attachment 18960 [details]
Comment 36 2004-11-05 10:03:26 UTC
To use this filter, be sure you have share/xslt/common/measure_conversion.xsl,
you can get it at

If you find your graphics are very small in draw, have a look at 
Comment 37 rcabane 2004-11-05 15:11:38 UTC
If you want to export figures from XFig you can follow other paths. 
For instance, you can export in EMF format, which OOo reads well (some problems
with colour fill but this is easy to fix in Draw).
In the very same way, you could use DXF format to import drawings from other
apps like Dia.
So although SVG is an important goal, it's not the only way to import vector
graphics; good DXF rendering is also crucial, as would be HPGL (plotter) import,
a much, much easier task.
Some conversion details can be found within the transfig package sources.
Comment 38 2004-11-07 05:06:45 UTC
Created attachment 19014 [details]
add more features and some test files
Comment 39 2004-11-07 05:10:56 UTC
Because I use OASIS as target format,so be sure to select OpenOffice Draw(.ood)
when you register XSLT filter. You may need OOo 1.96 . I don't know OOo 1.x
support OASIS or not.
Comment 40 rvojta 2004-11-09 19:18:04 UTC
Comment 41 niendo 2004-11-11 08:50:09 UTC
I tested the filter and think there are a very good start point for further 
It should be possible to render most of the SVG test suite 
( before 
oo 2.0 is released. 

But I suggest to move development of this filter to or any other place, 
where we have a 
* cvs support 
* mailing list 
* information page with test results and some other stuff. 

and to make this filter well-known to other guys. 

So, what about to create a project "svg2draw" on 

Greetings, Peter 
Comment 42 2004-11-12 10:04:59 UTC
Thanks Peter 
But I prefer to get it integrated into OOo.
Comment 43 andreschnabel 2004-11-12 11:56:49 UTC
Peter: all this
* cvs support 
* mailing list 
* information page with test results and some other stuff.

is available at the OOo site too. Sourcecast provides a similar environment like sf.

First step should be the relevant projects via mailinglist. In this case, I'd sa
the graphics project with would be the right place.

Comment 44 2004-11-18 06:49:32 UTC
I had checked in the last svg2draw.xsl into a cws base on m62. You can get at

or check it out from filter/source/xslt/import/svg with tag cws_src680_svgxslt01.
Comment 45 niendo 2004-11-22 00:13:39 UTC
Trying opening SVG Documents from the OpenClipart project will fail on some 
images. For Example see attached eagle_01.svg.

If I remove the line
from the SVG Header then everything works fine.

Is there a way to avoid this behavior?

Comment 46 niendo 2004-11-22 00:15:47 UTC
Created attachment 19548 [details]
Can't opened with the filter
Comment 47 2004-11-22 03:55:21 UTC
It sames that xmlns:xml prefix is not allowed by xalan xslt processer which we
used to process xslt transform. And a quick google shows that it's suggested to
avoid declare xmlns:xml prefix.
Comment 48 niendo 2004-11-23 02:38:00 UTC
Just for Info about the xmlns:xml prefix:

It is added automatically by libxml,
but it seems to be a bug in xalan.

Comment 49 kami911 2005-02-26 05:16:11 UTC
Professional SVG export import functions is very important. Without this we can
not use SVG galleries on best way.
Comment 50 kami911 2005-03-13 06:01:52 UTC
Time is running so fast. Any news?
Comment 51 kami911 2005-03-13 07:24:28 UTC
The mission statement says "To create, as a
community, the leading international office suite that will run on all major
platforms and provide access to all functionality and data through
open-component based APIs and an XML-based file format.". SVG seems XML to me.
We need this functionality...
Comment 52 giuped 2005-03-13 10:38:24 UTC
Open clip art library is becoming a great collection based on svg.. why do we
lose this opportunity?

excuse me for my very bad english!!!
Comment 53 kami911 2005-03-22 10:16:44 UTC
One more comment: This issue not depend on temlate location... 1.9.86\share\template path doesnt work like 
Application Data\OpenOffice.org1.9.86\user\template path...
Comment 54 dcarrera 2005-03-23 09:14:23 UTC
I'm removing the dependency on issue 37210. That issue was set to "WONTFIX", but
the idea that OOo will never integrate SVG import is plain silly. Furthermore,
issue 37210 is not the only path towards an SVG import filter.

Removing dependency.

Comment 55 dcarrera 2005-03-23 09:15:09 UTC
I'm removing the dependency on issue 37210. That issue was set to "WONTFIX", but
the idea that OOo will never integrate SVG import is plain silly. Furthermore,
issue 37210 is not the only path towards an SVG import filter.

Removing dependency.

Comment 56 kami911 2005-03-23 10:54:04 UTC
Windy, why are you want to leave the family of OOo?
The target milestone should be 2.0, please set it...
Comment 57 kami911 2005-03-29 19:52:29 UTC
202 votes should be enough to develop this important feature into 2.0...
Comment 58 dcarrera 2005-03-29 20:37:51 UTC
Well, it's not that simple. Writing an SVG filter is not like flicking a light
switch. It is not enough that people want a feature. We also need someone with
the time and skill to do it.

If you submit an XSLT transformation, I'm sure that the developers will
evaluated. Heck, I'll test it for you. :-)

Comment 59 rolanddeschain 2005-04-02 23:28:17 UTC
This may or may not help:

Keystone is a cross-platform, object oriented application framework which allows
applications to be written to build on the target platforms of GNU/Linux and
Win32 without modification of their source. Keystone implements several modern
Web standards, including SVG graphics and the XUL user interface description

SVG import support will be a great bonus to OOo, not to mention the Open Clip
Art Libary =)
Comment 60 jlp 2005-05-07 13:54:16 UTC
I would also like the support for SVG graphics in OOo 2. There are so many nice
SVG clipart and flags and no easy way to use it in OOo. And there are already
214 votes and this bug is here from the year 2001. Is anyone even doing
something to fix issues with high vote count and that re being so old?!
Comment 61 graupner 2005-05-11 13:11:32 UTC
Regarding windly's import filter

I think a filter importing only the important features (lines, text etc)
is sufficient for many applications. Far better than nothing.
I want to use it in conjuction with pstoedit to import former post-script
pictures with the ability to edit it in OO.

But I was not able to test the filter so far

1. I got share/xslt/common/measure_conversion.xsl
2. I copied the latest version of svg2draw.xsl to
3. I set up an import filter in OO:
   Filter name SVG Import
   Application: Draw
   Name of File type: SVG
   File extension: svg
   XLST for import: $HOME/OpenOffice.org1.1.2/share/xslt/import/svg/svg2draw.xsl

when I open one of windly's samples OO Draw opens but nothings
seems to have been imported.

I am using OO 1.1.2

What do I make wrong?
Comment 62 graupner 2005-05-11 14:20:33 UTC
Regarding windly's import filter

I think a filter importing only the important features (lines, text etc)
is sufficient for many applications. Far better than nothing.
I want to use it in conjuction with pstoedit to import former post-script
pictures with the ability to edit it in OO.

But I was not able to test the filter so far

1. I got share/xslt/common/measure_conversion.xsl
2. I copied the latest version of svg2draw.xsl to
3. I set up an import filter in OO:
   Filter name SVG Import
   Application: Draw
   Name of File type: SVG
   File extension: svg
   XLST for import: $HOME/OpenOffice.org1.1.2/share/xslt/import/svg/svg2draw.xsl

when I open one of windly's samples OO Draw opens but nothings
seems to have been imported.

I am using OO 1.1.2

What do I make wrong?
Comment 63 2005-05-12 03:11:45 UTC
It does not support OO 1.x. You can try it in last 1.9x version from
Comment 64 michael.ruess 2005-05-12 07:22:30 UTC
*** Issue 49120 has been marked as a duplicate of this issue. ***
Comment 65 haui 2005-05-12 09:06:02 UTC
Hi Windly,

just had a look into your svg2draw.xsl transformation to see whether I could
start some hacking based on it. Without having read much of the 1357 lines, I
wonder whether you use some "magic" tool to "generate" this XSLT. It looks that
homogeneous - very long lines, no blanc lines, almost no comments - and makes me
believe that this couldn't be a piece of hand-crafted software, is it, or isn't it?

Best regards,   Haui.
Comment 66 2005-05-12 10:08:40 UTC
You can use some xslt editors like xmlspy html-kit to edit and format the file. 

Comment 67 haui 2005-05-22 09:49:22 UTC
When importing SVG using the attached filter, some strokes are rendered wrong
(it appears as if line styles 'solid' and 'none' are exchanged). But the problem
behind the scenes is a bug in the interpretation of the svg:stroke-opacity
attribute of OpenDocument format by the OpenOffice draw component. This is
already described in issue 42959.
Comment 68 haui 2005-05-22 14:00:30 UTC
Due to issue 37213, strange things happen sometimes when saving SVG imported
graphics. Objects that were placed correctly after the import are flushed to the
document's top left border when the document is saved in OpenDocument format and
reopened with OOoffice.
Comment 69 haui 2005-05-28 17:38:25 UTC
I'm working on this (only from time to time - so do not expect miracles).
Unfortunately, I think it's not possible to write a clean-room implementation of
the svg2oodraw transformation. One reason for this is that the Open Document
format is specified with far less rigor than SVG. Is there somebody out there
who is willing to discuss issues in the Open Document format that affects the
import from SVG? I mean someone, who has either written the spec or at least
slept with it under his pillow? (Hoping for excuse from non-matching literally
translated German metaphors :-)

Because of the complexity of both formats, I also think it's not an option to
simply start with an "almost" working but arbitrary complex XSL(T) and keep
fixing until people get tired filing bug reports. A far better approach would be
to first specify how features of SVG could be expressed (or at least simulated)
in Open Document format. 

To be more concrete, here are some issues with Open Document format. I think
these will prevent OpenOffice from ever being a SVG editor, since structural
information which was present in SVG is lost during import and cannot be
reconstructed upon export.

1) There is no equivalence for svg:symbol/svg:use. (Is this true?) This means
that all references to graphical shape definitions must be expanded during
import in OOoffice. From an SVG editor's perspective it's like an editor for C
programs would first expand all macro definitions. You guess, how useful such
editor would be?

2) Coordinate system transformations (the draw:transform attribute) do not nest.
(Don't they?) The OOspec seems to disallow draw:g elements carrying a
draw:transform attribute. At least, I couldn't prove they do by Ctrl-f-ing
though the spec. (Is there a version of the spec that has cross-referencing in
the defined Schema names?) Therefore, the OOdraw coordinate system is flat. Only
some basic shapes (exactly draw:page-thumbnail, draw:custom-shape,
office:annotation, draw:rect, draw:line, draw:polyline, draw:polygon,
draw:regular-polygon, draw:path, draw:circle, draw:ellipse, draw:connector,
draw:caption, draw:measure, draw:control) might have a transformation attribute,
which only controls the transformation of the shapes own points. In short, the
problem is the same as with the symbols above. Nested transformations in a SVG
image must be flattened blowing up the file with transformation attributes and
removing structure.

3) SVG graphics may be CSS-styled, while OOdraw graphics have their own styling
mechanism. The problem of transforming structure-sensitive CSSs into a useful
small amount of concrete sensible-named OOdraw styles looks like a challenge.

4) OOdraw does nothing know about clipping. (Doesn't it?) This deficiency can be
observed in OOdraw itself. An usual workaround is to draw "white" (or whatever
the background is) shapes above the parts of the image one wants to clip away.
But this workaround is not applicable to an automatic transformation, since this
transformation would have to know the size of the clipped part, and it must make
sure not to over-paint some other unrelated parts of the drawing.

5) Markers. While SVG allows the definition of arbitrary complex marker elements
for line endings, OOdraw restricts markers to simple paths. The question here
again is what to do with SVG markers. They cannot be converted to OOdraw
markers, but they also cannot be inlined, because of the missing clipping feature. 

I think there are more issues - I started writing this with two in mind and
found more each time looking more deeply into both specs. Without doubt, there
is a bi-simulation between SVG and OOdraw, but there is nothing close to a
conversion / bijection. 

In my opinion, the only way to do the SVG "import" correctly, is to take a
full-featured SVG rendering engine and render into OOdraw primitives instead of
those of the graphics card. Of cause, this is not what people expect from SVG
import, since all structure other than grouping, which was present in SVG, is
completely removed.

The attached filter svg2draw almost goes the direction of partially rendering
SVG into OOdraw primitives. If not impossible, writing a SVG rendering engine in
XSL(T) is at least not easy - and pretty useless. The optimal solution in my
opinion would be to include a third-party SVG rendering engine (batik?) into
OOoffice and let people include their SVG images unmodified into their graphics
and texts. This is the best solution, because for non-trivial SVG images, the
results that can be expected from a conversion of SVG into a native OOdraw
graphic must be almost unusable for anything other than displaying (e.g.
editing). Therefore, the best way of preventing people from destroying their SVG
images by "importing" them into OOoffice is not to include an SVG import filter
at all.

Since the conclusion of best closing this issue and not including an SVG import
filter into OOoffice was found while writing, the statement at the beginning is
relative. But I'll at least provide an "improved" version of the svg2draw
filter, if I'm convinced that it does reasonable things for simple SVGs.
Comment 70 haui 2005-05-28 18:16:34 UTC
Close this issue in favor of issue 49991. :-)
Comment 71 lohmaier 2005-06-20 18:07:31 UTC
*** Issue 50991 has been marked as a duplicate of this issue. ***
Comment 72 pioterus 2005-06-22 23:11:59 UTC
I really need this feature. Don't mind how the opened/imported into eg. text
document drawing is saved, I just want to be albe to import SVG graphics. As for
me it could be then even converted into OOo Draw format.
Comment 73 hritcu 2005-06-26 10:23:18 UTC

This looks like a very useful improvement for OpenOffice. Let me know if you
need a hand with the XSLT, and how can I can contribute. I have already been
involved in a "huge XSLT" project ( and I would
like to help.

However, I ran into some problem trying to use your transformation from within
OpenOffice. I recognize this I a new OpenOffice addict so maybe it is just my
fault. In OpenOffice 1.9.104 I am adding this as an extension (
1.9.104/share/xslt/import/svg/svg2draw.xsl) and then create the import filter by
just pointing to this file. However, when I try to open a SVG file and select
the filter nothing happens - I just get a new "clean" surface. Am I doing
something wrong?

PS: If i'm using a plain XLST processor and I transform my file into a
content.xml then copy that over the one in an empty .odf file the drawing gets
pretty messed up. The text is all in the upper left corner. I thing it has
someting to do with groups (we use a lot of them). I will attach the svg file so
you can have a look.
Comment 74 hritcu 2005-06-26 10:27:58 UTC
Created attachment 27492 [details]
Possible problems with text rendering
Comment 75 kami911 2005-07-23 14:31:10 UTC
hritcu -> Can you do something for this feature? I wuould be very glad :o))
Comment 76 kami911 2005-07-23 14:31:29 UTC
hritcu -> Can you do something for this feature? I would be very glad :o))
Comment 77 haui 2005-07-25 14:19:19 UTC
Created attachment 28207 [details]
Updated version of SVG import filter.
Comment 78 haui 2005-07-25 15:05:17 UTC
I just added an updated version of the SVG import filter. This version is still
not ready for productive use. The changes to the transformation were made during
my research of the issue and during learning about both the SVG and OpenDocument
specification. Finally, I feel that the transformation cannot reasonably be done
in (plain) XSLT, since the transformation is absolutely non-trivial and requires
complex computations and data structures. I provide the attached version as
minimally improved starting point for potential additional contributors to the
issue (who want to prove the opposite). 

Since the results of any transformation must be far from optimal (due to
non-compatible features of both formats), I still think that Issue 49991
(displaying SVG without editing) should be resolved first. In a second step, a
command could be offered that allows to "break" a SVG graphic into OOdraw
primitives for editing. This is an equivalent approach to embedded OOcalc
diagrams in OOdraw. With this combination, the user can get perfect display of
SVG with an option to import/edit the graphic. If he requests to break the
graphic, he cannot complain about the result being somewhat broken :-).

Since I'm still interested in the transformation issue, my current approach is
to use a visitor-based Java transformation on top of the Apache batik SVG DOM.
Using the first half of the batik SVG rendering engine, gives all SVG-related
computations such as full CSS styling, viewport and coordinate system
transformations for free. Additionally, the full flexibility of a real
programming language can be used. Unfortunately, this version is not yet ready
for a sneak preview.

The following improvements/changes are made to the 2004-11-06 version of
svg2draw from windly:

  - Fixed some default values for SVG properties (stroke, fill).
  - Fixed parsing of CSS style attributes (the first property that has the
    searched property name as prefix was found).
  - Added approximation for the SVG properties opacity and fill-opacity
    (values are multiplied, if both properties are given).
  - Refactored handling of the transform attribute (The transform attribute
    handling is not yet complete. Neither are nested transformations
    supported, nor are all types of transformation matrixes understood.)
  - Replaced improper use of XPath name() function with self:: axis tests.
  - Added some documentation. 
  - Cosmetic changes: Use XSL as default namespace of the
    transformation. Do no longer rely on tab-with settings.

Just to say it a the end: Issue 49991 should be resolved first! :-)
Comment 79 wolframgarten 2005-07-28 10:40:52 UTC
*** Issue 52571 has been marked as a duplicate of this issue. ***
Comment 80 bht 2005-08-08 04:13:53 UTC
If I could import SVG into an empty drawing, scale it and print it with high
quality (as expected from vector graphics) then this would be ABSOLUTELY
Comment 81 thorsten.martens 2005-08-10 07:53:48 UTC
*** Issue 52843 has been marked as a duplicate of this issue. ***
Comment 82 haui 2005-08-12 10:51:45 UTC
Added Issue 36713 to the list of dependencies. This issue describes a defect in
the interpretation of the svg:viewbox attribute specified in OpenDocument
format. Without this issue being resolved, an external normalization of path and
poygon data is necessary during SVG import.
Comment 83 haui 2005-08-15 16:19:09 UTC
Announcement: SVG Import Filter for OpenOffice 2.0

Finally, I managed to build a distribution for my SVG import filter. It's a Java
UNO component using services from the Apache batik SVG engine. The component 
can be plugged into OpenOffice using the package manager. Since it is a little
to large to attach it to this issue, I set up a page from where you can grab the

I'm curious to hear your comments.
Comment 84 lars.nooden 2005-08-15 16:27:20 UTC
I'd love to test it, but I'm on OS X these days (will probably return to Linux this winter) and only have OOo 
1.1.2  If there is someplace I can down load OOo 1.9 for OS X, then I'll be glad to try out your filter.  I think 
it will be a very useful thing when it is done.

The filter needs OOo Version 1.9.m122 or above. The filter will not work with OpenOffice versions 1.1.X or 
below, which is what all us OS X users have for the time being...
Comment 85 falcaraz 2005-08-15 23:44:35 UTC
Explendid!; I have used it with several svg files and it is runing fine :-) 
Thanks so much for your work 
Francisco Alcaraz 
Murcia (Spain) 
Comment 86 lohmaier 2005-08-16 00:19:19 UTC
larsnooden: If you don't mind a german version: (m123)

haui: IZ could handle it, the limit is not 1MB as the page reads.. But since one
cannot tag attachments as obsolete and/or replace them, I'd suggest not
attaching it to the issue.

Is there any reason why the files are two seperate files and not one single
uno-package bundle?

Apart from that - Great work!
Comment 87 haui 2005-08-16 09:31:39 UTC
cloph: Thanks for the keyword "UNO package". 

The only reason, why there was no single installation package, is that this
filter was my first contact with UNO programming. IMHO, there is a lot of
documentation, but it's wide spread and not quick-start-friendly... now there is
an update.

And, just to repeat the URL:
Comment 88 sardisson 2005-08-16 09:33:41 UTC

> I'm curious to hear your comments.

While this will no doubt be a great solution for users on the "official"
(Sun-produced-builds) OOo platforms, it will certainly be problematic for the
two ports with the largest number of OOo users (according to OOo survey stats)
because of the 1.5 JRE requirement.  LinuxPPC seems to have some with 1.3.1 and
some with 1.4.2, and on Mac OS X, 1.5 is only available to users of Mac OS X
10.4.x (while there are still significant numbers of Mac OS X users still on
10.2.x, not to mention 10.3.x).

I applaud your efforts in coming up with a third-party solution to this vexing
issue, but I wanted to point out that it is a solution that will not help
everyone :-(
Comment 89 eric.bachard 2005-08-16 09:58:00 UTC
ericb ->haui

great work ! And since I have found jre1.5 for amd64 this is even better :-)

Thank you !

ericb -> sardisson

I can't believe, even one minute, you can care about Linux PPC users... 
IMHO you just are here complaining because NeoOffice cannot use this
Comment 90 ovvldc 2005-08-16 13:02:12 UTC
Ericb, please don't make pointless conjectures about other people's frame of
mind. Such a thing speaks less well of the speaker than the one adressed.

Personally, I'm anxious to have this feature implemented. From what I read, it
looks good. As for platform targetting, I would suggest Panther and Tiger are
supported for OSX. I don't use PPC linux, but I would suggest going with an
implementation that is supported by at least 50% of users out there.

Best wishes,
Comment 91 andreschnabel 2005-08-16 13:37:04 UTC
would you please keep your discussion about importance of specific ports /
platforms outside IssueZilla? This has nothing to to with the current

The only thing, this considerations are relevant for, is the fact, that you
might ask haui for help, if you are going to work on an implementation, that
would have no Java5 dependencies. (As it is open source, everyone is free to
work on a better implementation)

for the moment ... current implementation is helpfull, may be offered as
additional module, but it is not likely to be integrated in master, due to the
Java5 dependencies. (Those deps. are not in line with OOo's java guidelines)
Comment 92 splante 2005-08-17 22:13:55 UTC
Bernhard, thanks for the patch. Is there a strong reason why it requires Java
5.0? I see batik only requires 1.3. Perhaps I could get it to run using 1.3 so
it can be included in an upcoming general OOo release. Would you consider
putting a source zip file on your site?

Comment 93 haui 2005-08-18 22:50:10 UTC
The filter and accompanying tools make some (more or less advanced) use of
generic types and enhanced for loops. This is not a strong reason, but I think
its a job for a compiler, not for a human to do the transformation back to 1.0
and from there to ByteCode :-). This is a fun project of mine and writing type
casts is not fun. 

I would suggest to move further discussion and expressions of anger and delight
to the newly created Wiki space for the filter located at:

There, you can also find a guide of how to obtain the filter sources and how to
build it yourself. Just let me say the following: At the current early stage, I
think it would be no good idea to do the fork. Who wants to be at the bleeding
edge of SVG import can risk to use bleeding edge Java technology. But of cause,
you are cordially invited to participate in improving the results of the import.

Best regards,   Bernhard.
Comment 94 haui 2005-08-25 19:39:12 UTC
While OOo 2.0 beta 2 is still waiting for its announcement, there is a new and
dramatically enhanced version of SVG import:

Version r2009 that has been uploaded shortly now provides workarounds for the
most problematic differences between SVG and OpenDocument (only support for
gradients is still poor). With the new version installed, your OpenOffice
converts into an almost usable SVG viewer. For details, see the documentation in
the section "OpenDocument" and/or download now:

Best regards
Comment 95 haui 2005-09-02 07:56:08 UTC
Added Issue 41438 to the list of dependencies. This issue request support for
the elliptical arc command in path data attributes. Those commands are specified
in SVG and OpenDocument. Unfortunately, OOo silently ignores those commands,
which requires special means in several import filters to work around this
Comment 96 haui 2005-09-02 08:10:02 UTC
Change dependency from Issue 41438 to Issue 41343 since the former seems to be a
duplicate of the latter. Sorry for that.
Comment 97 kami911 2005-11-22 01:42:32 UTC
When the new version will be available?
Comment 98 haui 2005-11-23 21:22:38 UTC
Till now, the SVG import filter has been downloaded more than 3000 times. Its
home has slightly moved with the new wiki installation to:

kami: I know, I promised a version with further improved gradient handling. But
I had not much time these days and ran into some mathematical difficulties with
geometrical constructions on/with/of ellipses. These are solved now but there is
still some code to write and test. Christmas 2005 seems to be a good date :-)
Comment 99 haui 2005-12-29 15:41:17 UTC
Just uploaded new version r2131 of the SVG import filter. If you hurry up, you
can get your copy still this year:

Detailed release notes can be found on the download page. Main features in
version r2131 are dramatically improved gradient import and support for embedded
bitmap images. 

Nearly optimal results are now achieved for path elements filled with radial
gradients. The filter works around limitations of gradients in
(the coupling of the gradient dimensions on the shape's bounding box) by
extending the shape's bounding box with invisible points on demand. If you don't
believe your eyes, or you feel that the transformation result is impossible to
achieve in, decompose the imported image into atomic shapes and
use the point edit mode to see whats has happened (until the documentation for
gradients has been completed).

Enjoy and Happy New Year 2006!
Comment 100 computerhotline 2006-02-14 12:25:06 UTC
Why developpers don't integrate this feature in OOo ?
Comment 101 acolorado 2006-02-14 15:09:20 UTC
They are... but it needs to be polished, the importer is not 100% reliable yet, 
it uses Java 1.5 which might make OOo dependant on the latest and greatest and 
break older installations with Java 1.4.
Comment 102 acolorado 2006-02-14 15:55:31 UTC
They are... but it needs to be polished, the importer is not 100% reliable yet, 
it uses Java 1.5 which might make OOo dependant on the latest and greatest and 
break older installations with Java 1.4.
Comment 103 kami911 2006-02-15 05:15:00 UTC
Yes it have to be more feature reach. See the homepage of project. But I hope it
will be good enough to integrate it. The situation looks ugly when a program
based on open standards is not supporting an open gfx fileformat.
Comment 104 seahen 2006-02-18 03:36:27 UTC
Can we at least have a ballpark date on the implementation?
Comment 105 haui 2006-03-04 20:16:14 UTC
There *is* an implementation, which you can grep from

and install with 3 clicks. The new bugfix release r2185 includes an improved
coordinate system  transformation, works around rounding problems that occur
within after import, and fixes problems with polylines.

BTW, the SVG import filter is included in the German distribution
CD available from
Comment 106 kami911 2006-03-05 09:00:54 UTC
I have integrated it into my Premium builds (like Writer2latex
filter). More information is come when it is released.
Comment 107 kami911 2006-03-06 07:50:06 UTC
-> is: I would like to integrate it like writer2latex filer:


+Module gid_Module_Optional_Javafilter_SVGImport
+    ParentID = gid_Module_Optional_Javafilter;
+    Files = (
+    Minimal = NO;
+    Default = NO;
+    Styles (en-US) = ();
+    Styles (de) = ();
+    Styles (ja) = (HIDDEN_ROOT);
+    Styles (ko) = (HIDDEN_ROOT);
+    Styles (zh-CN) = (HIDDEN_ROOT);
+    Styles (zh-TW) = (HIDDEN_ROOT);

+/* SVG Import Filter */
+STD_JAR_FILE( gid_File_Jar_SVGImport, svg-import)
+File gid_File_Registry_Spool_Oo_TypeDetection_SVGImport_Types_Xcu
+    Styles = (PACKED);
+    Dir = gid_Dir_Share_Registry_Modules_Oo_TypeDetection_Types;
+    Name = "/registry/spool/svg-type.xcu";
+File gid_File_Registry_Spool_Oo_TypeDetection_SVGImport_Filters_Xcu
+    Styles = (PACKED);
+    Dir = gid_Dir_Share_Registry_Modules_Oo_TypeDetection_Filter;
+    Name = "/registry/spool/draw_svg_Import.xcu";

It can be enough, can't it?
Comment 108 2006-03-06 10:30:12 UTC
-> kami_ : The scp code looks good. But do not forget to define the module name
and module description in module_javafilter.ulf.
Comment 109 kami911 2006-03-06 12:28:56 UTC
->is: It is ready! But I didn't want to overload this file...
Comment 110 kami911 2006-03-06 12:29:36 UTC
->is: It is ready! But I didn't want to overload this issue...
Comment 111 kami911 2006-05-25 20:23:54 UTC
There is a perfect implementation of SVG engine in the latest stable Firefox...
Are there any way to use it?
Comment 112 kami911 2006-05-25 20:28:07 UTC
I would like to use the current SVG filter in my installer. This import filter
has to registered into services database? Simple filecopy doesn't work...
Comment 113 andreschnabel 2006-07-04 17:20:03 UTC
*** Issue 66964 has been marked as a duplicate of this issue. ***
Comment 114 kendy 2007-01-09 15:20:06 UTC
Just for the record, I have done an experimental proof-of-concept 
miniimplementation of SVG import (in C++, using libsvg).  Still needs a lot of 
work, so if there's a volunteer to help me, just contact me.

More info:

The code:*checkout*/ooo-build/trunk/patches/src680/svg-import.diff
Comment 115 kendy 2007-04-15 22:01:31 UTC
JFYI, native SVG import was just accepted as a Google Summer of Code 2007 
project, see
Comment 116 kami911 2007-08-19 09:24:04 UTC
Are there any new about this topic? I am really interested in...
Comment 117 troodon 2007-08-19 11:32:28 UTC
-> kami_

Comment 118 zhangweiwu 2007-10-03 16:48:57 UTC
There must be some unusual reason otherwise I cannot understand why high
priority and hot issue like this stayed 6 years time in issue tracker and still
not available in 2.3. Yesterday I received email notification from Sun
introducing good news that a lot of features are there, check again, no SVG.

I suffer because now I can hardly get high resolution diagram printed. I can
only use low-resolution png and my diagram happen to be hard to convert to odg
(external importer failed). I really don't need all these fancy 3D chart stuff
and I am definitely not going to upgrade to 2.3. Suddenly I got a feeling like
several years ago crying for png transparency support in IE. I know Sun provided
OOO for free and we should be thankful, but I got a mixed feeling. I have waited
years and years and read every release note, I subscribe OOO release
notification only to wait for the day to come. Sorry for just keep complaining
without understanding even a little technical background, I am no developer just
a user.
Comment 119 dprina 2007-10-03 20:42:19 UTC
zhangweiwu try this extension:

you can read this for more detail on the external/internal import:

Comment 120 tuharsky 2007-10-04 07:05:09 UTC
My feelings are similar, even broader.
I say: should the OOo have fixed all bugs older than 5 years, it would be the
best office suite ever.
Comment 121 ianlynch 2007-10-04 09:13:14 UTC
I'm using Inkscape now. I'm now recommending the schools I deal with use this
whereas as previously I was recommending OOo Draw. Inkscape has some real
advantages. First is its a lot smaller to download than the whole of OOo, it
supports svg as its native format and its not seen as a competitor to MS Office.
Draw was in some ways a killer application to get OOo into schools. Since
Inkscape is Open Source how hard to replace the Draw engine in OOo with
Inkscape's? I suppose licensing would probably be a show stopper there though :-(

Seems to me that odf as an ISO standards is seen as a selling point for OOo so
why such low priority given to the ISO standard for vector graphics? 
Comment 122 gebu 2007-10-04 09:30:27 UTC
I'm using Inkscape for my students too. I mirgrated from Draw, but the filter is
important for presentation if you would like to use SVG pictures from Inkscape
or OpenClipart to Impress.
Comment 123 nmailhot 2007-10-04 10:30:29 UTC
IMHO inkscape and draw are not competitors, they're complementary. People that
do serious graphic work will always prefer inkscape, people who do light work
will prefer something closely integrated like draw. inkscape should be seen as a
replacement for both visio and illustrator in the FLOSS ecosystem.

(serious graphic work includes diagrams for impress presentations)

For those reasons I don't think draw should be dumped to be replaced by
something build around inkscape, but at the same time OO.o and SUN should invest
to make sure  OO.o and inkscape integrate well. Which mostly means first-class
SVG support in OO.o.

Because good inkscape integration does not detract from OO.o's value, but
enhances it, as Microsoft understood perfectly when they bought visio and make
it part of the Office family.
Comment 125 olo 2008-03-03 11:44:35 UTC
Woohoo! Way to go Thorsten!

Looking forward to seeing your work in a stable build!
Comment 126 micool 2008-04-04 16:14:19 UTC
We miss SVG integration a lot...

I fully agree to what is being said. I use Inkscape for years now, and OO draw
should never try to convert SVG to its own primitives. Do we need a full bitmap
editor included in OO when we import images in OOwriter ?... no we don't: we
already have comprehensive tools for that...

This is the same issue with svg files, we just need something to display,
arrange and print svg in OO.
Comment 127 joergwartenberg 2008-04-04 17:36:26 UTC
Hi micool,

this issue is about importing SVG graphics into the OOo drawing application. If
you need something diffrent, you should open another issue (If such an issue is
not already existing).

Regards Jörg
Comment 128 gleppert 2008-06-26 15:46:31 UTC
According to Thorsten's weblog
(, import
of SVG Graphics is already integrated in the most recent Go-OO release. When can
we expect this feature in an release?

Thank you for your work,
Comment 129 thb 2008-07-03 13:43:51 UTC
@gleppert: with the current state of affairs
(, that svg importer cannot
be integrated with vanilla OOo currently.
Comment 130 gleppert 2008-10-26 20:48:59 UTC
@thb Thank you for your clarification on SVG import.

Any news on SVG import for 

I tried the variant of OpenOffice and indeed, SVG import works fine
there. For me, this was (and still is) a clear reason to switch: 2.4 -> 2.4.1 -> 3.0 -> 3.0 (when it will be ready). 

Unfortunately, the difference of opinion between Novell and Sun is a burden for
the users! The responsible persons should seriously think about it!

Comment 131 lars.nooden 2008-10-27 06:35:20 UTC
@gleppert: the differences are *legal* and ones pertaining to *your* continued
ability to enjoy access to your data.  These are facts not opinions.  We'll
pretend you're not trolling, just this once.  Projects like the one you mention
are at liberty to make their own variants of OOo, even ones that contain
licensing problems at odds with the requirements and goals of Free Software.  

Comment 132 lars.nooden 2008-10-27 06:41:36 UTC 3.0 is unable to import SVG either by the Insert->Picture route
or via File->Open.

The error is "unknown graphics format" for the former, and an attempt at
importing the file as ASCII as the other.   
Comment 133 simonbr 2008-10-27 08:05:38 UTC
Would it be possible to implement this as an extension, based on the same code
as used in Go-OO? It would make the functionality available in OOo (although you
have to install the extension afterwards) without the "legal" issues.
Comment 134 lars.nooden 2008-10-27 08:23:39 UTC
@ simonbr: I would strongly doubt that since the source / origin is tainted. 

However, importing is related to embedding (#49991)

Could importing SVG be a step in embedding SVG graphics, or are they same, or
completely unrelated?
Comment 135 mmeeks 2008-10-27 09:18:26 UTC
larsnoonden wrote:
> the differences are *legal* and ones pertaining to *your* continued
> ability to enjoy access to your data.  These are facts not opinions.

What !? are you smoking !? :-) How can adding an SVG import filter affect your
ability to enjoy access to your data ? last I checked SVG was some form of open
standard, and this is import !? AFAICS Sun itself is not making any of these
bogus IP arguments around potential pollution of OO.o. They are just arguing
instead that they want to own it for various (nice or them but frankly optional)

larsnooden wrote:
> I would strongly doubt that since the source / origin is tainted. (IANAL)

Tainted ? please substantiate such pestilent accusations: show us the lines of
code in the SVG filter that you're concerned about, and we'll re-factor them.
What we will not do is submit to the unreasonable Sun demands to own our
components :-)
Comment 136 thb 2008-10-27 11:46:20 UTC
@simonbr: yes for the document import (though with some effort & silly code
duplication - but then, the Java svg import extension already offers this), the
"Insert as picture" (imho the more relevant part) not - it uses internal OOo
functionality not available to extensions (even less so with the 3.0 three-layer

Comment 137 mbayer 2008-10-27 14:41:27 UTC
Dear fellow users of OOo, holding discussions in an issue is counter-productive.

Instead, please start a discussion on the mailing
list, in order to convince the UX team to recommend this issue for development.
Comment 138 juaninse 2009-01-23 14:48:03 UTC
This should be 2 different topics.  2 Features are needed in OpenOffice
regarding SVG that are distinct.  One is "insert SVG Image" which only inserts
it for display.  I will argue that this may be the most important one as other
tools such as inkscape exist for editing SVG.  It should also be the first

This does not mean that draw should not be able to import SVG as draw primitives
later on.  Draw has some great features like dimensionning that are missing in
other packages, and it may sometimes be disirable to play with the drawing for
other reasons.  Still this should be a LOWER priority than the "insert SVG"
image feature.
Comment 139 lars.nooden 2009-01-24 06:59:16 UTC
Agreed, simply being able to display or render SVG is enough at this stage. 
There are other programs available for editing.
Comment 140 mbayer 2009-01-24 11:18:23 UTC
Please note that this issue is about *import* of SVG graphics into Draw. *Embedding* of SVG graphic files 
(into all kinds of documents) is issue 49991.
Comment 141 zak_mckracken 2009-06-28 21:40:31 UTC
I've gone through the "duplicate" issues to this one and found the following:
At least to my understanding the issues 2570, 7720, 7645, 7731, 49120, 52843 
and 66964 are really only about _inserting_ svg images into documents.
This issue is about creating an import filter, which means a svg->odg converter.

While in the long run this serves a similar purpose, the difference between 
both has been discussed much already. I should just add that when using an 
import filter which will convert svg to draw, any svg features that will 
survive will be a subset of draws abilities. svg currently has a lot more nice-
looking features that draw doesn't need to duplicate, there's more important 
stuff to do.

=> I'd like to ask anyone interested "only" in inserting svg graphics into 
documents (presentation, drawing, text, whatever) to head over to issue 49991 
and cast a vote. Thank you.

P.S.: Can someone please explain to an issue tracker newb how to make the issue 
numbers clickable in comments?
Comment 142 irneb 2009-08-15 10:57:12 UTC
Second this! Or is that 439th this? As there's already 438 votes? Anyway there's
439 now!

SVG is the only open source vector format with decent capabilities. ODG still
has some problems (especially with text formatting & positioning) see Issue 74715
Comment 143 michael.ruess 2010-02-22 08:42:14 UTC
*** Issue 109493 has been marked as a duplicate of this issue. ***
Comment 144 gleppert 2010-06-07 22:47:45 UTC
According to this article there will be a SVG import coming with version 3.3.
Is this true? This issue has already 466 votes, I hope that we see it coming soon:;post-1557
Comment 145 thb 2010-06-08 12:12:50 UTC
Added folks that may be able to authoritatively comment on previous question to CC.
Comment 146 clippka 2010-06-15 12:31:08 UTC
cl->gleppert: I'm not sure how the author of that blog got his 'facts' but most
of them are completely wrong.
Comment 147 nick_s 2010-06-15 15:22:51 UTC
From an end-user's perspective, I'd like to be able to cleanly import a vector
graphic into OO-Impress and be able to "break" that object into its elements so
I can use a sequence of animations to build up a technical diagram. Importing
SVG should be the logical way of achieving this, but the current SVG import
filter struggles with basic issues like:

1) text disappears (but reappears in the wrong location after a "break" operation")
2) open paths become closed
3) even a simple 2-point path seems to be constructed as a filled closed path of
its outline (rather than a 2-point path with the correct width, arrowheads, etc).

These aren't advanced things like opacity, gradients, etc (which the OO Wiki
specifies as unsupported features), but are pretty fundamental attributes of
vector graphics (simple paths, etc).

I get slightly better results by doing a ".odg" export from Inkscape (although
open paths still become closed, arrowheads are lost) and the imported graphic
still needs a lot of manual fixing each time. This is frustrating enough that
I'd be forced back to Microsoft Windows/Powerpoint/Visio (if I could afford it!).
Comment 148 hakre 2010-08-01 10:20:09 UTC
Some user-feedback: I've run some import / export between latest stable
available OOo (3.2) and various files and other programs like Adobe Illustrator.
I'm very confident with the improvements this made in the last version, it's
working as intended for me.

As with other unexpected formatted paths (like unclosed ones or unsupported
features), it's totally clear that this can / does not work round-trip pixel
perfect. I don't see this is a limitation of the SVG import/export more a
limitation of OOo Draw which is limited in the one or other feature compared to
a full graphics program. I see nothing wrong with that. It's a tool for it's job
and I'm glad it's part of the suite.

Summary: 3.2 SVG import/export does work for me and it helps to better exchange
graphical vector data between OOo Draw and other programs and reading the more
and more popular SVG format.
Comment 149 lars.nooden 2010-08-01 10:39:21 UTC
to add to what @hakre

An export of a simple document from Draw produced an SVG file that was usable in
Inkscape.  It had only a few objects and splines and text, but was usable, so
this is a large and welcome improvement.  
Comment 150 yecril71pl 2010-09-29 09:50:09 UTC
I can open SVG in 3.2.1 all right.  Just tell Draw to open the SVG.
Comment 151 sphakka 2010-11-22 11:37:14 UTC
It doesn't work for me with OOv3.2.1: when opening a .svg file it pops up an
"ASCII filter options" window, then passes the content to the writer.

Importing into the gallery doesn't work as well: the find function simply
ignores any SVG file... 
Comment 152 irneb 2010-11-22 11:50:55 UTC
I've got the same problem. I have to install the svg-import add-on manually
otherwise I simply cannot open any SVG files at all.

Anyhow, I prefer using Inkscape to saveas to ODG - seems to produce better
conversion from SVG.
Comment 153 njsg 2010-11-22 17:14:45 UTC
@sphakka, @irneb: The issue might be that some GNU/Linux distros are
distributing OpenOffice with the Go-OO patches, but still branded as Go-OO. For
example, Gentoo uses Go-OO sources when compiling OpenOffice. This results into
a program branded "" which is able to import and insert SVG.

So I think the official OOo still lacks SVG, but Go-OO (and LibreOffice which
already incorporated the Go-OO patchset) supports it (even if not 100% perfectly).
Comment 154 Ariel Constenla-Haile 2013-02-06 15:23:14 UTC
Assigning to Armin

@Armin: this bug is said to depend on bug 37213 (assigned to you, too). It looks like with your new SVG implementation these two bugs are independent, isn't it? If so, this can be closed.

This bug blocks bug 48702 (Support SVG import in Gallery) which can be closed too: in fact, the gallery in OpenOffice 4.0 will come with several SVG graphics from Symphony.
Comment 155 Armin Le Grand 2013-02-08 17:26:30 UTC
ALG: Yes, this is done with AOO3.4.0.