Interesting upshot: when a single-column textless page precedes the last
page (all text, 2 column) it appears thao FOP is um, er, forgetting to
go to two column mode. The last text page is filled with sentences which
run from border to border, then eventually the two column directive
kicks in and the second column is printed over the first (page-wide)
column. I can think of a couple of work-arounds (raise the
MAX_RECOVERY_ATTEMPTS to 20 and revert to two column) or make a new
layout definition for 'special textless pages near the end of a
chapter'. Regrettable nuisance either way.
Cheers,
rjs
On 08/15/2012 11:53 AM, Rob Sargent wrote:
And now we have attached the smallest possible fo, with only
font-family="any" which shows the spurious text loss across a page
break. Note that the top of page 2 is slightly indented (not our
intent) and is missing text (in this case the single word "appears").
I'm tempted to include the pdf (generated with 1.1rc1-VHx2) but won't
until I here you're not able to reproduce the problem!
Cheers,
rjs
On 08/15/2012 09:14 AM, Rob Sargent wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
