Bug 39840 - Multi page table fails with an endless loop error message
Multi page table fails with an endless loop error message
Status: CLOSED WORKSFORME
Product: Fop - Now in Jira
Classification: Unclassified
Component: pdf
trunk
PC Windows XP
: P2 critical
: ---
Assigned To: fop-dev
: ErrorMessage
: 39870 41841 (view as bug list)
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2006-06-20 03:42 UTC by Pavel Ganelin
Modified: 2012-04-30 00:19 UTC (History)
3 users (show)



Attachments
fo file to reproduce error message (3.71 KB, application/octet-stream)
2006-06-20 03:44 UTC, Pavel Ganelin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Ganelin 2006-06-20 03:42:29 UTC
From the README file:
 - Auto table layout is not implemented, yet.

I have a table which does not fit into a single page. I am not sure whether it
is the same issue as item from README. Just i case I report a bug. FO file is
attached. It is running fine in fop -0.20.5. Does not work in both fop-0.92betae
and fop-trunk.
gives the following error

================
doc:
      [fop] target\doc\bad.fo -> target\doc\bad.pdf
      [fop] Jun 19, 2006 11:33:27 PM org.apache.fop.hyphenation.Hyphenator
getHyphenationTree
      [fop] SEVERE: Couldn't find hyphenation pattern en
      [fop] Jun 19, 2006 11:33:27 PM org.apache.fop.cli.InputHandler error
      [fop] SEVERE: javax.xml.transform.TransformerException: Some content could
not fit into a line/page after 50 attempts.
      Giving up to avoid an endless loop. (fo:block, location: 1/40356)

BUILD FAILED
D:\DONGE\EmuJ\build.xml:387: javax.xml.transform.TransformerException:
java.lang.RuntimeException: Some content could no
t fit into a line/page after 50 attempts. Giving up to avoid an endless loop.
(fo:block, location: 1/40356)


=====================

File originall was generated from docbook using xm-1.70.1 stylesheets.
Comment 1 Pavel Ganelin 2006-06-20 03:44:26 UTC
Created attachment 18489 [details]
fo file to reproduce error message
Comment 2 Jeremias Maerki 2006-06-20 19:35:43 UTC
The document is littered with keeps. You don't give FOP a chance to break
anywhere. The worst of them is the keep-together on the block surrounding the
table. The table is longer than a page. That's why FOP fails. We're currently
discussing relaxing the keep conditions for these situations but the spec is a
little ambiguous about this. What you can do now is remove that keep-together
and let the table break. It has nothing to do with auto table layout. It's just
our current interpretation of the FO spec that may need to be revised.

Unless anybody objects I'll leave the bug open as an additional reminder for us
to go after this phenomenon. Funny coincidence anyway, that you file this entry
while we're already discussing the very problem.
Comment 3 Pavel Ganelin 2006-06-22 14:18:56 UTC
As I mentioned before I did not put all these keep. I used docbook-xsl-1.70.1
stylesheets to generate FO file from my docbook document. Now I am squeezed
between FOP and docbook-xsl-1.70.1 stylesheets neither of which I control. Just
a poor end user trying to create PDF files :-(

Two points to mention:
1. It is used to be working fine with FOP 0.20.5.
2. I can contribute my time and Java programming skills to help with fixing the
problem. 

I am very interested to updating from FOP 0.20.5 to the latest one, especially
now when it finally has widow/orphan control. Before generated documents looked
ugly with single line at the end of the page.
Comment 4 Jeremias Maerki 2006-06-26 14:43:30 UTC
We're still discussing the expected behaviours of keeps. We have some indication
that the behaviour of FOP 0.20.5 is actually not correct. On the other side the
latest code, should probably also behave differently. I think we will need to
run this by the XSL working group for clarification and then we need to fix FOP
accordingly. ATM, you will simply have to make sure that the keeps don't add up
to situations that would make FOP overflow the page and therefore trigger the
error under discussion here.
Comment 5 Jeremias Maerki 2006-07-10 12:36:53 UTC
*** Bug 39870 has been marked as a duplicate of this bug. ***
Comment 6 Jeremias Maerki 2006-08-04 15:17:02 UTC
I did a change [1] that removes the somewhat cryptic exception. Instead content
overflows the region-body's reference area according to the "overflow" property
on region-body. Note that this does NOT change the bahaviour of keeps. A keep
with a value of "always" will not allow the content to be broken. We hope to add
support for integer values for keeps later which will allow breaking content
with a keep constraint as defined in the FO spec.

[1] http://svn.apache.org/viewvc?rev=428750&view=rev
Comment 7 Barton Wright 2006-11-20 15:50:08 UTC
Please be aware that this bug is what is preventing my company from using FOP
for a new document build system based on DocBook 4.4 and DocBook-XSL 1.71.0. 

The exact same FO file generated by the DocBook XSL transforms into a PDF just
fine using (a) FOP 0.20.5 and (b) XEP 4.7. While the FO generated by DocBook XSL
may well be peculiar, other FO processors manage to get through it without Java
errors. Please don't blame the FO file. The error is clearly in FOP 0.92.
Comment 8 Vincent Hennebert 2006-11-21 00:29:21 UTC
(In reply to comment #7)
> Please be aware that this bug is what is preventing my company from using FOP
> for a new document build system based on DocBook 4.4 and DocBook-XSL 1.71.0. 

Keep in mind that Fop is open-source software and that you can improve it
yourself if there's a missing feature you need. Or have someone improve it for
you if you don't feel capable to.

> The exact same FO file generated by the DocBook XSL transforms into a PDF just
> fine using (a) FOP 0.20.5 and (b) XEP 4.7. While the FO generated by DocBook XSL
> may well be peculiar, other FO processors manage to get through it without Java
> errors. Please don't blame the FO file. The error is clearly in FOP 0.92.

Actually the behavior to adopt is implementation-dependant in such a case:
http://lists.w3.org/Archives/Public/xsl-editors/2006JulSep/0001.html

Granted, the result might not be desirable, but with Jeremias' latest change Fop
is now compliant. A possible workaround is described in the following thread and
may be of interest to you:
http://lists.oasis-open.org/archives/docbook-apps/200611/msg00142.html

Vincent Hennebert
Comment 9 Vincent Hennebert 2007-11-29 11:13:45 UTC
*** Bug 41841 has been marked as a duplicate of this bug. ***
Comment 10 Glenn Adams 2012-04-07 01:23:50 UTC
does not produce indicated error message in current trunk; if reporter feels there is a bug in keep behavior, then a new bug should be submitted
Comment 11 Glenn Adams 2012-04-30 00:19:39 UTC
batch transition resolved+worksforme to closed+worksforme; if you believe this
remains a bug and can demonstrate it with appropriate input FO file and output
PDF file (as applicable), then you may reopen