Oh no...I meant removing the TreeExt interface, and
instead coding for the underlying BookmarkData object
that it represents within AreaTreeHandler instead.
Our code including id resolution (it will still
implement Resolvable) remains mostly the same, and in
the same places (AreaTreeHandler and
Re
[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
--- 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 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
> >
Jeremias Maerki wrote:
> jeremias2004/10/10 04:21:29
>
> Modified:src/java/org/apache/fop/layoutmgr LineLayoutManager.java
> Log:
> This is supposed to fix a problem that surfaced with Finn's latest
> change in PageSequence. There was an ArrayIndexOutOfBoundsException here in
> LineL
That's exactly why we need a good regression test facility. I apologize
for not being more thorough. I'll probably have time on Thursday to look
into it if noone beats me to it.
I also thought about reusing the static areas but as soon as there are
things like the page number or another reference
Folks
I am planning to use the following XSLTInputHandler constructor in an
applet downloaded on the client side. Before I use it I have the following
questions.
public XSLTInputHandler(File xmlfile, File xsltfile) throws FOPException
{ }
public XSLTInputHandler(String xmlURL, String xsltURL)
[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]
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
