You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by "Foucault, Sebastien" <Se...@hraccess.com> on 2006/01/02 15:09:38 UTC

0.9.X Status

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 ***)
- Large images
- Long page sequences

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.

Thank's in advance
-- 
Sébastien



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: 0.9.X Status

Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org