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 fletcher111 <fl...@gmail.com> on 2008/06/16 23:45:23 UTC
Fop Progress Output
Hi,
I have a program which uses fop to create PDFs. Generating the PDFs takes a
long time and I was wondering if there is some kind of output which can be
used to create a progress bar in Java.
Thanks ahead of time,
fletcher111
--
View this message in context: http://www.nabble.com/Fop-Progress-Output-tp17873901p17873901.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop Progress Output
Posted by Antti Karanta <an...@napa.fi>.
On Thu, 19 Jun 2008 11:30:56 +0300, Andreas Delmelle
<an...@telenet.be> wrote:
> 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.
IMO it would be great just to be able to get an event every time a page
is produced (or even every time a page sequence is produced). This would
enable showing something other than a "processing, please wait" to the
user - having a (somewhat) realtime running count on the number of pages
produced, even w/ no idea on how much more there is to go, would be much
better than nothing. That way the user could see concrete progress and
know that the process is not stuck.
::Antti::
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop Progress Output
Posted by Andreas Delmelle <an...@telenet.be>.
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.
Interesting...
> 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
> SAX
> 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 (?)
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop Progress Output
Posted by Daniel Noll <da...@nuix.com>.
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 SAX
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.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop Progress Output
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Not sure how you want to do that or what exactly you had in mind. FOP
doesn't have access to the original InputStream. FOP just receives a
series of SAX events through the SAX ContentHandler exposed by
Fop.getDefaultHandler(). Furthermore, page production is not
proportional to the input that comes in. Layout is always triggered at
the end of a page-sequence: FO tree build-up, layout page-sequence, more
FO tree build-up, layout next page-sequence, etc. etc. Efforts are
underway to make this process more parallel, but for the time being,
that's how it works. No chance for a progress bar with percentages. The
only thing possible is to indicate how many page-sequences and pages
have already been generated.
On 18.06.2008 07:11:03 Daniel Noll wrote:
> On Tuesday 17 June 2008 17:36:07 Jeremias Maerki wrote:
> > FOP receives streamed input and therefore has no chance to provide
> > information for a progress bar (at least in percent). Now that we have
> > an event facility, we could add some progress events like a "new page"
> > event that gets called each time a page has been created. But we would
> > still not know how many pages there will be in order to calculate a
> > percentage.
>
> If we could somehow rely on it reading it in a streamed fashion (i.e. the data
> for page 21 is not read until the previous content is already completely
> handled) then intercepting the InputStream itself would allow a % readout.
>
> I think Java already had such a utility class but I haven't tried using it
> with FOP before.
>
> Daniel
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop Progress Output
Posted by Daniel Noll <da...@nuix.com>.
On Tuesday 17 June 2008 17:36:07 Jeremias Maerki wrote:
> FOP receives streamed input and therefore has no chance to provide
> information for a progress bar (at least in percent). Now that we have
> an event facility, we could add some progress events like a "new page"
> event that gets called each time a page has been created. But we would
> still not know how many pages there will be in order to calculate a
> percentage.
If we could somehow rely on it reading it in a streamed fashion (i.e. the data
for page 21 is not read until the previous content is already completely
handled) then intercepting the InputStream itself would allow a % readout.
I think Java already had such a utility class but I haven't tried using it
with FOP before.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Fop Progress Output
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
FOP receives streamed input and therefore has no chance to provide
information for a progress bar (at least in percent). Now that we have
an event facility, we could add some progress events like a "new page"
event that gets called each time a page has been created. But we would
still not know how many pages there will be in order to calculate a
percentage.
On 16.06.2008 23:45:23 fletcher111 wrote:
>
> Hi,
>
> I have a program which uses fop to create PDFs. Generating the PDFs takes a
> long time and I was wondering if there is some kind of output which can be
> used to create a progress bar in Java.
>
> Thanks ahead of time,
> fletcher111
> --
> View this message in context: http://www.nabble.com/Fop-Progress-Output-tp17873901p17873901.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org