Current master stores svg images cloaked as .svm metafiles, with a preview bitmap. That's not very interoperable - if possible, store native svg instead.
Fix pushed to master. There were two things:
Fix fdo#41995 fallout - recognize .svg in odf container
Seems the graphic load code is stupid and not using the path name /
file extension to guess file type, but only "magic byte" detection.
Giving filter framework the path now, so that .svg actually loads.
Fix fdo#41995 - true embedding of svg images.
Previously, svg images were always wrapped as .svm metafiles with
a preview graphic. Sucks for interop - so now, we save true svgs
at least for bleeding edge extended odf1.2
So what LibreOffice will do, starting with 3.5, is by default store
true .svg files. Those should load fine in recent 3.4 versions as
well, the first fix is pending review there. They will *not* load in
OOo versions, and, unless we do another release there, for LibreOffice
I am not sure whether I understand all details. Do we talk about documents with picture.svg inserted by 'Insert -> Ficture -> From file?'
(In reply to comment #2)
> I am not sure whether I understand all details. Do we talk about documents with
> picture.svg inserted by 'Insert -> Ficture -> From file?'
Verified with Server installation of MSVC Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: a653e50-1f92ab1-3bd0388]" Win-x86@6 - 111128). It seems my Master with what I tested before Comment 2 was the last one with the bug :-/
It works for me with 3.5rc1 on RHEL6 x86_64. Files created using asciidoc-odf look fine when opened with LibreOffice !
Thanks for fixing this !
Since this seems to be the only change between 3.4.3 and 3.4.4 with respect to SVG handling, I wonder whether this might be the cause of the following bug: