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
|