[Glen]
OK, I'd like to
1) rename TreeExt to OffDocumentItem (to clarify what
it's really for)
2) change it from an interface to an abstract base
class.
3.) Have this base class hold the "when" parameter for
when this ODI is to be generated, so the "when" does
not need to be hardcoded into A
--- Finn Bock <[EMAIL PROTECTED]> wrote:
> [Glen]
>
> > Actually, to clarify what I wrote: why do we need
> an
> > extension interface (TreeExt) for objects placed
> > outside the document (pdf bookmarks/metadata),
> while
> > *not* needing one for extension objects that end
> up
> > placed *on* t
--- Finn Bock <[EMAIL PROTECTED]> wrote:
>
> [Glen]
>
> > Finn, ***be very careful***, the definition of
> tree
> > extension was #2, *not* #1 (see previous email).
> I
> > don't like its name, it should be OutOfAreaObject
> or
> > something like that.
>
> And why shouldn't extensions be allo
[Glen]
Actually, to clarify what I wrote: why do we need an
extension interface (TreeExt) for objects placed
outside the document (pdf bookmarks/metadata), while
*not* needing one for extension objects that end up
placed *on* the document?
You subclass Area for elements on the document and TreeExt
[Glen]
Still, I wonder if it may be better to do away with
this interface and just hardcode the layout/rendering
of these objects (i.e. bookmarks) directly, just like
we do all the other Area objects that are created
during the layout process. This would simplify
area.extensions.BookmarkData and
--- Glen Mazza <[EMAIL PROTECTED]> wrote:
> --- Finn Bock <[EMAIL PROTECTED]> wrote:
>
> > [Glen]
> >
> > > Still, I wonder if it may be better to do away
> > with
> > > this interface and just hardcode the
> > layout/rendering
> > > of these objects (i.e. bookmarks) directly, just
> > like
> >
--- Finn Bock <[EMAIL PROTECTED]> wrote:
> [Glen]
>
> > Still, I wonder if it may be better to do away
> with
> > this interface and just hardcode the
> layout/rendering
> > of these objects (i.e. bookmarks) directly, just
> like
> > we do all the other Area objects that are created
> > during th
[Glen]
Still, I wonder if it may be better to do away with
this interface and just hardcode the layout/rendering
of these objects (i.e. bookmarks) directly, just like
we do all the other Area objects that are created
during the layout process. This would simplify
area.extensions.BookmarkData and
t; Sent: Monday, 25 October 2004 12:26 PM
> To: [EMAIL PROTECTED]
> Subject: RE: meaning of Area.TreeExt interface
>
> Thanks for the clarification. PDF Bookmarks aren't
> working currently, so that's what I'm looking at
> ATM.
> We may have another object ext
: [EMAIL PROTECTED]
Subject: RE: meaning of Area.TreeExt interface
Thanks for the clarification. PDF Bookmarks aren't
working currently, so that's what I'm looking at ATM.
We may have another object extending the TreeExt
interface, should we have a fox:metadata in the
future.
Still,
;
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
> Sent: Sunday, 24 October 2004 10:46 AM
> To: [EMAIL PROTECTED]
> Subject: meaning of Area.TreeExt interface
>
> Keiron (or others?),
>
> A few years back Keiron created an Area.TreeExt
> interfa
-
From: Glen Mazza [mailto:[EMAIL PROTECTED]
Sent: Sunday, 24 October 2004 10:46 AM
To: [EMAIL PROTECTED]
Subject: meaning of Area.TreeExt interface
Keiron (or others?),
A few years back Keiron created an Area.TreeExt
interface for area tree extensions. PDF Bookmarks are
our only object that
Keiron (or others?),
A few years back Keiron created an Area.TreeExt
interface for area tree extensions. PDF Bookmarks are
our only object that implements this interface
currently.
I'm not certain what was originally meant by an "area
tree extension" though. Is it:
1.) A layout area that is
13 matches
Mail list logo
