Perhaps I can clarify some of the confusion.
The examples under the
Images, Shapes, Charts section of the ECT proposal were intended to show that for areas that are slippery slopes with lots of potential granular changes to track that may have lower end user value to track on such a granular level, they can be easily
treated at the level of the whole object. Text that exists on these objects can be treated the same way as any other text.
I think Ben was pointing to the first subsection, Edit Image/Shape/Chart when he referred to “page 17”. In this case, the question of how to handle text:p
is irrelevant since draw:frame does not allow text:p as a child element. The Edit Shape Text subsection below that demonstrates that text change tracking can be handled for drawing objects that are allowed to take text. If there was confusion about the Edit
Image/Shape/Chart (as in, edit the core object itself) using an image as the example and seeming to preclude tracking text changes, if the image is specified using draw:image rather than draw:frame, then it can have a text:p child element and can be change
tracked the same as demonstrated in the Edit Shape Text example.
Frank’s comments below are correct. Though of course the ECT proposal as initially proposed could be expanded to track changes to higher-value properties of
drawing objects. (Top of my head, this could be addressed similarly to changing which style is applied to text, which is also an attribute value.)
From: Frank Meies [mailto:frank.meies@oracle.com]
Sent: Tuesday, April 26, 2011 7:06 AM
To: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Let's Keep the Cases Straight
Hi all,
On 25.04.2011 14:17, monkeyiq wrote:
One might stipulate that the text:p inside the draw:frame should be
handled like the normal text:p changes on page 9. Though this still
leaves the situation where the user changes the caption, creates a new
revision, and then applies a "filter" as the example on page 17 does. In
this case, the document would include one or more buckets for the
draw:frame, each of which might include more than one revision to its
text:p.
In this example, we have a frame containing and image and a caption:
<draw:frame svg:width="3cm" >
<draw:text-box>
<text:p>
<draw:frame>
<draw:image xlink:href=""Pictures/pic.jpg"/>
Caption
</text:p>
</draw:text-box>
</draw:frame>
if you first change the caption text, this will be tracked like any other regular text change, because the caption is nothing but a regular paragraph inside a text box. If you then change the image, only the *inner* draw:frame element will be replaced according
to the ECT Proposal. But if you change e.g., the width of the *outer* frame, the complete outer draw:frame has to be replaced because ECT lacks the ability to track attribute changes. I also consider this problematic and prefer the way GCT handles this case.
Regards,
Frank
--
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.
Hertogswetering 163/167, 3543 AS Utrecht, 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