Apache OpenOffice (AOO) Bugzilla – Issue 2497
allow import of SVG (Scalable Vector Graphics)
Last modified: 2022-10-28 12:59:39 UTC
enough said yeah?
Here is one for you, Falko.
This issue is re-assigned to Christian Jansen for further evaluation.
We support SVG for export, I agree in the long term we have to support this for import, too.
*** Issue 2570 has been marked as a duplicate of this issue. ***
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.
Please change OS to All (and probably platform too). (And please also close bug 7720 which is a duplicate).
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.
Support for more Vector graphics brings better diplay and printing output.
If import works, will it work for all types of coduments ?
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). Cheers Andree
... 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. Thanks, Markus
Yes, we should try it for the Q (OO.o 2.0) to get the SVG-Import-Filter.
*** Issue 7720 has been marked as a duplicate of this issue. ***
*** Issue 7645 has been marked as a duplicate of this issue. ***
*** Issue 7731 has been marked as a duplicate of this issue. ***
*** Issue 22470 has been marked as a duplicate of this issue. ***
Pleeeease do SVG imports! Better yesterday than tomorrow!
Having this feature resolved would help greatly in making a good clip art gallery, like the one proposed by the Open CD team.
Funny you should mention that, this issue is important to the Freedesktop Clipart team too http://clipart.freedesktop.org/ http://freedesktop.org/pipermail/clipart/2004-April/
Please change the component as the Import into Writer is needed as well.
There are unfortunately no ressources available for doing it into the Q.
started/later looks like an abnormal state.
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.
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.
changing according to new RFE process... (OS, Platform -> ALL)
This issue has been OPEN FOR 3 yrs now, hmmm...shows something of the state of this project.....at 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?
> 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. http://www.w3.org/TR/SVGMobile/ The smaller specification of SVG Mobile might serve as a useful subset that OpenOffice.org 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
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 size/resolution. 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.
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. http://librsvg.sourceforge.net/ The requirements of librsvg are: librsvg has a small footprint only using libxml and libart (and optionally libgsf.)
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!
yeah,, 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.
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" svg:y="4.472cm"/> <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" svg:y="12.894cm"/> <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" draw:end-angle="287.99"/> So maybe we can create an xslt filter for it. It should be easy to import all OOo supported parts.
Created attachment 18892 [details] an simple xslt filter for svg
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.
Created attachment 18960 [details] updated
To use this filter, be sure you have share/xslt/common/measure_conversion.xsl, you can get it at http://www.openoffice.org/source/browse/framework/filter/source/xslt/common/measure_conversion.xsl If you find your graphics are very small in draw, have a look at ttp://www.openoffice.org/issues/show_bug.cgi?id=36713
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.
Created attachment 19014 [details] add more features and some test files
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.
.
I tested the filter and think there are a very good start point for further development. It should be possible to render most of the SVG test suite (http://www.w3.org/Graphics/SVG/Test/) before oo 2.0 is released. But I suggest to move development of this filter to sf.net 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 sf.net? Greetings, Peter
Thanks Peter But I prefer to get it integrated into OOo.
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 dev@graphics.openoffice.org would be the right place.
I had checked in the last svg2draw.xsl into a cws base on m62. You can get at http://framework.openoffice.org/source/browse/framework/filter/source/xslt/import/svg/Attic/svg2draw.xsl or check it out from filter/source/xslt/import/svg with tag cws_src680_svgxslt01.
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 xmlns:xml="http://www.w3.org/XML/1998/namespace" from the SVG Header then everything works fine. Is there a way to avoid this behavior?
Created attachment 19548 [details] Can't opened with the filter
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.
Just for Info about the xmlns:xml prefix: It is added automatically by libxml, but it seems to be a bug in xalan.
Professional SVG export import functions is very important. Without this we can not use SVG galleries on best way.
Time is running so fast. Any news?
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...
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!!!
One more comment: This issue not depend on temlate location... OpenOffice.org 1.9.86\share\template path doesnt work like Application Data\OpenOffice.org1.9.86\user\template path...
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. Cheers, Daniel.
Windy, why are you want to leave the family of OOo? The target milestone should be 2.0, please set it...
202 votes should be enough to develop this important feature into 2.0...
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. :-) Cheers, Daniel.
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 language. http://freshmeat.net/projects/keystone/ SVG import support will be a great bonus to OOo, not to mention the Open Clip Art Libary =)
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?!
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 share/xslt/import/svg/ 3. I set up an import filter in OO: General: Filter name SVG Import Application: OpenOffice.org Draw Name of File type: SVG File extension: svg Transformation: 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?
It does not support OO 1.x. You can try it in last 1.9x version from http://download.openoffice.org/680/index.html
*** Issue 49120 has been marked as a duplicate of this issue. ***
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.
Hi,Haui You can use some xslt editors like xmlspy html-kit to edit and format the file.
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.
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.
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.
Close this issue in favor of issue 49991. :-)
*** Issue 50991 has been marked as a duplicate of this issue. ***
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.
Hello, 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 (http://uml2svg.sourceforge.net/) 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 (OpenOffice.org 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.
Created attachment 27492 [details] Possible problems with text rendering
hritcu -> Can you do something for this feature? I wuould be very glad :o))
hritcu -> Can you do something for this feature? I would be very glad :o))
Created attachment 28207 [details] Updated version of SVG import filter.
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! :-)
*** Issue 52571 has been marked as a duplicate of this issue. ***
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 FAAAAANTASTIC!
*** Issue 52843 has been marked as a duplicate of this issue. ***
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.
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 release: http://haumacher.de/svg-import/ I'm curious to hear your comments.
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...
Explendid!; I have used it with several svg files and it is runing fine :-) Thanks so much for your work Francisco Alcaraz Murcia (Spain)
larsnooden: If you don't mind a german version: http://web5.pagelist.de/ (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!
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: http://haumacher.de/svg-import/
> http://haumacher.de/svg-import/ > 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 :-(
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 functionnality...
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, Oscar
would you please keep your discussion about importance of specific ports / platforms outside IssueZilla? This has nothing to to with the current implementation. 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)
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? Scott
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: http://wiki.services.openoffice.org/twiki/bin/view/Main/SVGImportFilter 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. http://wiki.services.openoffice.org/twiki/bin/view/Main/SVGFilterSourceCode Best regards, Bernhard.
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: http://wiki.services.openoffice.org/twiki/bin/view/Main/SVGImportFilter Best regards Bernhard
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 deficiency.
Change dependency from Issue 41438 to Issue 41343 since the former seems to be a duplicate of the latter. Sorry for that.
When the new version will be available?
Till now, the SVG import filter has been downloaded more than 3000 times. Its home has slightly moved with the new wiki installation to: http://wiki.services.openoffice.org/wiki/SVG_Import_Filter 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 :-)
Just uploaded new version r2131 of the SVG import filter. If you hurry up, you can get your copy still this year: http://haumacher.de/svg-import/ 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 OpenOffice.org (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 OpenOffice.org, 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!
Why developpers don't integrate this feature in OOo ?
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.
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.
Can we at least have a ballpark date on the implementation?
There *is* an implementation, which you can grep from http://haumacher.de/svg-import/ and install with 3 clicks. The new bugfix release r2185 includes an improved coordinate system transformation, works around rounding problems that occur within OpenOffice.org after import, and fixes problems with polylines. BTW, the SVG import filter is included in the German OpenOffice.org distribution CD available from http://www.prooo-box.org/
I have integrated it into my OpenOffice.org Premium builds (like Writer2latex filter). More information is come when it is released.
-> is: I would like to integrate it like writer2latex filer: scp2/source/javafilter/module_javafilter.scp: +Module gid_Module_Optional_Javafilter_SVGImport + MOD_NAME_DESC(MODULE_OPTIONAL_JAVAFILTER_SVGIMPORT); + ParentID = gid_Module_Optional_Javafilter; + Files = ( gid_File_Lib_Xmergesync,gid_File_Jar_SVGImport,gid_File_Registry_Spool_Oo_TypeDetection_SVGImport_Types_Xcu,gid_File_Registry_Spool_Oo_TypeDetection_SVGImport_Filters_Xcu ); + 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); +End scp2/source/javafilter/file_javafilter.latex.scp +/* SVG Import Filter */ + +STD_JAR_FILE( gid_File_Jar_SVGImport, svg-import) + +File gid_File_Registry_Spool_Oo_TypeDetection_SVGImport_Types_Xcu + TXT_FILE_BODY; + Styles = (PACKED); + Dir = gid_Dir_Share_Registry_Modules_Oo_TypeDetection_Types; + Name = "/registry/spool/svg-type.xcu"; +End + +File gid_File_Registry_Spool_Oo_TypeDetection_SVGImport_Filters_Xcu + TXT_FILE_BODY; + Styles = (PACKED); + Dir = gid_Dir_Share_Registry_Modules_Oo_TypeDetection_Filter; + Name = "/registry/spool/draw_svg_Import.xcu"; +End + It can be enough, can't it?
-> kami_ : The scp code looks good. But do not forget to define the module name and module description in module_javafilter.ulf.
->is: It is ready! But I didn't want to overload this file...
->is: It is ready! But I didn't want to overload this issue...
There is a perfect implementation of SVG engine in the latest stable Firefox... Are there any way to use it?
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...
*** Issue 66964 has been marked as a duplicate of this issue. ***
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: http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2006-10.html#2006-10-02T17_14_44.htm The code: http://svn.gnome.org/viewcvs/*checkout*/ooo-build/trunk/patches/src680/svg-import.diff
JFYI, native SVG import was just accepted as a Google Summer of Code 2007 project, see http://wiki.services.openoffice.org/wiki/Summer_of_Code_2007#Draw.2FImpress:_SVG_Import_Filter
Are there any new about this topic? I am really interested in...
-> kami_ See http://blogs.sun.com/GullFOSS/tags/svg
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.
zhangweiwu try this extension: http://extensions.services.openoffice.org/project/svgimport you can read this for more detail on the external/internal import: http://wiki.services.openoffice.org/wiki/SVG Ciao Davide
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.
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?
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.
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.
FYI, we took kendy's internal implementation (http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2006-10.html#2006-10-02T17_14_44.html) a bit further: http://blog.thebehrens.net/2008/02/28/built-in-svg-import/
Woohoo! Way to go Thorsten! Looking forward to seeing your work in a stable build!
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.
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
According to Thorsten's weblog (http://blog.thebehrens.net/2008/05/30/recent-progress-on-svg-import/), import of SVG Graphics is already integrated in the most recent Go-OO release. When can we expect this feature in an OpenOffice.org release? Thank you for your work, Gerald
@gleppert: with the current state of affairs (http://www.gnome.org/~michael/blog/2007-10-08.html), that svg importer cannot be integrated with vanilla OOo currently.
@thb Thank you for your clarification on SVG import. Any news on SVG import for OpenOffice.org? I tried the go-oo.org variant of OpenOffice and indeed, SVG import works fine there. For me, this was (and still is) a clear reason to switch: OO.org 2.4 -> Go-oo.org 2.4.1 -> OO.org 3.0 -> Go-OO.org 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!
@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.
OpenOffice.org 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.
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.
@ simonbr: I would strongly doubt that since the source / origin is tainted. (IANAL) However, importing is related to embedding (#49991) http://www.openoffice.org/issues/show_bug.cgi?id=49991 Could importing SVG be a step in embedding SVG graphics, or are they same, or completely unrelated?
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) reasons. 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 :-)
@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 architecture).
Dear fellow users of OOo, holding discussions in an issue is counter-productive. Instead, please start a discussion on the discuss@ux.openoffice.org mailing list, in order to convince the UX team to recommend this issue for development.
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 priority. 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.
Agreed, simply being able to display or render SVG is enough at this stage. There are other programs available for editing.
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.
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?
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
*** Issue 109493 has been marked as a duplicate of this issue. ***
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: http://blogs.techrepublic.com.com/10things/?p=1557&tag=leftCol;post-1557
Added folks that may be able to authoritatively comment on previous question to CC.
cl->gleppert: I'm not sure how the author of that blog got his 'facts' but most of them are completely wrong.
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!).
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.
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.
I can open SVG in 3.2.1 all right. Just tell Draw to open the SVG.
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...
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.
@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 "OpenOffice.org" 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).
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.
ALG: Yes, this is done with AOO3.4.0.