Bug report for Fop [2006/09/17]
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) |
| | +-+
| | | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| | | MIN=Minor NOR=Normal ENH=Enhancement |
| | | +-+
| | | | Date Posted |
| | | | +--+
| | | | | Description |
| | | | | |
| 953|Opn|Nor|2001-03-12|Incorrect hyperlinks area rendering in justified t|
| 1063|New|Nor|2001-03-21|fop does not handle large fo files|
| 1180|New|Maj|2001-04-02|Problem with monospaced font |
| 1773|Opn|Blk|2001-05-16|A table that is bigger than the page produces an e|
| 1859|Opn|Min|2001-05-22|org.apache.fop.apps.Driver.reset() doesn't fully r|
| 1998|New|Nor|2001-06-05|linefeed-treatment not understood |
| 2150|Ass|Maj|2001-06-13|New page with a table-header but without any tabl|
| 2475|Ass|Nor|2001-07-06|Borders don't appear to work in fo:table-row|
| 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly |
| 2909|New|Maj|2001-07-30|Gradient render error |
| 2964|Ass|Nor|2001-08-02|problems with height of cells in tables |
| 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-|
| 3044|Ass|Maj|2001-08-08|keep-together not functioning |
| 3280|New|Nor|2001-08-27|PCL Renderer doesn't work |
| 3305|Opn|Nor|2001-08-28|list-block overlapping footnote body |
| 3497|New|Cri|2001-09-07|id already exists error when using span=all attr|
| 3824|New|Blk|2001-09-25|MIF option with tables|
| 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S|
| 4126|New|Nor|2001-10-12|FontState.width() returns pts instead of millipts |
| 4226|New|Nor|2001-10-17|The orphans property doesn't seem to work |
| 4388|New|Nor|2001-10-24|Nullpointer exception in the construction of new D|
| 4415|New|Nor|2001-10-25|scaling=uniform does not work on images... |
| 4510|New|Nor|2001-10-30|fo:inline common properties ignored? |
| 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG |
| 4767|New|Nor|2001-11-09|SVG text is distored in PDF output|
| 4814|Opn|Nor|2001-11-12|0.20.2RC infinitely loops if there are tables in f|
| 5001|New|Nor|2001-11-21|content-width and content-height ignored? |
| 5010|New|Enh|2001-11-21|Better error reporting needed |
| 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using |
| 5335|New|Min|2001-12-10|Text with embedded CID fonts not retrievable from |
| 5655|Ass|Nor|2002-01-02|text-decoration cannot take multiple values |
| 6094|Opn|Maj|2002-01-29|0.20.3rc hangs in endless loop|
| 6237|Opn|Nor|2002-02-05|#xFB01 (fi ligature) produces a sharp? |
| 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|
| 6437|New|Maj|2002-02-13|Tables without fo:table-column don't render |
| 6483|New|Nor|2002-02-15|Table, Loop, footer could not fit on page, moving|
| 6844|New|Nor|2002-03-04|No line breaks inserted in list-item-label|
| 6918|New|Enh|2002-03-06|reference-orientation has no effect |
| 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|
| 7283|New|Nor|2002-03-20|Table border misaligned when using margin-left in |
| 7337|New|Nor|2002-03-21|border around external image leaves empty space |
| 7487|New|Nor|2002-03-26|break-before=page for table inserts empty page |
| 7496|New|Nor|2002-03-26|The table header borders are not adjusted to the b|
| 7525|New|Cri|2002-03-27|table with spans inside a list-block |
| 7919|New|Cri|2002-04-10|problem to use attribute linefeed-treatment and li|
| 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images |
| 8050|New|Nor|2002-04-13|Soft hyphen (shy;) is not handled properly |
| 8321|New|Nor|2002-04-19|from-parent('width') returns 0 for nested tables |
| 8463|New|Nor|2002-04-24|SVG clipping in external.fo example doc when rende|
|
DO NOT REPLY [Bug 40519] - While generating output as image/tiff it is only possible to use PackBits compression.
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=40519. 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=40519 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED]|fop- ||[EMAIL PROTECTED] Status|ASSIGNED|NEW -- 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 40519] - While generating output as image/tiff it is only possible to use PackBits compression.
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=40519. 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=40519 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2006-09-18 08:56 --- Patch applied with modifications. Thanks Oliver! http://svn.apache.org/viewvc?view=revrev=447325 You'll see from the change that I've solved the multi-page problem with the ImageWriter. Please test and send feedback if it works for you, too. I'll write some docs about it in the meantime. -- 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 40519] - While generating output as image/tiff it is only possible to use PackBits compression.
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=40519. 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=40519 --- Additional Comments From [EMAIL PROTECTED] 2006-09-18 12:14 --- (In reply to comment #4) Against what branch of FOP did you do the patch? I can't apply it and it's really weird because your patch tries to change the license header which has been done long ago. It's important to do an svn up before creating the patch. And you should make sure you're producing the patch from FOP Trunk. I'll try to port your changes manually from your patch. But if you can supply updated patches against the latest FOP Trunk that would help. Sorry, but I had a lot of problems with a proxy and couldn't do an update. I did a visual comparation to the source from web and it seemed to me that I had the same source, but it was old. sorry, today I've solved the problem but i see you did the update manually. Thanks! -- 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 40519] - While generating output as image/tiff it is only possible to use PackBits compression.
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=40519. 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=40519 --- Additional Comments From [EMAIL PROTECTED] 2006-09-18 13:25 --- (In reply to comment #7) You're wellcome! I've just tried your patch and it works ok for me after some tests. Thanks for your improvements, your help and for dedicating your time to this issue. I'll keep on testing tomorrow and I'll give more feedback. -- 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: Committing again..
Bertrand, On Fri, Sep 15, 2006 at 01:32:32PM +0200, Bertrand Delacretaz wrote: I hope it's ok if I commit my work on OpenType fonts directly - I haven't committed anything here for a looong time, but still have commit rights. FOP does not give up on its old lovers. And here you are again. :) I'll do my best not to break anything, and also to include automated tests for my changes. Why don't you start a branch? That gives you more room for experimenting. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: [Xmlgraphics-fop Wiki] Update of PageLayout/PageAndLineBreaking by SimonPepping
Vincent, Thanks for your reaction. On Tue, Sep 12, 2006 at 08:26:49PM +0200, Vincent Hennebert wrote: According to that representation paragraphs with inline text have legal linebreak points. I consider those legal linebreak points also as legal pagebreak points. In addition, there are legal pagebreak points between the vertical elements such as paragraphs and blocks. One issue that will have to be addressed is that widow or keep-with-previous settings may invalidate some previously believed legal breakpoints. In such cases, active nodes which contain those breakpoints in their chains will have to be deactivated; if they were the chosen best nodes, some other nodes will somehow have to be retrieved to replace them. I hope this won't be a too great difficulty. Indeed, you mentioned it before. It certainly is a complicating factor. In page independent linebreaking, for each feasible breakpoint the best node is retained, which represents the best layout of the paragraph up to that point, and which, due to the dynamic principle, is part of the best layout of the whole paragraph if that layout uses this breakpoint. If line numbers matter, the best node for each line number is retained. In page dependent linebreaking, even that is not enough. We must retain the best node for each vertical offset on the page, because that is the quantity that influences page breaking. This Good point. This led me to the following thoughts: Currently the iteration over the active nodes is broken into two loops: one loop for iterating over the line numbers, one for iterating over the active nodes associated to each line number. Why? Because if line widths aren't the same they have an influence on the computation of best line breaks. Because when considering a given legal breakpoint, we must know the width of the line it would end in order to be able to compute the shrinking/stretching for that line. In fact we make a distinction between line numbers because they determine the /context/ in which linebreaks are computed. If all the lines had the same widths such a distinction wouldn't be necessary. The merging of line- and page-breakings generalizes this problem of differing contexts. This time, not only the line number counts, but also the page number, the offset from the beginning of the page, the out-of-lines to be placed, etc. I think the greatest challenge will be to identify all the elements which determine that context, and to be able to compare two contexts and say if they are equivalent or not. Considering the case 1 you describe on the wiki page, there are only two different contexts: page number even or odd. In this case the offset from the beginning of the page doesn't count. In other more complex documents this may be much more complicated. Yeah, difficult point. I do not think I understand this aspect well enough. In most cases the whole paragraph will fit on the page, and the legal pagebreak point after it is not feasible. So we do another paragraph, and another. Finally we will reach a feasible pagebreak point, which ends page 1. The corresponding linebreak point ends a line which is able to fill the page height with maximally tolerable stretching. In the next steps we will find more feasible pagebreak points. They correspond to different layouts of the last paragraph that starts on this page, with the same number of lines, and to layouts with more lines, which also fit on the page, until the maximal shrink is exceeded. At this point the starting node is deactivated, and the active page node list only contains nodes that end page 2. Unless I've missed something: that end page *1*. Or? Yes. Thanks. It should be noted that for each feasible pagebreak node, we restart the linebreaking calculations of that page. Of course we must optimize this. We could attach a data structure to the starting page node which records the results of the calculations done. Those results consist of the active line node list, the last linebreak point considered, and the widths calculated up to that point. During uninterrupted linebreak calculation these data are held in loop variables. Now we must store them so that they can be retrieved when we resume the calculation in the consideration of the next current pagebreak point. On the first If the main loop were iterating over line breaks, we wouldn't have to do this. But perhaps we would have to for pagebreaks then? Which would be equivalent, but I can't figure out yet. I have not thought about the problem in this way. It seems unnatural to me and also rather equivalent. I will update the wiki page as soon as I can reach it again. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu
