On Sun, 2011-04-24 at 20:12 -0600, monkeyiq wrote:
> On Sun, 2011-04-24 at 19:56 -0600, Andreas J. Guelzow wrote:
> > On Sun, 2011-04-24 at 18:16 -0600, monkeyiq wrote:
> >
> > > The context dependant processing of text:p means that such code paths
> > > would have to be duplicated; one for text:p elements at top level, and
> > > another for text:p elements buried inside a bucket.
> >
> > I would disagree. There are other ways to keep context than to duplicate
> > code paths. In fact text:p elements can already occur in various
> > distinct contexts, so I would assume that you are aleady preserving the
> > context for those situations without duplicating the code paths.
> >
> The duplication is to handle loading and assembling the changes from the
> text:p inside all the buckets for the old versions.
>
> Page 9 of the ECT proposal shows how "normal" text:p would have calls
> out to change tracking to describe style changes inline, however page 17
> uses en masse retiring & versioning of text:p objects each time a
> draw:frame is changed. Thus to load each text:p instance (page 9 vs
> inside bucket on page 17) the code itself would have to be quite
> different. And again, to generate these serializations, one would need
> quite different code.
I don't see any occurrence of text:p on page 17 (of course since the odt
documents do not have any fixed pagination I may be looking at a
completely different page than you). On the other hand the only
occurrences of draw:frame are on my pages 3, 17 and 18 so the pagination
can't be that different.
Andreas
>
>
