Well, the error simply means you have content which is larger in height than is available on a page. The layout engine then tries to move the element to the next page to see if there's more room, and so on, until it has tried that 50 times which is when it gives up. Note, the overflow may not necessarily be due to a single element (like an image) but could also be several element held together by some combination of keep-* properties.
On 02.06.2006 15:11:23 Raphael Parree wrote: > Thanks got the highlighter working again using an XMLFilter (working on > 0.20.5). Trying now to move to 0.92, but that is giving many > headaches...many "Some content could not fit into a line/page after 50 > attempts. Giving up to avoid an endless loop" occur...(I am now moving first > without the extension/filter) > > > > -----Original Message----- > From: Jeremias Maerki [mailto:[EMAIL PROTECTED] > Sent: 02 June 2006 09:50 > To: [email protected] > Subject: Re: Preprocessing > > I don't have a working example ready to pass over but I can give you > some pointers. > > Essentially, I think you'd best implement an org.xml.sax.XMLFilter (you > can case XMLFilterImpl as a base class). That's the recommended way. > You can get some hints to the approach from: > http://www.javalobby.org/java/forums/m91825016.html > http://www.javalobby.org/forums/thread.jspa?threadID=16216&tstart=0 > > In FOP we also have code that operates similarly although it's not a > filter/conversion operation on the XML level. Since we're on the > receiving end of the SAX chain and thus have to operate purely on the > passive side, we can't use XMLFilter. Everything is implemented as a > passive ContentHandler (active would mean it would be an XMLReader with > parse() methods). This is all code used to build the FO tree and foreign > elements. Building blocks are: > - org.apache.fop.fo.FOTreeBuilder and it's nested MainFOHandler. > - org.apache.fop.util.DelegatingContentHandler > - org.apache.fop.util.ContentHandlerFactory > - org.apache.fop.util.ContentHandlerFactoryRegistry > > But don't look too much at FOP. I'd use the XMLFilter approach. > > Good luck! > > On 02.06.2006 08:56:25 Raphael Parree wrote: > > Hi, > > > > Would you perhaps have a demo/example showing the best way of > postprocessing > > the FO after XSL transformation before it is fed to FOP? > > > > Tx., > > > > > > -----Original Message----- > > From: Jeremias Maerki [mailto:[EMAIL PROTECTED] > > Sent: 30 May 2006 13:27 > > To: [email protected] > > Subject: Re: LazyFont NullPointerException > > > > Frankly, migrating this kind of extension could be a problem. But I'm > > not sure. At any rate, there's no "layout()" method anymore and the FO > > tree itself had a few changes, too. If I were you I wouldn't implement > > something like that as a FOP extension but as a generic, SAX-based > > pre-processor which is independent of the FO processor. That would make > > the thing much more versatile. > > > > On 30.05.2006 13:13:16 Raphael Parree wrote: > > > > > > The extension performs syntax checking and color highlighting of various > > > languages (JAVA, JSP, HTML, XML, SQL, HQL, EJBQL etc). It does not > > generate > > > SVG, but produces FO where it changes the font attributes. > > > > > > It extends the FObj and relies on the layout method to call an addText > > > method for each token. I can't recall from which example I obtained the > > > skeleton code (especially the addText method). Do you think it will be > an > > > easy transition? I have been postponing the move, but am aware that one > > day > > > I will have to make it ;) > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Jeremias Maerki [mailto:[EMAIL PROTECTED] > > > Sent: 30 May 2006 12:40 > > > To: [email protected] > > > Subject: Re: LazyFont NullPointerException > > > > > > The extension API has been stable for a while. A few months ago I've > > > added some additional gadgets I needed for Barcode4J. I don't expect any > > > major changes anymore. Backwards-incompatible changes are highly > > > unlikely, but no guarantees. > > > > > > So far, there's no documentation for writing extensions. I usually point > > > people at Barcode4J as the prime example. :-) The examples directory in > > > the distribution (MathML and plan extensions) can also help. > > > > > > The migration shouldn't be too difficult. A few things have changed but > > > most of your custom code can stay the same. I'm pretty confident that > > > you can do the migration in 2 or 3 hours max if your extension simply > > > generates SVG. > > > > > > Now, I'm curious: What kind of extensions did you implement? > > > > > > On 30.05.2006 11:57:13 Raphael Parree wrote: > > > > Hi, > > > > > > > > I would like to move to 0.92beta, but have so far been reluctant to > make > > > the > > > > move due to the FOP extension we have written. Is it safe to start > > porting > > > > the extensions (IOW is the extension API stable?). Is there > > documentation > > > > available on writing extensions for the new release (or even better on > > how > > > > to migrate your extensions?) Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
