incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver-Rainer Wittmann <>
Subject Re: [Review|Discussion]For Ideas and Comments on the Vision of Writer's Track Changes Improvement
Date Mon, 09 Jul 2012 15:25:21 GMT

On 04.07.2012 04:41, chengjh wrote:
> Hi Dennis,I appreciate your questions,they are significant areas we have to
> take carefully.Thanks.
> On Wed, Jul 4, 2012 at 12:36 AM, Dennis E. Hamilton <
>> wrote:
>> I have questions about the way that the improvements are intended to be
>> extensions to the ODF format.
>> I understand from what is said that improvements are introduced into the
>> ODF document in a way that they will be ignored by older implementations
>> and other implementations that are unaware of them.  The intention is to
>> map to and from .doc in a reliable manner.
>   1. How are the extensions introduced such that conforming ODF consumers
>> will ignore them properly?  Will users be able to turn off the improvements
>> in order to produce conforming ODF documents?
>> a)That's a good question.Because current ODF formats on Track Changes are
> limited,that means only limited capabilities are able to be supported. In
> order to achieve our goal to improve the fidelity with MS Word, we have to
> extend Track Changes ODF formats and propose to OASIS ODF to become
> standard at the end.Thus,the compatibility with previous releases will be a
> challenging job.Our strategy is that the current import/export code logic
> on Track Changes will be kept to ensure the same supported change records
> defined in ODF 1.1/1.2 as before in our improved solution.If
> possible,the extended
> parts will be implemented with another code logic,not mixed, to ensure
> these parts will not be recognized by previous releases.
> b)And also,it seems a good idea to provide an option item in
> "Tools->Options...->Writer->Compatibility" to turn on/off the
> improvements.Thanks.

This can be already handled in general.
As mentioned in my presentation at OOoCon 2010 (especially slide 14ff) [1] we 
already have the ODF format version field. On this field we can depend our (not 
yet in ODF available) features//enhancements/improvements/...

>>   2. Will ignoring the extensions result in an usable conforming ODF
>> document and will round-trip return to the producer of the extensions be
>> tolerable.  Should there be warning when an user makes changes that rely on
>> the improvements in a document that was not produced by an
>> improvement-aware implementation?
> c) We should avoid to generate un-usable ODF document,otherwise,the design
> should have problem..
> d) I don't think it necessary to give warning message to end users when
> saving changes records with our improvements..I think it better for an
> application to enable a mechanism to provide warning message to end users
> when identifying un-recognized info.
>>   3. How are the improvement extensions to the ODF format being made known
>> so that other consumers of ODF can support them either partially or
>> completely to provide a smoother experience in support of their users and
>> in providing interoperability?
> e)Finally,our improvements on the ODF formats on Track Changes will be
> proposed and taken as OASIS ODF standards.

In general I think we should align our change tracking enhancements with the 
work currently going on in the ODF TC regarding change tracking. The work in the 
ODF TC should more or less guide how we represent/express our change tracking 
enhancements in ODF.


Best regards, Oliver.

>> -----Original Message-----
>> From: chengjh []
>> Sent: Tuesday, July 03, 2012 00:25
>> To:;
>> Subject: Re: [Review|Discussion]For Ideas and Comments on the Vision of
>> Writer's Track Changes Improvement
>> Hi Dennis,
>> Thanks for your feedback.Please say my a),b),c) and d).
>> On Tue, Jul 3, 2012 at 12:16 PM, Dennis E. Hamilton <
>>> wrote:
>> [ ... ]
>>> Because of this, it is important to understand how your proposed Track
>>> Changes Improvement will be reflect in the ODF 1.2 documents consumed and
>>> produced by Apache OpenOffice at this time.  That is, what needs to be
>> done
>>> in the format, if anything, and how is interoperable communication of
>> that
>>> handled in the persistent document?
>> b) One of the significant principles of the improvement is to keep
>> compatibility
>> with
>> previous releases of AOO/Symphony in order to ensure the persistent
>> document. The new formats saved in the improvement will be lost when being
>> launched into old versions' AOO/Symphony.
>> [ ... ]

View raw message