[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-collab] Generic Change Tracking, example 6.4.2 thelatter and canonicalization of text:style-name
On Sun, 2011-04-10 at 20:55 -0600, monkeyiq wrote: > Hi, > While hacking away at abiword and the generic change tracking > proposal, I hit upon the example 6.4.2 of the generic spec. I had > earmarked this example as one that presented a fair impedance mismatch > between the internal abiword tracking data model and the proposed > serialization to ODT+GCT. While the delete-leaving-content construct > is very powerful, perhaps text:style-name changes are an example use > of this GCT construct which is unnecessarily complex. > > I propose a slightly different serialization for text:style-name at > the end of this mail. There are likely some cases which have been > considered by the spec makers which will break my serialization for > applications treating files as plain ODT? The main downside that I can > see with my plan is that applications which do not know about GCT will > have to parse and process each nesting text:span/text:style-name for > older revisions when loading such a document. > > The example 6.4.2 extends an embolding to include an extra word at the > start of the block and remove a single word at the end. Using rNo > where N is the revision number, and o is the style operation > (b=bold,i=italic) one gets the following. Bold and Italic should > appear as one would see in revision3 if html email is rendered as > expected. > > Here is some <r3b>text </r3b><r1b>where the <r2i>decoration</r2i> is > <r3n>changed<r3n></r1b> several times. > > Note that this means that the word "changed" is now in normal text but > was bold in revision 1. The proposal serializes this as the following: > > <text:p> > Here is some > <text:span delta:insertion-type='insert-around-content' > delta:insertion-change-idref='ct2' text:style-name="bold-style"> > text > <delta:remove-leaving-content-start delta:removal-change-idref='ct2' > delta:end-element-idref='ee888' /> > <text:span text:style-name="bold-style"/> > </delta:remove-leaving-content-start> > where the > <text:span delta:insertion-type='insert-around-content' > delta:insertion-change-idref='ct1' > text:style-name="italic-style"> > decoration > </text:span> > is > </text:span> > changed > <delta:remove-leaving-content-end delta:end-element-id='ee888'/> > several times. > </text:p> > > This same example is serialized in abw format by abiword as the > following. The <c> tag can be thought of somewhat like ODT text:span. > Looking at the second last <c> tag, we can see that abiword explicitly > records that the font went to bold in revision 1 and then was changed > back to normal in revision 3 (!3 is a change in rev 3). > > <c revision="1">Here is some </c> > <c revision="1,!3{font-weight:bold}">text </c> > <c revision="1{font-weight:bold}">where the </c> > <c revision="1{font-weight:bold},!2{font-style:italic}">decoration</c> > <c revision="1{font-weight:bold}"> is </c> > <c revision="1{font-weight:bold},!3{font-weight:normal}">changed</c> > <c revision="1"> several times.</c> > > Section 5.1.3 of OpenDocument-v1.2-part1-cd03.pdf (page 117/801) > states that text:span may appear within a text:span. Given this > nesting possibility, I propose to have abiword create a more direct > translation for styles to produce an ODF file like the following. > <text:p text:style-name="Normal" delta:insertion-change-idref="1" > > Here is some > <text:span text:style-name="bold" delta:insertion-change-idref="3" >text </text:span> > <text:span text:style-name="bold" delta:insertion-change-idref="1" >where the </text:span> > <text:span text:style-name="bold" delta:insertion-change-idref="1" > > <text:span text:style-name="boldital" delta:insertion-change-idref="2" >decoration</text:span> > </text:span> > <text:span text:style-name="bold" delta:insertion-change-idref="1" > is </text:span> > <text:span text:style-name="bold" delta:insertion-change-idref="1" > > <text:span text:style-name="norm" delta:insertion-change-idref="3" >changed</text:span> > </text:span> > several times. > </text:p> > > One complexity I see is for a span which had partial formatting > revoked. For example, if in revision 4 "decoration" has italic removed > then another nested text:span would be needed and have to reference a > style as at revision 3 sans the italic though this style work has to > be done by abiword internally anyway to be able to show the document > at last revision. > > 1,!2{font-weight:bold},!3{font-style:italic},!4{font-weight:normal} > > Thoughts on the text:span nesting idea? > I am getting more and more confused about this generic change tracking proposal. I believe part of my confusion arises from the fact that abiword implementation details are mixed with proposed ODF specification. As far as I am concerned the abiword implementation details do not matter at all. The real question is whether the proposed specification allows a consumer to readily reconstruct the changes even if the file was written by an unknown compliant producer. As far as I can tell it would be nearly impossible for an application to do so. Even something as simple as deleting a column in a spreadsheet may not be uniquely identifiable, ie. in a spreadsheet with 256 rows and content in the first 20 rows the deletion of B1:B100 appears to be recorded in the same way as deletion of B1:B265. Andreas -- Andreas J. Guelzow Concordia University College of Alberta
This is a digitally signed message part
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]