xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Layouts tree pruning for the prototype
Date Tue, 28 Oct 2008 15:08:49 GMT

we do care. The Bugzilla entry with the lowest ID that is still open is
https://issues.apache.org/bugzilla/show_bug.cgi?id=1063 and actually
targets exactly that topic. What Vincent and Simon are working on goes
exactly into this direction (although implementing changing available
IPD is the immediate front goal). I'm not sure what makes you think we
are not interested in this. But you also need to see where we stand:
Most funding for FOP comes from companies doing business-style documents
(not more an a couple of dozen pages per page-sequence). Those not
backed by some company probably just have too little free time to make a
difference since this is such a huge task to get right. And then we're
not a dozen active people anymore who can throw in huge amounts of time.
People come and go. FOP desperately needs people like you who are not
afraid to dive in and help. Dario, please don't get frustrated about the
current state of FOP. Layout is a complex beast and implementating a
highly complex specification like XSL-FO is not easy. Yes, there are
different priorities. But that doesn't mean you cannot bring in yours
and make a difference. The ASF is about collaboration. I very much like
to see you working together with Vincent and Simon towards a better
layout engine (like you already did during recent time). Unfortunately,
I don't have enough time and energy to help out. I'm trying to keep up
as best as I can and will offer constructive suggestions if I have any.

On 28.10.2008 16:03:58 Dario Laera wrote:
> About my main goal (start imaging violins playing a moving song): I  
> dream of a fo processor that can process document in "streaming" using  
> a constant amount of memory regardless the size of the input document  
> (stop imaging... :P). Probably some nice features needs to be dropped,  
> or it's simply not possible, but I think that this is an interesting  
> challenge. Anyway I'm far from reaching this goal.
> Why a streaming memory-efficient processor? Because industry need it:  
> XML and related are beautiful technologies but sometimes too much  
> academics and not production oriented. My company need it (I hope they  
> will allow me to continue working on this...). A prove of the market  
> interest in this sense is XF Ultrascale, a commercial fo processor  
> that is claiming very low memory footprint [1]. It managed to obtain  
> impressing results in some test, but it fails rendering my company  
> test going out of memory. So it seems that a streaming processor still  
> doesn't exists, even in commercial products.
> Obviously, you (and the FOP team) may consider streaming processing  
> not interesting or a very low priority goal. You probably have targets  
> different from mine. Let's consider pruning from the two points of view.
> Do you care about streaming processing?
> Pruning is *necessary* (along with mixed line/page breaking) if you  
> want to render pages before the end of the document is reached while  
> keeping output quality better than best fit.
> Don't you care about streaming processing?
> Pruning is a way of improving performance, surely not the more  
> efficient. Keeping the amount of active nodes (with pruning or other  
> solutions) is not necessary and maybe its benefits in the real life  
> use make it not so desirable.
> I expect you and the FOP team don't care, at least ATM, about  
> streaming processing. Anyway thank you for your feedback, you spent  
> time for it.
> Dario
> [1] http://www.ecrion.com/Products/XFUltrascale/PerformanceComparisonGraph.aspx

Jeremias Maerki

View raw message