On 02.01.2006 15:09:38 Foucault, Sebastien wrote: > Dear all, > > Just a few questions about the new version of FOP. > > Performances > ------------ > > The following page http://xmlgraphics.apache.org/fop/0.91/running.html reads > : > > <<FOP can consume quite a bit of memory, even though this has been > continually improved. This is partly inherent to the formatting process and > partly caused by implementation choices. All FO processors currently on the > market have memory problems with certain layouts. >> > > and then > > <<One of FOP's stated design goals is to be able to process input of > arbitrary size. Addressing this goal is one of the prime motivations behind > the FOP Redesign. >> > > What is new version status toward all these performance hints ? > > - Forward references (Page X/*** Y ***)
For output formats that support "out-of-line" rendering of pages (such as PDF), fully resolved pages can be output sooner now. "out-of-line" rendering means that page 5 can be rendered before page 3 if page 3 contains an unresolved forward reference and page 5 does not. Otherwise, the status is more or less the same as with 0.20.5. Howeverm this out-of-line rendering doesn't help if you have page x/y on every page because that means that every (!) page is unresolved until the last page has been layouted. I'm also currently working on something that will (as a side-effect) allow to temporarily unload unresolved pages to disc until they can be fully resolved. That could help handle huge documents with "page x/y". > - Large images No changes against 0.20.5 in this area. > - Long page sequences The same here, unfortunately. I guess this will be disappointing. However, the current design still holds the potential to address these points. It is simply so that due to the progress of the project shortcuts had to be taken to get the new FOP running so it doesn't appear dead anymore. Only a live project attracts new contributors. That means taking a few shortcuts. On the other side, we now have some major new features over 0.20.5 which in the end makes 0.91 a huge step forward. Anyway, handling large images wouldn't be a hell of a job. The current code does this in a somewhat naïve way and could certainly do better. Less memory-intensive handling of forward references is also doable. I believe that implementing a two/multi-pass mechanism for FOP would be one way to solve this, however at the cost of speed, of course. Handling long page sequences is not quite so easy though not impossible. Currently, a whole page-sequence is broken into pages in one run, but this can be broken down to smaller pieces (topic: first/best fit and restartable element list generation). It's all a matter of allocating the necessary resources. Everybody can help. > Extensions > ---------- > > Is an extension mechanism planned in the development roadmap. I perfectly > understand that APIs and extension mechanisms exposing the internals of a > product are the kind of things which cannot be implemented in the early > releases. However, planning to upgrade an application based on a customized > FOP 0.20.5, I'd like to know whether such features are on the verge on being > implemented or not. We do have several points where various kinds of extensions can be plugged in in the new code. What kind of extension do you imagine? If you want to handle custom XML elements, have a look at the plan and mathml extensions in the examples directory of the distribution. I will soon publish the new FOP extension for Barcode4J that will handle barcode generation in fo:instream-foreign-object. Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
