It is possible to save a graphics file (ODG) from Impress using the Save as dialog. However, the resulting file is opened with Impress again instead of Draw Steps 1) Create a ODP file using Impress 2) Save as ODG from File -> Save as command 3) Reopen making from the "recent files" dropdown Result: The ODG file is opened using Impress instead of Draw Expected Since one have saved a ODG, the file should be opened with Draw. Workaround a) Extract the zipfile, b) change the content of the file "mimetype" from "application/vnd.oasis.opendocument.presentation" to application/vnd.oasis.opendocument.graphics". c) Rezip the file and change the extention to ODG d) Open with LibO. It will argue that the file is damaged, but it can repair it. Workaround 2 a')Save your file as FODP b')Open that file with a text processor with UTF-8 encoding c')Look for the string "office:mimetype" and replace "presentation" with "graphics" d') Save that file with the extension FODG e') Open with LibO: Draw will be the application used. Note: I have selected the oldest version in which I could reproduce the bug. However, I suspect that this has been inhereted from OOo. OS: Kubuntu Linux x64
(In reply to Francisco from comment #0) > It is possible to save a graphics file (ODG) from Impress using the Save as > dialog. No, it isn't. The resulting file is actually a presentation with a wrong file extension. I believe this "ODF Drawing (Impress)" entry in the file dialog is mainly intended for file open, but shown also in the file save dialog by mistake. > However, the resulting file is opened with Impress again instead of > Draw Right, because it's a presentation... > Workaround > a) Extract the zipfile, > b) change the content of the file "mimetype" from > "application/vnd.oasis.opendocument.presentation" to > application/vnd.oasis.opendocument.graphics". This works by accident. When LO gets a broken file, and the user confirms repairing, it assumes that the file extension is correct, and forces the associated app to open that file... Actually there is much easier way - just change the extension of a presentation to odg, and in the LO open file dialog, explicitly choose the "ODF Drawing" filter. Same would work the other way (odg->odp).
Hi Maxim, thanks for your advice. I understand that workaround 1 it's working by accident. But what about #2? As far as I understand, Impress and Draw are very similar, and if the content inside the presentation are only drawings with a specific page setup, a real export from ODP to ODG, (not only a change in the file extension) should be possible. I guess that in that case, the export should keep all drawings and its styles, page setup, etc., while removing all animations and slide transition information, and update the mimetype. So, is this a bug?
(In reply to Francisco from comment #2) > Hi Maxim, thanks for your advice. I understand that workaround 1 it's > working by accident. But what about #2? #2 works for the same reason that #1 works eventually. By changing office:mimetype you're making the type-detection code think it's a drawing, thus feeding the file to the wrong filter. > As far as I understand, Impress and Draw are very similar, and if the > content inside the presentation are only drawings with a specific page > setup, a real export from ODP to ODG, (not only a change in the file > extension) should be possible. Right. But why do you need export, when there is apparently a working import, and is only a matter of choosing the filter in the open dialog?
(In reply to Maxim Monastirsky from comment #3) > Right. But why do you need export, when there is apparently a working > import, and is only a matter of choosing the filter in the open dialog? I never knew that that was there. I mean, I knew that I could filter the file from the Open Dialog, but I never had a clue that if I used the filter the import would work. When I filled this report, I though that when doing what you suggested, the result would be the same: Impress is opened instead of Draw. But even now that I know that I can use your workaround, let me express this from a simple user perspective: John exported a ODG file to make use of it another day. A few days later he doubleclicked the ODG file he exported, expecting to be able to open it with a drawing tool like Draw. However, Impress is opened if using LibreOffice. And it's not possible to open this file with, for example, Calligra Karbon. That's why I think it's a bug, even if I already know how to handle it :-) So, IMHO, either LibreOffice shouldn't offer incomplete options, or a real export option ODP -> ODG should be done. I guess the first option is the easiest solution, but not sure if it's the best: cutting options instead of improving them (or finishing them actually) doesn't sound good for me. Also, bug 53391 is about the same but the opposite. So, solving one could pave the way to solve the other. Regards, Francisco.
(In reply to Francisco from comment #2) >... > So, is this a bug? No this can already be done, but the conversion from ODP -> to SDraw meta is done with *import* filters, and not by the SImpress export filters. So, as Maxim notes simply rename the ODP archive and then force filter import into Draw. When the ODP archive opens into Draw--it will be reformatted to some extent (slide styles and transitions have no equivalent) the Drawing can then be saved and all the import converted draw objects will be filter exported into an ODG archive. And I believe you have to take the import through meta using the GUI. A headless command line conversion with "soffice --headless -convert-to odg:"draw8" <filename>.odp" will only rename the presentation extension. There may be a use for a more controlled/feature specific import filter, i.e. a "draw8_impress8" filter, which might then support the CLI convert-to syntax and perhaps could improve fidelity of Text box and font selection on the resulting Draw pages. @Maxim, would a more specific impress8 -> draw8 filter be useful? Otherwise this is a WFM.
(In reply to Francisco from comment #4) > But even now that I know that I can use your workaround, let me express this > from a simple user perspective: John exported a ODG file to make use of it > another day. A few days later he doubleclicked the ODG file he exported, > expecting to be able to open it with a drawing tool like Draw. However, > Impress is opened if using LibreOffice. And it's not possible to open this > file with, for example, Calligra Karbon. That's why I think it's a bug, even > if I already know how to handle it :-) > > So, IMHO, either LibreOffice shouldn't offer incomplete options, Yes, I agree on that part. I already said in comment 1 that "I believe this "ODF Drawing (Impress)" entry in the file dialog is mainly intended for file open, but shown also in the file save dialog by mistake." (In reply to V Stuart Foote from comment #5) > No this can already be done, but the conversion from ODP -> to SDraw meta is > done with *import* filters, and not by the SImpress export filters. So, as > Maxim notes simply rename the ODP archive and then force filter import into > Draw. > @Maxim, would a more specific impress8 -> draw8 filter be useful? Could be. I tested now some complex presentations, and they don't look good when forced into Draw (e.g. some problems with content from master pages). For comparison Insert->File... into Draw gives much better results. So I believe there is still some work should be done to improve the odp->odg scenario.
I've encountered this bug in previous versions of LO, and it's still happening in 7.3.7.2 (x64) on Windows. I don't know why this bug was closed; I reopened it because: 1. A workaround is not a fix. 2. The first workaround is too technical, and too many steps. 3. The second workaround is too obscure because: a) the filter in the Open Dialog is (or should be) just for restricting what files are shown in the dialog. b) the filter popup menu has way too many items (≈180), the first item that looks right ("Drawings (*.odg, *.otg, ...") doesn't work (it opens in Impress), and the item that does work ("ODF Drawing (*.odg))") is two-thirds of the way down the long list of items. If the filter provides an import operation, then the dialog should explicitly say so. A better solution would be to have a separate "Import" item in the File menu.
So, "Save as ODF Drawing (.odg)" doesn't actually export to a different format. Regardless of anything else anyone might do - it should therefore not appear as a format option in the File | Save As... dialog. Very simple. All other discussion is interesting/important, but should not get in the way of fixing this bug.
(In reply to Maxim Monastirsky from comment #6) > I tested now some complex presentations, and they don't look good > when forced into Draw (e.g. some problems with content from master pages). > For comparison Insert->File... into Draw gives much better results. So I > believe there is still some work should be done to improve the odp->odg > scenario. Is there an open bug about that? If not, please open it and attach ODPs which don't get imported well enough.
With the rephrased title, I believe we can mark this NEW.
OK so is the action simply to remove the incorrect Save-as listing for the "OpenDocument Drawing (Impress) (.odg)" import filter. Or do we need to formulate a proper export filter to convert ODF Presentation to ODF Drawing? Also, the UNO .uno:ImportFromFile does handle slides from an ODF Presentation reasonably well--it is just cumbersome to configure via customize and use effectively. While removing the Save-as entry fixes a bug in the UI, a proper filter seems desirable for ODP --> ODG conversions seems worth enhancement. And if I understand our convention, such conversion would be a Save-as and not an Export action.
(In reply to V Stuart Foote from comment #11) > OK so is the action simply to remove the incorrect Save-as listing for the > "OpenDocument Drawing (Impress) (.odg)" import filter. Yes. > Or do we need to formulate a proper export filter to convert ODF > Presentation to ODF Drawing? That is now a separate bug: 156195 , so please comment there. If that bug is resolved first, then this one becomes irrelevant; if this one is resolved first, then that one will involve reintroduction of the export format choice.
Bug 156195 requests an export filter and kind of duplicates the request here. We usually keep the older request but in this case the other ticket is more clear. Resolving as Moved. I still don't understand why you need to export a presentation or a selection as drawing object. Would be nice to add some clear use case on the other ticket.
(In reply to Heiko Tietze from comment #13) > Bug 156195 requests an export filter and kind of duplicates the request > here. It really doesn't duplicate this one, and I made that quite explicit... If bug 156195 is accepted as NEW, then the significance of resolving this one is reduced to the interim period until that one is resolved. But - who knows how long that will take? Bugs can remain NEW for years. This one, however, should only take a few minutes. to someone familiar with the code.
Can we just remove impress8_draw from isODFFormat() in cui/source/options/optsave.cxx?