If you're getting the "Some content could not fit..." message it simply
means that you have keep constraints in your document that glue a set of
elements together in a way that they are longer than the available space
on one page. There's no chance that adjusting the number "50" will help
you in any way. 50 is the number of times FOP will attempt to move the
whole content that is kept together to a later page in the hopes that
there will come a longer page from the page-sequence-master. That number
"50" was way to high in the first place and this is removed in the
latest code anyway. Current FOP Trunk will simply let your page overflow
and display a slightly different warning message. The overflow property
on simple-page-master will control how FOP will react to this situation
(i.e. "hidden", "visible" or "error-if-overflow").

As soon as I have time I'll refine the keep implementation so you can
specify integer values instead of "always" to achieve a less than
absolute keep which will allow to break apart your otherwise unbreakable
content (because of your keeps).

So, in short, remove some keeps until the error goes away. You've got
too many. :-)

On 10.08.2006 22:47:11 Zaleski, Matthew \(M.E.\) wrote:
> 
> > -----Original Message-----
> > From: Andreas L Delmelle [mailto:[EMAIL PROTECTED] 
> > 
> > On Aug 8, 2006, at 22:27, Zaleski, Matthew (M.E.) wrote:
> > 
> > Hi,
> > 
> 
> Thanks for the reply.
> 
> 
> > > One feature that seems to be still under development is the 
> > > keep-with-next / keep-with-previous attributes.  From the 
> > conformance 
> > > table on the FOP website it wasn't clear if those 
> > attributes works on
> > > *any* of the table features.  Is that a correct conclusion?
> > 
> > Not entirely. From what I could dig up in the archives, 
> > keep-together and keep-with-next should work on table 
> > nodes... It's only keep-with- previous that has the mentioned 
> > restriction.
> 
> I'm having problems with keep-with-next attribute on <fo:table-row>.
> It's triggering "java.lang.RuntimeException: Some content could not fit
> into a line/page after 50 attempts. Giving up to avoid an endless loop."
> that I don't think I should be getting as each table is small enough.
> > 
> > > Is there a work-around to hold a table together and not get broken 
> > > across pages?
> > 
> > See above. Chances are you may not need a workaround.
> > 
> > At any rate: if you're using the table only as the 0.20.5 
> > workaround for keep-together, then you might consider 
> > switching to a block structure.
> > 
> 
> Yes, I do have plenty of workaround <fo:table> entries in my XSL
> templates.  However, I truly am designing a series of tables anyways so
> it's not like I didn't need table elements.  There is still a fair
> amount of nesting of tables to achieve my current layout.  I really need
> the table column attribute text-align="<string>" but that hasn't been
> implemented in any of the FOP versions to date (understandably so as
> that has to be pretty difficult to implement).  So I make do with tables
> within my cells to do pseudo text-align for my columns of numbers
> containing decimal points.  I also have a "wrapper" table around my
> tables to attach a table caption as well as (more importantly) some
> additional formatting of a variable number of summary tables that need
> to be attached to what a normal person would call a table.
> 
> I tried putting keep-together="always" on my top-level <fo:table>
> elements and I got the same failure as with keep-with-next attributes on
> <fo:table-row>.  Without the "keep-*" attributes, the PDF gets generated
> and it is obvious that each table is small enough to fit.  I had been
> using keep-with-previous="<number>" with 0.20.5 to better control page
> breaks when a table got too big for a page.
> 
> I'm now wondering if changing the "attempt limit" to something higher
> than 50 would solve my problem.  The number of nested tables may be
> impacting the break detection code.  Now I just need to figure out if I
> can change that limit of 50 via some Java method.
> 
> --Matthew Zaleski


Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to