Re: keep...=always and Knuth penalties
On Wed, 2006-06-21 at 16:50 +0200, Jeremias Maerki wrote: Have you tried the Disposition of Comments? I don't know how accessible they are to Google. They are accessible through the list archive at W3C. I've looked at those I found but I found no listing of all XSL-related ones. Jeremias, I'm not sure that they are accessible. The only way I've ever been able to find them is by following links from messages in the xsl-editors list. It's not a big deal for me; I'll go with always=always. If you need it resolved, you might be best to write to the editors. Paul Grosso will probably respond quickly. Peter
DO NOT REPLY [Bug 39840] - Multi page table fails with an endless loop error message
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39840. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39840 --- Additional Comments From [EMAIL PROTECTED] 2006-06-22 14:18 --- 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. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: [GSoC] How the work should progress
Vincent Hennebert wrote: Hi all, I'd like to have the opinion from the team about how I should proceed. I'm currently at a point where I think I know enough, both from theoretical and code points of vue, to start the implementation of floats. By mimicing the handling of footnotes, I think I can have a working implementation rather quickly and easily. However, it wouldn't be very satisfying IMO. Some refactoring wouldn't be useless, and while I'm at it, why not doing it completely? Sounds reasonable so far. I've already spent much time figuring out how the code is working. From what I've seen, some areas of the code still look experimental. I think the implementation of floats may be an opportunity to bring it to a more polished level. A refactoring would have several benefits: - this may help sorting things out, and even prepare the implementation of a first-fit algorithm (although this might be a bit too much unrelated, I'm afraid) Jeremias mentioned the idea of different XSL-FO features requiring different implementations of the Knuth algorithm, specifically first-fit and total-fit. I get the impression though that they are usually mutually exclusive and we cannot have one bit of the code using first fit and another using total-fit. - this may help future contributors to easier understand this area of the code and get involved more quickly Always a good thing. - this is always better to have a clean design. Moreover, I think this is possible to make the implementation even more object-oriented, which would help sharing code between the line and page levels. This has always been a concern of mine. Although as I understand it there are some differences between the two. - a refactoring process is more efficient and secure if one has the opportunity to think full-time about it... I quite agree. If only I was a student again :) That's why I would propose to refactor the breaking algorithm. However, to do things properly I would need to understand a bit more of the code than just the breaking stuff. This may take some time, especially if I want to make sure that I don't introduce new errors. The implementation of side-floats may suffer from that. That was not the original intent of the SoC project, but I think this would be a benefit for Fop. WDYT? I think you need Jeremias's input here before proceeding further. He's going to be offline for about 10 days I think. Chris
DO NOT REPLY [Bug 39870] - Some content could not fit into a line/page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39870. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39870 --- Additional Comments From [EMAIL PROTECTED] 2006-06-22 19:00 --- Created an attachment (id=18509) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18509action=view) fo file -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 39870] New: - Some content could not fit into a line/page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39870. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39870 Summary: Some content could not fit into a line/page Product: Fop Version: 0.92 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: pdf AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] Hi, I got the following exception on producing pdf file. The error and the fo file will be provided below. Sorry it is too long but there is no way for me to attach them. Thank you very much, Hao Error: ERROR: 'Some content could not fit into a line/page after 50 attempts. Giving up to avoid an endless loop. (fo:block, location: 21/325)' javax.xml.transform.TransformerException: java.lang.RuntimeException: Some content could not fit into a line/page after 50 attempts. Giving up to avoid an endless loop. (fo:block, location: 21/325) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform (TransformerImpl.java:647) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform (TransformerImpl.java:279) at embedding.ExampleFO2PDF.convertFO2PDF(ExampleFO2PDF.java:88) at embedding.ExampleFO2PDF.main(ExampleFO2PDF.java:137) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) Caused by: java.lang.RuntimeException: Some content could not fit into a line/page after 50 attempts. Giving up to avoid an endless loop. (fo:block, location: 21/325) at org.apache.fop.layoutmgr.BreakingAlgorithm.findBreakingPoints (BreakingAlgorithm.java:434) at org.apache.fop.layoutmgr.BreakingAlgorithm.findBreakingPoints (BreakingAlgorithm.java:339) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout (AbstractBreaker.java:289) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout (AbstractBreaker.java:220) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout (PageSequenceLayoutManager.java:152) at org.apache.fop.area.AreaTreeHandler.endPageSequence (AreaTreeHandler.java:320) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:147) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement (FOTreeBuilder.java:357) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:193) at com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.endElement (ToXMLSAXHandler.java:262) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement (AbstractSAXParser.java:633) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanEndElement (XMLNSDocumentScannerImpl.java:719) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$Fragment ContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1685) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocu ment(XMLDocumentFragmentScannerImpl.java:368) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse (XML11Configuration.java:834) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse (XML11Configuration.java:764) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse (XMLParser.java:148) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse (AbstractSAXParser.java:1242) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity (TransformerImpl.java:557) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform (TransformerImpl.java:638) ... 8 more =The fo file=== ?xml version=1.0 encoding=UTF-8?fo:root xmlns:html=http://www.w3.org/1999/xhtml; xmlns:fo=http://www.w3.org/1999/XSL/Format; writing-mode=lr-tb hyphenate=false text-align=start role=html:htmlfo:layout-master- setfo:simple-page-master margin=25mm 25mm 25mm 25mm master- name=PageMaster-TOC page-height=8in page-width=11info:region-body margin=0mm 0mm 0mm 0mm//fo:simple-page-masterfo:simple-page-master page- width=auto page-height=auto master-name=all-pagesfo:region-body margin- top=1in margin-right=1in margin-bottom=1in margin-left=1in column- count=1 column-gap=12pt/fo:region-before region-name=page-header extent=1in display-align=before/fo:region-after region-name=page- footer extent=1in display-align=after/fo:region-start extent=1in/fo:region-end extent=1in//fo:simple-page-master/fo:layout-
DO NOT REPLY [Bug 39870] - Some content could not fit into a line/page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39870. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39870 --- Additional Comments From [EMAIL PROTECTED] 2006-06-22 19:00 --- Created an attachment (id=18508) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18508action=view) error message -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
