THANKS! I'll start with the patch, then leader, then revisit indent
property and report first success.
My apologies for conflating two issues in this thread. I had no
business presuming they were related.
rjs
On 08/22/2012 04:23 AM, Vincent Hennebert wrote:
On 20/08/12 16:05, Rob Sargent wrote:
Do we agree that this portion of the thread (small data loss at page break)
really is an issue?
Yes, this is due to the text-indent property set on the block that is
broken over the two pages, that doesn't play well with the changing IPD
code.
You can:
. Remove the text-indent property, if you can live with the start of the
paragraph being flush with the left margin;
. Replace the text-indent with an <fo:leader leader-length="{the value
of the text indent}/> at the beginning of the block. This might be
tricky as there must be no whitespace whatsoever between that
fo:leader and the word starting the paragraph. Also, I may have
overlooked undesirable side effects. But it may be worth a try.
. Avoid creating page masters where the region-body only has one column.
That triggers the changing IPD hack that is notoriously buggy. Note
that in theory the trigger shouldn't be made, as your columns all have
the same width (I believe). But there's another bug in FOP where the
number of columns on a region-body is not taken into account when
determining whether the IPD changes or not.
So in the present case, FOP compares the width of the region-body on
the first page to the width of the region-body on the second page,
which are different since the second region-body has a big left margin
to leave space to the region-start.
. Apply the attached patch and hope that it doesn't break anything else.
It resets a few variables to account for the fact that the first line
of the block has already been rendered.
HTH,
Vincent
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
