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 alex <al...@in2soft.com> on 2005/05/28 11:34:20 UTC

XML2PDF formatting progress

Hi,

I'm using FOP 0.20.5 embedded in a formatting project, where I have
XML + XSL = FO => PDF. Everything works fine, but I would like to
display a progress bar indicating transformation progress from
XML to XSL-FO (first part) and from XSL-FO to PDF (second part).

I have searched very intensively for a solution, but couldn't find
any way to determine the progress.

Does anyone have an idea on how to approach my problem ?

I thought about modifying the fop source at the point, where the
System.out gets the [INFO] about whats going on, so as to notify
my application thereof. But I haven't found that point yet.
Anyone a suggestion ?

thx for the help
Alex Dima


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

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


Re: XML2PDF formatting progress

Posted by Jeremias Maerki <de...@greenmail.ch>.
You can have that easier and portable if you're decorating the
InputStream with a CountingInputStream from Jakarta Commons IO.

On 01.06.2005 14:18:36 Warren Young wrote:
> In that case, the program driving fop could set up a named pipe, and 
> provide the fo file through that.  Then the driver program would know 
> where fop is reading in the file, and can infer progress from that.
> 
> The only problem with this approach is that it's hard to do portably. 
> But if you're on some *ix type system, it's pretty easy to do.


Jeremias Maerki


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


Re: XML2PDF formatting progress

Posted by William Gilbert <gi...@informagen.com>.
On Jun 1, 2005, at 8:18 AM, Warren Young wrote:

> Glen Mazza wrote:
>
>
>> So I don't think FOP would ever know itself how much finished it  
>> is with its input, and hence would not be able to report on it.
>>
>
> In that case, the program driving fop could set up a named pipe,  
> and provide the fo file through that.  Then the driver program  
> would know where fop is reading in the file, and can infer progress  
> from that.
>
> The only problem with this approach is that it's hard to do  
> portably. But if you're on some *ix type system, it's pretty easy  
> to do.


FOP uses a logger object to report information, warnings, and  
errors.  For embedded FOP, I would write and install a custom logger  
object to echo the current page number into a progress box.

For servlets, cache and send back the growing log report then use a  
META tag to have the browser refresh one second later.  Use servlet  
sessions to connect the right FOP thread with the right browser.

Been doing it for years this way.

--will gilbert

Re: XML2PDF formatting progress

Posted by JB...@s-s-t.com.
> You can do XSLT processing separately, with xsltproc.  It's a
> pretty quick process, compared to the FOP step.  The xsltproc
> step will produce the single FO file you want, which FOP will
> accept.

I haven't been following this conversation in full, but the above 
paragraph caught my eye.

You can also use Xalan (included in the FOP distribution) or Saxon or a 
number of other XSLT processors. I use Saxon 8.4 (to get XSLT and XPath 
2.0 features) to produce all my FO files, which I then send to FOP to get 
PDF output.

FWIW

Jay Bryant
Bryant Communication Services
(presently consulting at Synergistic Solution Technologies)





Warren Young <wa...@etr-usa.com> 
06/02/2005 03:39 PM
Please respond to
fop-users@xmlgraphics.apache.org


To
fop-users@xmlgraphics.apache.org
cc

Subject
Re: XML2PDF formatting progress






Glen Mazza wrote:

> The problem with that would seem to be that the "file" is not usually a
> single input FO document, but the combination of an XSL stylesheet with 
an
> XML data file being fed into the XSL processor, 


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




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


Re: XML2PDF formatting progress

Posted by Warren Young <wa...@etr-usa.com>.
Glen Mazza wrote:

> The problem with that would seem to be that the "file" is not usually a
> single input FO document, but the combination of an XSL stylesheet with an
> XML data file being fed into the XSL processor, 

You can do XSLT processing separately, with xsltproc.  It's a pretty 
quick process, compared to the FOP step.  The xsltproc step will produce 
  the single FO file you want, which FOP will accept.

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


Re: XML2PDF formatting progress

Posted by Glen Mazza <gr...@verizon.net>.
The problem with that would seem to be that the "file" is not usually a
single input FO document, but the combination of an XSL stylesheet with an
XML data file being fed into the XSL processor, so ascertaining a percentage
would probably be quite difficult.  Being 30% from the beginning of an XSLT
stylesheet (in contrast to being 30% through an FO document)--even if you
could get that information--wouldn't mean anything, stylesheets are
template-driven and bounce all over the place.

Glen

----- Original Message ----- 
From: "Warren Young" <wa...@etr-usa.com>
To: <fo...@xmlgraphics.apache.org>
Sent: Wednesday, June 01, 2005 8:18 AM
Subject: Re: XML2PDF formatting progress


> Glen Mazza wrote:
>
> > So I don't think FOP
> > would ever know itself how much finished it is with its input, and hence
> > would not be able to report on it.
>
> In that case, the program driving fop could set up a named pipe, and
> provide the fo file through that.  Then the driver program would know
> where fop is reading in the file, and can infer progress from that.
>
> The only problem with this approach is that it's hard to do portably.
> But if you're on some *ix type system, it's pretty easy to do.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>


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


Re: XML2PDF formatting progress

Posted by Warren Young <wa...@etr-usa.com>.
Glen Mazza wrote:

> So I don't think FOP 
> would ever know itself how much finished it is with its input, and hence 
> would not be able to report on it.

In that case, the program driving fop could set up a named pipe, and 
provide the fo file through that.  Then the driver program would know 
where fop is reading in the file, and can infer progress from that.

The only problem with this approach is that it's hard to do portably. 
But if you're on some *ix type system, it's pretty easy to do.

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


Re: XML2PDF formatting progress

Posted by Glen Mazza <gm...@apache.org>.
I would think, in order to give a progress indicator, FOP while running 
would need to know where the end of the input is (how else could FOP 
declare itself to be 25% done, 50% done, etc.).  But FOP does not do 
such preprocessing, it processes the data as it gets it (well, starting 
at the end of each fo:page-sequence it finds), without knowledge of the 
number of future fo:page-sequences to be found.  So I don't think FOP 
would ever know itself how much finished it is with its input, and hence 
would not be able to report on it.

Also I believe the two parts you mention are not discrete, but happen 
simultaneously (we use SAX processing internally.)

But in the future 1.0 version (not 0.20.5), you will be able to 
programmatically override the FOEventHander (which signals the start/end 
of most FO's occured while processing), and I think here you would be 
able to set a counter/fire an event for the "end" of each 
fo:page-sequence as it occurs, before calling the default processing.  
If you were to preprocess the document separately and get a count of 
fo:page-sequences to begin with--you can get a % done that way.  Problem 
is, however, it would be time consuming to run the "first part" 
mentioned below another time just to get that total count.  Also, 
differing sizes of the fo:page-sequences would make that percentage 
questionable.

Glen


alex wrote:

> Hi,
>
> I'm using FOP 0.20.5 embedded in a formatting project, where I have
> XML + XSL = FO => PDF. Everything works fine, but I would like to
> display a progress bar indicating transformation progress from
> XML to XSL-FO (first part) and from XSL-FO to PDF (second part).
>
> I have searched very intensively for a solution, but couldn't find
> any way to determine the progress.
>
> Does anyone have an idea on how to approach my problem ?
>
> I thought about modifying the fop source at the point, where the
> System.out gets the [INFO] about whats going on, so as to notify
> my application thereof. But I haven't found that point yet.
> Anyone a suggestion ?
>
> thx for the help
> Alex Dima
>
>


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