Apache OpenOffice (AOO) Bugzilla – Issue 49991
Allow embedding SVG vector graphics into all documents.
Last modified: 2017-05-20 10:30:37 UTC
This is *not* a duplicate of issue 2497. Embedding (this issue) instead of importing (issue 2497) SVG vector graphics is better (as described in my lengthy post to issue 2497) and far more simple. Embedded SVG should be displayable in all OOoffice applications (like bitmap graphics), but it should not be editable. Nevertheless, there is a benefit of SVG over bitmaps, since they are resolution independent and can be rendered to each device without aliasing effects. Due to limitations in the OOdraw format, the only way of "importing" SVG 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 effect is that for non-trivial SVG images, the results obtained from importing into native OOdraw must be almost unusable for anything other than displaying. But then it's better to provide a way of perfectly displaying arbitrary embedded SVG graphics by including a third-party SVG rendering engine into OOoffice. This prevents people from destroying their SVG images by "importing" them into OOoffice.
Embedding (only displaying) would be just fine with me. Editing can wait for later. I guess most users would also only need displaying and resizing the image. The same is true for KDE/GNOME desktops where I also only need to display the SVG picture (for icons and backgrounds) and not edit it. Editing is more for the artisitc types of people. So if it is possible to include only rendering into OOo (like there is one in the latest nighlies of Firefox browser) that would be great.
*** Issue 49991 has been confirmed by votes. ***
Embedding can be a solution for Writer and Calc, this is also how Abiword works (Abi uses librsvg for rendering). I am not sure this is a good solution for Draw, wich *is* a vector editor, so users will expect it to be able do edit the images.
just voted for this Issue. Embedding is great - there are already lots of tools to create/edit SVG images. No need for OOo to do that. But embedding like PNGs etc. is important.
reassigned to wg mci -> wg: Please have a lookat this, thanks...
Reassigned.
Although I agree that the most import thing is to render the SVG files correctly, I think in the long run, OOo should be able to edit SVG graphics. Several applications can create SVG output, and thus SVG importing would increase significantly the interoperability with them. Of course I hope that the Open Document Format will be as widely supported as SVG, but we are not there yet. The problems pointed out by haui are very important. They should be discussed with the designers of the Open Document Format and taken into account in the future version of the Open Document Format. I think, it is crucial to have an almost one-by-one correspondence. Alex
Incidentally, I think the explanation haui left on issue 2497 was fantastic. Thanks to it now users understand the issue better and can have a more reasonable expectation for its resolution. I hope that other developers will do the same on other issues. A few explanations like that can go a long way to reduce frustration from users. I've added myself to the CC list of this issue and added my votes. Cheers, Daniel.
Is there a chance to get a target milestone for this feature? As I understood from haui's explanation in issue 2497 (thanks a lot!) it is much easier to embed SVG than to import it. I suggest that most of the voters for issue 2497 (230 votes!) prefer embedding SVG instead of no implementation at all - at least as a short time solution. It is an impotant feature - I'd like to see it as soon as possible! Thanks Bernhard
After reading the other thread on importing SVG, and then this one, it appears that embedding is the interim answer. However, I also agree that it isn't the optimal one since Draw is a vector editor, and doesn't have complex enough internal support to be able to handle SVG. So, like was said on the [users] list, it needs a major overhaul. Could the source code from inkscape be food for thought (Inkscape being open source), and a help in designing a better implementation for OOo? - Eric.
Eric, based on the post on issue 2497, borrowing code won't help. The problem is in the OpenDocument specification. It has to be solved by the OpenDocument Technical Committee at OASIS. I will talk to Garry about this. Maybe a future version of OpenDocument can solve the problem with SVG compatibility. Cheers, Daniel.
I just checked the OASIS spec - (page 298, see http://www.oasis-open.org/committees/download.php/12572/OpenDocument-v1.0-os.pdf) Images can be stored in arbitrary format (with a specified filter name). However, the spec recommends that vector graphics are stored as SVG and bitmaps in PNG. Thus this seems to allow the treatment of SVGs just like PNGs: embed them in the 'Pictures' sub-directory of the document and provide an <xlink:href> to it (either internal or external) and give it a new filter-type which can render SVG for direct display (like a bitmap).
I'm sorely missing import of SVG images into Writer and Calc documents. I don't want to use OOo as SVG editor - I just want to see my SVG images in Writer documents. Just wanted to add my vote :-)
Embedding SVG is an important feature and in my eyes a "must have" for OOo. I need to embed them in my presentations and writer documents. It would also be a good differentiator compared to MS. Editing of SVG is "nice to have" because SVGs can be edited with other tools so that (issue 2497) could be done later.
Just in case anybody wondered (I did): The svg issue gathered the most votes already (264): ID:votes 2497:264 allow import of SVG (Scalable Vector Graphics) 12686:101 Tabbed Document Windows 18024:82 Direction of weak characters: A new method for dealing with 30631:133 R2L enabled controls 32117:82 SQLite SDBC driver for OOo http://qa.openoffice.org/issues/buglist.cgi?issue_type=DEFECT&issue_type=ENHANCEMENT&issue_type=FEATURE&issue_type=TASK&issue_type=PATCH&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&email1=&emailtype1=exact&emailassigned_to1=1&email2=&emailtype2=exact&emailreporter2=1&issueidtype=include&issue_id=&changedin=&votes=80&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=&short_desc_type=substring&long_desc=&long_desc_type=substring&issue_file_loc=&issue_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&keywords=&keywords_type=anytokens&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Issue+Number&Submit+query=Submit+query
*** Issue 30927 has been marked as a duplicate of this issue. ***
Since openoffice.org links to openclipart.org and the entire contents of openclipart.org is SVG, I downloaded the OCAL expecting full compatibility. D'oh! And three cheers for people more clued up than I, who have started to implement the suggestions and differenciated between full support and embedded support.
changing component to "Drawing" as that's the place where the implementation would happen. Also adding my vote to the issue. :-)
Does anything happen in this issue? This can't be so difficult to implement. Koffice already supports inline SVG. When will we see this feature? Chris
Commplete editors for SVG already exists ( inkscape ) and offers more capabilities than OOo will ever bring: we juste need display and print like it's done for the other image types SVG has become a standard, it has to be used like it is. Sylvain
As mentioned by others, SVG support doesn't have to include editing capabilities, other programs to that just fine. The ability to import and place /view SVG objects within OOo documents is "all" that's needed.
The above would be true if there was an easy way to export svg's, edit them in a seperate tool and them reimport into OO while keeping placement and other attributes intact. At present it is already possible to import svg's using the SVG import extension. This gives 95% accurate imports and it is slow (java?). Even if you don't like OO Draw (which I happen to do) you can quickly and easily make small changes to the imported SVG. It seems to me we are on the last mile to 100% accurate imports. Compiled code would improve the speed a great deal.
Interesting. I would like to add something, maybe it's a strange idea, but let's see. svg is not the only graphics format OOo can't edit directly. So if I have my graphic embedded in my Writer document, there is only one way to change it later on: save the graphic via context menu, edit it externally and then reinsert it. We could make this at least a two-step process by adding an "edit graphics with..." entry. It would save the graphics and start the selected external editor. After successful editing we could use a "re-import" entry in the context menu to update the file again. We could switch the embedded graphic to a linked one when we export it and then switch back to embedded after editing is finished.
Please note that this issue is about *embedding* SVG graphics into OOo documents. *Import* of SVG graphic files (into Draw) is issue 2497. Furthermore, please note that holding discussions in issues is not 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.
I think mba is not holding a discussion but providing a solution. Note how similar it is to M$ OLE solution: - each object type can be embedded in an OLE container as the container does not need to know the contents - each object provides a server for edit (embedded edit) and open (standalone edit) - the object's server provides a preview for display and printing (bitmap, wmf or emf) - better would be: the objects server proves a rasterizer for printing and displaying (see bryancole above) For OO: - using inkscape for 'edit' (I mean editting embedded in f.i. writer) won't work as inkscape is not a OLE server - but it will work for 'open' as mba described - who needs 'edit'? Draw does only 'edit' and not 'open' which is a big frustration when trying to edit a complex, large draw object embedded in writer. Ferry
The reason why this issue has importance in my view is that there is currently no vector graphics format that can be embedded into OO documents and will display and print correctly: WMF and EMF have problems with transparency EPS displays (and converts to PDF) only as a preview image, prints only on Postsrcipt printers -- although it is industry standard! Microsoft Office is a long way ahead in these things, despite supporting also proprietary vector formats (WMF and EMF). SVG can only be imported to Draw via lossy conversion (with a beta stage extension) and embedded as Draw object. => Unlike for rasterized graphics, there is currently _no way_ to embed vector graphics (line graphs etc.) from outside of OpenOffice into documents and know that they will work correctly. I find this embarassing. As of now, the safest way is to convert to a bitmap format and then embed, which can be detrimental to image quality and/or memory requirements. Therefore, it is probably not wise to wait for a reliable SVG-to-Draw converter. Nor is it useful. OO needs to have at least one Vector graphics format that can be embedded and will produce appropriate output in all cases. Since SVG is _the_ Open Source vector format, OpenOffice should support it.
I share this point of view ! SVG has it's open source editor : inkscape. No need to internaly edit SVG in OOO.
micool, it would still be very useful to be able to export OpenOffice Draw graphics to SVG. Unless you are able to quickly recreate any complex drawing that was made in OpenOffice in Inkscape whenever you need it in SVG format.
Please note that this issue is only about *embedding* (w/o editing) of SVG graphics into OOo documents. *Import* (into Draw) is covered by issue 2497. *Export* (from Draw) is already possible. For discussions please join the discuss@ux.openoffice.org mailing list.
With embedded bitmap graphics, one can right-click on the bitmap and select "Save Graphics..." in order to export/save this embedded graphic object to a separate file. Such possibility should exist for all embedded graphic objects, be it bitmap or vector, so one should also have an option to click on an embedded SVG, select "Save Graphics..." and save that SVG drawing to a .svg file on disk.
Right olo! But after you saved it, and editted with Inkscape, you will want to reimport it. And then restore all the image properties, like position, anchor, etc. I do that all the time, even with embedded Draw objects (since you can not zoom inside Writer). And it is a pain. Ferry
I want to emphasize, that this is a very important issue. At the moment, open office does not support any standard vector format usable under Linux. Many scientific applications can output into svg or eps, but as these formats are unusable in openoffice, it is really hard to use impress for giving a talk. If you walk around in scientific institutions like CERN, half of the people are using Mac's Keynote, just because the presentations look better. I really think openoffice should make an effort to support displaying either svg or eps. I also think many of the voters for issue 2497 actually didn't mean importing but displaying, which would be the most important thing. Furthermore, it seems unlikely to me, that the svg import filter will ever support things like latex formulas. Is this really so difficult to implement? As far as I know Cairo supports displaying svg...
Inserting SVG graphics in OpenOffice documents is an essential feature. There is no other good format for inserting vector graphics in Writer documents. Windows Metafiles are badly supported in other applications and .odg is hardly supported at all in other applications. I don't see why some people insist on being able to edit the inserted graphics inside OpenOffice. I can insert JPG's in documents, yet OpenOffice does not have the editing abilities of Gimp or Photoshop. Just because OpenOffice Writer is related to a vector drawing program (OO Draw) it shouldn't mean that Writer should prevent me from inserting competing vector graphics formats!
cl->ka: I think this issue is something you are working on?
@ka: that would be nice to know indeed, especially after questions in issue 2497, and on http://wiki.services.openoffice.org/wiki/Features remained unanswered, and CWS svg100, 200 & 201 got deleted. FWIW, I had just hacked up a rough-but-working svg rendering solution for OOo: http://identi.ca/notice/35645833
A detailed communication about this topic/feature related to OOo 3.3 will be made within the next days via the official channels (Blog, Feature announcemnt etc.). Please stay tuned and please no more 'hacked up rough-but-working' features anymore! That's not the kind of feature quality I'd like to have for OOo (at least not for Vanilla OOo).
Embedding of SVG graphics for Vanilla OOo is currently in development for OOo3.3. The related CWS is ka102.
According to eis.services.openoffice.org CWS ka102 is scheduled for 3.4. instead of 3.3. If this is true, please adjust the target milestone of this issue. Thanks.
Adjusted the target to 3.4, according to the comment from 'gleppert'. FYI, although planned for 3.3 and almost completely implemented, this feature didn't make it into 3.3 for just one single reason: me, getting seriously sick about one week before code branch off and being on sick leave for about 2 and a half weeks without having the chance to finalize the last bits for this CWS. Nevertheless, this feature is now the next one to be integrated for the DEV300 baseline. After fixing the last issues for 3.3, which has the highest priority at the moment, the related CWS will be finalized/cleaned up and given to QA for testing and integration. I'd like to say sorry to anybody awaiting this feature for 3.3, but as life always tells us, shit *really* happens...
target adjusted
fixed in CWS ka102
http://download.openoffice.org/all_beta.html (linux Intel DEB - OpenOffice.org 3.4 Beta 1) I get 'Graphics filter note found' when attempting to import an SVG (Writer, Draw, Impress). Note: also tested http://download.openoffice.org/next/other.html#dev2 DEV300 (milestone DEV300m106) (linux Intel DEB) with the same results. Testing OpenOffice.org 3.4 Beta 1 on Windows XP does work. So there appears an issue with the linux version.
ka=>noop: the SVG graphic import/display capability of OOo depends on the external library librsvg (and depending ones). On Windows and Mac, those are built and shipped with OOo. On Unix systems, librsvg needs to be made available to OOo by the system admin. So, please verify, if 'librsvg' is installed on your system, either by use of your systems package manager or by providing an own build. In any case, OOo needs dynamic access to this lib during runtime in order to import and display SVG files correctly.
I do have these installed: $ apt-cache policy librsvg2-2 librsvg2-2: Installed: 2.32.0-0ubuntu1 Candidate: 2.32.0-0ubuntu1 Version table: *** 2.32.0-0ubuntu1 0 500 http://us.archive.ubuntu.com/ubuntu/ maverick/main i386 Packages 100 /var/lib/dpkg/status $ apt-cache policy librsvg2-common librsvg2-common: Installed: 2.32.0-0ubuntu1 Candidate: 2.32.0-0ubuntu1 Version table: *** 2.32.0-0ubuntu1 0 500 http://us.archive.ubuntu.com/ubuntu/ maverick/main i386 Packages 100 /var/lib/dpkg/status Available: $ apt-cache search librsvg ..snipped cairo-clock etc. librsvg2-ruby - RSVG renderer bindings for the Ruby language librsvg2-ruby1.8 - RSVG renderer bindings for the Ruby language librsvg2-ruby1.8-dbg - RSVG renderer bindings for the Ruby language librsvg2-2 - SAX-based renderer library for SVG files (runtime) librsvg2-2.0-cil-dev - CLI binding for RSVG 2.22 librsvg2-2.18-cil - CLI binding for RSVG 2.22 librsvg2-bin - command-line and graphical viewers for SVG files librsvg2-common - SAX-based renderer library for SVG files (extra runtime) librsvg2-dbg - SAX-based renderer library for SVG files (debug) librsvg2-dev - SAX-based renderer library for SVG files (development) python-rsvg - Python bindings for the RSVG library
I absolutely disagree this issue has been fixed. The initial report was clear that it was not about *importing* svg (that is, making it editable), but rather *embedding* as a non-editable image. The fix discussed above and implemented in v. 3.4 is definitely importing svg, and,for the svg drawings I have tried, this import yields barely recognizable junk. It is *not* a usable solution to include (in the sense of *embedding*) a picture-perfect vector graphics in open/libre office. Let me restate the initial aim of this bug report : It would be nice if we had the choice of just *embedding* a non-editable but perfectly rendered svg, instead destroying it upon import. There are out there very good open source solutions for rendering svg (firefox 4 for instance does a great job)... Ok, it might require quite some work to incorporate these codes, but there could be also simpler approaches. For instance eps drawings are correctly *embbeded* (and as such graphically preserved). Hence a quick hack to embbed svg would be to offer an option when opening an svg file that would silently call a utility to convert the svg to eps and embbed the resulting file...
ka=>pjoyez: reading your comment and reading the product name LibreOffice in it, I assume, that you tested this with LibreOffice, which doesn't have the current OOo solution integrated, but instead has the mentioned import/conversion to DrawingObjects with all problems, that such an import has. OOo's solutions just takes the raw SVG data as a blob and displays its content via background rendering with the librsvg library. IMO exactly what you'd like to see. Please don't ignore that there are current differences between OOo and LO, especially with new features, and with the current code donation to Apache, both products won't have so much in common in the future, I suppose, but time will tell. So, please address your problems at the right project, you are working with. If this is LO, just go to the LO mailing lists/bugtracker. OOo is a different project!
pjoyez->ka: Alright,I was indeed referring to LO 3.4, my mistake then. Thanks for pointing this and for adding this feature.
@noop @ka (comments #43-45): I just found that SVG embedding works in the latest Linux Intel DEB versions (3.4 Beta 1 and DEV300_m106) if you install librsvg2-dev. Apparently a dependency. sudo apt-get install librsvg2-dev Before installing librsvg2-dev I had the same error noop reports ("Graphics filter not found").
Inserting SVGs almost works very well, but there are currently 2 flaws that essentially makes it no better than first rasterizing an SVG to a bitmap (e.g. PNG) and inserting the bitmap. Should this be re-opened or should a new bug be opened? 1) Exporting to PDF rasterizes the SVG anyway, in the output PDF file. Insert an SVG either by Insert > Picture > From File, or drag-and-drop, and it is definitely a vector render on-screen. Export as PDF with the default settings (with PDF/A-1a not checked) and the rasterization is very obvious if you view the output PDF file (the SVG is a low-resolution bitmap; the pixels are quite large). If you check PDF/A-1a during export, it says the following: During PDF export the following problems occurred: Transparencies removed Some objects were converted to an image in order to remove transparencies, because the target PDF format does not support transparencies. Possibly better results can be achieved if you remove the transparent objects prior to exporting. And in the output PDF file it is less obvious visually, since PDF/A-1a option seems to rasterize the SVG at around 1200 dpi. But if you zoom in >1000% the pixels are visible. This is of course also reflected in the output PDF file size as the SVG has been stored as a high resolution bitmap image. My inserted SVG doesn't have any apparent transparency. I also tried creating a new simple SVG without transparency with Inkscape but it had the same problem. Maybe all SVGs include transparency, or the PDF-export doesn't really know what it's talking about. 2) Inserting an SVG with "link" to file option does not work properly. (Insert > Picture > From File, and check the Link check-box). The image appears on-screen while you still have the document open. If you either close the document and open it again, do File > Page Preview, Print, or Export to PDF, the image disappears and is replaced with a bounding box with "Read error: path/to/file" displayed inside in a flickering red font. Linking to files is very useful when you want to update inserted images. This is not as critical as #1 but it should work the same way as linked PNGs (properly). Basically, embedded SVGs can only be displayed in OpenOffice, so as it is we still cannot produce high-quality (with vector images) PDFs with OpenOffice. (Tested on latest versions in Linux and in XP, 2.4 beta 1 and DEV300_m106)
Created attachment 76734 [details] ODT file with embedded SVG created and saved by Abiword. Abiword opens it and displays it fine, and even keeps the SVG as vector in Export to PDF. OpenOffice does not show the embedded SVG Final comment for today :) Tried Abiword since comment #3 mentioned it can handle inserted SVGs. It is indeed able to embed SVGs (no link option) and it properly renders them as vectors when exporting to PDF (of course, Abiword is otherwise missing a number of critical features of OpenOffice such as captions, bibliography, etc etc). Incidentally, Abiword also can save a .odt file with embedded SVG and read it back in. Opening that .odt in OpenOffice gives a "Read error" message inside a placeholder box where the SVG should be. Attached is the .odt file.
Created attachment 76735 [details] Imported svg Re comment #49: installing librsvg2-dev does indeed resolve the import filter issue - I no longer get the 'Graphics filter not found'. Thanks! Import of an SVG in OOo-dev 3.4.0 DEV300m106 (Build:9582) into draw renders the svg properly (see attached screenshot). However, as mentioned in comment #50, the imported svg is imported as a graphic rather than an svg and therefore can't be broken (grouping) or edited. The result is the same as importing an eps. But, it does accomplish what this bug (comment #1) requests.
(In reply to comment #52) > Import of an SVG in OOo-dev 3.4.0 DEV300m106 (Build:9582) into draw renders the > svg properly (see attached screenshot). However, as mentioned in comment #50, > the imported svg is imported as a graphic rather than an svg and therefore > can't be broken (grouping) or edited. The result is the same as importing an > eps. But, it does accomplish what this bug (comment #1) requests. Indeed, this bug fix / feature is not about being able to ungroup/edit the SVG once embedded (that would be "importing" the SVG). Just to re-iterate the important issue remaining described in comment #50: While OpenOffice now can successfully embed an SVG as a vector object (zoom in, or save the .odt and unzip it and look at its contents, there will be an svg file in a subfolder), unfortunately it becomes rasterized when exporting the document to PDF. (And linked embedded SVGs do not continue working when re-loading the document.)