incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chengjh <chen...@apache.org>
Subject Re: [Review|Discussion]For Ideas and Comments on the Vision of Writer's Track Changes Improvement
Date Tue, 10 Jul 2012 07:14:18 GMT
Oliver,I can not access  http://www.ooocon.org/  to get your presentation
for 2010 conf..And I am not authorized to access
http://people.apache.org/~orw/**210-209-1-PB.pdf<http://people.apache.org/~orw/210-209-1-PB.pdf>
either..Could you please send your presentation to me?thanks.

On Mon, Jul 9, 2012 at 11:25 PM, Oliver-Rainer Wittmann <
orwittmann@googlemail.com> wrote:

> Hi,
>
>
> 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 <
>> dennis.hamilton@acm.org
>>
>>> 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.
>
> [1] http://people.apache.org/~orw/**210-209-1-PB.pdf<http://people.apache.org/~orw/210-209-1-PB.pdf>
>
>
> Best regards, Oliver.
>
>
>
>
>>
>>> -----Original Message-----
>>> From: chengjh [mailto:chengjh@apache.org]
>>> Sent: Tuesday, July 03, 2012 00:25
>>> To: ooo-dev@incubator.apache.org; dennis.hamilton@acm.org
>>> 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 <
>>> dennis.hamilton@acm.org
>>>
>>>> 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
>>>
>>> http://wiki.services.**openoffice.org/wiki/Writer/**
>>> ToDo/TrackChanges#Design_**Principles<http://wiki.services.openoffice.org/wiki/Writer/ToDo/TrackChanges#Design_Principles>
>>> 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.
>>>
>>> [ ... ]
>>>
>>>
>>>
>>
>>
>


-- 

Best Regards,Jianhong Cheng

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message