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.
Created attachment 18489 [details] fo file to reproduce error message
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.
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.
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.
*** Bug 39870 has been marked as a duplicate of this bug. ***
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
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.
(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
*** Bug 41841 has been marked as a duplicate of this bug. ***
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
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