I just took care of it--you may need to refresh PSLM
in the marker patch though as I did some minor changes
in that class as well.
BTW, I'd like to remove "String
getCurrentPageNumber();" from the LayoutManager
interface and replace it with "PageSequence
getCurrentPageSequence()". The latter offe
Glen,
no, that's ok. Thanks for the review. I've removed my change locally and
will commit either tomorrow or on Monday. I can't commit right now
because it overlaps with my changes for the marker problem where I still
hope for another comment.
On 05.02.2005 04:11:10 Glen Mazza wrote:
> Jeremias,
Jeremias,
We are using this pageCount statistic only at
endDocument() in ATH, i.e., when the document is
complete. Any problem with us just relying on the
rootFObj.getRunningPageNumberCounter() in
endDocument() instead of this page-by-page callback
(i.e., get rid of pageCount in ATH)? I would li
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
>
> I have contained
> its effect by catching the exception, and have not
> explored the stack
> of methods that may need to declare the throwing of
> an exception. That
> is a problem in its own right, to be solved at
> another moment.
>
OK...sorry t
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
> Glen,
>
> In my view the FO system knows nothing about the LM
> system.
It appears that you've just made a friend in Colorado.
;)
> That is
> how the LM system can be pluggable.
Not really, it can still be pluggable if you have
addLayoutManager
Glen,
On Mon, Dec 27, 2004 at 06:55:01AM -0800, Glen Mazza wrote:
> Simon,
>
> Why aren't these fatal errors--what's the gain in
> having FOP continue running in an invalid state?
>
> One-in-a-million bugs like these that occur for
> inexplicable reasons should raise an
> IllegalStateException a
Glen,
In my view the FO system knows nothing about the LM system. That is
how the LM system can be pluggable. The FO system sets itself up and
waits if any subsequent system finds it useful. Its only connection
with the subsequent system is that it sends FO events to its
FOEventHandler.
The LM sy
This doesn't seem appropriate--the business logic to
determine whether or not a layout manager is needed
for a particular FO should be within that FO object,
where it reads its own private variables--in whatever
manner it is internally constucted--and makes its own
determination.
Otherwise (1) you
Simon,
Why aren't these fatal errors--what's the gain in
having FOP continue running in an invalid state?
One-in-a-million bugs like these that occur for
inexplicable reasons should raise an
IllegalStateException and halt. FOP should not
continue running after catastrophic failures.
Glen
--- [
