Hi all, I agree that the remove-leaving-content might add unnecessary complexity. But often this can be avoided by splitting your text portions: In OOo Writer, I guess the example would be coded this way: <text:p> Here is some <text:span delta:insertion-type='insert-around-content' delta:insertion-change-idref='ct2' text:style-name= bold-style > text </text:span> <text:span text:style-name= bold-style > where the </text:span> <text:span text:style-name= bold-italic-style ac:change001= ct1,change,text:style-name,bold-style > decoration </text:span> <text:span text:style-name= bold-style > is </text:span> <text:span text:style-name= normal ac:change002= ct2,change,text:style-name,bold-style > changed </text:span> </text:p> However, if you completely want to reset the formatting of the word changed instead of setting the style to normal , you either have to use remove-leaving-content or you have to remove the respective span and insert the text content behind the span. Regards, Frank On 11.04.2011 04:55, monkeyiq wrote:
1302490527.1516.42.camel@alkid.localdomain type= cite > 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? -- Frank Meies Software Developer Phone: +49 49 23646 500 Oracle OFFICE GBU ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven Oracle is committed to developing practices and products that help protect the environment