Issue 49991 - Allow embedding SVG vector graphics into all documents.
Summary: Allow embedding SVG vector graphics into all documents.
Alias: None
Product: Draw
Classification: Application
Component: code (show other issues)
Version: OOo 2.0
Hardware: All All
: P3 Trivial with 200 votes (vote)
Target Milestone: 3.4.1
Assignee: ooo
QA Contact: issues@graphics
: 30927 (view as issue list)
Depends on:
Reported: 2005-05-28 18:15 UTC by haui
Modified: 2017-05-20 10:30 UTC (History)
40 users (show)

See Also:
Issue Type: FEATURE
Latest Confirmation in: ---
Developer Difficulty: ---

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 (32.69 KB, application/vnd.oasis.opendocument.text)
2011-07-29 13:45 UTC, christoph.graves
no flags Details
Imported svg (129.17 KB, image/png)
2011-07-29 17:18 UTC, noop
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description haui 2005-05-28 18:15:18 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.
Comment 1 jlp 2005-05-29 00:09:26 UTC
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.
Comment 2 sardisson 2005-05-29 04:29:13 UTC
*** Issue 49991 has been confirmed by votes. ***
Comment 3 nicu_ooo 2005-05-29 11:38:32 UTC
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.
Comment 4 ansorg 2005-05-29 15:24:53 UTC
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.
Comment 5 mci 2005-05-30 11:50:34 UTC
reassigned to wg

mci -> wg:

Please have a lookat this, thanks...
Comment 6 wolframgarten 2005-05-30 11:55:06 UTC
Comment 7 abarth2 2005-05-31 16:07:35 UTC
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. 

Comment 8 dcarrera 2005-06-02 06:38:54 UTC
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.

Comment 9 bernhard 2005-06-19 04:02:48 UTC
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!

Comment 10 ecjb1969 2005-06-22 16:24:03 UTC
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.
Comment 11 dcarrera 2005-06-22 20:03:28 UTC
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.

Comment 12 bryancole 2005-06-23 10:25:29 UTC
I just checked the OASIS spec -

(page 298, see

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

Comment 13 vitko 2005-07-13 11:55:03 UTC
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

Just wanted to add my vote :-) 
Comment 14 auberger 2005-07-27 20:17:06 UTC
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. 
Comment 16 stp 2006-03-10 08:04:48 UTC
*** Issue 30927 has been marked as a duplicate of this issue. ***
Comment 17 daveybops 2006-11-06 19:58:13 UTC
Since links to and the entire contents of 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.
Comment 18 Mathias_Bauer 2006-12-07 12:34:19 UTC
changing component to "Drawing" as that's the place where the implementation
would happen. Also adding my vote to the issue. :-)
Comment 19 calestyo 2007-09-10 18:30:15 UTC
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?

Comment 20 calestyo 2007-09-10 18:41:40 UTC
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?

Comment 21 micool 2008-09-19 11:20:35 UTC
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.

Comment 22 lars.nooden 2008-09-19 13:45:14 UTC
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.
Comment 23 ftoth 2008-09-19 15:34:28 UTC
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.

Comment 24 Mathias_Bauer 2008-09-19 15:57:02 UTC
Interesting. I would like to add something, maybe it's a strange idea, but let's

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.

Comment 25 mbayer 2008-09-19 16:00:48 UTC
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 mailing
list, in order to convince the UX team to recommend this issue for development.
Comment 26 ftoth 2009-01-24 12:27:27 UTC
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.

Comment 27 zak_mckracken 2009-02-11 13:44:37 UTC
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.
Comment 28 micool 2009-02-17 09:58:38 UTC
I share this point of view !
SVG has it's open source editor : inkscape. No need to internaly edit SVG in OOO.
Comment 29 olo 2009-02-17 11:47:19 UTC
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.
Comment 30 mbayer 2009-02-17 11:56:11 UTC
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 mailing list.
Comment 31 olo 2009-02-23 14:22:09 UTC
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.
Comment 32 ftoth 2009-02-23 16:02:24 UTC
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.

Comment 33 marcusantonius 2009-11-23 21:29:27 UTC
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

Is this really so difficult to implement? As far as I know Cairo supports
displaying svg...
Comment 34 asw20pilot 2010-03-05 14:34:18 UTC
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!
Comment 35 clippka 2010-06-10 14:44:14 UTC
cl->ka: I think this issue is something you are working on?
Comment 36 thb 2010-06-10 21:31:52 UTC
@ka: that would be nice to know indeed, especially after questions in issue
2497, and on remained
unanswered, and CWS svg100, 200 & 201 got deleted. FWIW, I had just hacked up a
rough-but-working svg rendering solution for OOo:
Comment 37 ooo 2010-06-11 04:41:59 UTC
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).
Comment 38 ooo 2010-06-17 09:04:45 UTC
Embedding of SVG graphics for Vanilla OOo is currently in development for OOo3.3. 
The related CWS is ka102.
Comment 39 gleppert 2010-08-01 08:53:26 UTC
According to CWS ka102 is scheduled for 3.4. instead
of 3.3. If this is true, please adjust the target milestone of this issue. Thanks.
Comment 40 ooo 2010-08-16 21:05:15 UTC
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...
Comment 41 ooo 2010-08-16 21:20:06 UTC
target adjusted
Comment 42 ooo 2011-02-15 05:24:41 UTC
fixed in CWS ka102
Comment 43 noop 2011-06-09 17:27:44 UTC
(linux Intel DEB - 3.4 Beta 1)
I get 'Graphics filter note found' when attempting to import
an SVG (Writer, Draw, Impress). Note: also tested
DEV300 (milestone DEV300m106) (linux Intel DEB) with the same results.

Testing 3.4 Beta 1 on Windows XP does work. So there appears an issue with the linux version.
Comment 44 ooo 2011-06-09 17:39:54 UTC
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.
Comment 45 noop 2011-06-10 23:04:05 UTC
I do have these installed:
$ apt-cache policy librsvg2-2
  Installed: 2.32.0-0ubuntu1
  Candidate: 2.32.0-0ubuntu1
  Version table:
 *** 2.32.0-0ubuntu1 0
        500 maverick/main i386 Packages
        100 /var/lib/dpkg/status

$ apt-cache policy librsvg2-common
  Installed: 2.32.0-0ubuntu1
  Candidate: 2.32.0-0ubuntu1
  Version table:
 *** 2.32.0-0ubuntu1 0
        500 maverick/main i386 Packages
        100 /var/lib/dpkg/status

$ 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
Comment 46 pjoyez 2011-06-11 10:20:53 UTC
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...
Comment 47 ooo 2011-06-11 19:19:17 UTC
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!
Comment 48 pjoyez 2011-06-12 06:00:09 UTC
pjoyez->ka: Alright,I was indeed referring to LO 3.4, my mistake then. Thanks for pointing this and for adding this feature.
Comment 49 christoph.graves 2011-07-29 10:44:38 UTC
@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").
Comment 50 christoph.graves 2011-07-29 12:08:51 UTC
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)
Comment 51 christoph.graves 2011-07-29 13:45:55 UTC
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.
Comment 52 noop 2011-07-29 17:18:32 UTC
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.
Comment 53 christoph.graves 2011-08-03 16:08:41 UTC
(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.)