[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office-collab] Let's Keep the Cases Straight
On Wed, 2011-04-27 at 00:25 +0000, John Haug wrote: > 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. Transitively draw:frame does allow text:p as a child element. And buckets containing the entire tree at an XML node are thus transitive with respect to containment. Open Document Format for Office Applications (OpenDocument) v1.2 Part 1: Introduction and OpenDocument Schema 03, 30 July 2009 (9.4.2) draw:frame allows as a child element draw:text-box (9.4.3). In turn draw:text-box (9.4.3) allows as child element text:p (4.1.2). So it is completely relevant as it is specified. > 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"/> > </draw:frame> > 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 > > -- > Oracle > 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 > > Green OracleOracle is committed to developing practices and products > that help protect the environment > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]