You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Laurent Vaills <la...@laposte.net> on 2001/12/11 13:34:27 UTC
number of pages generated
Hi.
Is there a way to get the number of pages generated after driver.run() ?
Laurent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: number of pages generated
Posted by James Richardson <ja...@db.com>.
I like the idea....
I was also wondering if theres a way to get notified of certain events
happening, like the completion of a page, number of pages calculated, or
similar, via some callback mechanism.... This way I could keep more of
an eye on the progress of a rendering job.
Cheers
James
Jeremias Maerki wrote:
>
>
> Yes, with the "FormattingResults" proposal I submitted on 2001-12-04
> this would be possible. I'm still hoping one of the committers might
> consider integrating it in FOP.
>
>
> On 11 Dec 2001 13:34:27 +0100 Laurent Vaills wrote:
>
>>Is there a way to get the number of pages generated after driver.run() ?
>>
>
> Cheers,
> OUTLINE AG
> Jeremias Märki
>
> mailto:jeremias.maerki@outline.ch
>
> Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
> Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
> Internet http://www.outline.ch
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: need help
Posted by Cyril Rognon <cr...@objectiva.fr>.
Keiron,
I would gladly share this info in order to contribute to FOP.
here is the last transcript from FOP :
[DEBUG]: Initial heap size: 1828Kb
[DEBUG]: Current heap size: 127392Kb
[DEBUG]: Total memory used: 125564Kb
[DEBUG]: Memory use is indicative; no GC was performed
[DEBUG]: These figures should not be used comparatively
[DEBUG]: Total time used: 67054ms
[DEBUG]: Pages rendererd: 85
[DEBUG]: Avg render time: 788ms/page
As everyone see, speed is ok, but memory ? I thought Fop would dispose of
all the objects inside a page sequence when it's done.
I have tested the following : adding some content to generate more page
sequences and fop did you more memory. so there might be a leak somewhere.
anyway, I would gladly participate in whatever plan ther is to improve this
great FO processor.
Thanks
Cyril
>I think first you need to understand what is goind on. So we need to
>provide information:
>- what the plans and issues are
>- what is currently being done
>
>I will be working on this!
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: need help
Posted by Keiron Liddle <ke...@aftexsw.com>.
On 2001.12.12 16:11 Nicola Ken Barozzi wrote:
> Are there any discussions on how to reorganize fop on a more scalable
> framework?
> Maybe going to SAX or other internal representations?
> Sorry for the questions, I'm not able to check the list arcives right
> now.
Yes there have been.
This is important information that needs to be more accessible.
Briefly the idea is to keep information minimal and use/dispose of any
data as soon as possible, failing that a simple caching mechanism will be
available.
> What are the plans for FOP.
> Are the releases giong to be so slowly incremental?
> I'm really in the need of enhancements on the performance side and I
> don't
> know where to start.
> I also needed something that could render fo dynamically but FOP is not
> made
> for this...
> How can I help regarding these issues?
I think first you need to understand what is goind on. So we need to
provide information:
- what the plans and issues are
- what is currently being done
I will be working on this!
Then should have a better idea and you can then ask more specific
questions.
For now getting a general idea of the code might help you get started.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: need help
Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
----- Original Message -----
From: "Keiron Liddle" <ke...@aftexsw.com>
To: <fo...@xml.apache.org>
Sent: Wednesday, December 12, 2001 3:54 PM
Subject: Re: need help
> While that is true there are certain things you need to realise.
> - there are serious layout issues that need to be addressed
> - performance and memory is very much tied up to how the whole system
> works, this makes it difficult to fix
Are there any discussions on how to reorganize fop on a more scalable
framework?
Maybe going to SAX or other internal representations?
Sorry for the questions, I'm not able to check the list arcives right now.
> - getting FOP to a stage where there is a clear development direction is
> difficult
> - none of this will happen by itself
Right.
> It appears that more effort needs to be put towards communicating the
> issues involved and the way in which FOP can be improved.
What are the plans for FOP.
Are the releases giong to be so slowly incremental?
I'm really in the need of enhancements on the performance side and I don't
know where to start.
I also needed something that could render fo dynamically but FOP is not made
for this...
How can I help regarding these issues?
Nicola Ken Barozzi These are the days of miracle and wonder...
...so don't cry baby, don't cry
<xm...@nicolaken.com> Paul Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Basic aspects
Posted by Matthias Fischer <m....@abc-media.de>.
Unfortunately, no patch. As I said before, I'm not a programmer.
A tentative to start a documentation on graphic file types, yes.
I had to pass it on, as I wouldn't be in possession of all the information
to fill out _all_ the fields of a 2D matrix.
To my knowledge, nobody has picked it up, neither to complete it, nor to
insert it into the apache webpage.
Have a nice evening (CET), Keiron, I have to bring my boy to the
kindergarden Xmas party. I'll reply tomorrow (CET) to possible suggestions
by you (or others).
Matthias
-----Original Message-----
From: Keiron Liddle [mailto:keiron@aftexsw.com]
Sent: Thursday, December 13, 2001 3:46 PM
To: fop-dev@xml.apache.org
Subject: Re: Basic aspects
I presume that was a frustrated email :)
One point I have to make:
You say that you have gone through all the problems and eventually sorted
them out after working through it etc.
Yet after solving the problem you did not write to the list and say (to my
knowledge): I have worked out how to solve a particular problem with FOP,
here is a patch for the website so others will know how to solve this
problem.
If this was done then someone else won't come along, exactly like you, and
explain how frustrating things are and how someone should make things
better. If many people do a bit then there will eventually be a lot of
info.
The limitations page is probably the place for this. ie.
docs/xml-docs/fop/limitations.xml
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Basic aspects
Posted by Keiron Liddle <ke...@aftexsw.com>.
I presume that was a frustrated email :)
One point I have to make:
You say that you have gone through all the problems and eventually sorted
them out after working through it etc.
Yet after solving the problem you did not write to the list and say (to my
knowledge): I have worked out how to solve a particular problem with FOP,
here is a patch for the website so others will know how to solve this
problem.
If this was done then someone else won't come along, exactly like you, and
explain how frustrating things are and how someone should make things
better. If many people do a bit then there will eventually be a lot of
info.
The limitations page is probably the place for this. ie.
docs/xml-docs/fop/limitations.xml
On 2001.12.13 15:35 Matthias Fischer wrote:
> Not entirely correct, Arved. I'm not a great specialist on literature,
> but I
> recall reading Tortilla Flat by J. Steinbeck at school. I remember a
> woman
> in the story who faked to clean her flat with a vacuum cleaner - the
> _first_
> vacuum cleaner in Tortilla Flat - although there was no electricity in
> the
> entire quarter...
>
> The FOP documentation "problem", as I see it, is a combination of
> different
> factors. It has happened to us quite frequently that something didn't
> work,
> and we had to
> 1 find documentation on FO which supplied us with, say for instance, 2
> contradictory statements on the syntax of an attribute; neither worked
> 2 assume devoutly that we had committed an error (true in 50% of the
> cases)
> 3 find out, whether someone would understand our problem and give us a
> solution
> 4 still have problems
> 5 back to 1
> Sometimes the source of the problem was that a feature of FO wasn't
> implemented, or that it wasn't implemented with a certain FOP version;
> that
> a problem was due to performance problems; that I didn't succeed in
> articulating what I needed so that someone would understand it, or that
> answers wheren't formulated in a way that I understood them etc. etc.
> You can immagine that, for instance, non-appearing graphics lead into
> intensive testing with regard to (a) the behaviour of FOP/Cocoon under
> different Windows versions (b) different compressions of graphic files -
> nothing. Then someone in the list tells you, the region containing a
> graphic
> must be big enough, otherwise FOP tacitly drops the picture. Hormons of
> happiness spread throughout the office. The result: some files appear,
> some
> not. Why? Questions, counter-questions and counter-counter-questions to
> the
> list: because FOP does with GIF's so and so, and with TIFF's so and so
> etc.
> Ok. Learn everything you didn't know about graphic formats. Implement it.
> Wait 10 minutes, and you don't get your file compiled.
> Testing-testing-testing: no significant result.
> Question-question-question:
> because of a performance problem. How to solve it? Hmmm... - Another
> session
> of questions and counter-questions bothering other people while they try
> to
> do honest work. The hapiness-generating answer: portion the stuff you
> send
> through the processor. How? Does anybody know how to accomplish this?
> Please
> help... - Etc. etc. etc.
> I quoted the example of graphics because it was the most nerve-consuming.
> Nevertheless, by far it wasn't the only one.
>
> My whish to Santa Clause this year: A big fat list containing all major
> graphic formats and the FO/FOP-related aspects that concern them. Right
> on
> the FOP page where everybody cannot avoid to take notice. With a big, red
> or
> yellow triangled exclamation mark and the wording: Hey, dummies (like
> me):
> before you get into this business, think of what you wanna achieve and
> consider these warnings, or it'll cost you real time+effort=money!
>
> Imagine a database outputting a table with all the FO commands in one
> column
> and updated, fresh-of-the-day remarks, warnings, examples etc. like above
> in
> the example. Enhanced, XML-based search functions. Sit back, take a
> drink,
> and find in a second all the bottlenecks that would have otherwise broken
> your neck.
>
> Am I a dreamer? Yes, I am.
> Can dreams come true? Yes, they can.
>
> Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Basic aspects (big fat list vs. live test documents)
Posted by Keiron Liddle <ke...@aftexsw.com>.
As you have visited the site you will know the information here:
http://xml.apache.org/fop/testing.html
This is all the information.
The plans are to get FOP to be able to run through all the tests first.
Of course if more people were involved then someone could work on
improving this.
Maybe this could be used to produce an output of information that users
could see.
On 2001.12.17 08:07 Matthias Fischer wrote:
> Great!
>
>
> What are _your_ plans with regard to the material offered by W3C/Carmelo?
>
> How are tests conducted? Is there a check list according to which one
> could
> record/submit test results systematically?
>
> Do you think, the access of the database by FOP users (and not
> necessarily
> developers) can be enhanced in order to permit easier spotting of single
> test pieces relevant to a user's specific problem?
>
> These questions are what comes to my mind after heaving visited the site.
>
> Matthias
>
>
> -----Original Message-----
> From: Carmelo Montanez [mailto:carmelo@nist.gov]
> Sent: Friday, December 14, 2001 8:43 PM
> To: fop-dev@xml.apache.org; bdelacretaz@codeconsult.ch; Matthias Fischer
> Subject: Re: Basic aspects (big fat list vs. live test documents)
>
>
> Hi all:
>
> Regarding the FO test suite. We at NIST in conjunction with the W3C
> Developed
> a test suite for FO. The site is:
>
> www.w3.org/Style/XSL/TestSuite/
>
> We are also working on expanding that work to include ALL of the basic
> aspects of the language. We expect to have close to 5000 tests by
> next march. Any contributions, ideas, etc. will be
> appreciated.
>
> Thanks
> Carmelo Montanez
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Basic aspects (big fat list vs. live test documents)
Posted by Matthias Fischer <m....@abc-media.de>.
Thank you, Bertrand.
-----Original Message-----
From: Bertrand Delacretaz [mailto:bdelacretaz@codeconsult.ch]
Sent: Monday, December 17, 2001 9:49 AM
To: Matthias Fischer; fop-dev@xml.apache.org
Subject: Re: Basic aspects (big fat list vs. live test documents)
[...]
In the meantime, I'd encourage users that find a bug or problem to send to
this list the smallest possible XSL-FO document that demonstrates the
problem. We could start collecting these in the hope of setting up a
user-friendly demo/test suite when someone finds time to do it.
- Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Basic aspects (big fat list vs. live test documents)
Posted by Matthias Fischer <m....@abc-media.de>.
I'd prefer a more systematic approach: let's wait until the e-mail address
exists. I fear a prefix, as you proposed, is not user-friendly enough.
Before starting, we should also devise the "smallest possible document" into
which users could then insert their functionning examples. This would make
sure that everybody builds upon the same basis. It would make the samples
more easily comparable.
Matthias
-----Original Message-----
From: Bertrand Delacretaz [mailto:bdelacretaz@codeconsult.ch]
Sent: Tuesday, December 18, 2001 10:20 AM
To: Matthias Fischer; fop-dev@xml.apache.org
Subject: Re: Basic aspects (big fat list vs. live test documents)
ok, right now we don't have an alternative address available.
I suggest that you post your code to the list, inline (not as an attachment)
with [TESTDOC] in the subject line (I hope I'm not breaking an existing
convention here).
We can then find it easily in the mailing list archives.
- Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Basic aspects (big fat list vs. live test documents)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Tuesday 18 December 2001 09:59, Matthias Fischer wrote:
> Right now, I have a pice of code I would contribute. It would be useful, if
> there were an alternative e-mail address to that of the list, to collect
> the submitted code segments.
ok, right now we don't have an alternative address available.
I suggest that you post your code to the list, inline (not as an attachment)
with [TESTDOC] in the subject line (I hope I'm not breaking an existing
convention here).
We can then find it easily in the mailing list archives.
- Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Basic aspects (big fat list vs. live test documents)
Posted by Matthias Fischer <m....@abc-media.de>.
Right now, I have a pice of code I would contribute. It would be useful, if
there were an alternative e-mail address to that of the list, to collect the
submitted code segments. Users could put this docu adress on CC, and you
could filter the stuff to heap it up somewhere until it gets used.
Matthias Fischer
-----Original Message-----
From: Bertrand Delacretaz [mailto:bdelacretaz@codeconsult.ch]
Sent: Monday, December 17, 2001 9:49 AM
To: Matthias Fischer; fop-dev@xml.apache.org
Subject: Re: Basic aspects (big fat list vs. live test documents)
[...]
In the meantime, I'd encourage users that find a bug or problem to send to
this list the smallest possible XSL-FO document that demonstrates the
problem. We could start collecting these in the hope of setting up a
user-friendly demo/test suite when someone finds time to do it.
- Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Basic aspects (big fat list vs. live test documents)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Monday 17 December 2001 09:07, Matthias Fischer wrote:
> What are _your_ plans with regard to the material offered by W3C/Carmelo?
As mentioned by Keiron (see http://xml.apache.org/fop/testing.html), the
current FOP tests are based on automatically comparing the ouput
of two FOP revisions.
This is needed to make sure new releases don't break existing features, but
IMHO doesn't make it easy for end users to find out exactly how FOP
interprets specific features.
Again, I think what would help end-users a lot (and also have good tutorial
value) would be small self-describing XSL-FO documents where one can check
the results by reading the PDF, along with an "official" list of which
samples work and which don't.
Nice and well, but I don't think anyone on the FOP team currently has time to
fully set this up (but I'd be happy to be proven wrong!).
There are quite a lot of FOP samples already
(http://xml.apache.org/fop/examples.html), some more useful than others, so
maybe it's just a case of sorting through the samples, classifying them and
making them easily accessible, ideally using a live Internet-accessible FOP
setup.
In the meantime, I'd encourage users that find a bug or problem to send to
this list the smallest possible XSL-FO document that demonstrates the
problem. We could start collecting these in the hope of setting up a
user-friendly demo/test suite when someone finds time to do it.
- Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Basic aspects (big fat list vs. live test documents)
Posted by Matthias Fischer <m....@abc-media.de>.
Great!
What are _your_ plans with regard to the material offered by W3C/Carmelo?
How are tests conducted? Is there a check list according to which one could
record/submit test results systematically?
Do you think, the access of the database by FOP users (and not necessarily
developers) can be enhanced in order to permit easier spotting of single
test pieces relevant to a user's specific problem?
These questions are what comes to my mind after heaving visited the site.
Matthias
-----Original Message-----
From: Carmelo Montanez [mailto:carmelo@nist.gov]
Sent: Friday, December 14, 2001 8:43 PM
To: fop-dev@xml.apache.org; bdelacretaz@codeconsult.ch; Matthias Fischer
Subject: Re: Basic aspects (big fat list vs. live test documents)
Hi all:
Regarding the FO test suite. We at NIST in conjunction with the W3C
Developed
a test suite for FO. The site is:
www.w3.org/Style/XSL/TestSuite/
We are also working on expanding that work to include ALL of the basic
aspects of the language. We expect to have close to 5000 tests by
next march. Any contributions, ideas, etc. will be
appreciated.
Thanks
Carmelo Montanez
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Basic aspects (big fat list vs. live test documents)
Posted by Carmelo Montanez <ca...@nist.gov>.
Hi all:
Regarding the FO test suite. We at NIST in conjunction with the W3C
Developed
a test suite for FO. The site is:
www.w3.org/Style/XSL/TestSuite/
We are also working on expanding that work to include ALL of the basic
aspects of the language. We expect to have close to 5000 tests by
next march. Any contributions, ideas, etc. will be
appreciated.
Thanks
Carmelo Montanez
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Basic aspects (big fat list vs. live test documents)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Friday 14 December 2001 10:05, Matthias Fischer wrote:
> However, you won't escape "big maintenance" so easily:
Right - maintaining such a test suite is not light work.
The advantage over pure documentation, however, is that both users and
developers directly benefit from having strong test documents.
So I think it would be easier to get the FOP community to work on building
such a test suite (or organize/document existing tests) than finding someone
to write and maintain documentation.
--
-- Bertrand Delacrétaz, www.codeconsult.ch
-- web technologies consultant - OO, Java, XML, C++
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Basic aspects (big fat list vs. live test documents)
Posted by Matthias Fischer <m....@abc-media.de>.
Not all too bad, I think - if I have understood you right.
One of the unbcertainties in most of the problematic stages of our work was
that we didn't know whether _we_ had commited an error, FOP didn't implement
some FO feature, or none of the examples we relied on was correct. A
database where to look for working examples would be of great help in these
cases.
However, you won't escape "big maintenance" so easily: Would you allow
everybody to send his/her examples uncontrolled, i.e. not really knowing
whether the stuff works or not (read: under certain circumstances works,
under others not)? Would you index the examples for easier
navigation/searching? How would outdated examples be deleted in front of
innovations of the W3C spec, or simply new programming insights by someone
contributing to the database? Santa Clause would need some helpers, he
certainly can't do it all by himself ;-)
Matthias
-----Original Message-----
From: Bertrand Delacretaz [mailto:bdelacretaz@codeconsult.ch]
Sent: Friday, December 14, 2001 8:22 AM
To: fop-dev@xml.apache.org
Subject: Re: Basic aspects (big fat list vs. live test documents)
On Thursday 13 December 2001 15:35, Matthias Fischer wrote:
> . . .
> My whish to Santa Clause this year: A big fat list containing all major
> graphic formats and the FO/FOP-related aspects that concern them.
> . . .
I'm skeptical: to me "big fat list" means "big maintenance work" and usually
"out-of-sync list".
I'd rather have many small, focused, self-documented, numbered XSL-FO
example
files that show what works and what doesn't in FOP (note that I haven't
looked at our test files for a while - maybe it's there already?).
Maybe a live FOP system where users can post a ZIP containing XSL:FO +
graphics files and get back the PDF?
(got to tell Santa Claus about this one ;-)
Such examples could be donated by users after they find that a particular
feature works or not, with a standard mail header ([TESTDOC] ?) that would
help committers sort out these files.
Any thoughts?
--
-- Bertrand Delacrétaz, www.codeconsult.ch
-- web technologies consultant - OO, Java, XML, C++
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Basic aspects (big fat list vs. live test documents)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Thursday 13 December 2001 15:35, Matthias Fischer wrote:
> . . .
> My whish to Santa Clause this year: A big fat list containing all major
> graphic formats and the FO/FOP-related aspects that concern them.
> . . .
I'm skeptical: to me "big fat list" means "big maintenance work" and usually
"out-of-sync list".
I'd rather have many small, focused, self-documented, numbered XSL-FO example
files that show what works and what doesn't in FOP (note that I haven't
looked at our test files for a while - maybe it's there already?).
Maybe a live FOP system where users can post a ZIP containing XSL:FO +
graphics files and get back the PDF?
(got to tell Santa Claus about this one ;-)
Such examples could be donated by users after they find that a particular
feature works or not, with a standard mail header ([TESTDOC] ?) that would
help committers sort out these files.
Any thoughts?
--
-- Bertrand Delacrétaz, www.codeconsult.ch
-- web technologies consultant - OO, Java, XML, C++
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Basic aspects
Posted by Matthias Fischer <m....@abc-media.de>.
Not entirely correct, Arved. I'm not a great specialist on literature, but I
recall reading Tortilla Flat by J. Steinbeck at school. I remember a woman
in the story who faked to clean her flat with a vacuum cleaner - the _first_
vacuum cleaner in Tortilla Flat - although there was no electricity in the
entire quarter...
The FOP documentation "problem", as I see it, is a combination of different
factors. It has happened to us quite frequently that something didn't work,
and we had to
1 find documentation on FO which supplied us with, say for instance, 2
contradictory statements on the syntax of an attribute; neither worked
2 assume devoutly that we had committed an error (true in 50% of the cases)
3 find out, whether someone would understand our problem and give us a
solution
4 still have problems
5 back to 1
Sometimes the source of the problem was that a feature of FO wasn't
implemented, or that it wasn't implemented with a certain FOP version; that
a problem was due to performance problems; that I didn't succeed in
articulating what I needed so that someone would understand it, or that
answers wheren't formulated in a way that I understood them etc. etc.
You can immagine that, for instance, non-appearing graphics lead into
intensive testing with regard to (a) the behaviour of FOP/Cocoon under
different Windows versions (b) different compressions of graphic files -
nothing. Then someone in the list tells you, the region containing a graphic
must be big enough, otherwise FOP tacitly drops the picture. Hormons of
happiness spread throughout the office. The result: some files appear, some
not. Why? Questions, counter-questions and counter-counter-questions to the
list: because FOP does with GIF's so and so, and with TIFF's so and so etc.
Ok. Learn everything you didn't know about graphic formats. Implement it.
Wait 10 minutes, and you don't get your file compiled.
Testing-testing-testing: no significant result. Question-question-question:
because of a performance problem. How to solve it? Hmmm... - Another session
of questions and counter-questions bothering other people while they try to
do honest work. The hapiness-generating answer: portion the stuff you send
through the processor. How? Does anybody know how to accomplish this? Please
help... - Etc. etc. etc.
I quoted the example of graphics because it was the most nerve-consuming.
Nevertheless, by far it wasn't the only one.
My whish to Santa Clause this year: A big fat list containing all major
graphic formats and the FO/FOP-related aspects that concern them. Right on
the FOP page where everybody cannot avoid to take notice. With a big, red or
yellow triangled exclamation mark and the wording: Hey, dummies (like me):
before you get into this business, think of what you wanna achieve and
consider these warnings, or it'll cost you real time+effort=money!
Imagine a database outputting a table with all the FO commands in one column
and updated, fresh-of-the-day remarks, warnings, examples etc. like above in
the example. Enhanced, XML-based search functions. Sit back, take a drink,
and find in a second all the bottlenecks that would have otherwise broken
your neck.
Am I a dreamer? Yes, I am.
Can dreams come true? Yes, they can.
Matthias
-----Original Message-----
From: Arved Sandstrom [mailto:Arved_37@chebucto.ns.ca]
Sent: Thursday, December 13, 2001 2:50 PM
To: fop-dev@xml.apache.org
Subject: Re: Basic aspects
[...]
When you say "documentation", I take it you mean operating instructions,
rather than stuff about XSL per se. Correct?
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Basic aspects
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
If I can specifically address one point, it is that I am curious about why
you think FOP is web-oriented at all.
If FOP is invoked from a servlet, which seems to be a popular mechanism,
then the output is indeed being delivered to Web browsers. Unless things are
different in Cocoon 2, Cocoon itself is nothing but a high-powered servlet
that uses FOP just like this.
But FOP itself has never been Web-oriented. HTML has never been produced by
any of the renderers. Nor WML or HDML or anything else Webbish. The initial
paragraphs on the main page (http://xml.apache.org/fop/index.html) do not
mention these formats at all. Speaking for myself I have always viewed FOP
as a print publishing tool, focused on producing print-quality documents.
I would not characterize PDF as web-oriented, not in the sense you mean. It
started out as a page description language, and it is stil a page
description language. It has design features that promote electronic
delivery, and this if anything makes it "web-compatible". Now, I've used PDF
since Reader 2.0, I worked for 2 years at a shop where we were intimately
familiar with PDF and did lots of early programmatic stuff with PDF (in
Perl, mostly) before the explosion of useful tools (including any Perl PDF
modules), and the PDF we produced had to be very high-quality for print
purposes. We also used extremely large TIFF files as the basis for PDF
images in those documents. So PDF may have some limitations, but I agree
that if anyone is bottlenecked right now they are probably bottlenecked
because of FOP, not because of PDF. That is, performance limitations.
I think Keiron and Karen, among others, would agree that the object of the
rewrite that they are spearheading is to allow other developers to more
usefully contribute. This should go a long ways to letting more people get
at the code.
When you say "documentation", I take it you mean operating instructions,
rather than stuff about XSL per se. Correct?
Regards,
Arved Sandstrom
----- Original Message -----
From: "Matthias Fischer" <m....@abc-media.de>
To: <fo...@xml.apache.org>
Sent: Thursday, December 13, 2001 5:27 AM
Subject: Basic aspects
> Hallo developers,
>
> I think I should give my contribution in backing Keiron's statement.
Please
> note that this is not some kind of a stuck-up, disengaged spectator's
point
> of view. I think the FOP developers have done a great job, sacrificing
time
> and money to achieve what has been achieved, and - as a beneficiary of
it -
> I'd like to thank you for it cordially. I also would like to express
> gratefulness towards those who helped my colleagues and me in our wading
> through the difficulties we met on our way.
>
> To help you to understand better who speaks: I am not a thorough-bred
> programmer. As a consultant, I'm trying to analyze different customers's
> needs, and as the mentor of my own company's programmers I develop ideas
and
> help my colleagues in persuing these objectives.
>
> There are no programmers in our company capable of messing with the source
> code of Cocoon, or FOP, or anything linked to it. Therefore, sometimes FOP
> is to us like a black box, which doesn't make things easier.
>
> As a user, or "customer", however, I could express some clearcut opinions
> which might be interesting feedback for FOP developers:
>
> - Documentation. I know, there is no entitlement to documentation, or to
> anything else, in an open-source project. Nevertheless, I found that (a)
W3C
> specs are great, but envisage no practical approach for those, like us,
who
> are not the ultimate specialists; (b) books seem to be scarce, contain
> sometimes wrong or misleading information, are too superficial in their
> examples, i.e. show what anyone would retrieve from somewhere in the
> internet anyhow, and not always are systematic. It has cost us thousands
and
> thousands of Euros to get hold of simple, necessary-to-operate
information.
> Something like "SelfHTML", a site very popular among German HTML
designers,
> would be needed.
> - Sometimes, I have the impression that FOP is a bit too web-oriented. I
> don't know whether it's true, but both my colleagues and I, at a certain
> point, got the impression that, when the HTML output side was finished,
> somebody said: "And what are we going to do next?", with someone else
> answering: "Let's do PDF". Of course, PDF is, first of all, a "portable"
> data format, i.e. it's web-oriented. But, more and more, it is used for
> typographical purposes. However, it is not possible to get anywhere near
to
> printshop quality unless EPS and TIFF files of a certain resolution rate
can
> be used. However, using twenty TIFFs of 1MB each puts FOP k.o. in a few
> milliseconds. due to my own experience, FOP seems designed to be uses with
> JPG/GIF pictures at 72dpi which look fine through the internet and on an
> ordinary office printer. Or take hyphenation: given the number of
languages
> involved, certainly not an easy task. On the other hand, if hyphenation
does
> not work properly - and we havent't got it to work properly with the W3C
> spec's language and country attributes for German and Germany - the output
> scores a further little minus
>
(thinkofthoselongGermanwordswhich-iftheysliptothenextline-dontlooktoowell...
> ), and these minus points accumulate.
>
> Please let me underline at this point that FOP is held by us a valuable
and
> very useful invention. We'll continue to utilize it, and we'll propagate
the
> use of it. Nevertheless, it would be encouraging to see the effort, which
is
> necessary to get it on its way, being reduced.
> You might reply: "So, why don't you get involved and help making it
better?"
> Rightly so. The answer is: I can't, I haven't got the expertise. What I
can
> do, I've done - to utter my point of view with some detail.
>
> Cordially
>
> Matthias
>
>
> -----Original Message-----
> From: Keiron Liddle [mailto:keiron@aftexsw.com]
> Sent: Wednesday, December 12, 2001 3:55 PM
> To: fop-dev@xml.apache.org
> Subject: Re: need help
>
>
> [...]
>
> While that is true there are certain things you need to realise.
> - there are serious layout issues that need to be addressed
> - performance and memory is very much tied up to how the whole system
> works, this makes it difficult to fix
> - getting FOP to a stage where there is a clear development direction is
> difficult
> - none of this will happen by itself
>
> It appears that more effort needs to be put towards communicating the
> issues involved and the way in which FOP can be improved.
>
> Yes it does need to be much better.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Basic aspects
Posted by Matthias Fischer <m....@abc-media.de>.
Hallo developers,
I think I should give my contribution in backing Keiron's statement. Please
note that this is not some kind of a stuck-up, disengaged spectator's point
of view. I think the FOP developers have done a great job, sacrificing time
and money to achieve what has been achieved, and - as a beneficiary of it -
I'd like to thank you for it cordially. I also would like to express
gratefulness towards those who helped my colleagues and me in our wading
through the difficulties we met on our way.
To help you to understand better who speaks: I am not a thorough-bred
programmer. As a consultant, I'm trying to analyze different customers's
needs, and as the mentor of my own company's programmers I develop ideas and
help my colleagues in persuing these objectives.
There are no programmers in our company capable of messing with the source
code of Cocoon, or FOP, or anything linked to it. Therefore, sometimes FOP
is to us like a black box, which doesn't make things easier.
As a user, or "customer", however, I could express some clearcut opinions
which might be interesting feedback for FOP developers:
- Documentation. I know, there is no entitlement to documentation, or to
anything else, in an open-source project. Nevertheless, I found that (a) W3C
specs are great, but envisage no practical approach for those, like us, who
are not the ultimate specialists; (b) books seem to be scarce, contain
sometimes wrong or misleading information, are too superficial in their
examples, i.e. show what anyone would retrieve from somewhere in the
internet anyhow, and not always are systematic. It has cost us thousands and
thousands of Euros to get hold of simple, necessary-to-operate information.
Something like "SelfHTML", a site very popular among German HTML designers,
would be needed.
- Sometimes, I have the impression that FOP is a bit too web-oriented. I
don't know whether it's true, but both my colleagues and I, at a certain
point, got the impression that, when the HTML output side was finished,
somebody said: "And what are we going to do next?", with someone else
answering: "Let's do PDF". Of course, PDF is, first of all, a "portable"
data format, i.e. it's web-oriented. But, more and more, it is used for
typographical purposes. However, it is not possible to get anywhere near to
printshop quality unless EPS and TIFF files of a certain resolution rate can
be used. However, using twenty TIFFs of 1MB each puts FOP k.o. in a few
milliseconds. due to my own experience, FOP seems designed to be uses with
JPG/GIF pictures at 72dpi which look fine through the internet and on an
ordinary office printer. Or take hyphenation: given the number of languages
involved, certainly not an easy task. On the other hand, if hyphenation does
not work properly - and we havent't got it to work properly with the W3C
spec's language and country attributes for German and Germany - the output
scores a further little minus
(thinkofthoselongGermanwordswhich-iftheysliptothenextline-dontlooktoowell...
), and these minus points accumulate.
Please let me underline at this point that FOP is held by us a valuable and
very useful invention. We'll continue to utilize it, and we'll propagate the
use of it. Nevertheless, it would be encouraging to see the effort, which is
necessary to get it on its way, being reduced.
You might reply: "So, why don't you get involved and help making it better?"
Rightly so. The answer is: I can't, I haven't got the expertise. What I can
do, I've done - to utter my point of view with some detail.
Cordially
Matthias
-----Original Message-----
From: Keiron Liddle [mailto:keiron@aftexsw.com]
Sent: Wednesday, December 12, 2001 3:55 PM
To: fop-dev@xml.apache.org
Subject: Re: need help
[...]
While that is true there are certain things you need to realise.
- there are serious layout issues that need to be addressed
- performance and memory is very much tied up to how the whole system
works, this makes it difficult to fix
- getting FOP to a stage where there is a clear development direction is
difficult
- none of this will happen by itself
It appears that more effort needs to be put towards communicating the
issues involved and the way in which FOP can be improved.
Yes it does need to be much better.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: need help
Posted by Cyril Rognon <cr...@objectiva.fr>.
Keiron,
Maybe Ed went a little too far about this.
of course I do not request immediate magical memory solution that would
enable me to generate my pdf on a cell phone :)
I have read in this list that some people have 200+ pages documents with
low memory footprint (around 20-50 Mo). I just want to know if someone
could give me any hints of achieving a nice FOP generation within 128 Mo
knowing that I am using page sequences under 15 pages.
Thanks in advance.
As for me, the speed of FOP is not an issue. The memory would not be an
issue if I had not a physical limit of 128Mo for now (too many units involved).
At 15:54 12/12/2001 +0100, you wrote:
>On 2001.12.12 15:39 Ed Howland wrote:
>>In researching this, I found the "Driver.setBufferFile(File buf)" method.
>>I've
>>set this, but it doesn't seem to work. There are no Javadocs on it. I've
>>looked
>>at the code but I don't think its being actively called by the renderer.
>>Does anybody know the intent and design of this function? Do any
>>developers
>>know if it will be implemented soon?
>
>This was not a full or solid solution and was disabled due to problems.
>
>>FOP is great, but it requires way too much kid gloving when it comes to
>>performance and memory utilization. I read a note a while back (2000 I
>>think)
>>that someone said they were trying to achieve 100% conformance with the
>>spec
>>before they addressed these issues. I might agree with that, but few web
>>browsers were 100% compliant with W3C standards before they were used
>>daily by
>>10s of millions of users. FOP is in a good enough state to be useful in
>>production environments. Isn't it time to address the scalability aspects
>>of
>>FOP to meet those needs?
>>I suggest that "out of the box" FOP needs to manage its own resources
>>much
>>better. XSLT is already a drain.
>
>While that is true there are certain things you need to realise.
>- there are serious layout issues that need to be addressed
>- performance and memory is very much tied up to how the whole system
>works, this makes it difficult to fix
>- getting FOP to a stage where there is a clear development direction is
>difficult
>- none of this will happen by itself
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: need help
Posted by Keiron Liddle <ke...@aftexsw.com>.
On 2001.12.12 15:39 Ed Howland wrote:
> In researching this, I found the "Driver.setBufferFile(File buf)" method.
> I've
> set this, but it doesn't seem to work. There are no Javadocs on it. I've
> looked
> at the code but I don't think its being actively called by the renderer.
>
> Does anybody know the intent and design of this function? Do any
> developers
> know if it will be implemented soon?
This was not a full or solid solution and was disabled due to problems.
> FOP is great, but it requires way too much kid gloving when it comes to
> performance and memory utilization. I read a note a while back (2000 I
> think)
> that someone said they were trying to achieve 100% conformance with the
> spec
> before they addressed these issues. I might agree with that, but few web
> browsers were 100% compliant with W3C standards before they were used
> daily by
> 10s of millions of users. FOP is in a good enough state to be useful in
> production environments. Isn't it time to address the scalability aspects
> of
> FOP to meet those needs?
>
> I suggest that "out of the box" FOP needs to manage its own resources
> much
> better. XSLT is already a drain.
While that is true there are certain things you need to realise.
- there are serious layout issues that need to be addressed
- performance and memory is very much tied up to how the whole system
works, this makes it difficult to fix
- getting FOP to a stage where there is a clear development direction is
difficult
- none of this will happen by itself
It appears that more effort needs to be put towards communicating the
issues involved and the way in which FOP can be improved.
Yes it does need to be much better.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: need help
Posted by Ed Howland <ul...@yahoo.com>.
I have the same problem but I could not easily change the XSLT to generate
different page sequences. (The data is tables from a DB that go into a report.)
However, since the PDFs are to be viewed only online, I split the input (with
position()) and generate multiple page sets. That way no one PDF stream is more
than a few hundred kilobytes over a 56k connection.
In researching this, I found the "Driver.setBufferFile(File buf)" method. I've
set this, but it doesn't seem to work. There are no Javadocs on it. I've looked
at the code but I don't think its being actively called by the renderer.
Does anybody know the intent and design of this function? Do any developers
know if it will be implemented soon?
FOP is great, but it requires way too much kid gloving when it comes to
performance and memory utilization. I read a note a while back (2000 I think)
that someone said they were trying to achieve 100% conformance with the spec
before they addressed these issues. I might agree with that, but few web
browsers were 100% compliant with W3C standards before they were used daily by
10s of millions of users. FOP is in a good enough state to be useful in
production environments. Isn't it time to address the scalability aspects of
FOP to meet those needs?
I suggest that "out of the box" FOP needs to manage its own resources much
better. XSLT is already a drain.
Ed
--- Cyril Rognon <cr...@objectiva.fr> wrote:
> Hello,
>
> I have already posted a message about memory issue but it went unseen.
>
> My problem is : I have 50-500 pages document to generate. Fop handles this
> perfectly and fastly (1200 ms / page average).
>
> I just have one draw back : I need to provide much memory to FOP.
>
> I have managed to have no more than 20 pages in each page sequences and yet
> need more than 128 Mo for a 81 pages document.
>
> I wloud like to know if someone can help or tell me where to look to
> downsize my memory requierments. If I succeed, Fop will be heavily used in
> a production environnement.
>
> Thanks
>
> Cyril
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
need help
Posted by Cyril Rognon <cr...@objectiva.fr>.
Hello,
I have already posted a message about memory issue but it went unseen.
My problem is : I have 50-500 pages document to generate. Fop handles this
perfectly and fastly (1200 ms / page average).
I just have one draw back : I need to provide much memory to FOP.
I have managed to have no more than 20 pages in each page sequences and yet
need more than 128 Mo for a 81 pages document.
I wloud like to know if someone can help or tell me where to look to
downsize my memory requierments. If I succeed, Fop will be heavily used in
a production environnement.
Thanks
Cyril
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
FOP memory foot print
Posted by Cyril Rognon <cr...@objectiva.fr>.
Hi list,
I have been using fop for some time now to produce small documents. Now I
have to generate medium size (50-500 pages) ones and at my surprise, I do
have a memory footprint problem.
I have managed to use as much page-sequence I could to "reduce" the fop's
needed memory as this list suggests, and yet for a 80 pages document with 7
long page sequences wich contain 11 pages each I need 115 Mo for the JVM...
I have a TOC in a previous page-sequence that use page-number-citation that
reffer to each of the big page-sequence start. Maybe that's where my
memory goes mad...
is there some option I am not using ?
I thought there was a buffering option that could do the trick but the -buf
buff.file did nothing.
I a sure fop can do better than this.
Could anyone point me to some info about this please ?
Thanks
Cyril Rognon
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: number of pages generated
Posted by Jeremias Maerki <je...@outline.ch>.
On 11 Dec 2001 14:04:45 +0100 Laurent Vaills wrote:
> Ok but I need it now :-(
You could apply the patch to you local copy of FOP yourself. If you
don't have the ZIP from my proposal I'd send it to you.
> I am using fop to generate a postscript file and to know how many pages
> have been generated.
>
> Therefore I have some 'bugs' in the generated Postscript. I got 'Creator
> null', and it seems thare information about pages are missing.
Sorry, but I don't understand what you mean. Could you explain a bit
more detailed?
> Laurent
>
> On Tue, 2001-12-11 at 13:51, Jeremias Maerki wrote:
> > Yes, with the "FormattingResults" proposal I submitted on 2001-12-04
> > this would be possible. I'm still hoping one of the committers might
> > consider integrating it in FOP.
> >
> >
> > On 11 Dec 2001 13:34:27 +0100 Laurent Vaills wrote:
> > > Is there a way to get the number of pages generated after driver.run() ?
> >
> > Cheers,
> > OUTLINE AG
> > Jeremias Märki
> >
> > mailto:jeremias.maerki@outline.ch
> >
> > Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
> > Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
> > Internet http://www.outline.ch
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> > For additional commands, email: fop-dev-help@xml.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
Freundliche Grüsse
OUTLINE AG
Jeremias Märki
mailto:jeremias.maerki@outline.ch
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
Internet http://www.outline.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: number of pages generated
Posted by Laurent Vaills <la...@laposte.net>.
Ok but I need it now :-(
I am using fop to generate a postscript file and to know how many pages
have been generated.
Therefore I have some 'bugs' in the generated Postscript. I got 'Creator
null', and it seems thare information about pages are missing.
Laurent
On Tue, 2001-12-11 at 13:51, Jeremias Maerki wrote:
> Yes, with the "FormattingResults" proposal I submitted on 2001-12-04
> this would be possible. I'm still hoping one of the committers might
> consider integrating it in FOP.
>
>
> On 11 Dec 2001 13:34:27 +0100 Laurent Vaills wrote:
> > Is there a way to get the number of pages generated after driver.run() ?
>
> Cheers,
> OUTLINE AG
> Jeremias Märki
>
> mailto:jeremias.maerki@outline.ch
>
> Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
> Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
> Internet http://www.outline.ch
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: number of pages generated
Posted by Jeremias Maerki <je...@outline.ch>.
Yes, with the "FormattingResults" proposal I submitted on 2001-12-04
this would be possible. I'm still hoping one of the committers might
consider integrating it in FOP.
On 11 Dec 2001 13:34:27 +0100 Laurent Vaills wrote:
> Is there a way to get the number of pages generated after driver.run() ?
Cheers,
OUTLINE AG
Jeremias Märki
mailto:jeremias.maerki@outline.ch
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
Internet http://www.outline.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org