Created attachment 55470 [details] Example, imports as objects in 3.4.4, as an image in 3.4.5b2 3.4.4 release could open the attached SVG file and this would create a bunch of objects in the drawing. It didn't do a great job, there were lots of errors, but at least they were still objects. 3.4.5b2 renders the same file beautifully (one glitch, a large stray rectangle) but "renders" is the word, since what it imports is an image, not a collection of objects. There are no "convert" options to return it to a set of objects. Hopefully this is not intentional in 3.5.0. It is important that LODraw import the SVG so that the objects are still there.
Note, this was with Insert->Picture->from file. Both 3.4.4 and 3.4.5b2 give a pop up: General Error: General input/output error. when File -> Open (select SVG file) is attempted.
Not reproducible, reporter compares results of 'File -> Open' (what imports the picture and converts it to a .odg) with results of 'Insert -> Picture from File' (what inserts a complete picture, elements can not be edited. Concerning the other problems (General Error, differs from original viewing) other bugs already have been submitted. So INVALID @mathog <http://wiki.documentfoundation.org/BugReport#General_information> item 4
Not valid? Under 3.4.4 insert ->picture -> from file does: open SVG and import as objects Under 3.5.0b2 insert->picture->from file does: open SVG and import as an uneditable image The behavior is completely different. Either it is a bug or a change in design. If the latter, why that change, and where is it documented? (It isn't in the release notes, as far as I can tell.) Every drawing program that I can think of with a similar "open picture from file" option acts on SVG, cgm, etc. by importing them as objects, not as a bitmap. If the file was imported as objects it could always then be exported as a bitmap, but the inverse operation isn't possible. So the behavior in 3.5.0b2 is a loss of function. "File -> open" on SVG files is so unreliable that I gave up using it under 3.4.4. 3.5.0b2 is the same. It only works on the simplest of drawings, and when it fails there is never a clue why. Either nothing comes in, or the general error results. Very strange that under 3.4.4 "insert->picture->from file" will work (perhaps not well, but at least it always did something) when "file->open" does not. One would assume they use the same code.
Due to mathog's objection I did some further research and found indications for a real problem. Comparing behavior with WIN 3.4.5 and 3.5.0Beta I compared "LibreOffice 3.4.5 RC2 - WIN7 Home Premium (64bit) German UI [Build ID: OOO340m1 (Build:502)]" to Parallel Dev-Installation of "LibreOffice 3.5.0 Beta2- WIN7 Home Premium (64bit) German UI [Build-ID : 8589e48-760cc4d-f39cf3d-1b2857e-60db978] Common behavior: Menu 'Insert -> Picture from file' for reporters sample into a new blank DRAW document shows a single picture that behaves more or less as a pixelpicture.png Different behavior: Context menu in 3.4.5 after right click on the inserted picture shows an item "Break" between 'Convert' and 'Description', additionally menu 'Modify -> Break' is active. All the same for a WMF I tested. In 3.5.0Beta the context menu Item for the SVG is missing, additionally menu 'Modify -> Break' is inactive (greyed out). For an inserted WMFpicture all those items exist, are active and work as expected. OOo 3.4 has the same handicap. Old problem, I already see that with Master from July. @Thorsten: Can you check whether there is any intention for the 3.5 behavior? Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
One more experience: Creating a LibO350Beta2.odg with Insert -> Picture -> reporterssample.svg, saving/closing it and reopening it with LibO 3.4.5, 'Break' works as expected in 3.4.5
Yes, this is intended - 3.5 trades much better svg rendering fidelity in for internal vector representation (as we had for 3.3/3.4). There are ways around that, e.g. loading the svg into Draw as a document (and potentially what bug 43991 talks about).
This is a very unfortunate decision. Like most end users I have absolutely no need for another SVG renderer - Firefox and every other browser works just fine for that. If a bitmap of an SVG is needed just open it in a browser and then grab a screen shot. Conversely, I really do need to be able to import drawings stored as SVG so that they can be further modified. If I wanted a bitmap, why would I have chosen to store the drawing as an SVG??? By the same logic LODraw should import cgm, wmf, and emf to bitmaps too. (Please don't tell me that 3.5.0 will do that as well!) Consequently this change to 3.5.0 gives me nothing I didn't already have, and loses something important. The thing it loses is the ability to import SVG (most of the time) into LODraw. This is because SVG open is highly problematic. The majority of SVG files I have tried with 3.4.4 release would not "open", but could be inserted. These files mostly also fail to "open" with 3.5.0b2. Open seems to only handle relatively simple SVG files well, and it handles output from Inkscape in particular, very poorly. Not that it does the wrong thing so much as that it just fails to import altogether. With insert no longer importing objects, the net result is that 3.5.0b2 is for all intents and purposes incapable of importing many (most?) SVG files as objects. I would also argue that changing Insert picture from SVG to result in a bitmap is a poor design choice since it converts an object oriented file type to a bitmap. From the end user's perspective, that is a bug, not a feature, no matter how accurate the rendering. If the user wanted that information as a bitmap, they would have exported it that way from the drawing program, rather than as an SVG.
(In reply to comment #7) > I would also argue that changing Insert picture from SVG to result in a bitmap > is a poor design choice since it converts an object oriented file type to a > bitmap. > See my comment in bug 37072 - this is *not* equivalent to simply storing a bitmap. Beyond that, a more promising way forward is to encourage people to improve e.g. the import via File->Open - if you don't want to engage yourself, your email address suggests you may have access to a pool of talented people that may? ;)
This is fixed with Armin's new svg importer for 4.0.0