On 15.05.2006 11:57:00 Giorgio [EMAIL PROTECTED] wrote: > Thank you for your replay, but I still need some info: > 1) how can I help you?
That's where it gets tricky, at least for this particular issue. Supporting large documents will take some rather extensive changes in the layout engine: - Introduction of a first-fit page breaking algorithm which is selected on demand. - Layout managers won't produce complete element lists anymore, only up to the point that a page can be filled. Therefore, layout managers must be able to restart at a particular point. In this case, the table layout manager is the biggest problem because it can't do that, yet. The other layout managers should be easier here as they already support that. - Optional: Reintroduce restartability into the layout managers for the case where the available width of a page changes from one page to the other. In this case, line break decisions have to be redone and the block-progression element list regenerated. - Free FO tree resources and layout managers as soon as certain FO elements have been fully produced on pages. - Improve the area tree storage to save unresolved pages to disk. This already exists but isn't hooked into FOP's normal operation, yet. Alternatively, implement a two-pass approach for resolving page-number-citations. The latter will provide us with a higher probability to get the layout right when page-number-citations are used while keeping the memory consumption low because no pages have to be kept in memory or disk until they can be rendered to the final format. To implement the above, deep knowledge about the Knuth element design and FOP's layout engine will be required. We can point anyone willing to dive in to the right spots in the code and the right book to read. As an alternative you can find someone who will implement the above for you. There are some people on this list who might be available for that. I do this kind of work but in the near future (next 3-5 months) I don't think I have enough time to take on such a big task myself. > 2) there is something planned about the unlimited page-sequence problem? Some of that is on my long-term task list, but for the moment it is a rather low priority for me. None of my clients nor I create documents with page-sequences larger than two dozen pages. Otherwise, I know of noone who is planning to do this. > Best regards, > Giorgio > > Jeremias Maerki wrote: > > The goal defined back then is still valid, but so far functionality was > > more important than handling large documents. If this is very very very > > important to you, then please consider allocating resources to help us > > implement it. This is open source; everybody can help. > > > > On 12.05.2006 18:03:55 Giorgio [EMAIL PROTECTED] wrote: > > > >>BTW, I found a very old topic discussed on the fop-dev list > >>(http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200305.mbox/[EMAIL > >> PROTECTED]) > >>about possibility of arbitrary size page-sequence. Anyone know a fallow > >>up of this? There is a planned release of this very very very important fix? <snip/> Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
