Issue 97319 - Mechanism to edit embedded non-native formats
Summary: Mechanism to edit embedded non-native formats
Status: CONFIRMED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: DEV300m35
Hardware: All Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks: 97765
  Show dependency tree
 
Reported: 2008-12-16 16:29 UTC by caolanm
Modified: 2017-05-20 10:55 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description caolanm 2008-12-16 16:29:26 UTC
Long ago we put in the feature to convert at load time embedded Microsoft Office
formats and convert them to our own so that double-clicking them could allow
them to be edited. (tools->options->load/save->microsoft office). Then later we
defaulted it off because it was slowing down the load of documents with a lot of
objects in them.

How difficult do you think it would be to instead somehow register OOo itself as
the handler for editing embedded Microsoft Office objects (esp. under unix).
That way we could get the best of both worlds. Fast no-conversion load, then the
ability to double-click to edit, which is probably the feature we should have
tried to implement the first time
Comment 1 mikhail.voytenko 2008-12-18 10:56:16 UTC
Yes, good point. The same should already happen on import of embedded objects of
OOXML format from MS. The objects are converted to OOo objects on demand, and
the implementation is already prepared to do the same for binary MSOLE objects.
So I see no problem to include this feature in one of the next 3.x releases.

The only thing that have to be done for this is a new UI design around the
feature. The current conversion flags are related to the container document
storing/loading, we need additional flags related to the objects
storing/loading, that would allow to avoid unnecessary conversion, the object
would store itself in requested format from the beginning.
Comment 2 Mathias_Bauer 2008-12-18 14:20:02 UTC
AFAIR we already had decided that we want to have "conversion on demand" for MS
objects. And also AFAIR we decided that the object should be stored in ODF
format only when the object is modified or if the user asks for it explicitly.

So we still need the "save" flags. We could see the "load" flags as a choice for
the user whether conversion should be done on loading or saving (in case (s)he
wants the conversion also for non-modified objects). 

Besides that IMHO one load flag and one save flag is enough.
Comment 3 mikhail.voytenko 2008-12-18 15:25:48 UTC
If I remember the discussion correctly, the following decisions should be made
based on the configuration:

- should editing of MS-format documents in OOo be disabled
- store the edited MS-objects in OOo or MS-format after object editing, so that
MS-objects stay MS-objects after editing
- convert untouched MS-objects to OOo objects
- export OOo embedded objects on export to MSOffice format ( equal to the
current "save" flag )

Of course if we always allow to edit the MS-format objects and store the edited
object in OOo format, we do not need flags to represent the fist two choices. In
this case two flags are enough. But even in this case, the UI change is
necessary, since the behavior will differ from the current specification of the
flags.
Comment 4 Mathias_Bauer 2008-12-25 23:36:53 UTC
After some more thoughts:

When a document containing embedded non-ODF objects is loaded, the objects
should stay unconverted by default. When a user edits and modifies such an
object, it should be stored in ODF by default. When the user saves the document
as ODF, all objects should stay as they are (converted or unconverted) by
default. This will give the best performance.

The user can ask for converting all objects into the "target format". This
means: if the document will be saved to an ODF format, all objects will be
converted to an ODF format also (if possible). If the document is saved to a
Microsoft format, all objects will be converted to a microsoft format (if
possible). 

This can be one or two flags in "Tools-Options". We should remove the existing
ones and also throw out the differentiation for the different applications. I
don't think that we need a third flag to automatically convert all objects at
load time. 
Comment 5 Marcus 2017-05-20 10:55:12 UTC
Reset assigne to the default "issues@openoffice.apache.org".