Meanwhile...
IT WORKS. I set column-count to 1 and set the (derogatory remark
redacted) MAX_RECOVERY_ATTEMPTS to 10, which was lucky because by the
time I got back to the original document it had 7 text-free pages in
succession.
Now, recall the title of this thread (swapping loss for lose of course):
I had hoped that the two issues were related but no such luck. I expect
to have a funky-font free example by end of day. This is a real problem
here and I have a sinking feeling that I cannot correct it with layout
tricks.
Thanks a ton,
rjs
On 08/15/2012 02:47 AM, Vincent Hennebert wrote:
On 14/08/12 23:20, Glenn Adams wrote:
On Tue, Aug 14, 2012 at 1:23 PM, Vincent Hennebert <vhenneb...@gmail.com>wrote:
If this is still not enough, then you can change the
MAX_RECOVERY_ATTEMPTS constant in
src/java/org/apache/fop/layoutmgr/BreakingAlgorithm.java to whatever
suits your needs. Note that this constant is also used for line
breaking, so you may want to keep it reasonably low in order to reduce
the impact on performance. Something as small as 10 might be more than
enough for your needs.
Is it worth introducing the ability for the FOP operator to specify the
maximum recovery attempts via fop.xconf? Is it worth dividing this into two
settings, one for page breaking, another for line breaking?
I don’t think it’s worth the additional complexity of wiring a look-up
to a configuration variable. I’d rather implement a more intelligent
analysis of the page sequence to determine if there will be an infinite
loop or not.
I'd prefer not to have non-configurable magic numbers of this sort if
possible.
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
