xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Delmelle <andreas.delme...@telenet.be>
Subject Re: Fop Progress Output
Date Thu, 19 Jun 2008 08:30:56 GMT
On Jun 19, 2008, at 03:53, Daniel Noll wrote:

> On Wednesday 18 June 2008 17:32:36 Jeremias Maerki wrote:
>> Not sure how you want to do that or what exactly you had in mind.
> Yeah, like I said, I haven't tried doing it with FOP.
> But as far as what I had in mind, see  
> javax.swing.ProgressMonitorInputStream.
> We use this in various other situations where the thing reading  
> from the file
> has no notion of how much of the file has been read, and it works  
> quite well
> in those other situations.


> In this particular case it would be dependent on both the XML  
> parser and FOP.
> Assuming the XML parser reads the file in chunks and then generates  
> events, and then reads another chunk, and so forth, you'll get an  
> update each
> time it reads a chunk.  The default one in Java more than likely  
> does work
> like this.

> So then depending on where FOP's time is spent, it may or may not  
> work.  If
> the bulk of FOP's time is spent when incrementally receiving the  
> SAX events,
> then it will work.
> On the other hand, if FOP merely collects SAX events
> until it hits the end of the page sequence and then does all the  
> hard work,
> it will only provide reasonable feedback if you have multiple page  
> sequences.

AFAIK, the situation is somewhere in between. FOP does not merely  
collect the SAX events, but already does some processing in that  
phase (property parsing, preparatory work for tables, basic FO  
validation...) The real 'hard work' --layout computations-- indeed  
only starts at the end of the page-sequence. IIRC from measurements,  
I'd say that FOP spends only about 10-20% of the total processing  
time on parsing/building the FO tree. (note: This depends greatly on  
the complexity of the layout)

Another difficulty arises with input that does not exist as a  
separate file, but is produced via XSLT. In that case, FOP does not  
know how large the input will be, and neither does the parser. The  
parser only receives and echoes the events generated by the XSLT  
processor. The only real InputStreams will be those of the input XML  
and the stylesheet. The FO will not necessarily exist as a stream,  
only as a collection of SAX events.

OTOH, /if/ one knows in advance how many pages a document is supposed  
to generate, then with the new event-mechanism, it would be possible  
to catch the new-page events, and derive a percentage from there. FOP  
cannot determine such an overall percentage all by itself, however,  
since there is no way for FOP to know whether a given page-sequence  
will be the last, or how many will follow... unless this information  
would be supplied somehow, via some metadata extension as the first  
node in the document (?)



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

View raw message