Bug report for Fop [2008/03/09]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 1063|New|Nor|2001-03-21|fop does not handle large fo files| | 3280|New|Nor|2001-08-27|PCL Renderer doesn't work | | 3824|New|Blk|2001-09-25|MIF option with tables| | 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S| | 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG | | 5010|New|Enh|2001-11-21|Better error reporting needed | | 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using | | 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output| | 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem| | 6997|New|Nor|2002-03-09|[PATCH] Row-spanned row data breaks over a page wi| | 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on| | 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images | | 8463|New|Nor|2002-04-24|SVG clipping in external.fo example doc when rende| | 8767|Ass|Min|2002-05-03|Image and solid colour background rectangle sizes | | 9379|New|Nor|2002-05-24|MIF Renderer generates incorrect MIF code | |10379|New|Enh|2002-07-01|Improvement to FOP Classloader| |12494|New|Nor|2002-09-10|fop produces pdf file which Acrobat Reader refuses| |12610|New|Enh|2002-09-13|[PATCH] onLoad Action for PDF documents or how to | |13586|New|Blk|2002-10-13|fop will not work on linux alpha because jre is br| |13734|New|Nor|2002-10-17|Hyphenation does not work correctly on long string| |14248|New|Enh|2002-11-05|51-page FO example, could be added to the samples | |14352|New|Enh|2002-11-07|It would be nice if FOP could be plugged into popu| |14356|New|Nor|2002-11-07|*NOT* embedding TrueTypeFont in PDF causes Acrobat| |14419|New|Enh|2002-11-10|Implement SourceResolver, Image Resolver | |14529|New|Nor|2002-11-13|SVG url references do not work| |14679|New|Enh|2002-11-19|Pluggable renderers | |14924|New|Nor|2002-11-28|Table disappears when it ends when the page ends | |15020|New|Enh|2002-12-03|Reuse of fo-tree | |16017|Opn|Nor|2003-01-13|Jpeg's and the PDF Serializer | |16130|New|Nor|2003-01-15|PS-Renderer emits lots of redundant moveto's | |16156|New|Nor|2003-01-16|0.20.5rc SVG example does not work| |16713|New|Nor|2003-02-03|Hyphenation error in tables | |17369|New|Nor|2003-02-25|Footnote duplication | |17380|New|Nor|2003-02-25|Batik Component will not recognize fe SVG elem| |17921|New|Nor|2003-03-12|Kerning is broken for standard fonts | |18292|New|Nor|2003-03-24|24 bit PNG not displayed correctly| |18801|New|Nor|2003-04-08|visibility property is not implemented | |19228|New|Blk|2003-04-22|[PATCH] Child LayoutContext is null in certain cir| |19341|Ver|Nor|2003-04-26|leader doesn't work since 0.20.5.rc2 | |19695|New|Enh|2003-05-06|[PATCH] Allow fox:destination as child of fox:outl| |19717|New|Enh|2003-05-07|Lets add support for JimiClassesPro.zip to build.x| |19769|Ass|Enh|2003-05-08|Indefinite page size is not implemented | |20280|Ass|Enh|2003-05-27|text-align and text-align-last only partially impl| |20407|New|Enh|2003-06-02|[PATCH] Configure image caching using the configur| |20827|New|Enh|2003-06-17|Derive other font styles and weights from normal T| |21265|Opn|Nor|2003-07-02|referencing a custom font (TTF or Adobe Type 1) fo| |21905|New|Nor|2003-07-26|large list-item-label bleeds into following block | |21982|New|Maj|2003-07-30|NullPointer Exception in LazyFont with embedded fo| |22450|New|Maj|2003-08-15|Unterminated iteration in JPEGReader class| |22627|Opn|Nor|2003-08-21|Update mirror/download page HEADER README (was [| |24148|New|Nor|2003-10-27|Kerning upsets text-align=end |
Re: inline and fo:list-block
Done now. But I didn't look at inline-container! On 07.03.2008 08:03:36 Jeremias Maerki wrote: Thanks for the feedback. I'll probably look into it during the weekend. On 06.03.2008 17:55:40 Andreas Delmelle wrote: On Mar 6, 2008, at 10:26, Jeremias Maerki wrote: Hi Jeremias First things first: Andreas, have you, by chance, started on this one already? I want to avoid that two people are working on the same problem. Not yet. In my experiments with fo:inline-container, I did stumble upon a similar problem, but there the BreakingAlgorithm actually chokes because the elements are still unresolved at the time the LineLM for the ancestor block wants to compute the break- possibilities. (ClassCastException in BreakingAlgorithm.getElement() because a BreakElement, for example, is not a KnuthElement) I'm not even sure how to get around this for inline-containers, so if you have an idea to fix it for inlines, then go right ahead. I've done some investigation here. It looks like fixing this leads to a somewhat bigger issue. But first things first: - The list-block (and tables and block-containers) don't get rendered because their Position objects don't return true on generatesAreas(). LineLayoutManager filters those in addAreas() because of that. Seems more correct to have this return true. - the mustKeepTogether() method in ListBlockLM must be adjusted like it was already done in BlockLM.mustKeepTogether(). The other LMs will need to be checked, too. That would fix the issue at hand but if I use a block-container inside an fo:inline I get an NPE because stackLimit in the LayoutContext is null. I then found out that stackLimit is used in both IP-direction and BP-direction. I think this would need to be split in two fields so the BP-direction value can be preserved so that block-level LMs which are children of an inline-level LM can restore the stackLimit value that was used by the last block-level LM in the stack. Good idea. I also noticed that the same stackLimit is used for both directions. By itself, this did not seem problematic as long as page- and line-breaking do not interact. Splitting up into a stackLimitBP and a stackLimitIP (or whatever names you had in mind) seems better in the long run. Cheers Andreas Jeremias Maerki Jeremias Maerki
Re: svn commit: r635508 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/layoutmgr/ src/java/org/apache/fop/layoutmgr/inline/ src/java/org/apache/fop/layoutmgr/list/ src/java/org/apache/fop/lay
Hi, Author: jeremias Date: Mon Mar 10 03:06:37 2008 New Revision: 635508 URL: http://svn.apache.org/viewvc?rev=635508view=rev Log: Fixed NPE in BlockContainerLayoutManager when used as a child of an inline-level FO. Split IP and BP stack limits in LayoutContext (there's now a certain amount of redundancy with refIPD in LayoutContext which I didn't resolve). Wouldn’t it make sense to re-use refIPD then? Or otherwise, add a TODO to the set/getRefIPD methods and possibly deprecate them? So that at least we know what should be used or not. Areas are now generated for block-level FOs when used as children of inline-level FOs. ClassCastException in ListLayoutManager.mustKeepTogether() fixed (occured if used as child of an inline-level FO). snip/ Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java?rev=635508r1=635507r2=635508view=diff == --- xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java (original) +++ xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java Mon Mar 10 03:06:37 2008 @@ -26,6 +26,7 @@ import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; + import org.apache.fop.area.Area; import org.apache.fop.area.LineArea; import org.apache.fop.area.Trait; @@ -583,7 +584,7 @@ // Set up constraints for inline level managers // IPD remaining in line -MinOptMax availIPD = context.getStackLimit(); +MinOptMax availIPD = context.getStackLimitIP(); This variable is used nowhere. Why not just remove it? Vincent -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
Re: svn commit: r635508 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/layoutmgr/ src/java/org/apache/fop/layoutmgr/inline/ src/java/org/apache/fop/layoutmgr/list/ src/java/org/apache/fop/lay
I didn't have time to do any fancy stuff. Feel free to improve. On 10.03.2008 13:17:53 Vincent Hennebert wrote: Hi, Author: jeremias Date: Mon Mar 10 03:06:37 2008 New Revision: 635508 URL: http://svn.apache.org/viewvc?rev=635508view=rev Log: Fixed NPE in BlockContainerLayoutManager when used as a child of an inline-level FO. Split IP and BP stack limits in LayoutContext (there's now a certain amount of redundancy with refIPD in LayoutContext which I didn't resolve). Wouldn’t it make sense to re-use refIPD then? Or otherwise, add a TODO to the set/getRefIPD methods and possibly deprecate them? So that at least we know what should be used or not. Areas are now generated for block-level FOs when used as children of inline-level FOs. ClassCastException in ListLayoutManager.mustKeepTogether() fixed (occured if used as child of an inline-level FO). snip/ Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java?rev=635508r1=635507r2=635508view=diff == --- xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java (original) +++ xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java Mon Mar 10 03:06:37 2008 @@ -26,6 +26,7 @@ import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; + import org.apache.fop.area.Area; import org.apache.fop.area.LineArea; import org.apache.fop.area.Trait; @@ -583,7 +584,7 @@ // Set up constraints for inline level managers // IPD remaining in line -MinOptMax availIPD = context.getStackLimit(); +MinOptMax availIPD = context.getStackLimitIP(); This variable is used nowhere. Why not just remove it? Vincent -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting Jeremias Maerki
fop 0.94 table-row keep-with-next bug
The fo below should only keep the rows together where it is specified and the totals row, but instead it keeps the entire table on one page. This is a test table, but I will have much larger tables that run over the page if they do not split after totals. As a second question, should sequential keep-with-next rows exceed the length of the page, how do I force a split instead of letting it run off the page? fo:table border-collapse=collapse table-layout=fixed width=100% border=1pt solid black font-family=Times Roman id=bkId1 fo:table-column column-width=40%/ fo:table-column column-width=40%/ fo:table-column column-width=20%/ fo:table-header fo:table-row keep-with-next=always fo:table-cell border=0.5pt solid black number-columns-spanned=3 fo:block font-weight=bold text-align=centerTop Exceptions/fo:block /fo:table-cell /fo:table-row fo:table-row keep-with-next=always fo:table-cell border-bottom=0.5pt solid black padding-left=3pt fo:block font-weight=bold text-align=leftCost Centre/fo:block /fo:table-cell fo:table-cell border-bottom=0.5pt solid black padding-left=3pt fo:block font-weight=bold text-align=leftDescription/fo:block /fo:table-cell fo:table-cell border-bottom=0.5pt solid black padding-left=3pt fo:block font-weight=bold text-align=leftExceptions/fo:block /fo:table-cell /fo:table-row /fo:table-header fo:table-body fo:table-row keep-with-next=always fo:table-cell padding-left=3pt fo:blockDIVISIONAL OFFICE/fo:block /fo:table-cell fo:table-cell padding-left=3pt fo:blockINACTIVE CARD/fo:block /fo:table-cell fo:table-cell padding-left=3pt fo:block3/fo:block /fo:table-cell /fo:table-row fo:table-row keep-with-next=always fo:table-cell padding-left=3pt fo:block/ /fo:table-cell fo:table-cell padding-left=3pt fo:blockNO FILL-UP ON THESE DAYS/fo:block /fo:table-cell fo:table-cell padding-left=3pt fo:block1/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell padding-left=3pt fo:block/ /fo:table-cell fo:table-cell padding-left=3pt fo:block text-align=right font-weight=boldTotal:/fo:block /fo:table-cell fo:table-cell padding-left=3pt fo:block font-weight=bold4/fo:block /fo:table-cell /fo:table-row fo:table-row keep-with-next=always fo:table-cell padding-left=3pt fo:blockCAR ALLOWANCE SCHEME/fo:block /fo:table-cell fo:table-cell padding-left=3pt fo:blockINACTIVE CARD/fo:block /fo:table-cell fo:table-cell padding-left=3pt fo:block3/fo:block /fo:table-cell /fo:table-row fo:table-row keep-with-next=always fo:table-cell padding-left=3pt fo:block/ /fo:table-cell fo:table-cell padding-left=3pt fo:blockNO FILL-UP ON THESE DAYS/fo:block /fo:table-cell fo:table-cell padding-left=3pt fo:block1/fo:block /fo:table-cell /fo:table-row fo:table-row keep-with-next=always fo:table-cell padding-left=3pt fo:block/ /fo:table-cell fo:table-cell padding-left=3pt fo:blockMULTIPLE TRANSACTIONS/fo:block /fo:table-cell fo:table-cell padding-left=3pt
Re: svn commit: r635508 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/layoutmgr/ src/java/org/apache/fop/layoutmgr/inline/ src/java/org/apache/fop/layoutmgr/list/ src/java/org/apache/fop/lay
Jeremias Maerki wrote: I didn't have time to do any fancy stuff. Feel free to improve. Sorry Jeremias, but I don’t buy that. I have many of my own things to take care of without spending time finishing the work of others. Adding a TODO in comments takes very little time and may be quite helpful to newcomers discovering the code. Eclipse tells you when a variable is not used, so unless you have a good reason to keep it that I may have missed, it makes good sense to just remove it. At some point we will have to stop just making things work, and start cleaning and refactoring. Otherwise we will end up having no other choice than rewriting the entire codebase from scratch once again. Vincent On 10.03.2008 13:17:53 Vincent Hennebert wrote: Hi, Author: jeremias Date: Mon Mar 10 03:06:37 2008 New Revision: 635508 URL: http://svn.apache.org/viewvc?rev=635508view=rev Log: Fixed NPE in BlockContainerLayoutManager when used as a child of an inline-level FO. Split IP and BP stack limits in LayoutContext (there's now a certain amount of redundancy with refIPD in LayoutContext which I didn't resolve). Wouldn’t it make sense to re-use refIPD then? Or otherwise, add a TODO to the set/getRefIPD methods and possibly deprecate them? So that at least we know what should be used or not. Areas are now generated for block-level FOs when used as children of inline-level FOs. ClassCastException in ListLayoutManager.mustKeepTogether() fixed (occured if used as child of an inline-level FO). snip/ Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java?rev=635508r1=635507r2=635508view=diff == --- xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java (original) +++ xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/LineLayoutManager.java Mon Mar 10 03:06:37 2008 @@ -26,6 +26,7 @@ import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; + import org.apache.fop.area.Area; import org.apache.fop.area.LineArea; import org.apache.fop.area.Trait; @@ -583,7 +584,7 @@ // Set up constraints for inline level managers // IPD remaining in line -MinOptMax availIPD = context.getStackLimit(); +MinOptMax availIPD = context.getStackLimitIP(); This variable is used nowhere. Why not just remove it? -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
DO NOT REPLY [Bug 44434] FO java Memory Error
https://issues.apache.org/bugzilla/show_bug.cgi?id=44434 --- Comment #3 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-03-10 11:22:37 PST --- (In reply to comment #2) I've increased the java heap size but still i'm getting memory error. I'm pasting the XML and fo file here. Please let me know what is the problem snip / fo:table-cell padding-top=3mm padding-left=1cm fo:block xsl:for-each select=benchmark xsl:for-each select=LINE fo:block xsl:value-of select=./ /fo:block /xsl:for-each /xsl:for-each Try: fo:table-cell... fo:block linefeed-treatment=preserve xsl:for-each select=benchmark xsl:for-each select=LINE xsl:value-of select=./ xsl:text#x0A;/xsl:text /xsl:for-each /xsl:for-each Please let us know if this alleviates the problem. I suspect so, but I'm not 100% certain. Thanks! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 44434] FO java Memory Error
https://issues.apache.org/bugzilla/show_bug.cgi?id=44434 --- Comment #4 from Yoganathan Kaliyaperumal [EMAIL PROTECTED] 2008-03-10 11:41:12 PST --- Your solution didn't give any memory error. Thank you so much. But all the records in 3rd column are wrapped in single line as follows: column1 column2 column3 comp1comp1 strat From: 30/09/1990 Standard Poor's 500 Index But i want the record to be displayed in multi-line as below. column1 column2 column3 comp1 comp1 strat From: 30/09/1990 Standard Poor's 500 Index Can you suggest something which can display the records in multi-line. Thanks, Nathan -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 44434] FO java Memory Error
https://issues.apache.org/bugzilla/show_bug.cgi?id=44434 --- Comment #5 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-03-10 11:51:28 PST --- (In reply to comment #4) Your solution didn't give any memory error. Thank you so much. But all the records in 3rd column are wrapped in single line as follows: column1 column2 column3 comp1comp1 strat From: 30/09/1990 Standard Poor's 500 Index But i want the record to be displayed in multi-line as below. column1 column2 column3 comp1 comp1 strat From: 30/09/1990 Standard Poor's 500 Index Can you suggest something which can display the records in multi-line. That's what the linefeed character (#x0A;) is for. That should work, unless... Do you have a keep-together or keep-with-next/-previous specified on the rows or the table. In that case, you probably want to change this to an explicit keep-together.within-page, keep-with-previous.within-page. If the component 'within-page' is not explicitly used, then keep-together also means keep-together.within-line, which overrides preserved linefeeds. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 44434] FO java Memory Error
https://issues.apache.org/bugzilla/show_bug.cgi?id=44434 --- Comment #6 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-03-10 11:54:10 PST --- (In reply to comment #5) That's what the linefeed character (#x0A;) is for. That should work, unless... Just noticed that I did not yet ask: which FOP version? linefeed-treatment=preserve does not work in FOP 0.20.5. In case you're still using that version, it's time to upgrade... -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 44434] FO java Memory Error
https://issues.apache.org/bugzilla/show_bug.cgi?id=44434 --- Comment #7 from Yoganathan Kaliyaperumal [EMAIL PROTECTED] 2008-03-10 11:56:10 PST --- I'm using FOP 0.14 version fo xalan commandline. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
