Bug report for Fop [2008/10/19]
+---+ | 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: [PATCH] Freeing area tree memory
Il giorno 14/ott/08, alle ore 00:15, Dario Laera ha scritto: If I understood correctly, the parentArea of a LM instance points to a new area each time it's called to create areas for a new page: a table that spans in 10 pages will point to 10 areas in the instance life time. So freeing parentArea shouldn't be a problem. The LMs I free are the LineLM (and, obviously, relative children): by definition, they shouldn't span in many pages. Am I correct? I realized I was wrong... I've attached a new patch that deals only with parent area and doesn't free any LM. This patch adds also an implements Serializable in a class that gets cached with the area tree, and adds a command line flag to enable caching. The changes in this patch are not always necessary, but in many cases can saves lots of memory. Dario freeAreaTree2.diff Description: Binary data
Re: Tables in Prototype
I’ve just put the documentation under version control: http://svn.apache.org/viewvc?view=revrevision=706297 so that it’s easy to track changes. Vincent Vincent Hennebert wrote: Hi All, I realize that I haven’t given any news about my prototype for quite a while now. This is not entirely due to holidays, unfortunately... Mixing line- and page-level breaking in paragraphs appeared to be the easy part. Even if I brought major refactorings to the code since I started working on it, at least I could come up with something basically working. Regarding tables, however, I haven’t really managed to find a satisfying solution yet. I did manage to implement a dirty hack in the prototype, but it doesn’t even merge columns properly. All I can think of is either too complex, too slow, too awkward, or even wrong. That said, I have the gut feeling that I’m not far from the solution. So I thought it was time for writing some documentation, and ask the community for feedback. Having different brains look at it from their own perspectives may help coming to a solution. At any rate, just writing doc helps me clarify my ideas in my own head, so it’s not wasted time. You will find a presentation of the problem here: http://people.apache.org/~vhennebert/prototype/ A pdf version is available for those who are allergic to screen-reading: http://people.apache.org/~vhennebert/prototype/prototype.pdf There’s more to come, obviously. Comments will be very welcome; given that it’s often the most naive and stupid question that leads to the solution, please don’t feel shy ;-) Thanks, Vincent
DO NOT REPLY [Bug 45956] leader-pattern=rule not rendered in pcl
https://issues.apache.org/bugzilla/show_bug.cgi?id=45956 Jeremias Maerki [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement Status|NEW |ASSIGNED --- Comment #3 from Jeremias Maerki [EMAIL PROTECTED] 2008-10-20 08:13:48 PST --- I've just added minimal support for this in FOP Trunk: http://svn.apache.org/viewvc?rev=706319view=rev I will do a more complete implementation as part of the new intermediate format work. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re:
As much as it hurts to admit it (being a FOP developer), Antenna House is right, I believe. The section in the spec that defines the layering is this: http://www.w3.org/TR/xsl11/#rend-layer I guess that slipped through the cracks and we'll need to see to it that this gets fixed. Thanks for bringing this up. On 20.10.2008 12:20:53 Tacio Naja Domingos wrote: I am running the below peace of code in both Fop 0.94 and Antenna house formatter, but get a rather different behaviour. I was hoping someone could point out which implementation is correct by directing me to the correct sentence in the FO spec. In Fop the table border is drawn below the block-container. In Antenna house formatter, the table-cell border is above the block-container but the table-cell contents are below the block-container. The code is: fo:table width=5cm table-layout=fixed fo:table-body fo:table-row fo:table-cell border-style=solid border-color=black border-width=1pt fo:block color=red background-color=yellowBelow fo:block-container absolute-position=absolute top=0.15cm left=0.25cm fo:block text-align=left fo:inline background-color=grey keep-together=alwaysAbove/fo:inline /fo:block /fo:block-container /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table Thanks for your help in advance. Tacio Jeremias Maerki
Re: Fixing marks layering
Hmm, it doesn't look like an 5-minute fix since we have stuff like drawBackAndBorders(). This will need to be taken apart into drawBackground() and drawBorders(). Similarly, handle*Traits() methods need to be split. And then lots of testing. I don't think we need to care about breaking external renderers in this case, since we're clearly talking about a bug here. I believe that someone who maintains a private renderer will be interested to fix that problem, too. If there's a reason for not breaking compatibility, please speak up ASAP. Since I'm working in the renderer area anyway (with the new intermediate format), I'll volunteer to fix this. On 20.10.2008 19:09:14 Jeremias Maerki wrote: As much as it hurts to admit it (being a FOP developer), Antenna House is right, I believe. The section in the spec that defines the layering is this: http://www.w3.org/TR/xsl11/#rend-layer I guess that slipped through the cracks and we'll need to see to it that this gets fixed. Thanks for bringing this up. On 20.10.2008 12:20:53 Tacio Naja Domingos wrote: I am running the below peace of code in both Fop 0.94 and Antenna house formatter, but get a rather different behaviour. I was hoping someone could point out which implementation is correct by directing me to the correct sentence in the FO spec. In Fop the table border is drawn below the block-container. In Antenna house formatter, the table-cell border is above the block-container but the table-cell contents are below the block-container. The code is: fo:table width=5cm table-layout=fixed fo:table-body fo:table-row fo:table-cell border-style=solid border-color=black border-width=1pt fo:block color=red background-color=yellowBelow fo:block-container absolute-position=absolute top=0.15cm left=0.25cm fo:block text-align=left fo:inline background-color=grey keep-together=alwaysAbove/fo:inline /fo:block /fo:block-container /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table Thanks for your help in advance. Tacio Jeremias Maerki Jeremias Maerki
