Re: meaning of Area.TreeExt interface
[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 for elements outside the document. For the latter types, area creation is hardcoded within our layout managers (to be replaced by extension writers when they have new FO's), so I don't logically see why we can't do the same with the former types. How can an extension pass information onto the renderer if TreeExt (or whatever we want to call it) is removed? regards, finn
Re: meaning of Area.TreeExt interface
[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 area.AreaTreeModel processing code. Thoughts (anyone)? [me] That would make the life of extension writers harder. Thus I would prefer that TreeExt stay. [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 allowed to create OutOfAreaObjects? Some extension writers will needed that just like the author of fox:bookmarks needed it. regards, finn
XSLTInputHandler questions
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) throws
FOPException { }
public XSLTInputHandler(InputSource xmlSource, InputSource xsltSource)
throws FOPException { }
1) Would a URL constructor passed as string like
new XSLTInputHandler (new String(http://host:7011/web/myXML.xml";), new
String(http://host:7011/web/myXSL.xsl";))
work ?
2) I read on some websites that
org.apache.fop.apps.XSLTInputHandler(InputSource ,InputSource ) constructor
doesnt work for InputSource and can only be used for String and File
arguments? Have anyone made it work with InputSource arguments?
3) As the XSLTInputHandler is called on client side I want to read the XSL
and XML files from app server. How should I go about reading the XSL,XML
files from server? as inputstreams?
Thanks
Manoj
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr LineLayoutManager.java
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, things get complicated. I don't think it's worth the trouble to write code that can detect if a static area is invariable. On 25.10.2004 17:47:09 Luca Furini wrote: > 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 > > LineLayoutManager when a static region was layouted for the second page > > (instance is reused). It seems to me that "iCurrParIndex" could be made a > > method-local variable instead of an instance variable. > > It took me a while to notice that these changes cause another problem for > blocks containing preserved linefeeds and whose lines are parted on > different pages. For these blocks, the array named knuthParagraphs has > more than one element (the block will generate more than one paragraph) > and the method LineLM.addAreas() is called more than once, so it isn't > always right to set iCurrParIndex to 0. I'm attaching a fo file showing > this problem. > > So, iCurrParIndex must be set to 0 in addAreas only for LineLM descendant > of a StaticContentLM. > But maybe it isn't necessary to call addAreas more than once for static > content: as the static content is repeated on each page, wouldn't it be > better to store the static area sub-tree and re-use it? Jeremias Maerki
Re: cvs commit: xml-fop/src/java/org/apache/fop/layoutmgr LineLayoutManager.java
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 > LineLayoutManager when a static region was layouted for the second page > (instance is reused). It seems to me that "iCurrParIndex" could be made a > method-local variable instead of an instance variable. It took me a while to notice that these changes cause another problem for blocks containing preserved linefeeds and whose lines are parted on different pages. For these blocks, the array named knuthParagraphs has more than one element (the block will generate more than one paragraph) and the method LineLM.addAreas() is called more than once, so it isn't always right to set iCurrParIndex to 0. I'm attaching a fo file showing this problem. So, iCurrParIndex must be set to 0 in addAreas only for LineLM descendant of a StaticContentLM. But maybe it isn't necessary to call addAreas more than once for static content: as the static content is repeated on each page, wouldn't it be better to store the static area sub-tree and re-use it? Regards, Luca http://www.w3.org/1999/XSL/Format";> First paragraph in the static content. Second paragraph in the static content. Text Text The following block has a preserved linefeed. Text with preserved linefeeds, bla first first first first first first first first first first first first; this is the first paragraph. This is the second paragraph, after a preserved linefeed: second second second second second second second second. The following block has a preserved linefeed. Text with preserved linefeeds, bla first first first first first first first first first first first first; this is the first paragraph. This is the second paragraph, after a preserved linefeed: second second second second second second second second fisecond rst.
Re: meaning of Area.TreeExt interface
--- 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 > > > we do all the other Area objects that are > created > > > during the layout process. This would simplify > > > area.extensions.BookmarkData and > > area.AreaTreeModel > > > processing code. Thoughts (anyone)? > > > > That would make the life of extension writers > > harder. Thus I would > > prefer that TreeExt stay. > > 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? For the latter types, area creation is hardcoded within our layout managers (to be replaced by extension writers when they have new FO's), so I don't logically see why we can't do the same with the former types. In other words, extension writers may very well create extension FO's that create areas *on* the document. Here, TreeExt won't help them--so I'm not really sure if it is actually buying us anything. Glen
Re: meaning of Area.TreeExt interface
--- 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 the layout process. This would simplify > > area.extensions.BookmarkData and > area.AreaTreeModel > > processing code. Thoughts (anyone)? > > That would make the life of extension writers > harder. Thus I would > prefer that TreeExt stay. > > regards, > finn > 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. Also, TreeExt will be abused, as it could be used for non-#2 reasons. Will you please elaborate how it would hurt extension writers though? Glen
Re: meaning of Area.TreeExt interface
[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 area.AreaTreeModel processing code. Thoughts (anyone)? That would make the life of extension writers harder. Thus I would prefer that TreeExt stay. regards, finn
RE: meaning of Area.TreeExt interface
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 RenderPagesModel.) Increasingly I'm seeing AreaTreeHandler as something of a RootLayoutManager, responsible for handling its graphical objects -- Bookmarks and (future) Metadata -- in the same manner that all the other LayoutManagers create/handle their area objects: explicitly ordered and coded. And yes, all renderers will still receive a handleBookmarkData() function call (instead of the current handleExtension()), and also a future handleMetaData(), with the hopes that as many as possible can work with the information. Glen --- Keiron Liddle <[EMAIL PROTECTED]> wrote: > > If you hard code the bookmarks how would you handle > the id resolution, > as that is done through the area tree. Potentially > you could code the > bookmarks in other renderers like AWT. > > -Original Message- > From: Glen Mazza [mailto:[EMAIL PROTECTED] > 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 extending the TreeExt > interface, should we have a fox:metadata in the > future. > > 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 area.AreaTreeModel > processing code. Thoughts (anyone)? > > > The major benefit I see of TreeExt is that our > Renderer interface can remain with a single > renderExtension() for this and any other TreeExt in > the future. But OTOH clarity arguments can be made > for explicitly spelling out each object that a > Renderer may need to support. For example, having > renderBookmarks(), processMetaData(), etc. methods > instead of using instanceof within renderExtension() > methods to determine the TreeExt object in question. > > Thanks, > Glen > > >
